But getting a good replication setup that's HA, potentially across multiple regions/zones, all abstracted under K8s - yea. That's not trivial. And, it can go very wrong.
> I bet you also hate on people making their own espresso instead of just going to starbucks
This is just unnecessary.
>This is just unnecessary.
I agree the ad hominem is not required, although the analogy is itself decent.
> In Comments:
> Be kind. Don't be snarky.
We also have managed databases, too.
Self-managed stuff means I can, generally, get shit done with it, when oddball things need doing. Managed stuff is fine right up until it isn't (i.e., yet another outage with the status page being green), or until there's a requirement that the managed system inexplicably can't handle (despite the requirement being the sort of obvious thing you would expect of $SYSTEM, but which no PM thought to ask before purchasing the deal…), and then you're in support ticket hell.
(E.g., we found out the hard way that there is not way to move a managed PG database from one subnet in a network to another, in Azure! Even if you're willing to restore from a backup. We had to deal with that ourselves, by taking a pgdump — essentially, un-managed-solution the backup.
… the whole reason we needed to move the DB to a different subnet was because of a different flaw, in a different managed service, and Azure's answer on that ticket was "tough luck DB needs to move". Tickets, spawning tickets. Support tickets for managed services take up an unholy portion of my time.)
If you don't have state, why not just either use something serverless/fully-managed (beanstalk, lambda, cloudflare workers whatever) if you really need to scale up and down (or have very limited devops/sysadmin capacity) or deploy like 2 or 3 bare metal machines or VMs?
Either sounds like a lot less work to manage and troubleshoot than some freaking k8s cluster.
If not rather use a specialist service like RDS for anything with serious uptime/throughput requirements.
k8s doesn't really make sense to me unless it's for spinning up lots of instances, like for test or dev envs or like in the article where they host DBs for people.
Hobbies are not the same as bottom line business.
As with everything, managing state at scale is _very_ hard. Then you have to worry about backing it up.