Source: containerjournal.com
IBM Combines Blockchain and Kubernetes Expertise Through Red Hat
IBM is leveraging the Kubernetes expertise of its Red Hat subsidiary to simplify deployment of its blockchain platform and to streamline management of Apache CouchDB instances running on Kubernetes clusters. The move reflects IBM’s broader strategy of integrating enterprise workloads — including stateful and blockchain-based applications — into container-orchestrated infrastructure.
IBM Blockchain Platform on Red Hat OpenShift
The IBM Blockchain Platform is built on Hyperledger Fabric, an open source enterprise blockchain framework maintained under the Linux Foundation. IBM has deployed this platform on Red Hat OpenShift, a Kubernetes distribution that brings enterprise-grade container orchestration to hybrid cloud environments.
Running the IBM Blockchain Platform on OpenShift offers several concrete benefits:
- Portability: Workloads can move across on-premises data centers, private clouds, and public clouds without significant re-architecting.
- Containerized smart contracts: Smart contracts (chaincode) run inside containers, improving isolation and consistency.
- Hybrid cloud support: Peers, certificate authorities, and ordering services can be distributed and managed across hybrid cloud environments.
- Immutable records on Kubernetes: Blockchain ledgers represent a particularly demanding form of stateful, immutable record-keeping — a meaningful test of Kubernetes’s suitability for stateful workloads.
CoreOS Operators Power CouchDB Deployment and Management
In parallel with the blockchain initiative, IBM is using Kubernetes Operator software — originally developed by CoreOS and inherited by Red Hat through its acquisition of CoreOS — to automate the deployment and lifecycle management of Apache CouchDB document databases.
Adam Kocoloski, Vice President and CTO for IBM Cloud Databases, explained that the Operator pattern makes it straightforward to provision CouchDB instances on a Kubernetes cluster and progressively automate common operational tasks such as scaling, backups, and upgrades. IBM has already vetted this CouchDB Operator in its own cloud service environments before making it more broadly available.
IBM also plans to offer commercial support for CouchDB alongside its managed Cloudant service — the hosted CouchDB-compatible database platform IBM acquired in 2014.
The Role of Database Administrators Is Evolving, Not Disappearing
Despite the automation that Operator software brings to database operations, Kocoloski does not expect the database administrator role to disappear. His reasoning is pragmatic: as the number of stateful applications running on Kubernetes grows, so too does the number of database instances requiring oversight. Greater automation raises the ceiling for how many instances a single team can manage, but it does not eliminate the need for human expertise.
Kocoloski also noted that fully autonomous database management remains more of an aspirational goal than a current reality — a distinction worth bearing in mind when evaluating vendor claims around “self-managing” databases.
Stateful Workloads on Kubernetes: An Emerging Pattern
One of the more significant observations from IBM’s experience is the type of stateful application making its way onto Kubernetes clusters. According to Kocoloski, traditional systems of record — core transactional databases that have always demanded high durability guarantees — are not the primary driver. Instead, systems of engagement (applications focused on user interaction, collaboration, and real-time data) account for the bulk of stateful Kubernetes deployments.
This matters for platform teams for several reasons:
- Storage and persistence requirements differ significantly between engagement and record-keeping workloads.
- Consistency and durability guarantees needed for systems of record are harder to achieve on Kubernetes without careful configuration of persistent volumes and storage classes.
- Scale testing for stateful Kubernetes workloads is still ongoing across the industry; there is no single, universally accepted benchmark for what scale is achievable.
Stateless Workloads Shifting to Serverless
Containers have traditionally been the go-to approach for stateless application components, but many of those use cases are now being absorbed by serverless computing frameworks. This shift is, in part, what is clearing the path for Kubernetes to take on more stateful responsibilities: as stateless workloads move to functions-as-a-service platforms, container orchestration platforms like Kubernetes are being evaluated for increasingly persistent, data-intensive work.
IBM Cloud Paks: Replacing Legacy Middleware with Kubernetes-Native Services
IBM’s investments in Kubernetes extend beyond blockchain and databases. The company has been rolling out IBM Cloud Paks — containerized software bundles that replace traditional WebSphere middleware with Kubernetes-based microservices. This represents a broader architectural shift within IBM’s software portfolio toward cloud-native delivery models.
The Larger Enterprise Kubernetes Debate
As of late 2019, enterprise Kubernetes adoption was still maturing, but the nature of the conversation was changing. The question was no longer simply whether to adopt Kubernetes, but rather which workloads should run on it, at what scale, and when. IBM’s moves — deploying blockchain, bringing Operators to database management, and replacing legacy middleware — are a concrete example of how a large enterprise vendor was answering those questions in practice.
For DevOps teams evaluating their own Kubernetes strategies, IBM’s approach illustrates both the opportunity and the complexity: Operator-based automation can dramatically reduce operational overhead for stateful workloads, but it requires careful architectural thinking, vetted tooling, and skilled personnel to manage at scale.