Increased Kubernetes Adoption Reveals a Need for an Open-Source Solution
There seems to be no doubt about Kubernetes’ victory in what was known as the “Container Wars” back in the day. As CNCF’s Cloud Native Survey 2020 states, “91% of respondents report using Kubernetes, 83% of them in production,” demonstrating that the platform has become a defacto standard for organizations implementing a hybrid cloud strategy. Along with that, containerization is making its way as most enterprises are adopting it for their production workloads. The latest Gartner forecast about Container Management Software and Services reveals that “by 2022, more than 75% of global organizations will be running containerized applications in production.” Both insights combined can lead us to conclude that Kubernetes is becoming the default platform for application deployment, increasing organizations’ needs for methodologies and tools that could ease adoption and migration.
Leveraging the advantages that the cloud native model provides requires some degree of adaptation on the target workloads to be migrated, leading to application modernization becoming a hot topic among large enterprises. According to Verified Market Research, “Global Application Modernization Market was valued at USD $7.74 billion in 2018 and is projected to reach USD $30.59 billion by 2026, growing at a CAGR of 18.7 % from 2019 to 2026.” There seems to be a problem with the transformation throughput though, since “the bottleneck will be the speed at which applications can be refactored and/or replaced,” as stated by Michael Warrilow, research vice president at Gartner, on the presentation of their Container Management forecast.
One of the key challenges for application modernization seems to be the existing gap in the market for open tools that can help organizations transform applications to leverage cloud native technologies, especially in the Kubernetes space. Most of the existing tools are proprietary and introduce some form of lock-in to a certain vendor, thus preventing organizations from achieving the level of flexibility that hybrid cloud aims for. In terms of the approach to modernization efforts, the situation is not better: most migration and adoption methodologies sit within organizations and are not generic enough to be broadly transferable and applicable in common scenarios. This has a negative impact on the speed at which application modernization can be implemented, as organizations are in most cases forced to reinvent the wheel and define their own tooling and methodology or incur some tradeoffs like vendor lock-in, as mentioned earlier.
Traditional Workloads Benefit From Being on Kubernetes, Too
Kubernetes has traditionally been seen as a platform for microservices. Although it is true that it provides an ideal environment for developing greenfield applications focused on innovation, more traditional workloads can benefit from it as well. Kubernetes was built to be a fault-tolerant platform by design, and in most cases legacy applications can leverage features such as high availability and health monitoring with little to no change in their architecture, thus dramatically reducing their mean time to recovery. Also, the deployment of applications on Kubernetes greatly eases the adoption of more advanced application lifecycle management techniques, such as fully automating it with the use of CI/CD pipelines, which becomes more accessible with the infrastructure as code approach the platform enforces. This, applied to a legacy application portfolio, can introduce the concept of fast monolith, or applications that can leverage the DevOps approach that Kubernetes enables to decrease their lead time for change and increase their deployment frequency. If some special care is put into bringing automated testing to the pipelines managing the application lifecycle, then we can also add a significant decrease in the change failure rate for applications while producing an increase in overall quality and confidence when releasing code in production environments.
The last paragraph can be summarized like this: bringing legacy applications to Kubernetes can have a significant boost on their software delivery performance, improving all of the four DevOps metrics that were popularized with the book Accelerate: The Science of Lean Software and DevOps, based on the research done by the DevOps Research and Assessments team, now part of Google Cloud. And more importantly, it can be done without requiring a complete re-architecture and rewrite of these applications, by just adapting the existing source code to run in the new platform and building a new set of modern application lifecycle management processes around it. But then, one question comes into mind: How can an organization adapt their legacy application portfolio to leverage Kubernetes and improve their software delivery performance?
An Approach for Large-Scale Kubernetes Adoption Projects
Prior to becoming Product Manager, I spent almost five years in Red Hat Consulting as an architect, helping customers with large-scale migration and OpenShift adoption projects. Based on my experience, the answer to the previous question that I’ve seen succeed the most in organizations working actively on Kubernetes adoption is the following: treat the application onboarding initiative as a full-blown migration project. This means breaking the adoption initiative into the following stages:
- First and most importantly, take a step back to have a holistic view of the whole application portfolio, digging deep not only on technology-related aspects but also on the processes surrounding these applications. During this assessment, it is essential to identify technical and process-related risks as early as possible in order to define mitigation strategies that ensure that the adoption process is predictable and measurable.
- Once the application landscape is well understood, the next logical step is to rationalize the portfolio and decide the migration strategy to follow with each application type. This could be typically done using the 6 R’s approach that Amazon popularized back in the day, although each one of these generic migration paths could have a special meaning in the context of Kubernetes adoption initiatives like we will see later on.
- The next step is to ensure that everything is ready to start deploying applications on the target platform and conduct technical feasibility tests for migration. Our main mission during this stage is to solve the technical challenges encountered during the assessment and mitigate the risks associated with them while initializing the common knowledge base with the findings that are being made.
- From here, once the identified risks have been mitigated, it is just a matter of choosing a representative set of applications to execute a migration pilot to test both the migration process that has been designed on previous stages and the capacity inside the organization to perform as expected on the designated tasks.
- Finally, once the process has been tested with real applications, it is time to scale the adoption team and kick off an iterative migration process to progressively move the whole portfolio towards the target platform, in this case, Kubernetes.
Although the overview of the whole adoption process might look simple, succeeding on this kind of project requires being able to make informed decisions and streamline the actual adaptation of the applications to Kubernetes, which can be a daunting task when, as we were discussing before, there are no standards on the market for this. It becomes apparent that having a set of tools and practices that could help in detecting any potential risks and automating some parts of the process would have a tremendous impact on the overall agility and reliability of the adoption process.