Don't separate the Devs any further!
I work with a large group of bog-standard 'enterprise' developers who write mainly Java and deploy to on-premises Linux VMs. They already barely have a clue between them about the operating environment such as the basics like file descriptors, network sockets and JVM settings.
The idea of abstracting away all the difficult bits into the cloud can sound attractive but it seems to almost invariably end up working out more expensive, and it's still highly complex - just s different type of complexity.
If there's a major problem with your code you've got naff-all chance of diagnosing many types of problem in the cloud and then you're at the behest of whichever provider and SLA you've paid for. In my limited experience with Azure and paid support, even a major issue can end up bouncing around for days between support teams.
Meanwhile, with a very small but experienced group of DevOps engineers - most on-premises issues are diagnosed and fully resolved very quickly.
In fact we keep bailing out projects that were headed for the cloud but failed to get there in the end.
I keep hearing people rave on about Kubernetes and sure, it looks cool. But it's also seriously complex and really needs a whole stack of other tools to become useful.
On the flip side, "serverless" and Functions as a service might be applicable in a limited number of scenarios, and maybe they are more developer-friendly, but they're still hiding a massive nest of complexity behind them.
I totally agree with the previous comments about using the right tool for the job. In this case I think it's still just an ideology which will never work in practice - not because of a technical limitation but because of the need for people to understand it and completely reset their way of designing and writing software.
Biting the hand that feeds IT
