5 ms·

AWS is hard to use because it maximizing ROI for Amazon. If it was profitable to make it easy to use they'd make it easy to use. Good tool though.

nathants 4y ago
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.
ttfkam 4y ago
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.
- nathants 4y ago
  extremely well said. bravo. 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.
  - nathants 4y ago
    to be fair, deeply understanding the aws primitives, their apis, and their relationships, is a lot more work than slapping together some cf json. while i enjoy it, and value the experience of it, i realize not everyone feels the same or has the time. this is fine, and why cf exists.
  - ttfkam 4y ago
    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!" https://youtu.be/1ps0Wh19MHQ https://youtu.be/1ps0Wh19MHQ
    - nathants 4y ago
      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.

nathants 4y ago

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.

ttfkam 4y ago

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.

nathants 4y ago
extremely well said. bravo. 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.
- nathants 4y ago
  to be fair, deeply understanding the aws primitives, their apis, and their relationships, is a lot more work than slapping together some cf json. while i enjoy it, and value the experience of it, i realize not everyone feels the same or has the time. this is fine, and why cf exists.
- ttfkam 4y ago
  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!" https://youtu.be/1ps0Wh19MHQ https://youtu.be/1ps0Wh19MHQ
  - nathants 4y ago
    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.