Live data from Hacker News

Move Back to Datacenters

rakkhi.substack.com

81–90 of 97 posts

Re: Move Back to Datacenters

#81
post #27

Earlier quoted context omitted.

The other thing they keep missing. Where are the people with the skills to do this work? I wrote a whole post about it, but it is not like people with that knowledge exist in troves just waiting to be hired. There are no path to learn this stuff either. Do we really expect every single company out there to build teams of sysadmin and operators from a non existing pool of talents? It is easy to say that people can mov…

AWS and Azure is a much more niche skill set. E.g., there's probably three orders of magnitude more engineers familiar with Postgres out there in the world than with DynamoDB.

To the point of running it smoothly at scale in prod with backup?

Nope. Hence you learn the RDS api and use it.

Re: Move Back to Datacenters

#82

The conclusion completely handwaves the massive overheads that come with not only owning your own infrastructure, but also having to manage a complex platform stack and its security. The security points, which the main points hinges on, seem hyperfocused and in most cases misguided. Redshift is not internet facing. If your Redshift is internet facing, you've messed up somewhere. The CPU attack example given is for AM…

Thanks all for your engagement and comments. I have updated the article to address many of these points.

Re: Move Back to Datacenters

#83
post #60
post #56

Earlier quoted context omitted.

> The business case is that someone else is doing the infrastructure management for you. Many business people believe that moving to cloud can reduce the headcount needed for managing the infra, but that is usually not what's happening. You will still need more or less the same amount of people to patch the OS and configure the networking, but with a slightly different skill set -- instead of Cisco IOS commands, they…

If you're treating cloud as a sort of 1:1 replacement of hardware infrastructure, then what you're saying makes sense. But we don't ever "patch the OS." Our cloud provider does that for us. Upgrades and patching are automatic within the maintenance window. We deploy containers, the OS is just a platform layer that the cloud provider manages. As for needing "more or less the same amount of people", that simply isn't t…

> But we don't ever "patch the OS." Our cloud provider does that for us.

This is absolutely not true. Unless your cloud services are limited to function-as-a-service and serverless/containerized applications,you are indeed responsible for "patching the OS".

This kind of thing is explicitly covered even by AWS' intro to AWS courses, namely in its shared responsibility model.

> As for needing "more or less the same amount of people", that simply isn't true IME. I've seen startups with whole teams devoted to running systems in a datacenter, whereas cloud-based startups will often have one or two guys, possibly even part-time, dealing with their cloud requirements.

Sorry, your claim is outright unbelievable. I've never seen a company who owned any web application that only had "one or two guys, possibly even part-time, dealing with their cloud requirements." Unless the whole company is only "one or two guys, possibly even part-time", your claim simply is extremely far-fetched and blatantly unbelievable.

Re: Move Back to Datacenters

#86

The conclusion completely handwaves the massive overheads that come with not only owning your own infrastructure, but also having to manage a complex platform stack and its security. The security points, which the main points hinges on, seem hyperfocused and in most cases misguided. Redshift is not internet facing. If your Redshift is internet facing, you've messed up somewhere. The CPU attack example given is for AM…

> The conclusion completely handwaves the massive overheads that come with not only owning your own infrastructure

Even if you feel that is a serious obstacle (which I personally don't) you can buy a managed solution (such as an Oxide rack) and use that on prem.

Re: Move Back to Datacenters

#87
post #37

Best of luck running your own data center properly. It's a massive pain in the hoop.

Most university IT departments I know manage just fine to do this. Allthough I get the idea of paying others to run your servers (I do so myself), I am somewhat puzzled that people so readily want to move on from the option of selfhosting. Knowing how to do things yourself has its own value. This reminds me a bit of developers who can't write anything useful without using a framework. There is life outside of framewo…

It depends on what level of "run your own infra" were talking about here. Like, purchasing hardware, racking and connecting, coming up with a nice way to PXE build your fleet and a way to manage the OS and config (chef/ansible/puppet/nix?), before implementing a complete monitoring stack that works on network equipment, raid controllers etc, and then bootstrapping your own Kubernetes cluster or hashistack (or pretending that you don't need complexity, but over time cobbling together your own unique undocumented mess). It's a huge amount of work that startups usually can't afford. The time and effort to do it properly is monstrous. You need to be a company of a certain size to devote the required engineering and support staff to it.

Re: Move Back to Datacenters

#88
post #60

Earlier quoted context omitted.

If you're treating cloud as a sort of 1:1 replacement of hardware infrastructure, then what you're saying makes sense. But we don't ever "patch the OS." Our cloud provider does that for us. Upgrades and patching are automatic within the maintenance window. We deploy containers, the OS is just a platform layer that the cloud provider manages. As for needing "more or less the same amount of people", that simply isn't t…

And now you need to patch the containers, too!

I had to do that with on-prem anyway.

In addition to the servers.

In addition to patching the routers.

Re: Move Back to Datacenters

#89
post #63

Earlier quoted context omitted.

I think people overestimate the expenses related to maintaining their own infrastructure. I work for a large org that does both. We have a lot of workloads running in the public cloud, and many more on premises (for various reasons, including compliance). Having worked on these for years, building solutions, diagnosing problems and so on I'd risk saying we have reached the point where the cloud is slowly getting more…

> anybody who has maintained a large repository of CloudFormation code will tell you its not a panacea. CloudFormation is one of the worst IaCs out there, so it's not really a good example. One really nice model is managed Kubernetes with IaC/GitOps via tools like ArgoCD or Flux CD. This eliminates the need for things like CloudFormation, Terraform, Ansible, Puppet, OS version and patch management, etc. - most of the…

I agree it's a reasonable solution as far as workloads are concerned, but at the same time you still need the infra around it. Most of the time you need to store data outside of Kubernetes, so you'll need to deal with things like S3, RDS, DynamoDB. You will probably want ECR etc. All these things need policies and configuration. And, depending on the size or your org, also security/governance/compliance services, and you end up with a complex setup even if your main focus is k8s.

Re: Move Back to Datacenters

#90
post #57

Why is the choice always portrayed as if it's either cloud, or on-prem / colocation ? Those are two extremes. At work I use dedicated physical machines from Hetzner. If I need an extra one they deliver it in a few minutes, and thanks to Ansible it's provisioned within a few minutes more. Hetzner keeps an eye on the hardware and replaces disks, PSU's and the like if needed. I wouldn't often advocate to do colocation o…

> at a price/performance ratio that makes AWS look like pure extortion.

I think if you try to host in US to have lower latency to many customers, and with some less cheap and more reliable server grade network/hardware, it is likely cost will be higher than for hetzner.

Post reply on HN