Live data from Hacker News

AWS to bare metal two years later: Answering your questions about leaving AWS

oneuptime.com

481–490 of 513 posts

Re: AWS to bare metal two years later: Answering your questions about leaving AWS

#481

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.

Well, if you want proper DR you really need an off-site backup, disk failover/recovery, etc. And if you don’t want to manually be maintaining individual drives then you’re looking at one of the big, expensive storage solutions with enterprise grade hardware, and those will easily cost some large multiple more than whatever 2U db server you end up putting in front of it.

Re: AWS to bare metal two years later: Answering your questions about leaving AWS

#482
post #71

Earlier 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…

So, I was around back then and am around now as a principal and this comment doesn't really pass the reality sniff test.

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

#483
post #295

I 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.

That was what I thought, but when the middle management also wants it, then it can become the 'obvious choice', a la 'nobody ever got fired for choosing IBM'. It seems that middle management + devs can make it seem inevitable to the people above them, especially if those people are non-tech.

Re: AWS to bare metal two years later: Answering your questions about leaving AWS

#484
post #463

Earlier 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.

I have literally never seen this at 20, 400, or 3000 engineers. But the companies that I've worked at have all been "name brand" or startups on the path to acquisition.

Re: AWS to bare metal two years later: Answering your questions about leaving AWS

#485
post #478

Earlier 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.

This is only true if you're not using value added services. In my experience, teams that don't accelerate by adopting cloud won't use something like SQS or Fargate, they'll throw an MQ on a k8s cluster and get enraged when it doesn't work how they expected.

Re: AWS to bare metal two years later: Answering your questions about leaving AWS

#486

Earlier 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.

Could definitely be skewed by my time at AWS and working for companies that hire ex-AWS people, but I've never seen infra being the real third-party roadblock. I've always seen a design review -> IaC creation pipeline that's relatively fast.

Re: AWS to bare metal two years later: Answering your questions about leaving AWS

#487
> 37% off instances still leaves you paying list price for bandwidth, which was 22% of our AWS bill.

This 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

#488
post #429

I 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…

You vastly underestimate what you can do on prem. Equivalent elastic compute for a $800 desktop that uses $100/mo in electricity is >$2000/mo. As sibling points out, it could easily be much much more depending on what you're doing.

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

#489

The 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.

YES, but let's also not ignore that the market is cold right now and the tech industry isn't really growing like crazy like it did during ZIRP.

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

#490
post #86
post #15

In 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.

Most years, AWS increases some prices:

https://github.com/SummitRoute/aws_breaking_changes/blob/mai...

Post reply on HN