“Kubernetes has crossed the chasm!” claimed VMWare in The State of Kubernetes 2022. Kubernetes market size estimates for K8s in 2021 varied wildly between a low that is too high for the pessimists and a high that is not good enough for the optimists.
A quick search would yield a lower bound estimate of USD 800 million and an upper bound of more than twice that at USD 1.7 billion. Growth rates seem to be more or less the same; in the lower double digits as a cumulative average growth rate.
However, diligent analysts who may be too eager to wrap up a research report would be well advised to keep in mind factors that have pushed K8s across Moore’s chasm once and for good. No longer are we in the age of the visionary early adopters; usher in the age of the pragmatist early majority.
As with any technical advancement, be it a tool in the 21st century or the steam turbine described in detail in Heron’s work in 100 BC, such advancements flourish only in a supportive ecosystem.
In the steam turbine case, it took us 1600 years approximately for Taqiu Eddeen Ash-Shami (a.k.a. Taqi al-Din Muhammad ibn Ma'ruf al-Shami al-Asadi (Arabic: تقي الدين محمد بن معروف الشامي السعدي, Turkish: Takiyuddin) (1526–1585) to describe the workings of a rudimentary steam engine and steam turbine, predating the more famous discovery of steam power by Giovanni Branca in 1629.
Neither the early inventor nor the later inventors realized the full potential of the steam turbine or the steam engine until the advent of the industrial age when the necessary tools were available for manufacturing the steam engine and using the engine to power industrial growth. These factors enabled the creation of commercial opportunities for the steam engine at a massive scale.
Kubernetes is now popular yet not universal. Its ascension to stardom may well be on its way thanks to working with the model of running software rather than proposing a whole new way of writing and running software.
It is a paradigm that requires a few changes and moving from running software before K8s to running software after K8s requires abstraction levels that are not beyond any techy.
Capture dependencies and achieve portability with K8s specifications for resources and … orchestrate! Simple really.
From a software development perspective, there are most probably many new paradigms developing. However, as with K8s, these will take time to mature, develop an ecosystem, plant roots in infrastructure, compete and survive the dreaded chasm.
A new paradigm for software development which runs at Web-scale requires many supporting tools. These tools need to be mature, loosely-coupled and tightly-integrated working together on platforms that are not only ready but also interested in promoting this paradigm.
Kubernetes Ecosystem; an accomplishment in of itself
The ecosystem of Kubernetes is huge and continues to grow. Growth begets growth, and this virtuous circle is not any different. Moreover, the popularity of Kubernetes has provided the community with many use cases for supporting tools which can fill gaps that manifested themselves through Kubernetes intense field testing.
Let’s have a look at a subset of these tools and touch lightly on the problems which they solve for K8s.
An enterprise would resort to Kubernetes with either hopes or actual demands of Web-scale. And if anything, the Web is huge. The State of Kubernetes 2022 points to an expectation of increase in the number of K8s clusters at 76% of its surveyed companies.
As you grow, you will need to keep track of your resource definition files. Such definitions are configurations which may be required for several environments and may be further needed across several projects. Keeping track of what applies where and how is not a trivial job. Solving this complexity has facilitated reuse of configurations for environments across projects.
Enter Helm with Helm Charts. A Chart defines a set of Kubernetes resources to start on a cluster when it is installed. These Charts are stored and made available through a repository and a tool that supports a local and virtual Helm chart repository. Helm is used to package services or use Charts with Values from a yaml file that can be injected on-demand during an installation.
Helm Charts have helped avail resources to be configured on environments and reused among projects.
With every application running in a container, a deployment pipeline would be needed on each application if you want to automate deployment on Kubernetes, right? This is a complexity that is further exacerbated by a lack of control on the cluster once delivered; modify the configuration on the cluster and it will stay out of synchrony until deployed again. Welcome, ArgoCD.
ArgoCD enables a GitOps approach within Kubernetes. It manages a cluster through a git repository, for example. It ensures correct cluster configuration by comparing git to the current cluster state. Any configuration to any cluster will be immediately detected and overwritten.
This creates a neat and concise way to keep clusters correctly configured and a means to communicate such configurations across teams. That aspect of the architecture is no longer shrouded in mystery and team members are likely to be able to deploy without worrying about edge cases of a custom pipeline.
Enhanced Management of Stateful Applications
Kubernetes best handles stateless applications since each instance of these applications runs independently. There are ways to deploy stateful applications but the outcome is far from ideal and inconsistent.
K8s operators solve this issue by adding a controller to the cluster. Reconciliation loops are controller loops which observe deviations of the current state from the desired state and adjust to revert the current state to the desired state.
Deviations of Kubernetes objects from desired states might be in deployments, services, secrets, ingress or config maps. Such desired states are configured through JSON or YAML manifests.
Operators are application-specific controllers which extend Kubernetes APIs to create, configure, and manage complex applications on behalf of DevOps engineers.
Of course, there is more to operators than that but you catch the drift; one can manage stateful applications consistently.
Secure Inter-Service Communication
Kubernetes inter-service communication is insecure as a default. No one wants that, right? Communication among nodes can be secured and optimized using a service mesh. That is, however, neither a simple nor straightforward task without a tool like Istio.
Istio creates a sidecar (proxy) container inside each marked pod to intercept all requests to the original container and uses this data to do all the work. Security and optimization without any code change and no matter what you are running on your containers.
And, yes, of course, there is more to it but I will leave that to the infrastructure security specialists at Sitech. For the purpose of this article, problem solved and yet another example of mature tooling that is part of the Kubernetes ecosystem and one that has helped push it over the chasm.
Kubernetes is Here to Stay
Yes, there may be new abstractions and new paradigms being developed that might sometime change the way we run software. However, for these new paradigms to be adopted and cross the chasm themselves, they need to have their own ecosystem developed and ready to take on enterprise-level challenges.
But for now, I will leave you with these percentages in hope that they, now, make perfect sense:
The percentage of companies surveyed in 2022 with more than 50 Kubernetes clusters has almost doubled to 29% while the percentage of respondents who had more than 10 clusters now make up 65% of total companies surveyed as opposed to 43% in 2021.
Welcome 2023, the year of Kubernetes.