The more languages you learn, the more you realize they have more in common than not. At some point it’s time to stop learning 20+ languages and start building stuff. I never said to stop learning, but be very careful what you spend your time learning. If you can be world class at Python alone, able to solve just about any problem with it, it’s better than 100% knowing many languages. Knowing a language doesn’t mean you know all of the standard libraries and third party libraries, much less solve challenging problems efficiently.
Learn shell, a scripting language like Python, and a systems language like Java, C, Rust, Go, etc. I think that’s all you need to know as a backend or systems/DevOps Engineer.
I learned many languages for years and I received a poor return on time investment. Later, I started learning AWS in depth and studying for certs. I now know way more than I previously did about networking, envelope encryption, messaging, infrastructure as code, pipelines, caching, CDN’s, networking protocols, load balancers, dns, and designing highly available and scalable systems. In summary, don’t forgo learning about systems to chase a hot new language.
Exactly. You can deploy a highly available, auto scaled, logging enabled, spot instance or Fargate multi-service ECS reference architecture here by deploying a “one click” cloudformation stack: https://github.com/aws-samples/ecs-refarch-cloudformation/bl...
AWS certification exams test for basic and foundational AWS knowledge. They don’t try to do anything other than that. The “whys” are learned in the field, certified or not.
The best I’ve ever had never went to college. I was extremely productive under this person because there was a high level of trust and ownership. This was at a company whose CEO also didn’t finish his undergrad at Yale. Prior to this company I worked as an engineer at Google and had some launch/promo obsessed managers who lacked basic management skills.
No, startups in Silicon Valley are starting to look at these certs because they realize how expensive poorly configured cloud infrastructure can be. It’s a skill that few people have at this point.
More employers than you would think. The professional certs are legit. Also, 50% of some cloud native DevOps and infrastructure engineering roles are covered by the pro certs.
True, it doesn’t always take a NDE, but I think it does require a certain amount of hardship and/or trauma. People need to be pushed into a corner to find out who they really are. They need to be truly alone, and often not by choice.
There isn’t sufficient separation between components within Kubernetes for ease of migrating piece by piece away from kubernetes. Documentation also plays an important role in migrations. I once counted the pages of documentation for Kubernetes vs AWS for equivalent functionality (VPC, ECS, Route53, etc) and AWS had 20 pages for every page of Kubernetes.
I think we can agree that Kubernetes does far more than schedule containers, even if “at its core” that’s what it does. How many lines of the 2e6 lines of code k8s project are directly related to scheduling containers? Very few. If a scheduler is all that is needed and you want to use any of the 3 different types of load balancers provided by AWS, a simpler architecture might be just to use AWS ECS. 500 lines of declarative Cloudformation or Terraform will do the job.
You are more likely to get locked in with kubernetes than with AWS. It’s easier to migrate out of highly decoupled, well documented systems piece by piece (AWS) than out of monolithic frameworks like k8s.
LOC is a very very bad metric. How exactly is it counted? Include mass refactoring? Is there a better metric? Yes, a long list of testimonials from happy customers.
good point. That’s great if the SDK for the language you are using has a utility for autocomplete and the terminal or IDE you are using has that utility installed, which may not always be the case.
I know this is a joke, but I’m glad this person wasn’t in charge of naming these services. Amazon’s concise and consistent names often translate directly to API calls, making it possible to guess CLI methods.
Exactly. Stack imports/exports was launched to address the shortcomings of nested stacks. Avoid using nested stacks in favor of stack imports/exports. Actually, avoid both nested stacks and stack imports/exports in favor of SSM parameters.
200 resources is way way too many for a single template. Split up your API Gateway API resources, methods, and models into multiple stacks. One stack for the API, another group of stacks for the API resources, methods, models, and another stack for your API deployments.
Lines of code is irrelevant when you are in the middle of a production deploy and you just want the highest visibility into what is going on. In cloudformation, there are only two possible places for resource state: 1) The actual resource state in AWS and 2) The desired state stored in CloudFormation.
Then choosing where and how to store state using Terraform becomes another point of possible inconsistency in your infrastructure and thing to worry about. In CloudFormation, the state is coupled with the service, and you don't have to worry about it. It just works.
The AWS CLI for CF is simple and consistent with other AWS CLI's. You can also use one of the language specific SDK's such as boto3 or use AWS CodePipeline to create/update stacks.
Totally agree. I don’t care how much less verbose terraform may be (this claim is questionable IMHO). The most important part of infrastructure engineering is being able to debug and fix things quickly by isolating issues to the smallest possible domain. The additional layer of highly unstable terraform source code does not decrease the debugging surface area.