IBM has introduced a new service, called the IBM Cloud Private, that will allow organizations to run cloud-native workloads in their own data centers, using the Kubernetes container orchestration engine, Hashicorp’s Terraform infrastructure management software, and eventually, the Istio service mesh.
“It is becoming almost a defacto standard. I think the ecosystem around it is great because it has the right pluggability points, in terms of ingress and egress,” said Bala Rajaraman, IBM fellow and chief technology officer for the Cloud Services Platform. “That is making it attractive to create enterprise versions of Kubernetes.”
To help its customers go cloud-native, the IBM Cloud Private offers a path to bring WebSphere applications into containers, allowing them to plug into the Kubernetes substrate. This means large, traditional Java applications can easily be managed by Kubernetes and Terraform, which bring with them features like logging, monitoring, fail-over and backups.
“A lot of the apps are built on existing middleware for data and analytics capabilities. Look at things like WebSphere: there are a lot of apps built on that, but there wasn’t a path forward for refreshing the underpinnings of that middleware because they’re stateful applications, and they made assumptions of the underlying infrastructure,” Rajaraman said.
“We can bring these components into a container based platform. We’re taking middleware, like WebSphere MQ, and progressively moving them to a Kubernetes substrate,” said Rajaraman. This will help customers avoid a complete rewrite of their applications.
While traditional applications running on traditional IBM infrastructure can be brought into the new IBM Cloud Private, the platform was also designed to provide benefits to modern applications as well. These are provided not just by Kubernetes, but eventually by Istio. While Istio is still a very young project, Rajaraman said that it will eventually become the governance and control plane for the IBM Cloud Private.
“We see Istio as supporting the service mesh that is going to be an obvious consequence of not only decomposing into microservices but microarchitectures. It supports virtual machines and containers, so that made it attractive. It also has things around certificate management and circuit breaker management. These are things that are going to become necessary in terms of enterprise-grade microservices,” said Rajaraman.
While that single control plane is appealing, containers and their management are a bit opposite to the traditional Java way of doing things, where a single application server was tweaked, tuned, and made to run all the workloads all the time.
“How do I unpeel that,” asked Rajaraman. “An app server is not necessarily a bad thing, it’s how things get packaged and how the app is constructed on top of it. We’ve taken WebSphere and decomposed its stateful characteristics into shared storage. That’s why we like Kubernetes: the attraction to a lot of these existing systems was manageability.”
Some years ago, this type of management and on-premise cloud solution was the purview of OpenStack. Today, however, Kubernetes seems to have taken over mindshare, thanks to a relatively simpler architecture.
“I think this has been a progressive market maturity. OpenStack tried to offer a particular type of services: infrastructure-as-a-service. It grew both deep and broad, and the associated complexity of management grew also. Kubernetes is easier because there’s a clear deconstruction between the infrastructure and how you build on top with containers,” Rajaraman said.
The Kubernetes platform, with the help of associated plug-ins and external services such as Helm Charts, offers flexibility, high-availability and the ability to control state automatically. “The best analogy I can think of is the Linux kernel, which is light and fast. You can plug in different file systems or drivers,” said Rajaraman.
For the future of enterprise cloud, Rajaraman sees a complex world of service level agreements (SLAs) emerging. He hopes that IBM can help administrators and CIOs help to manage the complicated differences that will likely emerge between disparate SLAs.
“We are moving to that realm where individual services are not going to be important enough, but the integrations of services will be. I think the definition of SLAs is going to get a lot more complicated,” said Rajaraman. “Enterprises will need tools for not just SLAs but to manage to SLOs [service level objectives] below those services. There are a lot of technically challenging issues around data and data mobility, but I think that’s what we’re progressively moving towards.”
Feature image via Pixabay.