I feel like it just depends on what you’re trying to do. * data driven website with some internal api integration, maybe some client-side application or tooling? Put a server rack in a closet and get a fiber line. * trying to serve the general public in a bursty, not-cacheable way? Probably going to have to carry a lot of machines that usually don’t do much, cloud might make more sense * lots of ingress or DNS rules?…
> In general once you start thinking about scaling data to larger capacities is when you start considering the cloud What kind of capacities as a rule of thumb would you use? You can fit an awful lot of storage and compute on a single rack, and the cost for large DBs on AWS and others is extremely high, so savings are larger as well.
AWS to bare metal two years later: Answering your questions about leaving AWS
481–490 of 513 posts
Re: AWS to bare metal two years later: Answering your questions about leaving AWS
#482Earlier quoted context omitted.
I was about to rage at you over the first sentence, because this is so often how people start trying to argue bare metal setups are expensive. But after reading the rest: 100% this. I see so many people push AWS setups not because it's the best thing - it can be if you're not cost sensitive - but because it is what they know and they push what they know instead of evaluating the actual requirements.
>I see so many people push AWS setups not because it's the best thing - it can be if you're not cost sensitive - but because it is what they know and they push what they know instead of evaluating the actual requirements. I kinda feel like this argument could be used against programming in essentially any language. Your company, or you yourself, likely chose to develop using (whatever language it is) because that's w…
Its a lot worse than this in terms of AWS cost for apps that often barely any people use. They're often incorrectly provisioned and the AWS bill ends up in the hundreds of thousands or millions and could have been a few thousand in bare metal on Hetzner with a competent sysadmnin team. No, its not harder to administer bare metal. No, its not less reliable. No, its not substantially harder to scale for most companies to do bare metal(large fortune 50 excluded).
Re: AWS to bare metal two years later: Answering your questions about leaving AWS
#483I had a problem figuring out why the place I was working wanted to move from in-house to AWS; their workload was easily handled by a few servers, they had no big bursts of traffic, and they didn't need any of the specialized features of AWS. Eventually, I realized that it was because the devs wanted to put "AWS" on their resumes. I wondered how long it would take management to catch on that they were being used as a…
with "dev wanting X" nothing happens. "leadership deciding X" then it needs to get done.
Re: AWS to bare metal two years later: Answering your questions about leaving AWS
#484Earlier quoted context omitted.
This is a toupee situation. Every effective company I've worked at has a slim platform team that might make some nice company specific templates for how to deploy, but individual teams were responsible for creating and owning their infra. The idea of having an AWS ops team is absurd if you're not at a truly massive company (XX,000+)
The "AWS ops team" is often 1-2 people and often part of the dev team formally, often augmented by external consultancies like mine. You start seeing that kind of structure in teams with 10+ people when the dev created infra starts collapsing under its own weight and they realise they need people with actual ops skillset.
Re: AWS to bare metal two years later: Answering your questions about leaving AWS
#485Earlier quoted context omitted.
This is a toupee situation. Every effective company I've worked at has a slim platform team that might make some nice company specific templates for how to deploy, but individual teams were responsible for creating and owning their infra. The idea of having an AWS ops team is absurd if you're not at a truly massive company (XX,000+)
Same difference. Just because the huge amount of AWS work is distributed among other teams doesn't mean it's less work. AWS in 2025 is way more work than Heroku/Fly/Vercel, but also more way work than renting bare metal from say Hetzner/OVH, and perhaps even more than renting colo.
Re: AWS to bare metal two years later: Answering your questions about leaving AWS
#486Earlier quoted context omitted.
This is a toupee situation. Every effective company I've worked at has a slim platform team that might make some nice company specific templates for how to deploy, but individual teams were responsible for creating and owning their infra. The idea of having an AWS ops team is absurd if you're not at a truly massive company (XX,000+)
I have never, ever seen dev-created infra that was well done, much less with repeatable IaC. It’s always résumé-driven nonsense based on whatever someone read on blogs, and they have no clue how any of it works, only that the output what they expect.
Re: AWS to bare metal two years later: Answering your questions about leaving AWS
#487This is the most infuriating pain point when using AWS.
We have premium support at work and the engineers basically read the documentation back to us, ignoring our complaints about cross-az bandwidth and the utter and complete lack of az-awareness in their services.
Example: we had some redises that we wanted to migrate to ElastiCache... All the aws engineers did was reading back the marketing pages and pushing for the serverless offering (where bandwidth was the main cost driver). The reader/writer endpoints are totally az-unaware.
Cross-AZ bandwidth for ElastiCache was costing us MORE than ElastiCache itself.
In the end we had to engineer AROUND ElastiCache in order to get it working, and working with predictable pricing.
"Invent and simplify" my ass...
Re: AWS to bare metal two years later: Answering your questions about leaving AWS
#488I have seen multiple startups paying thousands of dollars a month in AWS bills to run a tiny service which could trivially run on an $800 desktop on a residential internet connection. It's absolutely tragic.
Then they architected and built it out wrong. It's pretty simple to run low cost services in AWS. If you're small enough that an $800 desktop on a home internet connection will handle it, surely you could run it completely serverless for much less. I'm surprised how many people I see wanting to go on-prem vs AWS/public cloud. Feels penny smart and pound foolish to me. Lots of people too deep into the technical side o…
Bandwidth is usually the killer with AWS. Bandwidth on prem is free. Some cloud vendors are much better, in fairness.
Re: AWS to bare metal two years later: Answering your questions about leaving AWS
#489The core of this success is this, IMO: > Our workload is 24/7 steady. We were already at >90% reservation coverage; there was no idle burst capacity to “right size” away. If we had the kind of bursty compute profile many commenters referenced, the choice would be different. Which TBH applies to many, many places, even if they are not aware of it.
So yeah in a hot economy anything you launch grows crazy. Then you do the thought leader talk circuit.
And in a cold economy, you can stop growing, optimize for your 24/7 steady workload, and also do the thought leader talk circuit.
Re: AWS to bare metal two years later: Answering your questions about leaving AWS
#490In the early days of cloud service providers, they offered a handful of high-value services, all at great prices, making them cost-competitive with bare metal but much easier. That was then . Things today are different. As cloud service providers have grown to become dominant, they now offer a vast, complicated tangle of services, microservices, control panels, etc., at prices that can spiral out of control if you ar…
AFAICT no AWS service has ever had a price increase. This is nonsense.
https://github.com/SummitRoute/aws_breaking_changes/blob/mai...