![]() |
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Databases are an increasingly popular workload for Kubernetes; in a recent Portworx-commissioned survey of organizations using Kubernetes, over 72% of respondents noted that their teams were running databases on Kubernetes.
Clearly, the discussion surrounding data on Kubernetes (DoK) has matured since persistent volumes in Kubernetes entered general availability in 2019. Teams with more advanced Kubernetes practices are moving beyond the simpler debate of stateless versus stateful applications and the need for persistent storage. Instead, they’re considering how a container data management layer — inclusive of databases — fits with the broader set of business goals, as well as the infrastructure, development and delivery solutions in their internal platforms.
For software, infrastructure and platform engineering leaders, deciding to run databases in containers and manage them with Kubernetes often comes down to some mix of the following factors:
If data is the payload for differentiated value to the end user, then applications are the delivery vehicle. For example, a social news feed provides similar functionality to everyone, but it relies on underlying data to ensure relevance to the reader.
Kubernetes’ declarative nature allows database teams to define consistent deployment guidelines and standardize across development, staging and production environments. This removes database provisioning as a bottleneck, leading to delivering more value, faster, to the end user.
Amid economic challenges, database teams are being asked to do more with less. They must manage more database instances, at greater scale, from more database providers and vendors, integrated with an increasingly complex set of infrastructure services.
Kubernetes offers a way to reduce complexity, as its standardized approach to database deployments across environments simplifies maintenance. While managed cloud databases offer shortcuts to deployment, in practice they often introduce more complexity through managing auxiliary cloud services, with the added drawback of cloud lock-in that drives up costs and hampers data mobility.
Kubernetes is purpose-built to run elastic, scalable, highly resilient applications. Why not allow databases to benefit from running on Kubernetes, as well as the collective knowledge of a massive, global cloud native community building to these principles?
If your applications demand scalable, automated data management with minimal friction, and you need to maintain consistency across development, testing and production environments, running databases on Kubernetes is an excellent choice.
Kubernetes’ advantages include life cycle management, self-service capabilities and enhanced data portability, especially for modern, cloud native applications where schema and data sizes can change rapidly.
Running databases on Kubernetes enables:
Other databases — like terabyte-scale relational database management system (RDBMS) deployments with decades of historical transactional data or massive unstructured data lakes — have inertia, and are unlikely candidates for containerization. They’re big, they’re hard to move and they serve a different purpose than modern databases supporting modern application development.
Let’s say your organization has decided against managed cloud databases or running databases on virtual machines (VMs), and believes that the benefits of faster development velocity, lower costs and risk reduction are worth the leap towards databases on Kubernetes. What else should you and your team consider as you make this change?
As a leader, you’ll likely focus on your team’s priorities, skills and time and invest in technical solutions accordingly. Database teams are generally experts in databases, not in Kubernetes. And while many developers are familiar with containers and Kubernetes, it’s unusual for their primary job to include managing Kubernetes deployments.
Consider whether DBAs or developers will handle provisioning and managing databases on Kubernetes, or if this requires a broader, automated as-a-service approach enabled by an internal developer or database platform. If it’s the latter, you’ll need to decide the level of Kubernetes abstraction your internal platform should offer to support other teams. Additionally, you’ll need to define how containerized databases will be configured with respect to persistent volumes, storage arrays, and backup or data protection policies.
For organizations that have just started their Kubernetes journey, running data-intensive workloads on Kubernetes can seem daunting. (And if this is where your organization is today, you’re far from alone!) But it can be done; businesses like Rivian are running databases on Kubernetes in production and provisioning them within hours instead of days, all while increasing uptime, resilience and controlling costs.
To learn more about how to unlock the value of data on Kubernetes at scale, visit Portworx.com or set up a conversation.