Do you run your database on Kubernetes? This has been an evergreen debate. Where does it stand now?
Kubernetes has come a long way from running only stateless workloads early on to now supporting statefulsets with improvements in sticky identity, persistent storage and unique network identity. Kubernetes has democratized the container orchestration and given the world tools to run most software at scale. This is only one part of the solution.
Databases built to run directly on servers or virtual machines have different features to make them highly available, resilient and scalable. Now if you bring those databases and run them on Kubernetes then it is a recipe for disaster. In the recent years, there have been cloud native databases built to run on Kubernetes. This is the remaining part of the solution.
You have a container orchestrator platform like Kubernetes which runs most of your software and now with cloud-native databases, you can run them on Kubernetes too.
Best of both worlds? What about latency? How do you handle frequent k8s release upgrades every three months? Now with EKS Auto mode, the worker nodes max lifetime is just 21 days. Imagine moving around your database nodes every two-three weeks? Is it recommended in production? Do you instead use managed database service from hashtag#AWS hashtag#GoogleCloud or hashtag#Azure?
There is no right or wrong answer and "It Depends" on the software architecture and business constraints.
I would like to hear from you all. Write your opinion in the comments below. Do you run your database on Kubernetes? Why? Why not? What are your reasons? Are you using it in production? What is the adoption for such databases?
Top comments (0)