Earlier quoted context omitted.
> You need to be triply redundant on 3 availability zones, (3x) both with the RDS db cluster and app containers (2x) . And then have separate dev/staging/prod envs (3x). That's 18x. Don't believe this has anything to do with the cloud, if you want the same thing with your own data center, it's going to be 18x there as well. > You can then get a pat on the head ("pass AWS well-architected review"). Or you can be pragm…
You could spend less than 18 x AWS cost, because AWS compute is so expensive, depending what hosting you chose. A self owned DC is isn't the best option for most. You might also skip the overkill (for most cases) AZ redundancy because it wasn't pushed on you. You might even go with a much more managed platform, like the Heroku like ones. Depends on what you build and for who. I'm not knocking IaC, but unnecessarily h…
You can, but I'm sure you are making a tradeoff to achieve that, sure that trade off might be worth it for your use case, but I seriously doubt you could get exactly the same thing you get from AWS for substantially less, you need to factor in the reliability and flexibility aspects, if an EC2 instance, fails, I can just get a new one, if your own server fails, hopefully you have another one on hand.
There are other things that make the AWS offering compelling: you get everything in one place and you can expect to find IT people who know how to operate AWS, whereas that is probably not true for smaller competitors who might be cheap but also have less to offer in terms of services and mindshare.
> AWS compute is so expensive
I do auto scaling, which means that if nobody is using the application, I'm paying for a single small instance and then I use ECS tasks for offline computation, which means I end up paying exactly for what I use.
If I were hosting my own on-prem solution, I would still end up building something similar.
> AZ redundancy because it wasn't pushed on you.
If you work for a client that wants AZ redundancy, likely they are a client that is more than happy to pay the premium. For some clients, reliability matters more than infrastructure cost. For those clients infrastructure cost might even look like a rounding error compared to all the other costs.
I generally have no problem implementing a requirement that I don't believe is technically needed, if the business wants it, if they believe 3x the cost is worth it for the additional resiliency.
> you can't afford the monolith + db model and get roped to dynamodb, lambda@edge, API gateway, step functions, etc all requiring IAM roles, security groups, observability tooling, cicd & version control complexity, config services etc etc all the downsides you read about in microservice horror stories.
1 instance(s) x 2.32 USD hourly x 730 hours in a month = 1693.6000 USD (Aurora PostgreSQL Compatible DB)
A single developer will cost you at minimum 10k per month.
From a business perspective, I'm more than happy to pay thousands more for RDS and potentially overpowered EC2 instances than wasting far more expensive developer time on going nuts with serverless. For small things where it makes sense, sure I'm happy to go with serverless and save a few pennies, but not at massive developer time costs.
> And you can't even ssh in and strace or tcpdump the stuff like you could with your own microservices
Then you should just stick to EC2 instances if that's your cup of tea, though the idea of debugging individual instances becomes distant when you start auto scaling or start using containers.