In today’s digital era, you cannot avoid the technical debt that comes with Kubernetes (K8S).
As an open-source platform for containerized application deployment, automation, management, and scaling, it set a new bar for cloud-native innovation. Some might even say that K8S throttled it.
Its ability to work in the cloud and on-premises environments meant that large enterprises with legacy baggage can take advantage of cloud-native innovation. DevOps teams can focus on their CI/CD pipelines and not worry about the granular details of cloud management.
It made large enterprises more responsive and agile to market demands without being held back by the past infrastructure buys. Using containers, they can also “lift and shift” their core legacy applications until they can phase it out — or modernize it — for a cloud-native version in the future.
But for all the promises of freedom that K8S brings to the table, it does add complexity. And this is where the technical debt comes in.
New debt formula
The most obvious is that K8S offers command-line interface (CLI) control, which can be daunting for developers who prefer working with feature-rich UI.
But beyond the cosmetics, the biggest challenge is that K8S can be cloud platform-specific. Almost every cloud provider or hyperscaler has its flavor of Kubernetes. You also get different add-ons, plug-ins, and app connectivity instructions.
While this approach makes sense for hyperscalers while allowing for app performance optimization, it becomes a challenge for DevOps teams working in hybrid clouds or across multiple clouds.
No developer likes to reconfigure the development environment several times, which you have to do with K8S if your favorite hyperscalers have their own distribution and cloud services or are not near your business location. Plus, the lack of quick start application templates in different coding languages can make it daunting to get started. Finally, there is also the governance challenge as visibility becomes occluded when working with various cloud platforms.
All these challenges add technical debt. DevOps and digital teams have to spend time and resources managing the application platform. This is one reason why Red Hat shifted its OpenShift (no pun intended) focus from the K8S infrastructure management layer to an application platform built on K8S by adding the above features into the platform.
“I think from the business value point of view, what’s really appealing is the time-to-value. Because we've built our position as an app platform — to build, deploy and manage your apps — customers do not need to invest resources in creating a custom platform. So this improves the time-to-value for innovation, and your product development teams can focus on the business logic or the competitive differentiation and not worry about the technical details underneath,” says Paul Whiten, DevOps business development manager for APAC at Red Hat.
Aligning with enterprise needs
OpenShift is hardened for enterprise use. “We've secured it; we tested it. And we’ve provided the security support in terms of all the necessary certifications on the different platforms and so forth,” explains Whiten.
By offering a standardized platform for container development, OpenShift allowed enterprises from different industries to deploy to drive cloud-native innovation.
“Because of our new positioning, we're reaching new markets and new teams. So there isn't one vertical where we don’t see the adoption of OpenShift. And more importantly, we see it adopted across different sized organizations,” says Whiten.
The Red Hat OpenShift Managed Cloud Services makes K8S development easier for resource-strapped SMEs.
“We are providing the flexibility of consumption. And basically, it means that customers can pilot OpenShift and see whether it’s the right solution for a certain initiative. And I think this is particularly important in the SME space. And because it’s managed, you do not have to worry about hiring and retaining the technical expertise,” Whiten argues.
In turn, this has helped open up new use cases beyond traditional enterprise use cases of containerizing monolithic legacy applications.
“We're seeing more use cases where businesses are looking to re-architect for cloud-native and run on OpenShift platform or a Kubernetes platform. And beyond that, we're seeing new use cases which are taking into account things like your 5G and edge IoT implementations,” says Whiten.
Other areas that Asia Pacific companies are exploring new use cases include AI and machine learning such as in the medical field through proactive diagnosis from analyzing scans; and real-time data processing such as for self-driving cars.
IBM Cloud Satellite adds a new dimension
Red Hat is now taking the next step in the OpenShift journey. The vendor is now looking at data science, especially DataOps and MLOps, where similar constraints appear, and calls for standardization and platformization are growing louder.
The collaboration with IBM on its Cloud Satellite product aims to broaden the case and strengthen OpenShift’s role as the application platform — especially in hybrid cloud environments.
“Hybrid cloud brings about complexity. And what OpenShift and IBM Cloud Satellite aim to do is simplify it as much as possible because we want to have a consistent set of services, regardless of where you're consuming the resources. It also offers the visibility and control that enterprise governance needs. So, we satisfy both sides,” says Whiten.
This level of transparency and control is becoming critical as CISOs become involved in DevSecOps.
“We've only got one CISO and maybe two or three cybersecurity people in an enterprise. So, how do we scale that knowledge across maybe 10 or more different product teams? That's where OpenShift and Cloud Satellite can potentially come in. So that way, you're building security, you're deploying security, and you're running securely. So the CISO is happy, and the developers are happy because they can push to production and not have to go through a security change control board every time,” says Whiten.
And by doing this, Red Hat is looking to lower the wall of technical debt that every cloud-native innovator faces.
Winston Thomas is the editor-in-chief of CDOTrends, DigitalWorkforceTrends, and DataOpsTrends. He is always curious about all things digital, including new digital business models, the widening impact of AI/ML, unproven singularity theories, proven data science success stories, lurking cybersecurity dangers, and reimagining the digital experience. You can reach him at [email protected].
Image credit: iStockphoto/SIphotography