Yeah the author is broadly talking about the difference between IaaS vs PaaS where in the latter the vendor is also your DevOps team. The cost being a more opinionated setup you have less control over.
A trade worth making oftentimes but it doesn't make the complexity go away.
AWS is built for production. It’s complex because it’s designed to create robust environments that can scale almost infinitely, that’s why half of the internet runs on AWS. But to make the most of it, you need to understand how it works and why it’s built that way. That’s why being an “AWS expert” is practically a job description on its own, thats why cloud engineering teams exists, platforms, SRE, etc.
For quick and dirty app deployments, though, other vendors like Heroku probably do a better job.
I think the larger reason being an "AWS expert" is a job description is lock in. If you've hired people who have spent years grokking the AWS names, terminology, and options then your likelihood of switching to anything else is much lower.
Not that AWS doesn't also enable scaling or something, it just (conveniently) doesn't give an option to deploy anything but scalable services you'll train your staff on. A lot of the time AWS interfaces/offerings are copied not because they were ideal, but because it's an easier way to break past that barrier with your offering.
And that’s true if you base your tech stack on VMWare, colo’s, GCP, Azure, etc.
No one can be an expert on everything. Even if you base your expertise on Kubernetes, someone still needs to know the underlying cloud infrastructure. Kubernetes is just an abstraction that maps to underlying infrastructure.
AWS Amplify was supposed to solve this. It is built on the AWS CDK. But I found it too clunky and slow and gave up on it.
These days I use SST (https://sst.dev) which is built on top of Pulumi. I find this to be a manageable infrastructure-as-code solution for AWS deployments.
Life is easy when you don't want to think about scale or security. Until you have to, that is.
Yeah the author is broadly talking about the difference between IaaS vs PaaS where in the latter the vendor is also your DevOps team. The cost being a more opinionated setup you have less control over.
A trade worth making oftentimes but it doesn't make the complexity go away.
AWS is built for production. It’s complex because it’s designed to create robust environments that can scale almost infinitely, that’s why half of the internet runs on AWS. But to make the most of it, you need to understand how it works and why it’s built that way. That’s why being an “AWS expert” is practically a job description on its own, thats why cloud engineering teams exists, platforms, SRE, etc.
For quick and dirty app deployments, though, other vendors like Heroku probably do a better job.
I think the larger reason being an "AWS expert" is a job description is lock in. If you've hired people who have spent years grokking the AWS names, terminology, and options then your likelihood of switching to anything else is much lower.
Not that AWS doesn't also enable scaling or something, it just (conveniently) doesn't give an option to deploy anything but scalable services you'll train your staff on. A lot of the time AWS interfaces/offerings are copied not because they were ideal, but because it's an easier way to break past that barrier with your offering.
And that’s true if you base your tech stack on VMWare, colo’s, GCP, Azure, etc.
No one can be an expert on everything. Even if you base your expertise on Kubernetes, someone still needs to know the underlying cloud infrastructure. Kubernetes is just an abstraction that maps to underlying infrastructure.
AWS doesn't want to avoid details, they want to wallow in them.
Technology advances by increasing the number of things a person can achieve without thinking about them. AWS has lots of room for advancement.
AWS Amplify was supposed to solve this. It is built on the AWS CDK. But I found it too clunky and slow and gave up on it.
These days I use SST (https://sst.dev) which is built on top of Pulumi. I find this to be a manageable infrastructure-as-code solution for AWS deployments.
AWS Amplify does far too many abstractions and it keeps you on the rails. It’s like AWS Beanstalk