Intro
Bimodal is a term often used in statistics that Gartner applied to the IT industry back in 2015. Gartner defined bimodal as “… the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration”. The two modes were named Mode 1 and Mode 2 (Am I the only one who thinks of Thing One and Thing Two?).
- Mode 1 – “… is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment …”
- Mode 2 – “is exploratory, experimenting to solve new problems and optimized for areas of uncertainty.”
The bimodal concept was created to guide the IT industry in the process of digital transformation, let’s explore how that fits the Kubernetes ecosystem and Helm charts.
The preferred method for packaging is Helm (68%) followed by managed Kubernetes offerings (19%).
Helm
Helm has emerged as the de facto way to manage Kubernetes applications(apps). Helm is a package manager for Kubernetes. The package is called a Chart, and it defines Kubernetes apps. There is a vast and vibrant Chart community that continuously delivers new Charts and bug fixes for current Charts. At Translucent, we leverage the community Charts to provide value to our clients.
Chart
There has been a rapid evolution of Chart development in both quality and innovation. The improved quality gives Chart user the ability to customize the deployment of the Kubernetes apps with more configuration options. The Chart developers are innovating by providing Charts for Kubernetes apps that pack more technologies into a single app. This recent trend in the growth of these monolithic Charts leads me to wonder if we should apply the bimodal concept to Chart development?
Monolithic
As the Kubernetes ecosystem continuously matures, a standard Kubernetes app pattern has emerged. App developers, following Microservice architecture, break up the app into smaller pieces, called Microservices. Besides the Microservices, the databases, jobs, and additional tools are deployed and distributed as smaller pieces in Kubernetes. Since most of the apps follow a standard pattern, there is a tendency to try to cram all the app microservices, databases, jobs, etc. into a single Chart. While such optimizations may appear to be beneficial, they feel incongruent with the DevOps or SRE approach.
Conclusion
Suppressing my inner DevOps disgruntled voices, I do have to acknowledge that packaging a whole app into a single Chart comes with benefits. You offload the app knowhow to the people who created the app and you are left with a one-click install of a single Chart. You don’t have to worry about deploying individual pieces and gluing them together. I call these monolithic Charts, Mode 1.
Mode 1 Helm Charts are well suited for infrastructure technologies like CI/CD tools. At Translucent we use Jenkins and Spinnaker for CI/CD. Both are packaged as Mode 1 Helm Charts. They combine all the technologies that are needed for deployment.
We use Mode 2 Helm Charts for everything that makes up our client’s apps. Since we continuously innovate, either by improving the Chart or by engaging in continuous deployments and delivery of individual Microservices, we require the flexibility that Mode 2 Helm Charts provide.
January 10th, 2020
Subscribe
0 Comments
See more:
December 10th, 2021
Cloud Composer – Terraform Deployment
December 2nd, 2021
Provision Kubernetes: Securing Virtual Machines
by August 6th, 2023
The Critical Need for Application Modernization in SMEs