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 …

[Anonymous Coward]

Ermm...

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.

[yoganmahew]

Re: Ermm...

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.

[elsergiovolador]

Re: Ermm...

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.

[Charlie Clark]

Re: Ermm...

If it's done correctly, that shouldn't matter that much. DB read performance comes from having the right indices as this is always magnitudes faster than scanning. But launching instance after instance of a DB is going to require careful configuration.

[lotus123]

Re: Ermm...

That is what I do. I rent bare metal servers. Fsck that cloudy rip-off

[Warm Braw]

Re: Ermm...

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.

[Charlie Clark]

Re: Ermm...

It's not the storage, it's the configuration.

[Anonymous Coward]

* Special today fom PostgreSQL *

* Our canned quotes are, seasoned with extra flavorful commas *

[Charlie Clark]

The truth about microservices

Deploying a microservices-based database is a big technical project: it’s hard to do

[elsergiovolador]

Re: The truth about microservices

I've seen so many microservices running on hundreds or thousands containers with all the complex monitoring, that it all could be merged into one small app on a single server and probably would run much better. The kool-aid tax.

[Anonymous Coward]

Running your database on a container is fine - just don't expect scaling and high availability via the container nor expect your DB to be up all the time unless you control the platform - and with K8, nope.

[Claptrap314]

Does this guy think that K8s just swaps pods between nodes at a whim?

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.

[Saywhat7]

Re: Does this guy think that K8s just swaps pods between nodes at a whim?

Of what I have seen you may need to drain the pods before doing a node upgrade. It can be a bit of a mare for databases such as Cassandra when that happens.

[Claptrap314]

Re: Does this guy think that K8s just swaps pods between nodes at a whim?

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.