Live data from Hacker News

Move Back to Datacenters

rakkhi.substack.com

91–97 of 97 posts

Re: Move Back to Datacenters

#91
post #83
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…

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

> Unless your cloud services are limited to function-as-a-service and serverless/containerized applications,

Yes, I'm talking about containerized applications, deploying to fully managed environments like EKS, Fargate, GKE, Cloud Run. If you're not using containers then yes, it will be more difficult to achieve what I'm describing.

I've been the one part-time guy for three different SaaS startups with funding in the $20-30m range, and globally distributed dev teams. I'm a software architect and dev primarily, so setting up the cloud platform is just a side activity.

For one of those companies, I was literally just a part-time contractor. Once it's set up properly, it should be easy for regular admins to operate, and devs can just follow the templates for configuring a service. It's not rocket science.

All the stuff you're imaging is so complex is exactly the stuff that the cloud lets you delegate to the provider. But you have to be willing to do it, you can't stick to the old way you've always done things and expect the cloud to make anything easier for you.

Re: Move Back to Datacenters

#92
post #70
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…

I see, so you are using PaaS and I was talking about IaaS offerings. The term cloud is so vaguely defined that it can mean so many things. If the PaaS works for your scale and budget then it’s perfectly fine. I just want to mention that it is probably no longer the case for scaled-ups.

You're right, I should have clarified that IaaS is exactly the stuff you want a cloud provider to take care of for you, and that's where many of the benefits come from.

But IaaS has been around for nearly 20 years now, and containers for at least 10 years, so I tend to assume people have got that message by now, especially on HN.

Re scale, you can run pretty high scale on managed Kubernetes clusters. E.g. GKE supports up to 15,000 nodes per cluster, hosting over 3.8 million concurrently running pods. Multi-cluster ingress is also supported if you need to run multiple clusters.

Re: Move Back to Datacenters

#93
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've never heard of patching containers.

Our build pipelines rebuild container images for every deployment. All you need to upgrade some dependency is to set a version number in the Dockerfile.

There's no "too" because that's the only place we deal with that kind of version dependency. (Not counting dependencies internal to a service, like libraries.)

Re: Move Back to Datacenters

#94
post #19

Earlier quoted context omitted.

In general when people mention "cost" as an issue for cloud, they're narrowly comparing what a CPU core or GB of RAM or disk costs on paper between cloud and datacenter/onprem. This completely misses the business case for cloud, and is why these sorts of analyses don't convince that many business folk, and why cloud use continues to grow fast. The business case is that someone else is doing the infrastructure managem…

Do the math and think again. Infra engineers needed to run your "managed" cloud stack cost much more than generic sysadmins for commodity open-source on-prem solutions.

One problem is those cheap, generic sysadmins usually can't deliver a fully-automated end-to-end SDLC with IaC and automated deployment out of source control. And asking devs to do that without depending on managed services is slow and expensive.

Re: Move Back to Datacenters

#95
post #49

No. We rolled our own stack for 10 years, until 2018, well after AWS and Azure were around. We switched to Azure in 2018 and never looked back. Sure you trade security (do you really, though?) in exchange for: - not needing to head to the DC because a power supply failed and a rando who was in the cage never plugged in the redundant one - not having to be way over-capacity in scalability, or suddenly under-capacity a…

Then there are options that are probably better for you. I've been doing colocation for many years, but I've never seen the inside of the datacenter. Remote hands set up the hardware for me and replace failed hardware. The service is so rarely needed that it's basically free. In recent years I've started to rent the hardware I want as I want more frequent changes. I tell my host what hardware I want and they'll acqui…

All of those things still require management, which is the issue at hand here.

Also if you're renting your hardware... for a subscription ... that sounds an awful lot like the cloud with extra steps.

Re: Move Back to Datacenters

#96
post #91
post #83

Earlier quoted context omitted.

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

> Unless your cloud services are limited to function-as-a-service and serverless/containerized applications, Yes, I'm talking about containerized applications, deploying to fully managed environments like EKS, Fargate, GKE, Cloud Run. If you're not using containers then yes, it will be more difficult to achieve what I'm describing. I've been the one part-time guy for three different SaaS startups with funding in the…

> For one of those companies, I was literally just a part-time contractor. Once it's set up properly, it should be easy for regular admins to operate, and devs can just follow the templates for configuring a service. It's not rocket science.

It's also a gross misrepresentation of the initial statement. Having a part time employee setting up a few containers to run in A container orchestration system is absolutely not what "setting up the company's cloud requirements" means. It's a blatant attempt to oversell a couple of clicks worth of work as covering a company's whole cloud requirements.

Re: Move Back to Datacenters

#97
post #16

Earlier quoted context omitted.

Genuinely feels like there’s a constant trickle of arguments from people looking to do all they can to shift the tides such that their skill set is more in demand. Or maybe it’s just an ideological obsession. I don’t know. I feel the same way whenever the “use C for everything” people catch a whiff of performance mattering and very strongly suggest that the only way to dig ourselves out of this mess is to move back t…

In my experience The Cloud™ requires a much larger skillset, ensuring that your ops department will never stop growing.

I have an impression that is "avoided" in many companies by demanding from the newly hired programmers to have "cloud experience". My problem is that that usually ends up being "programmers have taken courses about the way cloud vendor Y does the job" which then actually means "the programmers had drunk the propaganda of the cloud vendor Y" which is not a directly reusable knowledge for anything than "here's how we adjust our work to be charged by the cloud vendor Y". Which I think is guaranteed to have a company which can't even imagine doing it any other way.
Post reply on HN