Live data from Hacker News

Move Back to Datacenters

rakkhi.substack.com

31–40 of 97 posts

Re: Move Back to Datacenters

#33
post #19

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…

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…

[deleted]

Re: Move Back to Datacenters

#34
post #8

The analogy of this article would be: Stop using airbnbs when traveling, just build a house.

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 complex than traditional setups. In theory, it should be simpler, right? A Transit Gateway is a virtual device so easier to configure than a Cisco router, right?

The problem is, as the cloud providers offering gets richer, with time it has to be more complex in response to various customers' requirements, so basically you need to learn both: traditional Linux operations and networking, and a whole new class of interactions between dozens of services with hundreds of API calls. It quickly becomes overwhelming. IaC obviously helps but anybody who has maintained a large repository of CloudFormation code will tell you its not a panacea.

And then a million small quirks that basically come from you not owning the infra. E.g. Amazon is pushing the Control Tower as a model for new setups especially for larger orgs. Guess what, this thing has almost no API. Last time I checked it allows you to maybe check a state of a control. This means you need to set it up manually! In 2023! After 5 years of development! And if you add an OU, you need to register it (you guessed it - also manually!). Say you want to create a dozen of VPC endpoints - they won't have names because there is no API, you need to name them manually. And so on and so forth. Why? because you are living in someone else's place, so you you are totally dependent on them.

Re: Move Back to Datacenters

#36
I'd say the attack surface on rolling your own tech in a datacenter is substantially higher.

Yes DynamoDB has an API, but I'd wager a AWS engineer with good security skills has looked at it carefully. Do you have an equally skilled security expert on hand to look at the datacenters stack and then same for whatever you're deploying on it?

Not all internet exposure is equal. Moving out of cloud often makes sense, but security isn't the right motivation for it.

Re: Move Back to Datacenters

#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 frameworks and life outside of the cloud.

These are the technological foundations of being able to do anything we are doing. Granted, it can be useful to outsource these parts, but that doesn't come without it's very own short and long term costs, it strengthens some market asymmetries that you maybe don't wanna strengthen, it let's your organization forget to do things that are the basis of your business and so on.

I don't say everybody has to run their own infra, just that the work of doing so can pay off in different ways — and whether these trade offs are worth it depends entirely on the nature of your endevour.

Re: Move Back to Datacenters

#38
post #19

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…

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…

The real business case for the cloud is it replaces capex with opex.

Which is great if you have limited capital (bootstrapping, new startup, etc), or are the CEO of a large company that wants to show better cash flow to earn a larger bonus.

In reality, the idea that the cloud somehow means you can outsource your infrastructure team rarely works out in practice.

At best you’ll get much more expensive developers having to spend time on infrastructure which might look like a couple of fewer salaries to pay, but you’re likely now paying for it through dev time anyways.

Re: Move Back to Datacenters

#40
post #28

Move stuff back on-prem. Great. But aside from all the usual practical matters (power, backups, spare parts, service contracts, etc...), software is rapidly becoming a roadblock to move back to on-prem. If everything you have is running on Kubernetes or other open source software, great. If not, then there's an increasing amount of roadblocks being put up: * Some software is only available as SaaS anymore * Jacking u…

> Intentionally knee capping on-prem software feature wise Or unavoidably. We have a SaaS product that's also available onprem - because we have some big enterprise customers who won't accept anything else - but there's a bunch of stuff we take advantage of in the cloud that we can't easily replicate in arbitrary onprem environments. So the onprem software ends up "kneecapped" just out of sheer pragmatism. There's no…

Would you mind giving an example of something that is easy in cloud but hard on prem (all I can think of is scaling up (down?) which seems kinda obviously hard)
Post reply on HN