It seems almost futile to try to predict the future of the fastest growing open-source project in history, especially since absolutely no one could have possibly imagined the road up till now. What pretty much started as a “hand-me-down” from Google to the rest of the community has grown into the de facto standard for orchestration and as some people are calling it, the ruler of the world. Never has there ever been one single project that has garnered support from the entire enterprise community collectively in such fashion. One look at the long list of CNCF members will show you that friends and foes alike have put aside not only their differences but also their own competing products in favor of supporting Kubernetes. With unprecedented support, technological backing, and the who’s who of the enterprise onboard, it’s safe to say everyone’s got their eggs in one big Kubernetes basket. And building on the success of 2019, Kubernetes 2020 will have more eggs and a bigger basket.
With regard to the present situation, however, it’s pretty clear that Kubernetes and serverless architecture are on a collision course. On one hand we have Kubernetes that is officially out of the experimentation phase and in production, and on the other hand, this idea called serverless, that people have been striving for ever since the first PaaS was rolled out. The reason we call serverless an idea here isn’t because it doesn’t exist, but rather because it refers to the eternal holy grail of platform developer goals, the abstraction of all infrastructure. Making sure developers are free to work on their apps isn’t a quest the enterprise is ever going to give up on, especially not in favor of Kubernetes or any other orchestrating software, no matter how powerful or versatile. Which brings us to one conclusion: The future is definitely going to feature containers, serverless architecture, and Kubernetes.
This, in turn, brings us to ask the obvious question, “What role will Kubernetes play in this future of serverless containers?” While the future always reserves the right to throw us a curveball, orchestration is a pretty safe bet. This is because serverless container infrastructure will have to travel a few light years to catch up with Kubernetes and a high- level orchestrator is always going to be required to build more complex systems. So rather than start from scratch and compete with the fastest growing open source project on the planet, it just makes a lot of sense to jump on the Kubernetes bandwagon and consolidate around its orchestration API. Additionally, dedicated machines and specialized hardware are always going to be required for sensitive data and high priority workloads, at least for the foreseeable future. So while the future is indeed going to be serverless, it’s also going to be a hybrid combination of a lot of other stuff (that runs on Kubernetes) as well.
An ideal situation would obviously be serverless containers doing the “bursty” stuff while some serious equipment holds down the fort (steady-state services). This implies another level of hybrid cloud that not only accounts for on-premises infrastructure and a couple of public clouds but serverless architecture as well. As things stand right now, virtual kubelet is one of the only ways Kubernetes gets to play around with serverless architecture. Virtual kubelet is an open source project that lets Kubernetes connect to other APIs, and is currently being used to integrate Kubernetes and serverless technology by creating a virtual node that represents serverless infrastructure. Virtual kubelet retains all the power and functionality that comes from Kubernetes and can handle higher level concepts like services, deployments, secrets and the like. Another cross venture between Kubernetes and serverless is Knative, a Kubernetes-based platform designed to offer a Kubernetes-native API for implementing serverless type functions.
The enterprise wants the hybrid cloud and Kubernetes is at the core of the hybrid cloud, so expecting Google to stand by and watch while its brainchild takes over the world is foolish, to say the least. Google recently announced Anthos, its hybrid and multicloud platform that features GKE at its core, in addition to GKE on-prem, Istio, Velostrata, and others. What’s different here from other hybrid cloud offering is that Anthos comes with Google’s deep understanding of Kubernetes and even deeper rooted foundations in containers. While Velostrata is the industry’s first physical to Kubernetes migration tool built by Google, Anthos also features Config Management, Stackdriver, GCP Cloud Interconnect, and GCP Marketplace. While it’s almost tempting to think that this was Google’s plan from day one, the proof is always in the pudding and we’ll have to see just how easy or user-friendly Anthos manages to make hybrid/multicloud management.
Another phenomenon we are probably going to be seeing a lot more of is cloud vendors paying attention to developer needs like end-to-end solutions that help manage the entire SDLC. As things stand at the moment, CloudBees, the architects of Jenkins and Jenkins X are dominating this sector. Earlier this year, alongside the Jenkins community and Google, CloudBees even launched the Continuous Delivery Foundation (CDF), a new offshoot of the Linux Foundation aimed at developing and promoting open source projects and best practices around continuous delivery. Additionally, CloudBees also announced the acquisition of Electric Cloud with the intent of being the first provider of CI/CD and ARA ) application-release-automation. BitBucket Pipelines which is part of the BitBucket Cloud from Atlassian is another big player in this market, one of who’s biggest competitors is GitLab. GitLab is also quite a popular choice for CI/CD and has its build test and deployment mechanisms connected to its repositories.
The point we were trying to make, however, is that we’re going to see a lot more of the big cloud players in this not-so-“niche” market in the near future. Big players have already started the process like Amazon’s AWS CodePipeline that does a great job of delivering code to an AWS server, though there are still a large number of layers to navigate through like CodeCommit, CodeDeploy, and CodeStar. Similarly, late last year Azure changed Visual Studio Team Services to Azure DevOps, a set of services aimed at helping users build end-to-end automated pipelines. This includes five different tools named Azure Pipelines, Boards, Artifacts, Repos, and Test Plans, and comes with literature that says “any language, any platform.” Additionally, Microsoft acquired GitHub last year, which means they are very, very interested in this sector.
So, while there is a lot of talk about futuristic lightweight VMs replacing containers or serverless containers replacing Kubernetes, applications across different enterprises are so diverse that there is rarely going to be a case of one size fits all. While serverless infrastructure like Azure Container Instances is a great way to run a few containers in the cloud, as you scale up, there’s no escaping orchestration, and to do it right, you need the power of Kubernetes. What this means is that with regards to the future, it isn’t about VMs or containers or serverless, but rather about how Kubernetes will be used to collectively orchestrate different workloads in the cloud. These workloads would include traditional VMs, micro-VMs, “future” VMs, serverless containers, and VMs, or even bare-metal infrastructure.
Featured image: Shutterstock / TechGenix illustration