[darkwater]

I'm a "DevOps" working in a company 100% on AWS and know what? There are hundred. thousand of men-hours per year of "DevOps" work, even in the cloud, even when using managed services. You don't need to manage a VPS maintenance but you do need to spend time refactoring Terraform code, you need to check for the best EKS workers to not shell out a fortune, now you have to migrate things to ARM/Graviton because Finance is telling you that we are throwing money away. Heck, you need to have 1 full-time people to control the bill and the spending!

You might say these problems come more from the scale of the business rather than the bare-metal/cloud dichotomy, but if you are a in startup like the linked article is about, well, you still have to do all the work and it doesn't change too much if you have to know how AWS/Azure/GCP work and bills you or which command-line backup tool you want to use. There will always be more than just pure code.

[Nextgrid]

> you need to check for the best EKS workers to not shell out a fortune, now you have to migrate things to ARM/Graviton because Finance is telling you that we are throwing money away

A lot of software projects I've been involved in had some extra complexity (asynchronous processing, etc) because the cloud is expensive and the hardware they ran on was underpowered as a result. This introduces more moving parts and you have less margin of error. These moving parts (as opposed to the underlying hardware) can fail and cause an outage and this may happen more frequently than if you were operating on a single, hardware point of failure, defeating the entire purpose.

In my own project running mostly on bare-metal it is much simpler because a lot of worry about cost or performance goes away. Yes I could put this in a queue and maybe it's the right solution down the line, but in the meantime I have so much CPU that I can afford to do the task on the main thread and not worry about any of this. I also have much more margin for error in terms of resources (CPU/RAM/disk) so that if a process does go haywire it'll take much more time for it to cause an issue, buying you time to notice and fix the problem before it takes the whole system down.

[MikeDelta]

There is this whole level of complexity in enterprises where enabling groups package or wrap cloud services that should be used by their devops teams, such that the result is compliant to the company's standards for security and monitoring etc.

Even though the product of the vendor doesn't change, there is a constant maintenance load on the devops teams to keep the internal packages/pipelines up to date with whatever the enablement teams cook up every time.

When doing new things, most time is lost in navigating the landscape and setup of these pipelines and products, firewall rules, network rules, which live in another documentation universe from the cloud as the world knows it.

No matter what you do, IaaS or SaaS: the enterprise is going to keep you busy.