AWS is hard by design. This created a cottage industry of consultants that further push AWS into enterprises and basically create a form of job security.
I think there's an ongoing notion that all things somehow suppose to be easy, even trivial. AWS enables running very complex system and caters to a wide spectrum of users,so it can't be one fits all solution with button to click. The same can be said about virtually anything from Java to Linux administration.
aws absolutely should be easy, and needn’t sacrifice any capability to do so.
i can choose to use none of apigateway but wiring up a domain to a lambda. i haven’t removed any of its other functionality, i’ve just chosen not to use it.
it will always be there, if i change my mind. one of the best reasons to use aws is that all those extra knobs are there, just waiting for you, if you need them.
trying to fiddle with all the knobs immediately is usually where the problems start, and the fun dies.
aws should be easy. maybe later, if it’s worth it, it can be hard.
i disagree. i believe that aws is hard because it provides the feature set that is the union of the needs of all customers, and that the customers are massive company inc.
inside of that bloated feature set, there exists an essential core of primitives, operated by the best sre the world has seen.
i believe this core should be easy to use, and fun too.
With the CDK and solutions constructs, AWS is much simpler if not outright easy. Apparently this was profitable for them. It was also sufficiently easier that its being used extensively inside Amazon itself for development. (Yes, most folks dislike CloudFormation.)
For what it's worth, I cannot fathom how competitors like Azure or Google Cloud could be seen as simpler for non-trivial stacks. DigitalOcean and its ilk aren't even competitors; they are made for simplifying what AWS used to be 10 years ago. (That's not a bad thing, just recognize it for what it is.)
For a lot of folks (myself included), the hardest part was mapping the concept to the product name in my head, eg. DNS is Route53, file storage is S3, relational database is RDS, auth is Cognito, queues are SQS, Redis/Memcached are ElastiCache, etc. There's very little in AWS that doesn't map directly to a well-known concept in software architecture.
If your context for an app is some autoscaling VMs (or dedicated server) serving a REST API with a relational database backing it, you're probably not the target audience.
That said, if you have a small site with meager database query requirements, DynamoDB (less that 20GB) + Lambda + API Gateway are basically free for less that a million requests per month. Hell, RDS is free for the first year. A statically generated site on S3 might be an even better option.
If you want/need queues, push notifiers, advanced DNS management with certs, flexibility with serverless constructs, machine learning engines, relational databases with automatically rotating creds instead of fixed passwords, analytics engines, an essentially infinitely scalable key-value store, flexible secrets management, stack change auditing, content delivery network, integrated CI/CD infrastructure, comprehensive authz at the app, dev, and ops levels, etc., you've graduated well last what a few VMs and a Postgres instance can do.
That's what AWS is for and what it currently does way better than anyone else. If that's not what you need right now, that's fine. But unless you're at Facebook or Google scale where provisioning, tooling, and staffing this yourself is doable, AWS (and to a lesser extent Azure and GCloud) are where you want to be.
(Shout out to Google Cloud for their Spanner database. Simply amazing. I just wish the rest of their cloud tools were similarly amazing.)
AWS is where folks go when the solution to their problems isn't a clear cookie cutter but in that vast expanse where "it depends" rules.
i don’t enjoy cdk/cf, and want to explore further, but i’m glad cf exists.
if i were to use one of the big 4 iac, it would be cf. it’s not that much worse than the others, and it’s documented and used in the exact same way as the api primitives.
I hate writing/editing/maintaining CloudFormation templates. Hate them in yaml. Hate them in json. Hate the ambiguity. Hate "debugging" them (which of course I mean try to deploy and fix problems that pop up one at a time).
And while I realize CDK mostly just synthesizes down to CF, it was honestly a breath of fresh air in the world of IaC.
"Oh! You want IaC that can also build/test all of your lambdas, containers, and VMs in a monorepo, generate the policies you need, and set up CI/CD pipelines that cross account boundaries without much fuss? Welcome to CDK World!"
cdk is for great good, and i’m glad it’s putting the spring back in your step! a rising tide raises all ships. i can’t wait until i’m embarrassed by how slow and annoying my aws sdlc is compared to sota. then i’ll have to do better. embarrassment driven development.
