5 ms·

AWS has a great business model of people over "optimizing" their architecture using new toys from amazon and being charged through the nose for it. It's amazing

AWS has a great business model of people over "optimizing" their architecture using new toys from amazon and being charged through the nose for it. It's amazing how clients that are doing a few requests per second will want a fully distributed, serverless, microservice + dynamodb + s3 + athena + etc + etc, in order to serve a semi-static web app and print some reports off throughout the day and pay 10-50k a month when the entire thing could run on a few nodes and even a managed RDS instance for a thousand bucks a month. I would argue at this point that early optimization of architecture is astronomically worse than even* your co-worker that keeps turning all of your non-critical, low-volume iterable functions into lanes to utilize SIMD instructions. Some irony in my anecdotal experiences is that most places that don't have the traffic to justify the cost of these super distributed service architectures also see a performance penalty from introducing network calls and marshaling costs

abluecloud 3y ago
It's honestly like a cult and a desire to want to "do it right" on AWS. The last few projects I've spent so much time setting up code deploy, load balancers, certificates, SES, route 53... This newest project, I've gone to heroku with everything being basically a few clicks to get setup.
- boredumb 3y ago
  It seems like another case of the road to hell being paved with good intentions, most places want/need redundancy and some managed devops and so a few ec2 instances and managed RDS is affordable enough and checks a lot of boxes, but after people start down this path it seems almost irresistible to start drilling down into managed kubernetes, spark jobs, to start ingesting some events we'll just introduce glue, and that plugs right into S3, and look how easy it is to plug in athena, add some quick alerting with cloudwatch, and the next thing you know you're vendor locked and having to hire a full time devops person with AWS experience to configure, manage and keep on top of it all.
- steveBK123 3y ago
  So guys we need Lambdas + Step Functions + SES + SQS + SNS + MSK + AWS Batch + S3 + Lakeformation + Cloudformation + Athena + EMR + Redshift + Aurora + SageMaker + Cloudtrail + Codepipeline + maybe some EC2s to run AWS CLI on them. Don't forget to configure Route53, VPC, IAM and an ELB. Great - ready to start writing your app now? Oh wow one of those components as configured with the other components isn't behaving as expected - time to contact AWS support! Cynically I think CTOs see all this stuff and think they'll turn all their expensive on-shore devs into cheaper DevOps because AWS is magic and you don't need to write hard app code anymore. I'd counter that AWS forces expensive on-shore devs into having to wear an entire new hat and be half a DevOps engineer to figure out how to make their code work on this alphabet soup instead of a Linux server.
lars512 3y ago
Tons of the pieces you mentioned are probably not that expensive to run for a small use case, given you're only charged on demand. The cost is really in the dev ops time and expertise to orchestrate the whole affair, and in the new ways it can break.
lastangryman 3y ago
> AWS has a great business model of people over "optimizing" their architecture using new toys from amazon and being charged through the nose for it I was back on AWS for the first time in a few years this week and the amount of new "upsell" prompts in the console is ridiculous. Spin up an RDS instance - "hey, would you like an Elasticache cluster too?". I think AWS are very aware of this behaviour and encourage it. Simplicity is not in their interest.
- coffeebeqn 3y ago
  I mean that’s upselling 101.
steveBK123 3y ago
Yes, and it attracts just the wrong kind of dev/architects. At a previous shop, we hired a cloud architect to drive our "cloud adoption". He of course bet the farm on a set of new AWS services that were barely in version v0.9 to be the backbone of the system he architected. It quickly became clear even he had no experience with the set of tools & services he had advocated, and the whole thing went off the rails slowly & surely. Low & behold 100% of existing customers are still on the on-prem offering 2 years later, and if you throw in the new customers that were shoehorned onto the AWS offering, his team has captured 2% of customer use after 2 years of effort.
- baobabKoodaa 3y ago
  But it's fun to play around with new toys!
andai 3y ago
I haven't dealt with high traffic systems but isn't a few requests per second well within the capabilities of a $5 VPS?
- harrisi 3y ago
  There was a blog post and discussion here about this a few months ago: https://news.ycombinator.com/item?id=34676186 https://news.ycombinator.com/item?id=34676186
- NohatCoder 3y ago
  A $5 instance gets you something like 1 core on a slightly dated CPU. Aka approximately as much processing power as a top of the line desktop processor 15 years ago. Aka enough processing power to fill a 25 Gb/s port with TLS data (not that you have the port to go with that). A few requests per millisecond should be well within the capabilities of this instance, depending on the complexity of each request of course.
andersa 3y ago
It is even more amazing when the entire $10k AWS setup can be replaced by a single minimally optimized monolith running on one $20/month Hetzner server that responds several times faster to most requests due to no internal latency.
nikanj 3y ago
The thing could run on a $99 Hetzner box just fine, but that looks terrible on your CV
fnordpiglet 3y ago
I’d note each of what you mentioned cost $0 at zero scale and nominal $ at small scale. But you’re right, engineers new to aws try to flex all the kit together for not much benefit. For a semi static website all you need is s3+cloud front+api gateway+lambda+dynomdb for state. This would cost you basically $0 for small scale, and there would be nothing to monitor. It either works or aws is down.
emodendroket 3y ago
I kind of see the opposite. Relying heavily on stuff like lambda has scaling limitations but it’s fast to get up and running. Built-in interactions between AWS services can do a lot of the lifting for you. And then if you find out that’s not a great fit for what you’re doing you can put in more bespoke pieces.
drw85 3y ago
I actually worked on an Azure based project recently and it was very similar. It was a small semi static contact form that was deployed on 27 web apps (9 services x 3 environments) and used a NoSQL storage, redis, serverless stuff, etc. Insanely complex deployment process, crazy complexity and all over the place.

abluecloud 3y ago

It's honestly like a cult and a desire to want to "do it right" on AWS. The last few projects I've spent so much time setting up code deploy, load balancers, certificates, SES, route 53... This newest project, I've gone to heroku with everything being basically a few clicks to get setup.

boredumb 3y ago
It seems like another case of the road to hell being paved with good intentions, most places want/need redundancy and some managed devops and so a few ec2 instances and managed RDS is affordable enough and checks a lot of boxes, but after people start down this path it seems almost irresistible to start drilling down into managed kubernetes, spark jobs, to start ingesting some events we'll just introduce glue, and that plugs right into S3, and look how easy it is to plug in athena, add some quick alerting with cloudwatch, and the next thing you know you're vendor locked and having to hire a full time devops person with AWS experience to configure, manage and keep on top of it all.
steveBK123 3y ago
So guys we need Lambdas + Step Functions + SES + SQS + SNS + MSK + AWS Batch + S3 + Lakeformation + Cloudformation + Athena + EMR + Redshift + Aurora + SageMaker + Cloudtrail + Codepipeline + maybe some EC2s to run AWS CLI on them. Don't forget to configure Route53, VPC, IAM and an ELB. Great - ready to start writing your app now? Oh wow one of those components as configured with the other components isn't behaving as expected - time to contact AWS support! Cynically I think CTOs see all this stuff and think they'll turn all their expensive on-shore devs into cheaper DevOps because AWS is magic and you don't need to write hard app code anymore. I'd counter that AWS forces expensive on-shore devs into having to wear an entire new hat and be half a DevOps engineer to figure out how to make their code work on this alphabet soup instead of a Linux server.

lars512 3y ago

Tons of the pieces you mentioned are probably not that expensive to run for a small use case, given you're only charged on demand. The cost is really in the dev ops time and expertise to orchestrate the whole affair, and in the new ways it can break.

lastangryman 3y ago

> AWS has a great business model of people over "optimizing" their architecture using new toys from amazon and being charged through the nose for it I was back on AWS for the first time in a few years this week and the amount of new "upsell" prompts in the console is ridiculous. Spin up an RDS instance - "hey, would you like an Elasticache cluster too?". I think AWS are very aware of this behaviour and encourage it. Simplicity is not in their interest.

coffeebeqn 3y ago
I mean that’s upselling 101.

steveBK123 3y ago

Yes, and it attracts just the wrong kind of dev/architects. At a previous shop, we hired a cloud architect to drive our "cloud adoption". He of course bet the farm on a set of new AWS services that were barely in version v0.9 to be the backbone of the system he architected. It quickly became clear even he had no experience with the set of tools & services he had advocated, and the whole thing went off the rails slowly & surely. Low & behold 100% of existing customers are still on the on-prem offering 2 years later, and if you throw in the new customers that were shoehorned onto the AWS offering, his team has captured 2% of customer use after 2 years of effort.

baobabKoodaa 3y ago
But it's fun to play around with new toys!

andai 3y ago

I haven't dealt with high traffic systems but isn't a few requests per second well within the capabilities of a $5 VPS?

harrisi 3y ago
There was a blog post and discussion here about this a few months ago: https://news.ycombinator.com/item?id=34676186 https://news.ycombinator.com/item?id=34676186
NohatCoder 3y ago
A $5 instance gets you something like 1 core on a slightly dated CPU. Aka approximately as much processing power as a top of the line desktop processor 15 years ago. Aka enough processing power to fill a 25 Gb/s port with TLS data (not that you have the port to go with that). A few requests per millisecond should be well within the capabilities of this instance, depending on the complexity of each request of course.

andersa 3y ago

It is even more amazing when the entire $10k AWS setup can be replaced by a single minimally optimized monolith running on one $20/month Hetzner server that responds several times faster to most requests due to no internal latency.

nikanj 3y ago

The thing could run on a $99 Hetzner box just fine, but that looks terrible on your CV

fnordpiglet 3y ago

I’d note each of what you mentioned cost $0 at zero scale and nominal $ at small scale. But you’re right, engineers new to aws try to flex all the kit together for not much benefit. For a semi static website all you need is s3+cloud front+api gateway+lambda+dynomdb for state. This would cost you basically $0 for small scale, and there would be nothing to monitor. It either works or aws is down.

emodendroket 3y ago

I kind of see the opposite. Relying heavily on stuff like lambda has scaling limitations but it’s fast to get up and running. Built-in interactions between AWS services can do a lot of the lifting for you. And then if you find out that’s not a great fit for what you’re doing you can put in more bespoke pieces.

drw85 3y ago

I actually worked on an Azure based project recently and it was very similar. It was a small semi static contact form that was deployed on 27 web apps (9 services x 3 environments) and used a NoSQL storage, redis, serverless stuff, etc. Insanely complex deployment process, crazy complexity and all over the place.