Best of 2021 – What Kubernetes’ Docker Deprecation Means for You
As we close out 2021, we at Container Journal wanted to highlight the most popular articles of the year. Following is the twenty-second in our series of the Best of 2021.
Will Kubernetes’ deprecation of Docker put a knife in its historic run? Probably not. But there is a lot to consider, and it is not just the technical aspects that scare me.
In the various dev tools spaces I’ve worked, I have never seen tool adoption like I did with Docker; Kubernetes (K8) was a very close second. Docker quickly became a DevOps darling, with rapid, bottom-up adoption from cloud-native developers, especially in dev/test environments. As it matured, it became a production-ready infrastructure tool; the container orchestrator functions were the icing on the cake. K8 arguably won the orchestrator race, and its capabilities took Docker from a convenient dev/test tool to a stable and scalable production infrastructure testing tool. But now, sadly, the duo seem to be parting ways. On Dec. 2, 2020, the contributors to K8 announced the deprecation of the Docker runtime as of version 1.20.
Instead of focusing on Docker as the runtime for containers, they are shifting to the Container Runtime Interface (CRI), which expands support for a broader set of container runtimes versus reliance on one. However, in production, selecting runtimes of containerd or CRI-O is going to be the appropriate strategy.
This does not mean Docker stops working, so don’t panic. Docker containers won’t explode, but future support for them in production goes away. But that is not why I am here – it is not the technical aspects of this decision that concern me. Beyond the technical support issues, there are other considerations enterprises have to make, and that is what I’m most fascinated with.
First, Be Smart
I will not dispute that there seems to be a concerted effort to consolidate CNCF projects. While Docker core tech is one, Docker itself is not. And this may or may not have some political motives. But, at the same time, the CNCF ecosystem comes with added community support and more longevity. I consider that a plus. What is more interesting is how this news has to have enterprise architects, cloud operations engineers and site reliability engineers (SREs) doing backflips.
Even for me, the immediate reaction to the deprecation of anything is “Uh-oh.” When I was an active developer, a deprecated API feature destroyed a product for which I had paying customers. It was painful, but we survived. Fortunately, I think all tool developers have gotten better at thinking through these implications, and I have a ton of faith in the contributors to Kubernetes. There’s no reason to believe their focus and rigor is any less exacting than any vendor’s proprietary product.
My first advice for coping with this anxiety is to slow down. Do not use these changes as an excuse to avoid or delay refactoring and embracing K8 as a container orchestration tool. Rather, respect the difficult decision that the bright technical talent on the K8 project had to make. Their reasons are solid, and likely better for the future of containerized applications. It’s likely that the impact on enterprise adoption, the psyche of the enterprise architect and environment parity will be greater than on the technology itself.
Enterprise Adoption
My biggest concern is the psychological impact. For those enterprises who are mid-stream in refactoring their applications, and are not cloud-native unicorns, will this decision create a barrier to adoption? I figure enterprises will do one of three things:
- Slow down: Put the brakes on any current efforts, and double down on current application architectures until they see how K8 v1.20 rollout goes.
- Get scared away: Even more drastic than a slowdown, they’ll pull the plug completely; revert to the fear they felt at the onset of the K8 project and use this as validation of the mentality that change is bad.
- See the opportunity: Forward-looking enterprises will see the logic in this transformation, and have even more confidence in the scalability and benefits of Kubernetes and containers for their production applications. But, maybe the opportunity is not related to K8 at all. It might actually force their hand in other cloud-journey efforts; for example, accelerating the use of public-cloud container tooling, or shift focus to a more strategic effort so that future platform changes do not dictate the direction of their engineering teams.
I hope the third option is the path chosen, but I suspect that most organizations will slow down their adoption and put all current efforts under a microscope. This will impact the entire market; an outcome that is less-than-favorable.
The reality is, if you are moving your applications to the cloud and intend to cater to end-users’ high expectations, you can’t avoid containers and container orchestration. K8 will remain the forerunner within its community and the broader tooling ecosystem. Chances are, it will haunt you again soon, and if you throttle back, you are delaying the inevitable and losing valuable time and knowledge. Keep your foot on the gas.
The Enterprise Architect
For those responsible for gauging the impact of all of this, you are going to have a busy Q1.
While K8 v1.20 may be the primary focus at the moment, use this decision as an opportunity to consider all aspects of your software delivery life cycle (SDLC). For example, consider how you test your infrastructure, how you measure the success of your pipeline and how you ensure uptime of your toolchain.
If deprecation like this causes a particular heartache because you anticipate cascading issues, the likely cause is you were burned in the past by poor strategy. Addressing the weakest links in your environment will help you reduce that heartache in the future. Minimizing the impact of any one tool on your architecture is an ongoing, healthy practice that all enterprises should embrace, but few do. Are changes to K8 the problem, or is it how your organization assimilates tooling? Because these changes are always going to happen as we get better and better at delivering high-quality services faster.
Environment Parity
That is not to say that this change could not propagate some old, bad habits. I suspect that Docker will revert back to its childhood, so to speak, and become, once again, the easiest-to-use rapid environment testing tool. It will be a tool for dev/test, training, demos and prototyping. It did so well with these use cases, but it is a step backwards and could further increase the issues that K8 + MiniKube helped to resolve; mainly, lack of environment parity. Having Docker in production and on developer machines was a plus.
The reason environment parity between development infrastructure and production is so important is because operational drift due to lack of parity is, to put it mildly, a bad thing. The slow bleed of configurations from one environment to another is, to varying degrees, the hidden disease in all engineering environments. The “Works on my machine,” problem. The higher the rate of operational drift, the less stable and secure production environments are.
Few enterprises invest direct effort into resolving operational difficulty. Usually because the drift crosses teams, and no one owns the effort. Sometimes it takes large tooling changes to get enterprises to think about things like operational drift. The more varied the environments, the greater the challenges created when reconciling those “Worked on my machine,” issues, communication between teams and the increased risk of bad configurations making it to production. This decreases stability and increases security concerns.
All this is to say that, at this juncture, I believe you should strongly consider what developers are using for containers versus what will now be used for containers in production. Docker has substantial usability benefits that developers love. But with the deprecation decision, will that upper hand last? And is it worth the added risk?
Buckle Up
This news will add effort enterprises did not ask for. If you are already using, or starting to use, Docker in K8 you have a large chunk of testing ahead of you. And I have no doubt that you’ll uncover a collection of unforeseen surprises.
This is a temporary ripping-off-the-BandAid, and the real story is how enterprises roll with the Docker deprecation – and future similar changes to critical platforms. As enterprises get better at going through these types of exercises, they will realize that most of the time, these updates offer better long-term functionality and stability to building cloud-native applications.
