A retail infrastructure team who already had spent almost half a million dollars attempting to move away from VMs into containers. A retail infrastructure team with nearly six figures lost in their attempts to move away from VMs into containers. They were exhausted. Not because containers broke, but because they selected the wrong platform for orchestration for their size and growth of their engineering team.
Strangely enough, they used to have a Docker Swarm setup without any issues at all.
Then the leaders joined a cloud conference, listened to several vendors touting them as the next great thing and found their inner voice switch to “stable deployment platform” to “we are behind the market.”
That’s what caused eight months of pain during operation.
When it comes to Kubernetes vs Docker Swarm, the discussion typically revolves around the technical aspects. In reality, businesses seldom make such a choice based on the features alone. They craft it based on reality of hiring, complexity of operations, alignment with the cloud vendor, the pressure of compliance, and infrastructure chaos they can handle in the next two years.
This alters the situation radically.
Most enterprises are not choosing the technically simpler platform anymore
Docker Swarm, at least on the surface, is still very straightforward when compared to initial deployment experiences.
You deploy services, and things work fast without having to learn dozens of new abstractions, and you install Docker, initialize a cluster and that’s it. I can recall the speed with which our first Swarm deployment was applied to a medium-sized SaaS application, having ~40 Developers. In less than a day the infrastructure team was able to get services discovered and containers scheduled to run.
This was the exact opposite with Kubernetes.
But the first production cluster we built took a number of weeks for us to get our policies, ingress controllers, networking plugins, RBAC policies, persistent storage classes, observability tools and CI/CD integration right. New and seasoned Linux administrators alike were overwhelmed by the amount of moving parts.
But so do enterprises continue to select Kubernetes.But still, enterprises are going with Kubernetes. Not because it’s cheaper.
Eventually, whatever is simple in the organization, will come back to bite them in the ass when they need to be flexible.
The Cloud Native Computing Foundation has released its annual surveys, which show that the use of Kubernetes is growing in enterprise IT environments, but Docker Swarm has been declining in visibility in large-scale production environments. As enterprises increasingly see Kubernetes as more than just another orchestration tool, the technology is gaining traction.The technology is gaining momentum as enterprises begin to understand that Kubernetes is more than just another orchestration tool, it’s a long-term infrastructure alignment.
This does count when it comes to finances.
Why Kubernetes keeps winning despite the operational frustration
I’m not sure most executives realize that it costs a lot of money during the first year to run Kubernetes.
This is a No-brainer when it comes to infrastructure cost. The talent cost is not a.
A production-level Kubernetes platform engineer with extensive production experience can expect to make much more than a traditional systems admin. Then you add:
- observability tooling
- security platforms
- managed cluster services
- container registry costs
- compliance controls
- service mesh experimentation
In a single swoop, the “modernization initiative” is put into budget reality.
But, Kubernetes addresses issues that large organizations have to face regardless of their readiness or not.
Initially a health care analytics company I had worked at were not very enthusiastic about Kubernetes because they could manage their workloads with Docker swarm. It was more important for them to be simple to operate than large in ecosystem size, said their engineering director.
He was somewhat correct.
Later, the company went international and began to support workloads across different regions in the cloud with more demanding compliance standards. Swarm started having problems with its operational use with regard to advanced autoscaling behavior, policy management and infrastructure standardization across the environments.
Despite this, the move to Kubernetes was made anyway.
Only later and with greater compupression.
One of the most misinterpreted aspects of the Kubernetes landscape is that. But businesses will often delay adopting, and believe that they are avoiding complexity they are really just delaying complexity until the organisation is bigger and less flexible.
Kubernetes vs Docker Swarm becomes a staffing problem faster than a technology problem
It’s one area that seldom sees a frank discussion. Availability of talent is the life of infrastructure platforms.
You may build the perfect Docker Swarm setup you can think of, but once you start hiring engineers that know Kubernetes, things flip-flop in an instant.
That’s what’s going on in the enterprise market, as a whole. Cloud service vendors have gone all-out for this transformation:
They realised that there’s a lot of value in the managed Kubernetes ecosystem, and they were doing a lot of investment. Adopting Kubernetes operational models led to cloud’s adoption gaining momentum around the surrounding services naturally.
Docker Swarm didn’t pull that same gravity towards itself to form this ecosystem. But the Earth’s attraction is more important than engineers would think.
Your team will reap huge rewards from:
- massive documentation availability
- community troubleshooting
- mature observability integrations
- broad vendor support
- standardized operational patterns
Kubernetes does that today at the Enterprise scale. Docker Swarm offers an easy-to-use solution, but is shallower in ecosystem support.
That doesn’t necessarily make sense for smaller organizations. This doesn’t for the most part for a global organization.
The simpler platform sometimes creates better business outcomes
The non-intuitive aspect that most people who advocate Kubernetes don’t like to admit to the world.
I’ve witnessed firms become over-engineered and go straight into longer delivery cycles.
Many logistics companies embraced Kubernetes even before they had a dedicated platform engineering team.Many logistics companies embraced Kubernetes even before the onset of a dedicated platform engineering team. Leadership thought that it would be easy to get better deployment reliability and developer productivity by using modern infrastructure.
Rather, developers spent months getting to know the nuances of YAML, working out network-related issues, and keeping up with tools overlying the tools, which provided little value to the customer in the short term.
A competing company, using the same product, worked in the same space, but quietly used Docker Swarm infrastructure with a smaller team, and shipped product features faster.Meanwhile, another company, competing in the same space, was quietly working with Docker Swarm infrastructure with a smaller team and releasing product updates sooner.
The easier the architecture was, the more of a business benefit it was. It was a learning experience for me, as far as I’m concerned, on assessing decisions in orchestration.
Sophistication of infrastructure doesn’t necessarily equal maturity. At times, enterprises become Kubernetes adopters for the following reasons:
- investors expect it
- recruiters market it
- engineers want resume value
- vendors promote it aggressively
These are actual pressures of an organization. However, not all the time it is for good technical reasons.
I’ve become more and more skeptical of any [container strategy] that’s more focused on the trend than being operationally viable.
What large enterprises actually optimize for
As the organization grows, conversations about infrastructure move beyond a technical to a more complex and strategic territory.
The responsibility for risk management takes over.
Cloud modernization benefit 2 is that a financial services company I saw during a modernization project didn’t care about the elegance of the orchestration, but rather:
- auditability
- vendor neutrality
- workload portability
- security policy enforcement
- disaster recovery consistency
The surrounding ecosystem was much more advanced in the context of enterprise governance requirements, making Kubernetes more aligned with the priorities.
That includes some tools from the companies such as:
Docker Swarm just didn’t have anything as similar to enterprise tooling momentum.
Platform engineering and cloud-native, operational consistency have been leading enterprise priorities as recognised by Gartner over the years. The broad cloud-native strategy became more and more about Kubernetes, and not just operating as a container scheduler.
The overall market momentum plays a big role in influencing procurement decisions.
Executives do not usually want to invest in standardization of the future infrastructure around ecosystems that are perceived as declining.
Despite the technology still functioning correctly.
The hidden cost nobody mentions during Kubernetes migrations
Tool sprawl.
This is more aggravating to me than it was a couple of years back as I see the same thing happening in multiple enterprises.
A company comes on into Kubernetes with the assumption that they’re going to have infrastructure standardization.
After 6 months they are doing ok:
- Helm
- ArgoCD
- Prometheus
- Grafana
- Istio
- Fluent Bit
- external secrets management
- multiple ingress layers
- policy engines
Every additional tool introduces:
- maintenance burden
- upgrade risk
- compatibility issues
- security exposure
- training overhead
In another manufacturing company I used to work, one of their production incidents came about when there was an incompatibility between the ingress controller updates that they did during a maintenance window, which caused disruption to their internal APIs. The power outage was less than 2 hours.
The effective cleanup downstream was accomplished in almost 2 weeks. These dangers were not discussed when the original proposal was made for the migration.
Generally, Docker Swarm environments are not as fragmented in their ecosystems as they have a smaller architecture surface area. This simplicity can take a lot of pressure off lean infrastructure teams’ operational lives.
But boring infrastructure is at times, the right business decision.
So what are enterprises really choosing in the Kubernetes vs Docker Swarm debate?
Most of the organizations are opting for Kubernetes at the enterprise level.Not because it is by any means better in all circumstances.
Its ecosystem, hiring market, the investment sphere of the cloud providers, compliance tooling and the support and longevity of the platform are also increasingly revolving around it.
It’s a momentum one that is important, regardless of whether the engineers like it or not.
But I also believe that there’s been instances where the industry is hyping up the adoption of Kubernetes to businesses where they can run simpler systems for a few more years.
What is not modern is not “modern”.What is not modern is not “modern”.
If you are taking this seriously, dedicate 1 week to measuring how things are working in your organization, rather than another month to listening to opinions about architectures. It will probably help to figure that answer out quicker than another vendor presentation ever will, with that one exercise.
Author Bio
Talha Qureshi is an enterprise technology analyst and blogger with over a decade of hands-on experience across cybersecurity, cloud infrastructure, B2B SaaS, and enterprise AI. He writes about the gap between how enterprise technology is marketed and how it actually performs in real organizational environments.
