Containers, after Docker made the user experience seamless for developers, not only captivated developers and garnered their mindshare, it also made deployment of applications into production much more easy. It completely altered the developer workflow, pushing the CI tools into oblivion. When Kubernetes came into the market and made the deployment part of applications friction free, there were questions about not only developer centric tools like Jenkins and Artifactory but also about some of the deployment tools.
Containers + Kubernetes were seen to redefine the DevOps pipeline and give developers confidence to deploy in production as often they want. Developers will package all their code and dependencies in containers and push it to a repository, which serves as the nerve center for the pipeline across dev, test and production. The thinking was that Dockerfile and Kubernetes YAML file are the only moving parts developers need to worry about and, with the right automation in place, the code moves from developer laptop to production without any hassle. In other words, there were expectations that containers will disrupt the DevOps landscape.
Old is becoming new once again
Recently, two announcements from “early DevOps” vendors made it clear that the DevOps landscape is not going to see the kind of disruption some of us were expecting to happen.
The first announcement came from Jenkins community (and supported by CloudBees) and they launched Jenkins X which automated the CI/CD for Kubernetes. The developers need not worry about the creation of Dockerfile or helm charts or Jenkinsfile. With one command, they can create an automation pipeline for continuously (and safely) deploying into production without having to worry about the internals of Jenkins or container packaging or deployment configuration files for Kubernetes.
With a single CLI command, Jenkins X creates a github repo with Dockerfile, Jenkinsfile, helm chart files and a webhook for SCM trigger to that applications are deployed using GitOps, a concept initially advocated by WeaveWorks. With Jenkins X, Kubernetes and some automation, you have a platform that lets your developers confidently deploy to production with the code going through all the tests needed before it is deployed in production. If the goal of modern enterprise IT is to empower their developers to deploy directly into production many times a day, Jenkins X + Kubernetes just gave another option that spans the entire DevOps lifecycle. Yes, you still use containers to deploy but it is not the shiny object that developers need to care about. Right now, Jenkins X comes with Spring Boot support but other languages are going to be supported in the near future. Jenkins X is the reboot that Jenkins community and Cloudbees needed in today’s Kubernetes driven market.
The second one is not an announcement but a blog post by JFrog, the company behind Artifactory, where they attempt to take the conversation beyond Docker or container registry with a campaign that uses the term Kubernetes registry. Their strategy seems to focus on the hybrid world of containers and virtual machines with a single registry that can help deliver various types of artifacts from executables to Docker Image to Helm. JFrog has been fairly successful with virtual machines, their strategy for Kubernetes has been evolving over the last few months and they are now positioning themselves as the repository for Kubernetes, bypassing the need for a separate container registry.
The force behind the push to make containers irrelevant
Containers are not becoming irrelevant and they are still the dominant way of packaging applications in the cloud native world. This is evident from the success of Amazon ECS and Kubernetes on AWS. However, Kubernetes is moving in a philosophical direction that first balkanized the containers and now makes containers one of the many ways to deploy applications to Kubernetes. With the massive success of Kubernetes as a declarative modern IT platform, containers are slowly becoming less shiny. Even the next iteration of modern stacks, Serverless, makes containers, continuing the trend. Some of the on-premises serverless platforms keeps containers as one of the deployment modes but the public cloud offerings like AWS Lambda, Azure Functions and Google Functions doesn’t support containers as a way to encapsulate code. Only IBM Cloud Functions supports containers for code packaging among the top cloud providers. In other words, containers are competing with other forms of code encapsulation in both Kubernetes world as well as FaaS world.
Is it end of containers?
Not at all. Containers will still be a major packaging mechanism for cloud native workloads but they may not be the dominant way of deploying applications. It is too soon to write off containers and Serverless is still far away from enterprise level maturity. But if the confidence exhibited by Jenkins community or JFrog is any indication, containers are not the shiny objects it was couple of years back. It will just be one of the options developers use for packaging their applications.
I agree this is a provocative post on containers but my idea is to spur some discussions on this topic. Feel free to add your thoughts.
