{"id":15243,"date":"2021-05-19T11:58:59","date_gmt":"2021-05-19T09:58:59","guid":{"rendered":"https:\/\/stage-fp.webenv.pl\/blog\/?p=15243"},"modified":"2021-10-22T13:12:52","modified_gmt":"2021-10-22T11:12:52","slug":"does-docker-make-sense-in-2021","status":"publish","type":"post","link":"https:\/\/www.future-processing.com\/blog\/does-docker-make-sense-in-2021\/","title":{"rendered":"Does Docker make sense in 2021?"},"content":{"rendered":"\n


What are Docker and Kubernetes?<\/h2>\n\n\n
\n
\n
\n Docker makes it possible to pack an application (e.g. a JAR file with compiled Java code) along with the runtime environment (e.g. OpenJRE JVM) into a single image, which then generates containers. In fact, all the dependencies in the operating system are added to the Docker image. <\/div>\n <\/div>\n <\/div>\n\n\n\n\n\n

This allows using the same package on the developer\u2019s laptop, in the test environment, and in production.<\/strong> So much for theory.<\/p>\n\n\n

\n
\n
\n Kubernetes is an orchestration system which manages several containers and attributes resources to them (CPU, RAM, storage) from a number of machines in the cluster. <\/div>\n <\/div>\n <\/div>\n\n\n\n

It is also responsible for the lifecycle of the containers and joining them into Pods. Compared do Docker, it operates on a higher level, as it controls many containers on many machines.<\/p>\n\n\n\n

If the Docker container is an equivalent of a virtual machine, Kubernetes is like a hosting or cloud provider. Docker (or Docker Compose) helps run various processes, combine them in a network, and attribute storage within one computer. Kubernetes can do the same within a cluster composed of a couple of computers.<\/p>\n\n\n\n

Kubernetes brings Docker down to the level of a component which runs the containers<\/strong>. Thanks to the introduction of the CRI standard (Container Runtime Interface), these components can be changed. At present, only containerd and cri-o are compatible with the CRI. Docker requires the dockershim adapter, which is precisely what the programmers supporting Kubernetes want to get rid of.<\/p>\n\n\n

\n
\n \n \"Docker <\/a>\n <\/figure>\n \n
\n
\n \n Close picture \n <\/use>\n <\/svg> <\/button>\n
\n
\"Docker <\/figure>\n <\/div>\n <\/div>\n<\/div>\n <\/div>\n\n\n\n


Why does Docker matter?<\/h3>\n\n\n\n


In the past few years, Docker has transformed from dotCloud\u2019s side project into a billion-dollar business. <\/strong>Despite the 280 million USD venture capital funding, Docker, Inc. didn\u2019t do well as an enterprise and was subsequently bought by Mirantis. The purchase amount was not published, which is quite curious. I guess they got a bargain.<\/p>\n\n\n\n

Mirantis\u2019s flagship product is Kubernetes-as-a-service \u2013 and so, they compete with VMWare and, obviously, with the cloud providers. Kubernetes is so important for the company that they wanted to maintain Docker Swarm for two years only<\/strong>, but they quickly backed out of that, surely pressurised to do so by their current clients. Actually, I know a company that has a large Docker Swarm installation and migrating to another solution would be a difficult affair for them.<\/p>\n\n\n\n


What is Docker Swarm?<\/h3>\n\n\n
\n
\n
\n Docker Swarm is an orchestration system built in Docker\u2019s distribution. <\/div>\n <\/div>\n <\/div>\n\n\n\n


It\u2019s a bit like Kubernetes which is as easy to use as the regular Docker. Of course, there\u2019s more to that \u2013 nodes, replicas, grids \u2013 but still, the cluster view is really simplified in comparison with Kubernetes.<\/p>\n\n\n\n

Does that mean that Mirantis bought a product which is competition for their flagship one? Yeah, in a way. Docker Swarm has already recovered from its childhood diseases (e.g. the bug of assigning duplicated IP addresses), so it looks like a reliable product for small teams. The problem is that small teams and small clusters make small money.<\/p>\n\n\n\n

Besides, Docker Swarm is simply too simple. In our team, it took a single person to create and manage Docker Swarm clusters. Apart from the bugs that I\u2019ve mentioned, there\u2019s not much work with that. Large updates arrive along with Docker, <\/strong>which doesn\u2019t happen too often, so that\u2019s another problem gone.<\/p>\n\n\n

\n
\n \n \"What <\/a>\n <\/figure>\n \n
\n
\n \n Close picture \n <\/use>\n <\/svg> <\/button>\n
\n
\"What <\/figure>\n <\/div>\n <\/div>\n<\/div>\n <\/div>\n\n\n\n


What is the agenda of Mirantis (owner of Docker Enterprise)?<\/h2>\n\n\n\n


The question is: if Mirantis makes money on Kubernetes-as-a-service for enterprise clients, and Kubernetes removes Docker support, what is that all about? From my point of view, a company that profits from Kubernetes has no reason to invest in Docker<\/strong> once it is no longer supported by Kubernetes.<\/p>\n\n\n\n


Mirantis takes care of the current enterprise customers<\/h3>\n\n\n\n


Later in December,\u202fMirantis announced<\/a> that they were not going to support\u202fdockershim\u202f(Docker\u2019s adapter to the CRI interface) with\u202fDocker, Inc. They explained that their current customers used more complex Kubernetes installations, which were dependent on specific Docker Engine features. What does that change? The situation resembles that related to Docker Swarm. Mirantis\u2019s technical debt will rise (more on that below).<\/p>\n\n\n\n

These are only my private musings. I haven\u2019t seen Mirantis\u2019s contract with Docker, Inc., or their strategy. I rely on official press releases and my observation of the market. Trying to imagine what a big company might do based on your own experience is an interesting mental exercise, which allows you to look from a distance at corporations<\/strong> that produce the technologies you use. I do recommend that.<\/p>\n\n\n\n


What does that mean?<\/h2>\n\n\n\n


Over the years, Docker Engine has grown and evolved into a modular architecture. <\/strong>Various implementations of components like logging have emerged. This gave room for standardising and simplifying the application architectur<\/strong>e. It was enough for an app to log to Linux streams stdout\u202foraz\u202fstderr, and Docker collected and stored logs locally. It also provided access to the interface in the form of docker logs\u202fcommands to read those logs.<\/p>\n\n\n\n

For developers, it\u2019s very convenient to have a single tool to view app logs written in Java, Node, PHP, or other languages.<\/strong> IT Ops, who maintain the systems, find other things important as well: the guarantee that the logs won\u2019t get lost, their retention, the speed with which they fill up disk space. This is a completely different set of problems, and Docker cannot solve them.<\/p>\n\n\n\n


A single machine vs. a cluster<\/h3>\n\n\n\n


What works perfectly for a single machine might not be so great in a cluster. A good example here is docker service logs, which is an equivalent of the log viewer for Docker Swarm (the cluster orchestrating system for Docker). Unfortunately, in this case, the logs are not displayed in a chronological order, which might be caused by the time differences between the particular machines in the cluster.<\/strong><\/p>\n\n\n\n

The use of NTP may reduce this problem to a certain extent, <\/strong>but that\u2019s not the best solution. In the case of log order, it\u2019s better to use a central aggregator that can add a timestamp at the moment of receiving the log. This is a solution of a different level, although normally necessary in distributed systems such as clusters.<\/p>\n\n\n

\n
\n
\n In short: it\u2019s great that Docker can facilitate and standardise so many things. And yet, these improvements make sense only if you work on a single machine (like logs). If you use clusters, the matters get complicated and the facilitation becomes an obstacle. <\/div>\n <\/div>\n <\/div>\n\n\n\n

To explain the Docker\u2019s incompatibility, I will use the Cynefin framework terminology. There is a problem with a distributed system, which is intrinsically complex, and the solutions applied are addressed to intrinsically complicated systems.<\/strong><\/p>\n\n\n\n

In other words: the solutions chosen by Docker might work for a single machine, but they are not suitable for clusters, which contain a number of machines.<\/p>\n\n\n\n


Programmers<\/h3>\n\n\n\n


For programmers, technically, little changes. We are still going to build Docker images, as they are compatible with the OCI standard (Open Container Initiative). This means that any compatible CRI will be able to run these images, be it locally or in a cluster.<\/p>\n\n\n\n

In my opinion, the most important changes refer to the way we think about containers. It\u2019s time to abandon the analogy of a container as a \u201clight virtual machine\u201d and take the cloud-native applications<\/a> into account.<\/strong> What\u2019s crucial here is that one container is one process and that resources, just like files, are temporary.<\/p>\n\n\n\n

On the other hand, it\u2019s time to start perceiving a container as an instance of an application running in the cloud. <\/strong>We need to remember that there will be many copies of the app and that nobody knows on what machine a container will be used. In result, we cannot rely on local files, as the new instance of the container won\u2019t have access to those saved by the previous one.<\/p>\n\n\n\n

Another issue is the single process in a container. Managing the container lifetime, load balancing between the instances \u2013 these should be left to the orchestrating system<\/strong> (like Kubernetes). I\u2019ve encountered a problem in database migration, where some of the containers didn\u2019t get a new address, because PM2 ran in the container instead of the direct Node (process manager for Node) and restarting the container didn\u2019t bring the desired effect.<\/p>\n\n\n\n

If the target deployment environment is Kubernetes, I think it\u2019s also a good idea to get interested in solutions that make it possible to comfortably run apps on a local Kubernetes cluster. I\u2019m referring here to tools such as Skaffold (from Google), Draft (Microsoft), Tilt, or KubeVela.<\/p>\n\n\n\n

Docker Compose works fine if the target environment is Docker Swarm, because they use the same file format of YAML \u2013 but that\u2019s a different story. I\u2019m talking about a rapidly changing market here and I\u2019m going to find something for me in it.<\/p>\n\n\n\n


SREs \/ IT Ops<\/h3>\n\n\n\n


For SREs and IT Ops (the people who maintain the infrastructure), the things get more complicated if Docker Engine is used in Kubernetes<\/strong>. It might be enough to use containerd as the CRI implementation. In this case, it all depends on how many Docker Engine dependencies have leaked to the infrastructure.<\/p>\n\n\n\n

Docker-in-Docker(DinD) is a good example here. It is used to build images on CI servers (Continuous Integration). As early as 2015, DinD for CI<\/a> was considered a bad practice, but before that could become common knowledge, it turned out that DinD was a sort of quick win in the CI environment in a cluster.<\/p>\n\n\n\n

Of course, Mirantis will listen to any complaints concerning the dependence of the complicated CI system on Docker-in-Docker or another legacy. After all, they declared they were going to support dockershim\u202fand they make money on that. I wonder, though, how much money it takes to get rid of such a problem.<\/p>\n\n\n\n

I\u2019m interested in this personally, because I\u2019m working on a complex CI, which uses DinD to build Docker images. I realise that 2021 is a year of preparing the transition to a different CRI or dockershim. <\/strong>I\u2019m afraid that the latter option will mean throwing yourself at the mercy of Mirantis, which may be a strategic risk. We\u2019ll see.<\/p>\n\n\n\n


Consultants<\/h3>\n\n\n\n


For consultants, this kind of transition is great news. After carefree years of using Docker in developer teams, it\u2019s time for tidying up, teaching and applying good practices. <\/strong>All with the objective of smooth transitioning to more restrictive environments, like Kubernetes.<\/p>\n\n\n\n

Personally, after six years of using Docker (including three years with Swarm), I\u2019m learning new runtimes, orchestrating systems, and cluster management. These trends are now emerging within the scope of interest of corporations other than the tech giants.<\/p>\n\n\n\n

On the other hand, companies such as Mirantis or VMWare have a vital interest in implementing and supporting clusters, charging a lot for that. The same applies to the cloud providers: AWS, Azure, or GCP, which offers hosted Kubernetes. Suffice to say that the independent provider Linode has offered the Linode Kubernetes Engine (LKE) since 2019.<\/p>\n\n\n\n


Summary<\/h2>\n\n\n\n


So, should you worry about the fact the Kubernetes deprecates Docker? You should\u2026 and you shouldn\u2019t. I believe that the cloud business will grow and more and more companies will migrate to the cloud.<\/a><\/strong> In this environment, application containers and horizontal scaling (for multiple machines) are a natural direction. Perhaps we\u2019ll just have to live with the complications resulting from the use of clusters.<\/p>\n\n\n\n

If horizontal scaling is inevitable, Kubernetes will make a lot of things easier, even though it seems complicated in itself. In fact, it is extended because the problem it solves (allocating resources in a cluster) is essentially complex. In this case, Kubernetes provides basic tools and terminology to deal with this complexity.<\/p>\n\n\n\n

With time, solutions simplifying Kubernetes will surely turn up<\/strong>. All the cloud providers already offer the service of hosted Kubernetes cluster, which releases IT Ops from many operational tasks. Thanks to the fact that Kubernetes configuration takes the form of declarative YAML files, it will be possible to construct tools that will enable you to kind of click your way through the clusters. I\u2019d even say that Kubernetes YAML will be to clusters what HTML is to the World Wide Web.
<\/p>\n\n\n\n

Do you want to know how Cloud can help your business develop? <\/p>\n\n\n

\n \n \"\" <\/a>\n \n \n
\n

\n Adapt your business to the changing world <\/h3>\n \n
\n

Embrace the cloud to support your strategy, accelerate your business<\/strong> and ensure data security.<\/p>\n <\/div>\n \n

\n Let\u2019s join our forces<\/span>\n \n <\/use>\n <\/svg> <\/div>\n <\/div>\n <\/a>\n <\/div>\n","protected":false},"excerpt":{"rendered":"

In early December 2020, the IT world was hit by the news that \u201cKubernetes 1.20 deprecated Docker\u201d. So far, this means that Kubernetes is issuing a deprecation warning. Specifically, this refers to dockershim\u202f\u2013 I\u2019ll elaborate on that later in the text. Docker support will be removed in version 1.22, which is planned for the second half of 2021. That\u2019s why I think that the year 2021 is the beginning of Docker\u2019s end. <\/p>\n","protected":false},"author":166,"featured_media":14435,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[980],"tags":[],"coauthors":[1979],"class_list":["post-15243","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software-development"],"acf":{"reading-time":"11 min","show-toc-sublists":false,"image":null,"logo":null,"button1":{"button1_type":"","button":null},"button2":{"button2_type":"","button":null},"person":{"person_photo":null,"person_name":"","person_position":""}},"_links":{"self":[{"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/posts\/15243","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/users\/166"}],"replies":[{"embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/comments?post=15243"}],"version-history":[{"count":0,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/posts\/15243\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/media\/14435"}],"wp:attachment":[{"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/media?parent=15243"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/categories?post=15243"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/tags?post=15243"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/coauthors?post=15243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}