Exactly ! What's worse that we seem to have developed this all-in-or-none-at-all approach towards cloud services. Whatever happened to a hybrid approah of using the cloud only for things that you wanted ?
I assume you meant that no-one wants to have to run and administer an RDBMS like Postgres, MSSQL, Oracle, etc - especially not things like backups, restoration, disaster-recovery, figure out storage, ensure high-availability, and maybe even things like user administration and index management: i.e. a DBA's grunt-work - and yes, I agree with you entirely.
...but using the other interpretation of "manage", people might think you meant that people don't want to know how to properly design a normalized schema and apply the business-domain, knowing how to clean-up data appropriately (i.e. the other half of a DBA's job), because we can either shove it all into a cloud vendor's proprietary (and horrendously expensive) non-relational database or data-lake solution (CosmosDB, etc) - or that we can outsource database modelling and implementation of DDL to an LLM - which I'll admit, is quite capable as-is for a first-draft for DB scaffolding and getting better all the time, but ultimately isn't able to take a proactive or autonomous approach to managing an org's databases; I don't want to seem like I'm advocating economic-protectionism of DBAs, but I get the impression LLM-based DBA-bots are being aggressively pitched to smaller-sized orgs that don't know any better, at a time when the technology is still very new, with potentially serious repercussions w.r.t. data-security and compliance (and ChatGPT still gives me T-SQL that uses Oracle functions...).
Most people I interact with are targeting CQRS as the CRUD model is what most people use. The problem with the DB central approach is many faceted as as most people really just need a repository the inherent problems testing, vertical scaling, availability, typical default of procedural cohesion etc... is why people don't care.
The self managed DB servers aren't cheap once you have to scale, typically have availability issues due to ACID rules typically limiting servers to only two AZ's per region etc...
It is actually adopting best practices for software maintainability and scalability that are getting rid of most DBA needs....because most databases use aren't doing batch processing, report generation, backups, job scheduling, or other needs that tend to be the right use cases for relational databases.
Concepts like encapsulation, persistence ignorance, and other methods of ensuring that the persistence layer is as loosely coupled as possible have proven to be cheaper, easier to test, and avoid the lock in you mention above.
As i have had a professional relationship with AWS/GCS here are a few anti-patterns from Microsoft that demonstrate this.
I made a good living as a consultant in the .com era helping companies throw money at their foreign key loving branching stored procedure systems that they couldn't even get to scale past the angel round some times.
And entire companies like AT&T wireless went under in a large part due to failed upgrades due to issues related to having logic in the DB.
DBs can be a good persistence layer when a system is simple and small. But really to work well within a cloud or distributed context they need to be treated as repositories unless there is a compelling technical reason to treat them differently.
'When all you have is a hammer' approach monolithic persistence layer what the primary blocker when I worked with cloud providers to help customers migrate. And they always were paranoid of moving things out of the database. And the funny thing is that most of them were trying to move to the cloud because vertical scaling on-prem DB servers became too expensive and didn't deliver the performance vendors promised.
Had companies followed say the design patterns of micro-services, where each service context has it's own DB, they probably could have stayed on-prem at lower costs.
But for the clients I worked with, who had failed to migrate on their own. Complex fragile schemas, triggers, sp's, etc... where almost always the main issue.
And we knew this even before the commercial internet existed.
