A Year of Kubernetes: Navigating Treacherous Waters
I had recently taken some time to reflect on thoughts from the passing year in the cloud-native ecosystem. After talking with many people and seeing many types of deployments and use cases, I decided to put some of my thoughts to paper in this two-part installment.
Community, Community, Community
I think the most evident theme of the cloud-native movement is the community. With KubeCon having doubled in size in the United States since last year’s event, it is evident that the community is thriving. Kubernetes is no longer an experiment discussed in obscure meetups around the world. It’s here to stay and increasingly taking on center stage. Ask anybody and they’ll tell you they’ve got something brewing with containers.
I know that the excitement or hype around KubeCon and Kubernetes, or even containers in general, might seem strange even for people in the tech industry bubble. Some of the people on the more cynical side are saying, “Why are people so gaga over Kubernetes? It’s just another task scheduler,” or Linux purists saying, “Containers are just processes with cgroups and namespaces; I had containers on my mainframe back in ’84. Nothing new to see here … move along.” Although technically they are not wrong, they might be looking at things from one dimension and missing the bigger picture.
The Kubernetes community brings together a wide range of the tech spectrum: On one side, developers, and the other side, IT\DevOps people. This might sound like a beginning of a bad joke or a really loud argument. However, the cloud-native movement has succeeded in showing it can provide value for everyone involved and drive people together toward a common goal: making the organization more agile. Everyone is excited to be part of this bleeding-edge of technology moving their organizations forward.
Kubernetes and cloud-native in general are to our current IT ecosystem what virtualization was back in 2005. The major difference here is that there is no specific vendor that is miles ahead of the pack; rather, the playing field is relatively level.
Kubernetes and containers are going to be the main drivers for applications in businesses in the next decade, and people are getting involved early to help steer the ship. This involvement in the technology and community is possible due to the open and inclusive plug-in-for-everything approach of the platform, which enables everyone to participate—from small startups creating a dedicated controller for a specific task to major vendors creating full-blown managed platforms. I believe this approach also trickles down to the community itself, creating one of the more diverse, inclusive communities in current tech, where everyone can participate and actually have an impact on the technology.
I believe the case of Kubernetes and how the Cloud Native Computing Foundation (CNCF) is managing the community and the different relevant projects should be studied in MBA programs around the world. It would serve as a great example of how to rally a multicultural, multinational, multiorganizational community around an idea by allowing everyone to have a personal stake to drive technological change and adoption.
I’m a Real Boy!
For the past couple of years, when talking with organizations about containers and Kubernetes and the reasons that lead to the current existing architecture, you would usually get one of two types of responses.
The first was from born-in-the-cloud companies, fully cloud-native from day one with a strong in-house development culture. These companies created their own solutions due to the half-baked nature of the container platform at the time and their need for a tailored use case. These companies, usually tech companies themselves, took it upon themselves to create their own solutions on top of the existing platforms and tools.
The second was from large organizations looking to accelerate their businesses by revamping the technology stack and deployment cadence. These large organizations, sitting on the fence, have been waiting patiently for the different technologies to mature while playing with them in their lab environments.
With the emergence of managed cloud and on-prem solutions for deploying and managing Kubernetes, we started seeing real projects with production workloads and technical staff to suit. In some way it’s also a product of the ongoing underground, bottom-up, evangelistic approach led by different enthusiasts in those organizations.
What does this mean? In essence, we see the different Kubernetes projects moving from a limbo state to ongoing real projects with target dates. However, no progress exists without its own specific hiccups, and our customers and many of the people we talk with mention two major issues.
The first occurs among innovators who are using “old” Kubernetes versions that are no longer supported due to the rapid version change and lack of backwards compatibility, and are seeing their architecture crumble before their eyes. All custom integrations built in-house break due to the API changes. For the older versions, cluster upgrades have never really been an option. These people are stuck in decision limbo of whether to deploy a new, self-managed system and replace\retrofit some of the existing tooling (which might break again in the next version) or just lift and shift everything to a managed service (on-prem or in the cloud).
The second case occurs among early adopting\early majority organizations that believe Kubernetes is mature enough but are also still stuck on selecting the right combination of literally hundreds of tools and plugins.
Paradox of Choice
As we see Kubernetes maturing and the other different CNCF projects graduating, more and more ways are being created to solve different problems around networking, storage, monitoring, load balancing, deployments and many other concerns around the application life cycle. On the bright side, this granularity enables us to choose the right tool for the job at hand. However, with so many CNCF projects to choose from, deciding on a solution architecture feels like a series of bets at this point, as there is no de facto leading architecture.
The current Cartesian product of the different plugins, runtimes and versions creates hundreds—if not thousands—of deployment options. There are some plugins and tools that are more popular than others usually due to buzz or great marketing. The reality is, there are not enough public success case studies at scale that organizations can refer to as “go-to” architectures.
With the emergence of such an overwhelming number of managed solutions on-prem and in the cloud, many organizations are deciding to choose between managed solutions instead of tinkering with and maintaining the different Kubernetes versions and plugins. Actually, managing the Kubernetes infrastructure creates a lot of overhead and requires multiple full-time employees. Not many organizations can and\or want to set up a dedicated team for Kubernetes management, so they opt to use managed solutions to cut down on costs and avoid the initial weeding-out of what works and what doesn’t. Organizations that do choose to create their own teams encounter a different type of problems—the bench is not deep enough right now.
It seems that even though the technology and the ecosystem are at a very exciting stage, Kubernetes is still a long way from crossing the chasm and actually becoming a “household” technology. Some of the more advanced organizations that have already tried to take the leap have gone through the trough of disillusionment in regards to taking this technology head-on and probably will be looking to consume it as a service or wait for it to become more mature. We will watch the space closely to see the evolution of the technology and the mindset of its user base.
Stay tuned for part two of our recap on the Kubernetes ecosystem and cloud native community.