For an enterprise that wants to optimize their cloud native application environment, two initial decisions are key: 1.) Adopting Kubernetes for container orchestration and 2.) selecting a platform provider. Once Kubernetes gets the nod and OpenShift, the enterprise cloud native leading platform, is chosen, it benefits the DevOps and platform team to have a well thought out plan in place for successful implementation.

In this two-part blog, we turn to an expert for some implementation guidance. Jonathan Le Lous is CTO of cloud native infrastructure for Capgemini and has deep knowledge of how to successfully design and implement OpenShift. After over 20 years of direct involvement in open-source software and as a program committee member for the Linux Foundation, he embarked on his first OpenShift journey five years ago. He has since been actively involved in guiding numerous Capgemini customers in their transition to Red Hat OpenShift.

 Part one of this blog covers:

• Key considerations for adopting Kubernetes
• How to successfully navigate the path to OpenShift

Part two will delve more into data security and focus on why selecting Kasten K10 is the obvious choice for its storage and disaster recovery (DR) features. With its multi-cloud compatibility and Kubernetes-centric design, Kasten K10 addresses the increasing importance of securing stateful application data. It also emphasizes the significance of robust security and reliable automated protection for stateful applications.

Adopting Kubernetes: Key Considerations

Where do you start with adopting Kubernetes? Well, you could initiate the process from scratch by independently using an open-source Kubernetes platform for container orchestration. However, this may not be the most practical approach due to the inherent limitations that come with some open-source solutions. Cloud providers like Amazon AWS, Microsoft Azure, and Google Cloud can also offer managed services, but these are predominantly tied to just their specific services, which restricts your ability to manage your data and operations across multiple clouds and on-premises environments.

The most critical question isn’t about whether Kubernetes can run in production, but whether your organization has the resources and expertise it needs to embrace an “Infrastructure-as-code” approach. Kubernetes adoption is ultimately about navigating the challenges of technological integration, organizational changes, and evolving roles within the organization.

Most Kubernetes deployments are at scale and consist of 51 or more nodes, according to the CNCF annual report shown above. Collaborating with a trusted consulting partner for Kubernetes adoption can help you avoid the pain and challenges that others experienced may have in the past. Le Lous shared Capgemini’s success in moving thousands of containers, assisting clients in scaling their own operations, and facilitating large-scale transformations. This process requires significant effort in rebuilding and rethinking your business strategies while also focusing on competitive challenges and opportunities.

For some organizations, there’s the temptation for DevOps teams to try and shift to Kubernetes without a consulting partner or platform provider. While DevOps team members may be enthusiastic about container technology and cloud services, the reality is that most organizations ultimately lack the resources to build, manage, and scale their clusters independently. Le Lous emphasized the importance of relying on Kubernetes service and platform providers, which is where OpenShift has proven to be invaluable.

Le Lous previously experienced much of the heavy lifting that comes with Kubernetes adoption and management in-house and leveraged support from the open-source community. This approach was necessary before Kubernetes orchestration platforms like OpenShift evolved to make cloud native adoption processes more manageable. OpenShift’s growth has proven particularly beneficial in scenarios where IT isn’t the core focus, like in banking, where managing finances takes precedence over IT. In these cases, individuals may not always have the expertise needed to effectively implement open-source software.

Le Lous also clarified his role, emphasizing that he’s not a UX designer, nor does his responsibility extend to orchestrating various Kubernetes components for the best developer experience. This domain belongs to OpenShift and Red Hat.

A Big Shift in How Developers Work

Microservices, APIs, and load balancers play a crucial role by serving as buffers and interfaces within the Kubernetes framework. By using smaller, focused teams, often referred to as “pizza makers”, organizations are better able to realize the benefits of microservices and agile methodologies. This approach then forms the structure of the entire Kubernetes infrastructure, including the CI/CD process for software firms.

Kubernetes facilitates decoupling and, due to its immutable structure, also enables scalable infrastructure deployment with minimal commands and processes compared to traditional mono-application IT environments. Different areas within Kubernetes, such as pods (i.e., groups of containers), services, namespaces, Ingress, and service mesh, contribute to regulating access control and interactions between microservices.

The operations team also plays a crucial role in managing infrastructure, designing APIs for developers, and establishing service level agreements (SLAs) for their work. Initially, developers were not as actively involved in this process, Le Lous said. This is because, during the initial stages of infrastructure development for a project, there’s less need to engage with developers.

“You’re setting up the foundational elements — opening the network, connecting components, building the basics,” Le Lous said. “It is when you progress into automation that you do not necessarily need extensive communication with developers. In the context of orchestration, particularly with Kubernetes, the expectation is minimal. Kubernetes primarily serves as an infrastructure-oriented container orchestrator.”

However, the main challenge in transitioning to Kubernetes lies with the developers. They must fundamentally change how they build software by:

• Changing focus to deploying software in a way that aligns with microservices.
• Decoupling application containers.
• Understanding the nodes that run the same operating system within the cluster that’s managed by operations.

This shift can present a steep learning curve for developers.

Developers of enterprise applications sometimes struggle to grasp concepts like microservices, mesh, and the process of constructing API-oriented architectures.

“This presents a significant challenge for them, as everything is now open, requiring a shift in the way software is built,” Le Lous said. “The technical complexity has increased, and the new opportunities that arise from cloud native approaches are extensive, necessitating a complete reevaluation. This is the most challenging aspect of the transition.”

This is why simplifying the methods of building software on top of Kubernetes is crucial. It is up to the operations team to discuss with the developers about what kinds of services they need and how they are going to integrate their application on top of OpenShift or another platform.

“This is how you start to talk,” Le Lous said.

Transitioning to OpenShift

Your next critical decision is to select a platform provider. Leading choices include VMware Tanzu, SUSE Rancher, and Red Hat OpenShift. Without delving into a detailed comparison of all the possible capabilities, we’ll say that OpenShift provides key enterprise features (e.g.: OIDC, RBAC) and Red Hat enterprise support. It also offers a wide array of choices for tools and processes you can deploy across multi-cloud environments. But before you take the plunge, what can you expect when opting for OpenShift?

Setting up Kubernetes has become more straightforward than it was a few years ago thanks to the help of platforms like OpenShift and serverless options offered by major cloud providers. This improved facility helps account for why most organizations have adopted cloud native, according to the CNCF annual survey of 2,063 respondents. Le Lous highlights the ease of Kubernetes setups now compared to when he learned to run Unix without the luxury of setting it up in just a few clicks.

Flexible Adoption Paths

There is no one way to adopt OpenShift. Organizations are often tasked with managing container workloads across environments and infrastructures. To address this challenge, Red Hat’s OpenShift is designed to offer a wide range of services that scale from edge deployments to both virtual and physical infrastructures that can be run in private or public clouds.

The services OpenShift offers are mostly open-source service packages that can fit on top of the platform itself. Often, organizations already have technologies such as GitLab, Jenkins, and Selenium in place. This means they’ve established their automation pipelines and may not opt for the pipeline framework provided by OpenShift. Instead, they prefer to use their existing pipeline to deploy applications on OpenShift.

“The decision-making process is influenced by factors such as the maturity of DevOps practices among our clients, the maturity of GitOps, and the complexity of applications,” Le Lous said. “Different decisions are made based on whether the organization is a newcomer lacking maturity and automation, dealing with high-complexity applications, and starting with DevOps practices. In these cases, OpenShift might be a great choice. However, for organizations that are already mature in these aspects, they can take an upright approach to application complexity by selectively incorporating OpenShift and choosing specific components.”

In other words, features built into the OpenShift platform can simplify container adoption, management, and security, but these features are designed to be interchangeable and upgradeable, since flexibility and interoperability throughout the application supply chain are paramount. Red Hat understands the value of expanding partner ecosystems and making it easy to interchange validated technologies.

Nonetheless, certain deficiencies may arise when adopting open-source tools that can be added on top of OpenShift. Unfortunately, these tools can introduce operational and security risks when employed instead of specific enterprise platforms and tools for critical functions like data protection services.

In Part 2 of this series, we will look at data security and how, in Capgemini’s case, Veeam has emerged as a valuable partner in addressing the complexities of backing up applications in Kubernetes or OpenShift environments.

“While backing up infrastructure components like etcd and deployment scripts may be straightforward with Kubernetes, ensuring the resilience of the applications layered on top presents a unique challenge”, concluded Le Lous.

For more best practices about Kubernetes application mobility, download The Gorilla Guide to Kubernetes Native Application Mobility e-book.

Share