Kubernetes is everywhere. Transactional apps, video streaming services and machine learning workloads are finding a home on this ever-growing platform. But what about databases? If you had asked me this question five years ago, the answer would have been a resounding “No!” — based on my experience in development and operations. In the following years, as more resources emerged for stateful applications, my answer would have changed to “Maybe,” but always with a qualifier: “It’s fine for development or test environments…” or “If the rest of your tooling is Kubernetes-based, and you have extensive experience…”
But how about today? Should you run a database on Kubernetes? With complex operations and the requirements of persistent, consistent data, let’s retrace the stages in the journey to my current answer: “In a cloud native environment? Yes!”
“Kubernetes is everywhere” is a very bad way of starting an article because it’s not a factual statement.
Started reading but the “former skeptic” thing is not visible to me. I’m seeing masked fanboyism only, so far at least.
I understand that it may be not the best way of starting the article, but if you are developer inside the cloud native bubble it will make all the sense when reading it.
Maybe if it had been complemented with something in the likes of In a cloud native world Kubernetes is everywhere then readers that are not deep inside the cloud native bubble would not feel it as an overstatement.
He explains why he is a former skeptic, you just need to read the article. He does it in the introduction and later here:
My hopes of running a database on Kubernetes came roaring back. Could Cassandra deal with the ephemeral nature of containers? At the time, it felt like a begrudging “I guess?“. It seemed possible, but there were significant gaps in the tooling. To take this to production, I’d need a team of Kubernetes and Cassandra veterans, plus a suite of tooling and runbooks to fill in the operational gaps.
The author is on the K8ssandra project, its a MVP for the Cassandra community and works at DataStax, therefore I understand that he is so enthusiastic about what he is talking about, after all he is a Developer Advocate for Cassandra.
I learned something from the article, but I am a fan of Docker and Kubernetes and I considered to be a DevOps before I came into API security, therefore I have a little of the cloud native bubble inside me 
I’ve still yet to ever touch kubernates other than articles saying how horrible it was to build a fake type system in it to work around Golang’s limitations. I’m still not entirely sure what it does, something like docker swarm but more, or… Lol, I just need to look in to it someday.
I am curious to see this article. Can you share it?
It’s been literal years since I’ve read it and I know it wasn’t just complained about once but a number of times by a number of people, but the first google result looks like a good start about it (I don’t think it’s the one I read, missing some stuff I recall, but still):
I’m the same - quite happy with dedicated servers for the moment…
OK, I read it, and my conclusion hasn’t changed, because:
-
He outlines a very specific case – namely using Apache Cassandra – and I am willing to bet that like 90% of the projects out there (if not 99%) will never deal with that.
-
He outlines mostly the benefits of containers, not Kubernetes itself. Plus what he describes seems to be easier to do with Docker Swarm (which supports the syntax of the
docker-compose.ymlfiles). -
He oversells Kubernetes, by a lot. It’s volume handling was anything but “resilient” last year when I worked in one quite big company; DevOps periodically had to pull backups just because K8s has yet again crapped the bed. Maybe things have improved for a year – I hope so – but I wasn’t that impressed, no, and I did talk with DevOps regularly. K8s works, there’s no doubt about it, but it has a lot of rough edges, and many operational workflows must adapt to it (and IMO the reverse should be happening).
-
He severely underestimates the effort of learning both K8s and its accompanying tooling like Tilt and Helm and 50+ others.
-
What the article pitches – K8ssandra – is a pure demonstration of everything I’ve said so far: K8s is a poor fit for Cassandra in general so they had to make a bunch of scripts and recipes to adapt Cassandra operations to K8s. This is all well and good, and more power to them to have pulled it off, but many teams out there won’t have the time or the human resources to hand-craft all those scripts and recipes for their specific stack. This is overlooked extremely often. People just assume that “the team will learn K8s” and they seriously don’t know what a huge effort this actually is.
I am happy that Kubernetes is improving in general. But it’s a very huge square peg that people keep trying to fit into round holes. This should be recognized widely if there’s any hope that we get an universal container orchestrator like K8s promises it will be (but IMO still isn’t).
Every single DevOps I’ve spoke with in the last 2 years has told me they prefer Docker Compose or Swarm, or Hashicorp’s Nomad. 
I also worked with K8s last year and it was a nightmare for a newbie like me. It was a complete chaos for weeks until I learned to tame the setup.
Am I dumb? Maybe I am, but another thing that must be said is that, again, many teams don’t have extra bandwidth to learn the rocket science 1000-pages worth of book called “Kubernetes”. Just brushing this off with “the team will adapt” is being very misguided and deluded. Not to mention mean.
@Exadra37 I don’t mean to demean what you post but IMO you are starting to tilt in the direction of looking things through the lens of a consultant / developer advocate. And those perspectives can be very different than those of the working programmer or sysadmin. This, too, needs to be recognized.
I like to see the opinions and experiences of others and really appreciate that you took the time to share yours.
The Developer Advocate lens needs to work in both directions. No matter what we advocate for we are your voice in the internal engineer team, be it in API Security, databases or whatever.