Live data from Hacker News

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

oneuptime.com

451–460 of 513 posts

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

#451
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…

Hard to say. A $800 desktop could easily equal the compute of $100k/mo in lambda costs.

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

#452
post #11

I'm so surprised there is so much pushback against this.. AWS is extremely expensive. The use cases for setting up your system or service entirely in AWS are more rare than people seem to realise. Maybe I'm just the old man screaming at cloud (no pun intended) but when did people forget how to run a baremetal server ? > We have 730+ days with 99.993% measured availability and we also escaped AWS region wide downtime…

> when did people forget how to run a baremetal server ?

I don't think people have forgotten, but I think Amazon has done an amazingly excellent job of marketing and developer relations over the years, to the point that they've convinced most developers that doing your own thing is 1) a lot of expensive, specialized work, and 2) actively dangerous for your business, whether it's because of security, uptime, or some other ops bogeyman of the day.

Note that I said "developers". Most developers are not sysadmins or IT operations people. Most of them have never set up Linux on a desktop or laptop, let alone on real server hardware (that they've also set up themselves). Most of them never had the chance to forget how to run a bare-metal server; they never knew how in the first place. (Hell, I've been running desktop Linux for 25+ years, and I don't think I've ever set up Linux on actual server hardware. Closest I've come is bare-metal Solaris, but that was like 25 years ago.)

"DevOps" today usually means that you know how to run a CLI tool or drive a web interface to deploy your automatically-built container artifact to some cloud-based production system that someone else manages, hiding the details from you. (This bit also can be true for shops that run on bare metal, depending on how advanced their own sysadmin/ops team is.) While developers are often not decision-makers in a larger org, they can be at smaller orgs, and once those developers get on the cloud, you probably will stay on the cloud (companies like OneUptime are the exception, not the rule), even if you've gotten much larger and it's stupid expensive to continue running that way.

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

#453
post #71
post #26

Earlier quoted context omitted.

The direct cost is the easy part. The more insidious part is that you're now cultivating a growing staff of technologists whose careers depend on doing things the AWS way, getting AWS certified to ensure they build your systems the AWS Well Architected Way instead of thinking themselves, and can upsell you on AWS lock-in solutions using AWS provided soundbites and sales arguments. ("Shall we make the app very resilie…

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.

> people push AWS setups not because it's the best thing - it can be if you're not cost sensitive

This is so weird to me, because if you're running a company, you should be cost-sensitive. Sure, you might be willing to spend extra money on AWS in the very beginning if it helps you get to market faster. But after that, there's really no excuse: profit margin should be a very important consideration in how you run your infrastructure.

Of course, if you're VC backed, maybe that doesn't matter... that kind of company seems to mainly care about user growth, regardless of how much money is being sent to the incinerator to get it.

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

#454
post #450

Earlier quoted context omitted.

My last team decided to hand manage a Memcached cluster because it cost half as much as an unmanaged service versus AWS’s alternative. Don’t know how much we really saved versus opportunity cost on dev time though. But it’s close to negative.

That should be extremely low maintenance...

As long as we didn’t need to touch the machines, nearly zero. But you gotta touch them sometime.

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

#455

Earlier quoted context omitted.

Well, they aren't wrong about the bare metal either: Every organization ends up tied to their staff, and said staff was hired to work on the stack you are using. People end up in quite the fights because their supposed experts are more fond of uniformity and learning nothing new. Many a company was stuck with a datacenter unit that was unresponsive to the company's needs, and people migrated to AWS to avoid dealing w…

Your comment also jogged my memory of how terrible bare metal days used to be. I think now with containers it can be better but the other reason so many switched to cloud is we don’t need to think about buying the bare metal ahead of time. We don’t need to justify it to a DevOps gatekeeper.

That memory is part of the problem: it doesn't reflect today's reality. You can have an IT ops team that buys and sets up servers, and then sets up (perhaps) Kubernetes and a nice CI/CD pipeline on top of it. They can fairly easily bill individual teams for usage, and teams have to justify their costs, just like they (hopefully!) do in any sane org that's running in the cloud.

The bad old days of begging an IT ops person for a server, and then throwing a binary over the fence at them so they can grumble while they try to get it running safely in production... yeah, no, that doesn't have to be a thing anymore.

The "we" you speak of is the problem: if your org hires actual real sysadmins and operations people (not people who just want to run everything on AWS), then "you" don't have to worry about it.

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

#457
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…

> they offered a handful of high-value services, all at great prices, making them cost-competitive with bare metal but much easier That was never the case for AWS, the point was never "We're cheap" but "We let you scale faster for a premium". I first came across cloud services around 2010-2011 I think, when the company I worked at at the time started growing and we needed something better than shared hosting. AWS was…

Yep.

AWS is a money printer because it enables companies to make a lot more money without hiring multiple 200k a year engineers to manage infrastructure that comes with scale. And that is also considering that the company will actually have to find competent people to do the work.

With AWS, if you wanna scale, you just use your credit card without worrying about anything.

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

#458
post #447

Earlier quoted context omitted.

I've seen this in startups with 7 figure ARR (where annual cloud costs were also 7 figures). Also seen that in F500 where a single architect caused a 5-figure mistake which remove cloud privileges from the entire architecture team. Can't make it up.

I mean 5 figures is nothing to most companies when your spending 10s of millions on aws.

7 figures is single digit millions. 5 figures is a single silly mistake. Just enabling more verbosity on logs is enough to trigger that in a day. Such mistakes would be found monthly. We could have easily had 10% more engineers with the same budget if it weren't for lighting our runway on fire that way.

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

#459

FD: I work at Amazon, I also started my career in a time where I had to submit paper requests for servers that had turn around times measured in months. I just don't see it. Given the nature of the services they offer it's just too risky not to use as much managed stuff with SLAs as possible. k8s alone is a very complicated control plane + a freaking database that is hard to keep happy if it's not completely static.…

Indeed Kubernetes is problematic for the complexity and fragility reasons. It's a scalability problem, it's designed for big scale with kube staffs and situations where cost savings from bin packing etc outweigh costs of the resulting complexity.

But, SLAs are no good (who cares about getting refunded).

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

#460
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.

Well, they aren't wrong about the bare metal either: Every organization ends up tied to their staff, and said staff was hired to work on the stack you are using. People end up in quite the fights because their supposed experts are more fond of uniformity and learning nothing new. Many a company was stuck with a datacenter unit that was unresponsive to the company's needs, and people migrated to AWS to avoid dealing w…

Considering the rapid shift from on Prem to the cloud I think it’s clearly false that the people who knew on Prem were fighting for their little area of expertise.

In my experience, the ops folks were absolutely thrilled with the arrival of the cloud because with a trivial amount of training and a couple of certifications they had a pathway to get paid as much, if not more, than devs, especially if they rebranded as “devops engineers” instead of “ops guys”.

The only pushback against the cloud, other than some of us engineers who actually were among the first to jump on the cloud, still really loved it, but also recognized that it wasn’t the best fit for all uses and carried significant risks, were people worried about data safety.

The latter concern has largely turned out to not be a real one yet, but a decade and a half later people are finally realizing that actually there are many areas where the cloud may not be the best fit.

Post reply on HN