[camsjams]

Is this cheaper though?

For a medium-to-large app, K8s should offset a lot of the operational difficulties. Also you don't have to use K8s.

Cloud is turn-on/turn-off, whereas on-premises you pay up front investment.

Here are all of the hidden costs of on-prem that folks forget about when thinking about cloud being "expensive":

- hardware

- maintenance

- electricity

- air conditioning

- security

- on-call and incident response

Here are all of the hidden time-consumers of on-prem that folks forget about when thinking about cloud being "difficult":

- os patching and maintenance

- network maintenance

- driver patching

- library updating and maintenance

- BACKUPS

- redundancy

- disaster recovery

- availability

[ilyt]

We have 7 racks, 3 people and actual hardware stuff is minuscule part of that. Few hundred VMs, anything from "just a software running on server" to k8s stack (biggest one is 30 nodes), 2 ceph cluster (our and clients), and a bunch of other shit

The stuff you mentioned is, amortized, around 20% (automation ftw). The rest of it is stuff that we would do in cloud anyway and cloud is in general harder to debug too (we have few smaller projects managed in cloud for customers.

We did calculation to move to cloud few times now, never was even close to profotable and we woudn't save on manpower anyway as 24/7 on-call is still required.

So I call bullshit on that.

If you are startup, by all means go cloud

If you are small, go ahead, not worth it.

If you have spiky load, cloud or hybrid will most likely be cheaper.

But if you have constant (by that I mean difference between peak and lowest traffic is "only" like 50-60%) load and need a bunch of servers to run it (say 3+ racks), it might actually be cheaper on-site.

Or a bunch of dedicated servers. Then you don't need to bother to manage hardware, and in case of boom can even scale relatively quickly

[andrewstuart]

This is the fiction that CTOs believe - "it's simply not practical to run your own computers, you need cloud".

[sn0wf1re]

Every one of your examples in the second list is relevant to both on-prem and cloud. Also cloud also has on-call, just not for the hardware issues (still likely get a page for reduced availability of your software).

[hnlmorg]

The problem here is “cloud” can mean different things.

If you’re taking about virtual machines running in a classical networking configuration then you’re not really leveraging “the cloud” — all you’ve done is shifted the location of your CPUs.

However if you’re using things like serverless, managed databases, SaaS, then most of the problems in the second list are either solved or much easier to solve in the cloud.

The problem with “the cloud” is you either need highly variable on-demand compute requirements or a complete re-architecture of your applications for cloud computing to make sense. And this is something that so many organisations miss.

I’ve lost count of the number of people who have tried to replicate their on-prem experience to cloud deployments and then came to the same conclusions as yourself. But that’s a little like trying to row a boat on land and then saying roads are a rubbish way to filter traffic. You just have to approach roads and rivers (or cloud and on-prem) deployments with a different mindset because they solve different problems.

[sn0wf1re]

Yeah, but you still need alerts to see if your lambda breaks. But yes, the managed solutions save a lot of time and effort.

[hnlmorg]

Absolutely. Observability is paramount regardless of where and how your application runs.

[tstrimple]

This is simply not true unless you build in the cloud the same way you build on prem and just have a bunch of VMs. PaaS services get you away from server / network / driver maintenance and handle disaster recovery and replication out of the box. If you're primarily using IaaS, you likely shouldn't be in the cloud unless you're really leveraging the bursting capabilities.

https://robertgreiner.com/content/images/2019/09/AzureServic...

[vlunkr]

“Just not for the hardware issues” is a huge deal though. That’s an entire skillset you can eliminate from your requirements if you’re only in the cloud. Depending on the scale of your team this might be a massive amount of savings.

[jrockway]

At my last job, I would have happily gone into the office at 3am to swap a hard drive if it meant I didn't have to pay my AWS bill anymore. Computers are cheap. Backups are annoying, but you have to do them in the cloud too. (Deleting your Cloud SQL instance accidentally deletes all the automatic backups; so you have to roll your own if you care at all. Things like that; cloud providers remove some annoyance, and then add their own. If you operate software in production, you have to tolerate annoyance!)

Self-managed Kubernetes is no picnic, but nothing operational is ever a picnic. If it's not debugging a weird networking issue with tcpdump while sitting on the datacenter floor, it's begging your account rep for an update on your ticket twice a day for 3 weeks. Pick your poison.

[Aeolun]

> At my last job, I would have happily gone into the office at 3am to swap a hard drive if it meant I didn't have to pay my AWS bill anymore

This seems foreign to many people, but I’d happily take on this responsibility if I get the attendant benefits.

Also incentivices me to make things robust enough I never have to.

[josho]

The flip side is there is an entirely new skillset required to successfully leverage the cloud.

I suspect those cloud skills are also higher demand and therefore more expensive than hiring for people to handle hardware issues.

Personally, I appreciate the contrarian view because I think many businesses have been naive in their decision to move some of their workloads into the cloud. I'd like to see a broader industry study that shows what benefits are actually realized in the cloud.

[ilyt]

Right. The skillset to pull the right drive from the server and put replacement one.

Says that you know nothing at all about actually running hardware as the bigger problem is by far "the DC might be drive 1-5 hour away" or "we have no spare parts at hand", not "fiddling with server is super hard"