Enterprise databases deployed in Kubernetes? Proceed with caution, warns seasoned analyst A leading analyst has warned big, non-tech companies against database deployments in the Kubernetes, dubbing the approach as “emerging technology” for enterprises. While developers might want the flexibility and agility the stateless container orchestrator promised, Carl Olofson, research vice president, data management …
Most modern databases are multiple stateless engines pointing at a stateful storage array. Does this "seasoned analyst" know what he is talking about?
One of the strong points of storage arrays is so that you can back up *everything* in one place, using one set of tools. As such, running your DBs/webservers/etc in a temporary container is no different to running it on hardware that occasionally has a powercuts - the important data survives even if the machine burns.
If what he is saying is Kubernetes is new, then... well... by the time your Enterprise database is decommissioned, it's going to be ancient.
Yeah, and if you're in GCP, Spanner or Firestore as your persistence layer exist whether you care about them or not - they are accessible from your cluster, but outside it.
If what he's further saying is you don't understand what Spanner and Firestore are doing, well, when your last mainframers retire, you won't understand your data centre either.
Don't you get a huge latency and performance penalty when using DB with a storage array and this type of workload?
I mean it's all convenient for cloud providers, as slow database means customers will be trying to buy beefier instances and pay more.
The best way is to have a dedicated bare metal boxes with local storage to run database on and then have Kubernetes services connect to it.
This post has been deleted by its author
I wasn't entirely sure what he meant so did a little exploring and some of the issues are explained here.
I think the other key point is that with most traditional (relational) databases you can't just randomly fire up multiple container instances as load demands: your replication and partitioning/sharding are not typically things you can simply change on the fly. Cloud Spanner is fundamentally different in this respect as it does automatic sharding and this requires the database to be aware of the load in a way which would be difficult to imagine with present container technology.
Because it most certainly does not. In fact, if I understand what the class I'm taking is saying, you can upgrade the version of K8s on a pod while the containers just keep running.
What K8s DOES let you do is say, "My cluster currently runs on 4 servers. I need to do a deep upgrade, so I'm going to allocate an additional server with the upgrade, and then take one offline. Four times. By pushing a yaml file & doing a one-liner."
K8s has plenty of issues. But long-running stateful tasks are not particularly hard for containers, or for K8s.
Now, if he's talking about running the database in the cloud, where you have at most limited control over when your server is going to go away, then yeah. That will take some serious work. But that has nothing to do with K8s.
You are saying that Cassandra cannot handle a (Cassandra) node going down? When did that happen?
I mean, it's been almost ten year since I saw the presentation, but I'm pretty sure that distributed resilience was a core aspect of Cassandra's architecture. I seriously doubt that they would give that up.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
