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

381–390 of 513 posts

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

#381

Post by yanslookup »

AndroTux wrote: post #192
yanslookup wrote: post #165

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

Managing a complex environment is hard, no matter whether that’s deployed on AWS or on prem. You always need skilled workers. On one platform you need k8s experts. On the other platform you need AWS experts. Let’s not pretend like AWS is a simple one-click fire and forget solution. And let’s be very real here: if your cloud service goes down for a few hours because you screwed something up, or because AWS deployed so…

Maybe I've drank the koolaid but I've done both a lot of systems level work and AWS work (I don't actually use any AWS stuff in my role here interestingly) and I think for a business that needs a handful of hosts in 2 AZs I can't imagine the ROI and risk profile being better to self host.

AWS truly does let you focus on your business logic and abstracts a TON of undifferentiated work and well beyond the low hanging fruit of system updates and load balancing.

I guess put another way, providing a SaaS you need to have an SLA, those SLAs flow from SLO and SLIs and ultimately a risk profile of your hw and sw. The risk of a bad HBA alone probably means a day of downtime if you don't do things perfectly. AWS has bad HBAs, CPUs, memory, disks etc all day long every day and it's not even a blip for customers, never mind downtime. And if you don't model bad HBAs in your SLAs then your board is going to be pissed when that outage inevitably happens.

Now if you don't have SLAs and you like sysops, networkops, clusterops, dbops work then sure, YOLO.

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

#382

Post by Sohcahtoa82 »

thelastgallon wrote: post #175

These are the features that AWS provides (1) Massive expansion of budget (100 - 1000x) to support empire building. Instead of one minimum-wage sysadmin with 2 high-availability, maxed-out servers for 20K - 40K (and 4-hour response time from Dell/HPE), you can have 100M multi-cloud Kubernetes + Lambda + a mix-and-match of various locked-in cloud services (DB, etc.). And you can have a large army of SRE/DevOps. You get…

> (2) OpEx instead of CapEx

Someone please explain to me why this matters. I'd think that expenditures are expenditures, and that if the outright purchase of hardware would see an RoI compared to renting it in the cloud in under a year, it'd be a no-brainer to just buy the hardware.

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

#383

Post by jmaker »

geodel wrote: post #375
jmaker wrote: post #272

Earlier quoted context omitted.

It’s a marketing trap. But also a job guarantee since everyone’s in the same trap. You got a couple cloud engineers or "DevOps" that lobby for AWS or any other hyperscaler, NaiveDate managers that write down some decision report littered with logical fallacies, and a few years in the sink cost is so high you can’t get off of it, and instead of doing productivity work you’re sitting in myriads of FinOps meetings, wher…

All great points. I have seen in company of smart people CIO/CTO would freely up admit "Look we know cloud may not be cheap or easier to manage but this is the direction we have taken since we are getting out of owning or managing hardware/datacenter" So it is not like one can dazzle decision makers with any logic or hard data. They are just announcing the decision while calling it a robust discussion over pros and c…

Yep. I’ve also seen managerial people worship AWS sales reps as oracles, misconstruing ordinary sales meetings with them as something divine, in which they would disclose a lot of company’s IP in awe for them, just to listen to some blabbing superficial truisms. I mean, ChatGPT could tell you more. To add insult to that, the managerial people wouldn’t listen to their own senior, staff, principal engineers, and prefer to follow what the AWS reps told them.

It’s really disturbing how the human factor controls decision making in corporations.

For my peace of mind, I chose a sane path - if the company as an entity decides to do AWS, I will do my best to meet its goals. I’ve got all Professional and Specialty certs. It’s the human nature. No purpose in tilting at windmills.

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

#384

Post by maccard »

whstl wrote: post #293
ghaff wrote: post #291

Earlier quoted context omitted.

A lot of people forget that, when server virtualization was still gaining momentum in a lot of circles, it wasn't uncommon at less technically savvy customers--say a regional bank at the time--to be told that it might take 2 months to provision a new server.

I don't think anyone is forgetting that in this thread, as there's dozens of answers mentioning this. But as an example: It took about 3 months to provision an AWS server in a recent company I consulted for due to their own bureaucracy and ineptitude of the Ops team. On the other hand, when I needed a few CI servers for a startup I worked at, I just collected them from AppleStore during lunch hour. Now this above is…

For us the problem is every device that gets plugged into our network is disabled by default, IT need to enable the port and they'll only enable it on machines that they've imaged.

But because AWS isn't in the office, it's fine. We could probably use Hetzner or OVH, but then we have to go through procurement which is as much of as hassle as going through IT.

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

#385

Post by anonymars »

infecto wrote: post #379
Hilift wrote: post #374

Earlier quoted context omitted.

Multiple Active Result Sets (MARS). During large query responses or bulk loads, "full" packets cause an additional packet to be sent over the wire with about five bytes to hold the MARS "wrapper". The net result is one full packet, and one empty packet on the wire, alternating. The performance impact in LAN latency is negligible. However on higher latency between AWS and your premises it has a terrible performance im…

Is that not a client connection flag? MARS does not require a setting change on the server?

I think you may have misinterpreted what he said. I can see why it seems to imply a server setting but that isn't the case

> Did you know there is a setting in MS SQL Server that impacts performance by an order of magnitude when sending/receiving data from the Cloud to your on-premises servers? It's the default in the ORM generated settings

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

#387

Post by StratusBen »

Co-Founder and CEO of https://vantage.sh/ here - I've been pretty impressed by the rate that repatriation is happening off of public cloud. It rarely ever came up and in the last year it's been popping up more and more -- and especially just for getting access to GPU workloads.

I thought there would be a greater unbundling to AWS or to cheaper providers but it seems like a good-sized portion of the market is just going back to managing their own hardware.

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

#388

Post by mk89 »

bilekas wrote: 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…

How would you do multi-region deployments with your own DC?

This is an issue for several companies that start small and within 5 years they find the need to expand abroad. Be it for data sovereignty or so, which is becoming more important than ever in the last 10 years.

Duplicating a region is "a few clicks away" on AWS. This is what the provider enables you to do.

This and a lot of other things. And for such things, yes, you gotta pay.

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

#389

Post by Nemo_bis »

darkwater wrote: post #48

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.

Reminds me of https://www.specbranch.com/posts/one-big-server/

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

#390

Post by 9cb14c1ec0 »

tonypapousek wrote: post #358
9cb14c1ec0 wrote: post #34

Earlier quoted context omitted.

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.

No one. I have automatic backups with proxmox backup server. Updates are automatic and deployments are automated.
Post reply on HN