The small players will always stay niche, a cloud is effectively a network monopoly (like iOS and Android) with most companies only wanting to invest in the cloud that's going to have everything they need when they need it, they'll still offer proprietary services to differentiate against the other 2 cloud vendors and additional way to lock you in and make it harder to migrate away.

You could choose to build out your system to be completely cloud agnostic but that is generally regarded to be economically irresponsible in itself preventing you from leveraging the best features available in each cloud.

I don't see it being anywhere near that clear-cut.

Seems more akin to what the RDBMS world went through for a long time, and still does, because people insist on using things other than Postgres[1]. You can stay SQL-standard compliant, writing your app to be portable. Or you can use these appealing proprietary extensions to the spec, and not be portable.

Seems like a majority of folks writing in-house choose to use the extensions, and the majority of folks who want others to use their software make an effort to be cross platform.

You'll probably see a similar split with cloud services, although I'm not sure it will necessarily follow the same lines.

[1] That's a joke, there.

This is only true as long as the costs of maintaining a cloud provider abstraction layer are greater than the costs of being locked in to a single vendor. I believe that some businesses, once they are armed with an abstraction toolkit like this, will be able to employ arbitrage between the cloud vendors for themselves, and sell that toolkit to other companies who want the same kind of freedom.

And then somebody creates a free software alternative, and will maintain it and keep it up to date.

but the assumption is that this layer is free (due to OSS), and the "owners" of this layer cannot pull the carpet under you by raising prices.

Billions of dollars and years of constructions to just start trying to enter the market, where you will fail because your offerings are relatively pathetic on multiple fronts.

When Google and Amazon are not making their own specialized hardware (good luck implementing your own TrueTime or TPU or competing with them with ML or DB products built on off-the-shelf stuff) they get custom made chips at prices you can't by Intel et al and have things like a very sophisticated SDN backed by a private global physical network infra and enormous amounts of expertise of building and running very efficient DCs. And then there is a software stack which often is literally more than a decade ahead of industry practice.

What's gonna be more useful CV and CYA wise? Who's ever been fired for choosing AWS? How is being expert in <obscure hosting provider> going to advance my career? Where do I hire people who know about <obscure hosting provider>? How would I even realistically learn that <obscure hosting provider> might be a good fit for my needs?

Honestly I can’t see the cloud making sense for another decade.

NVidia’s new hobby board for $99 + open source has me imagining a future where someone like myself can offer similar experiences to Alexa or a number of Googley features to family and friends in a few years.

Just curious, you are going to host your database on k8s? Or is there some other solution you are looking at?

My understanding is that k8s is great when you need stateless services, but gets more complicated when you need to maintain state. Been a while since I looked at it, though.

We also have a job that runs nightly to make a dump of the db and store it in the object store and the persistent disk has a snapshot scheduled for every two hours and in both cases, we are backing up the binary logs, so we can do point in time recovery much like AWS's Aurora offering.

We may eventually switch to a mariadb Galera cluster where there are 3+ master pods that distribute the load and can stay available if one pod dies. But I haven't done the research on stability of that setup yet. A few years ago it wasn't ready yet, but I imagine it is by now.

Our K8s deployment is setup to automatically make backups and test those backups periodically with a full restore. It also notifies us in case of a failed backup. Updating the software is as easy as a single helm command and scaling is about the same as with Aurora. Either you set it up to scale up automatically or you go in and upgrade instances when needed.

Aurora admins aren't monitoring your server for performance issues then making configuration tweaks to speed things up. So I'm not really seeing a lot of difference.

Your CTO is no more going to risk an infrastructure migration because you pinky promised that it would be “seamless” than your DBA is going to migrate from your seven figure Oracle installation to Postgres because you used the “Repository Pattern to abstract your database access”.