Couchbase’s Kubernetes operator approach eliminates the need for custom scripts that organizations spend time on to automate management tasks.
Couchbase has made it simpler to deploy its namesake document database on top of a Kubernetes cluster using operator software that automates the management of routine database tasks.
The Couchbase Autonomous Operator for Kubernetes is essentially an application-specific controller that extends the Kubernetes management functions using application programming interfaces (APIs) defined by the Cloud Native Computing Foundation (CNCF) that oversees development of Kubernetes, says Dave Finlay, vice president of engineering for Couchbase.
See also: Kubernetes 1.11 rolls out for general release
That approach eliminates the need for many of the custom scripts that organizations spend time writing themselves to automate management tasks, says Finlay.
“It’s all built into the Operator,” says Finlay.
Couchbase claims that initial beta users of Couchbase Autonomous Operator for Kubernetes are reporting a 95 percent reduction in operational complexity.
As interest in microservices based on containers running on Kubernetes continues to rise, Finlay says there’s been a marked increase in the number of organizations looking to deploy stateful applications on Kubernetes clusters.
As an open source document database built from the ground up for distributed computing environment, Finlay says Couchbase is increasingly seeing many of those deployments being driven by developers looking for a database platform that is simple to deploy and manage using best practices rooted in DevOps processes. Couchbase also expects Kubernetes to become a foundational element of hybrid cloud computing strategies that will be based on instances of Kubernetes running on-premises and in the cloud, adds Finlay.
Kubernetes stateful application use still new
While Kubernetes has emerged as a de facto standard for deploying containerized applications, deployment of stateful applications on Kubernetes in production environments is still in its infancy. Various persistent storage project led by the CNCF remain works in progress.
But as those projects advance it’s now only a matter of time before more stateful applications are deployed on Kubernetes. Those deployments, however, may further exacerbate long-simmering tensions between developers and database administrators. Many developers opt to use open source document databases because they don’t require a DBA to set up a schema for the developer before they can be employed. Developers often argue that the speed at which applications now need to be updated requires a more flexible alternative to traditional relational databases. But the challenge that creates over time, however, is the number of document databases distributed across the enterprise starts to rapidly increase, an issue that will only loom larger as developers leverage DevOps processes to automate deployment of containerized databases on Kubernetes.
Of course, not every organization want developers to spend time managing databases. Every minute a developer spends managing the underlying database is theoretically one less minute they are spending writing code. The person that eventually assumes responsibility for managing document databases may not be a classically trained DBA. But within the construct of DevOps processes most organizations will probably try to establish some form of a middle ground between developers and administrators. The only real issue is whether that middle ground will be established before or after silos of document databases wind up being distributed all across the enterprise.
