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

Move Back to Datacenters

rakkhi.substack.com

Post reply on HN
Print view View original

21–30 of 97 posts

Re: Move Back to Datacenters

#21

Post by hdjjhhvvhga »

> Serverless functions – still running on someone’s server… but if you have a function that you need to evoke infrequently and cold start times don’t matter that much, yeah good for cloud.

While I agree in principle, these functions don't exist in thin air. You will often want to store the results somewhere. And then protect them. So with time you are almost replicating a lot of infrastructure. And if you are a big org you will probably want to enable SecurityHub and other security/governance services like AWS Config and things get expensive again.

Re: Move Back to Datacenters

#22

Post by johncolanduoni »

qaq wrote: post #11
johncolanduoni wrote: post #9

Earlier quoted context omitted.

It requires concurrent execution on the same core of multiple VMs, which none of the major cloud providers do (at least on machines new enough to have Zen cores).

Sure they do for "serverless workloads"

I can’t find specific documentation that indicates that AWS deploys firecracker with core isolation (though I would be pretty surprised if they didn’t given their documented caution around shared-core VMs). Google uses gVisor with Linux Core Scheduling to prevent this for GKE sandbox, but I can’t find any documentation that they do the same for Cloud Functions.

In any case ”don’t use serverless functions” is a very far goalpost from “move back to the data center”.

Re: Move Back to Datacenters

#23

Post by RedShift1 »

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 up prices to ridiculous levels for on-prem licenses (to favor their SaaS offering of course)

* Intentionally knee capping on-prem software feature wise

* Stifle development of the on-prem product

* Force you to use some parts of their cloud services to make other things work

* Dark patterns and endless nags in software to push people to use some part of their cloud services

* Poor documentation how to install/use/maintain the software on-prem or make it needlessly complex

* Slower response from the software vendor in case of security issues

* Exporting data from the cloud and importing it on-prem is impossible

And I can make this list go on and on and on... My point being, for small time firms that don't have the resources and solely rely on commercial software, moving back might not even be an option anymore.

Re: Move Back to Datacenters

#24

Post by [deleted] »

tmpX7dMeXU wrote: post #13
politelemon wrote: post #2

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…

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…

[deleted]

Re: Move Back to Datacenters

#26

Post by [deleted] »

politelemon wrote: post #2

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…

[deleted]

Re: Move Back to Datacenters

#27

Post by di4na »

politelemon wrote: post #2

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 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 move to onprem, but orgs can barely hire the talents they need already. Sure let put even more pressure on a limited supply.

Re: Move Back to Datacenters

#28

Post by antonvs »

RedShift1 wrote: post #23

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 not a single missing feature onprem that isn't because it would be too much effort to implement and support it.

> Stifle development of the on-prem product

Similar issue here. We have finite engineering resources, and onprem is a fraction of revenue.

> Force you to use some parts of their cloud services to make other things work

See first point.

> Poor documentation how to install/use/maintain the software on-prem or make it needlessly complex

See second point.

In short, many of the things you're saying are indeed disadvantages of onprem products today, but it's often not the result of some sort of "intentional kneecapping" or "dark patterns". In my direct experience, it has never been the result of that.

Re: Move Back to Datacenters

#29

Post by HolyLampshade »

RedShift1 wrote: post #23

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…

I noticed this issue a few years ago looking for COTS or OS distributed schedule/process managers to replace a home grown solution to reduce some support risk.

Turns out in the two decades I’ve been in my industry everyone else has gone to ‘the cloud’, and the tooling has gone with it. Every product or project I looked at was skewed entirely toward physical host agnostic and/or single service reliability agnostic management.

So not only is in an issue with going back on prem, there’s entirely unserviced customers that cannot adopt the tooling given the direction it’s been developed.

Post reply on HN