Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

oneuptime.com

Post reply on HN
Print view View original

421–430 of 513 posts

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

#421

Post by dilyevsky »

thelastgallon wrote: post #419
dilyevsky wrote: post #335

Earlier quoted context omitted.

You say cloud allows massive expansion like it's a negative but it can be boon for a pre-pmf startup or a scaleup. You simply don't have to worry much about capacity planning in cloud and that can be a huge time/effort saver. Sure, if you're only growing <30% YoY and already paying several millions for cloud and bandwidth/storage are large fraction of that, by staying in cloud you're proving your incompetence as an e…

You say as if every startup scales to facebook size within months. Most startups are hilariously small and their workloads won't stress out a mac mini. Of course, you could overengineer and spend too much and hire too many people, but thats on the people running the startup.

Great, put it on t4g.small or Render or something, what's your point?

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

#422

Post by twodave »

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? A hybrid approach could make sense.

In general once you start thinking about scaling data to larger capacities is when you start considering the cloud, because just the storage solution ends up on a long amortization schedule if you need it to be resilient, let alone the servers you’re racking to drive the DB.

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

#423

Post by nostrebored »

briffle wrote: post #350
Spooky23 wrote: post #80

Earlier quoted context omitted.

I don’t think it’s paid shilling, it’s dogma that reflects where people are working here. The individual engineers are hammers and AWS is the nail. AWS/Azure/GCP is great, but like any tool or platform you need to do some financial/process engineering to make an optimal choice. For small companies, time to market is often key, hence AWS. Once you’re a little bigger, you may develop frameworks to operate efficiently.…

The tooling should be getting close to manage this on-prem now, with VM's, K8s clusters, networking, storage, etc. I know that oxide computers exists, and they look fantastic, but there has got to be more 'open' ways to run things on your own Dell/HP/Supermicro servers with NVMe drives. Especially since VMware has jacked up their prices since being acquired. Talos OS looks really interesting. But I also need the stor…

teams can't even run k8s in the cloud. teams I've seen running k8s on prem have always been disaster shows. productivity in the gutter.

the tooling to manage on prem is truly awful, and attempts to port the nice semantics of cloud have all slowly died (who remembers localstack?)

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

#424

Post by kaydub »

baq wrote: post #135
dangus wrote: post #108

Earlier quoted context omitted.

I think a lot of engineers who remember the bare metal days have legitimate qualms about going back to the way that world used to work especially before containerization/Kubernetes. I imagine a lot of people who use Linux/AWS now started out with bare metal Microsoft/VMWare/Oracle type of environments where AWS services seemed like a massive breath of fresh air.

I remember having to put in orders for pallets of servers which then ended up storage somewhere because there were not enough people to carry and wire them up and/or there wasn't enough rack space to install them. Having an ability to spin up a server or a vm when you need it without having to ask a single question is very liberating. Sometimes such elasticity is exactly what's needed. OTOH other people's servers are…

Not just spin up a server, you can spin up whole regions, even in foreign countries, at the click of a button.

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

#425

Post by nostrebored »

whstl wrote: post #176
vidarh wrote: post #89

Earlier quoted context omitted.

I help people run their systems. Clients that use cloud consistently end up spending more on devops resources, because their setups tends to be wastly more complex and involve more people.

I've worked on both kinds of companies in almost 25 years and I can confirm this is true. The biggest ops teams I worked alongside were always dedicated to running AWS setups. The slowest too were dedicated to AWS. Proportionally, I mean, of course. People here are comparing the worst possible of Bare Metal with "hosting my startup on AWS".

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+)

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

#426

Post by nostrebored »

evanelias wrote: post #208
speleding wrote: post #144

Earlier quoted context omitted.

If your database has a hardware failure then you could loose all sales and customer data since your last backup, plus cost of the down time while you restore. I struggle to think of a business where that is acceptable.

Why are you ignoring the huge middle ground between "HA with fully automated failover" and "no replication at all"? Basic async logical replication in MySQL/MariaDB is extremely easy to set up, literally just a few commands to type. Ditto for doing failover manually the rare times it is needed. Sure, you'll have a few minutes of downtime until a human can respond to the "db is down" alert and initiates failover, but…

When I worked at AWS, the majority of customers who thought they had database backups had not tested recovery. The majority of them could not recover. At that point, RDS sells itself.

The other huge middle ground here is developer competency and meticulousness.

People radically overestimate how competent the average company writing software is.

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

#427

Post by franktankbank »

_the_inflator wrote: post #364
Hilift wrote: post #50

Earlier quoted context omitted.

> The direct cost is the easy part I don't think it is easy. I see most organizations struggle with the fact that everything is throttled in the cloud. CPU, storage, network. Tenants often discover large amounts of activity they were previously unaware of, that contributes to the usage and cost. And there may be individuals or teams creating new usages that are grossly impacting their allocation. Did you know there i…

Yes. Cloud sellers new this: Happy path for this flagship project, the shinny new object, and some additional services. After the point of no return what usually happens is, that cloud will be a replica of bare metal development. As an Computer Science dude and former C64/Amiga coder in Senior Management of a large international Bank, I saw first hand, how cost balloon simply due to the fact, that the bank recreates…

Ferrari actually makes tractors.

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

#428

Post by nostrebored »

nemothekid wrote: post #342

> We now save over $1.2M / yr and we expect this to grow, as we grow as a business. Am I just naive? How is a uptime SaaS product saving over a million year on managed colo vs AWS? Was every API route in it's own EC2 instance? AWS is expensive sure, but over a million dollars a year? For this product specifically?. I got some clarification from their earlier posts and it looks like they were intentionally avoiding an…

In almost 100% of cases I've seen this, people are convinced that they are going to go for a multi-cloud situation and using any value added service is "lock-in". The amount of times I've seen the migration scenario play out favorably for people has been absolutely ZERO.

Meanwhile, I've seen huge companies successfully complete cloud->cloud migrations in less than a year, as long as they use the value added services of the other cloud.

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

#429

Post by kaydub »

jcalvinowens wrote: post #244

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 of things that they don't even understand the business side.

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

#430

Post by evanelias »

nostrebored wrote: post #426
evanelias wrote: post #208

Earlier quoted context omitted.

Why are you ignoring the huge middle ground between "HA with fully automated failover" and "no replication at all"? Basic async logical replication in MySQL/MariaDB is extremely easy to set up, literally just a few commands to type. Ditto for doing failover manually the rare times it is needed. Sure, you'll have a few minutes of downtime until a human can respond to the "db is down" alert and initiates failover, but…

When I worked at AWS, the majority of customers who thought they had database backups had not tested recovery. The majority of them could not recover. At that point, RDS sells itself. The other huge middle ground here is developer competency and meticulousness. People radically overestimate how competent the average company writing software is.

Putting aside the fact that replication and backups are separate operational topics -- even if a company has no competent backend engineers, there are plenty of good database consultancies that can help with this sort of thing, as a one-time cost, which ends up being cheaper than the ongoing markup of a managed cloud database product.

There's also a big difference between incompetent and inexperienced. Operational incidents are how your team gains experience!

Leaning on managed cloud services can definitely make sense when you're a small startup, but as a company matures and grows, it becomes a crutch -- and an expensive one at that.

Post reply on HN