Docker company established back in 2013 revolutionized the concept of software packaged in containers. Although the concept behind the technology was not new, it was Docker that empowered the ubiquitous deployment of container software. Once the hype transformed into a widespread adoption of this innovative and exciting system, an add-on in the form of a container orchestrator called Swarm made its appearance. A relatively new on-the-market arranger was not only built directly into the Docker system but was also responsible for managing container scheduling in relation to several hosts.
As it has gotten more and more popular over the years, people have started wondering whether there is more to this seemingly flawless technology. This reluctance has resulted in them becoming more demanding for an additional value. The search for a better alternative has begun. Consequently, another system with a similar nature known as Kubernetes was developed. Designed by Google, it presented an appealing software for the deployment, scaling, and management of applications. The technology gained popularity quite quickly, which prompted a question: is the Docker Swarm era coming to an end? Or is it still being used in 2021? If so, what does the future hold for Docker Swarm?
Is Docker Swarm Dead by 2021?
Before answering the question, it is critical to make sense of the system and its peculiar features. What gives the edge to favoring Docker Swarm over any other similar software is its simplicity. It does not involve any complex attributes one ought to learn beforehand and is thus accessible to everyone. Besides being easy to use, the availability of two cluster node types such as master and worker guarantees the continuous functionality of the software. This is possible due to the nodes working in a complementary mode, thus enabling the user to not experience any downfalls. Basically, in case one node fails to operate, the other one comes to rescue. And, in the event of both of them breaking down, containers are suspended to other sets of nodes (Skałecki, 2017).
The affirmative configuration is another trump card in the hands of Docker Swarm. According to the number of replicas the user requires, the system is able to satisfy the demand in an automatic mode while also taking into consideration existing limitations. The option of making referrals to various services and thus aiding in their discovery is an additional feature of the software. Regardless of the containers’ storage place, the solicitations are bound to come in on a regular basis. Lastly, the updates associated with the Swarm’s configuration are secured. This means that as soon as the configuration is updated, the batches of containers are updated by default as well (Skałecki, 2017).
All of these benefits are naturally attractive to IT experts as much as to those with zero knowledge in the industry. For this reason, the software could not simply die and not be adopted and perfected by other systems of similar nature. This is exactly what happened with Docker Swarm. The container industry conference known as Dockercon that took place in 2017 served as a ground for Docker’s orchestration with Kubernetes. Hence, the software is still being used either by itself or in combination with Kubernetes. With other systems like Apache Mesos and HashiCorp Nomad gaining momentum in the same arena, the strive for more qualitative services and solutions to common issues is there. It has more advantages than disadvantages though, as it persuades companies to better their products and attract more loyal customers.
Is anyone using Swarm in production in 2021?
As mentioned in the previous paragraph, Swarm remains to be utilized by both Docker and Kubernetes as a core engine for container storage. Granted that Kubernetes is in a dominant position on the market right now, its adoption and usage of Swarm continue to be in the spotlight. Indeed, the wise move of the Kubernetes community to take over and implement the popular software-enabled Cloud Native Computing Foundation to reap the benefits of running a successful business (Kennedy, 2017).
It appears that Docker does not present the only company widely used by users across the globe anymore. This is, however, not a bad thing. Instead, this change must be seen as an evolution in the industry that widened the spectrum of the community’s usage of open-source software. Users have gained knowledge of how to operate various software apart from the one developed by Docker. Swarm, brought into Kubernetes operation, has undergone several changes under the guidance of the Google’s Developer Advocate Kelsey Hightower. From CRI-O to containers and then to visors, the progression is apparent (Saidel-Keesing, 2019).
The future of Docker Swarm
The list of alternatives coming to the market is steadily increasing – kata containers and clear containers are merely a few of them. Are they going to ultimately take over the Swarm? We cannot predict that. For the time being, however, we can explore the possible scenarios of what could happen to Docker Swarm in the nearest future. To have a clear picture of feasible changes in the Docker’s future, one has to keep in mind that the containers stored in the software had the initial goal of using the Linux features to the maximum. As the company began to base its operational activity on these features, the viability of Docker Swarm is dependent upon their improvement.
To keep Docker alive, developers ought to meet the diverse requirements that have arisen in the past few years. One of them involves exploiting, in the best ways possible, the latest kernel aspects of Linux 5.0 along with adapting to the stateful workloads, which are more tricky than the stateless ones. Also, the workloads recognized as ‘Edge’ workloads could be adopted at the network’s edge as opposed to the widely used core cloud. Docker would greatly benefit from the Internet of Things (IoT) integrated into small-scale devices as much as from industrial settings. From a security standpoint, Docker could employ enhanced support for the namespace. This could potentially influence the provision of permissions executed by default and affecting operating containers, which would also assist in reaching the bigger goal of creating rootless containers (Fisher, 2018).
All things considered, we are prone to believe that Docker and Swarm, in particular, have the time and place for existence and improvement. Undoubtedly, the new containers present a big competition for the vulnerable position of Docker, and they have all the reasons to remain that way. The innovations in the informational technology realm require fast, secure, and feature-rich software that is also fully automatic. Surely, why would anyone want to use something that is old and outdated when there are countless efficient options out there? This puts pressure on companies like Docker that have earned their place on the market throughout the years. But besides pressure, a stimulus to evolve, implement innovative and exciting features also appears on the horizon. And, if Docker decides to step up its game and get on the same level as other companies (or soar even higher), the debates whether or not its products’ life cycle is coming to an end will no longer be present.