Live data from Hacker News

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

oneuptime.com

351–360 of 513 posts

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

#351

Earlier quoted context omitted.

Nobody is hiring generalists nowadays. At the same time, the incredible complexity of the software infrastructure is making specialists more and more useless. To the point that almost every successful specialist out there is just some disguised generalist that decided to focus their presentation in a single area.

> Nobody is hiring generalists nowadays. What? I throw up in my mouth every time I see "full stack" in a job listing. We got rid of roles... DBA's, QA teams, Sysadmins, then front and back end. Full Stack is the "webmaster" of the modern era. It might mean front and back end, it might mean sysadmin and DBA as well.

Even full stack listings come with a list of technologies that the candidate must have deep knowledge of.

> We got rid of roles... DBA's, QA teams, Sysadmins, then front and back end.

On a first approximation, those roles were all wrong. If your people don't wear many of those hats at the same time, they won't be able to create software.

But yeah, we did get rid of roles. And still require people to be specialized to the point it's close to impossible to match the requirements of a random job.

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

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

[dead]

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

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

> if your using the right services, if someone asked you tomorrow to scale 100x you likely could during the workday.

"The right services" is I think doing a lot of work here. Which services specifically are you thinking of?

- S3? sure, 100x, 1000x, whatever, it doesn't care about your scale at all (your bill is another matter).

- Lambdas? On their own sure you can scale arbitrarily, but they don't really do anything unless they're connected to other stuff both upstream and downstream. Can those services manage 100x the load?

- Managed K8s? Managed DBs? EC2 instances? Really anything where you need to think about networking? Nope, you are not scaling this 100x without a LOT of planning and prep work.

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

#354

Earlier quoted context omitted.

Actually nothing new here, this was the same in the pre-cloud era where everyone in enterprises prefer big names(ibm, microsoft, oracle, ecc) to pass the responsibility to them in case of failures ... aka "nobody get fired because of buying IBM"

And the big name companies always refuse to take responsibility, and have worse reliability metrics than the lean alternatives... but somehow that is never a problem.

This fired of some warning bells in my head. Is the data available to actually make a verifiable claim regarding those reliability metrics like you are.

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

#355
post #107
post #90

>We're now moving to Talos. We PXE boot with Tinkerbell, image with Talos, manage configs through Flux and Terraform, and run conformance suites before each Kubernetes upgrade. Gee, how hard is to find SE experts in that particular combination of available ops tools? While in AWS every AWS certified engineer would speak the same language, the DIY approach surely suffers from the lack of "one way" to do things. Change…

If you're that much of a slave to your tool chain you don't get to call yourself an engineer.

Or you have PTSD after 10 years of being on-call 24/7 for your company's stack. I've built my next chapter around offloading the pager. Worth every penny.

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

#356
post #101

Earlier quoted context omitted.

A lot of people here have built their whole professional careers around knowing AWS and deploying to it. Moving away is an existential issue for them - this is why there's such pushback. A huge % of new developer and devops generation doesn't know anything about deploying software on bare metal or even other clouds and they're terrified about being unemployed.

meanwhile skills in operating systems, networking, and optimization are declining. Every system i've seen in the last 10 years or so has left huge cash on the table by not being aware of the basics.

That could have more to do with containerization than the cloud - and that was a goal if I recall.

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

#357

Managed DB costs a lot. Is there a simple safe setup that we can run on an Ubuntu server? We self-host the Postgres db with frequent backups to s3 but just in case the site takes off, we need an affordable reliable solution. Does anyone here run their own db servers? Any advise? Backups, security, upgrades etc

Maybe look at R2 or Wasabi instead of S3. That would cut your storage bill by 3x and take your cloud network bill to zero. IMO self-managing DBs always sucks no matter what you do.

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

#358

Earlier quoted context omitted.

Forget? You have to hire people for that. We are a software organization. We build software. If we rent in the cloud, there is less HR hassle - hiring, raises, bonuses, benefits, firing … none of that headache involved with the cloud. Technically? Totally doable. But the owners prefer renting in the cloud over the people-related issues of hiring.

This is the fallacy that Amazon sold everyone on: that the cloud has no headache or managment needed. This is manifestly untrue. It's also untrue that bare metal takes lots of management time. I have multiple Dell rack servers colocated in several different datacenters, and I don't spend any time at all managing them. They just run.

> I don't spend any time at all managing them

Who does, then? Even with automatic updates, one can assume some level of maintenance is required for long-term deployments.

Don’t get me wrong, I love running stuff bare metal for my side projects, but scaling is difficult without any ops.

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

#359
I'm involved in a fairly large academic cloud deployment, sited in a 15MW data center built and shared by a few large universities.

There are huge advantages of scale to computer operations in a few areas:

- facility: the capital and running cost of a purpose-built datacenter is far cheaper per rack than putting machines in existing office-class buildings, as long as it's a reasonable size - ours is ~1000 racks, but you might get decent scale at a quarter of that. (also one fat network pipe instead of a bunch of slow ones)

- purchasing: unlike consumer PCs, low-volume prices for major vendor servers are wildly inflated, and you don't get decent prices until you buy quite a few of them.

- operations: people come in integer units, and (assuming your salary ranges are bounded) are only competent in small number of technical areas each. Whether you have one machine or 1000s you need someone who can handle each technology your deployment depends on, from Kubernetes to network ops; multiply 4x for those requiring 24/7 coverage, or accept long response times for off-hours failures.

That last one is probably the kicker. To keep salary costs below 50% of your total, assuming US pay rates and 5-year depreciation since machines aren't getting faster as quickly as they used to, you probably need to be running tens of millions of dollars in hardware.

Note that a tiny deployment of a few machines in a tech company is an exception, since you have existing technical staff who can run them in their spare time. (and you have other interesting work for them to do, so recruiting and retention isn't the same problem as if their only job was to babysit a micro-deployment)

That's why it can be simultaneously true that (a) profit margins on AWS-like services are very high, and (b) AWS is cheaper than running your own machines for a large number of companies.

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

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

This is the right take - there is a huge variation in "value per dollar" across AWS services. The base ones that solve hard problems like durable persistent state can be very much worth it. They tend to be the older ones.
Post reply on HN