DEV Community: Alex Susanu

Why Kubernetes Won the War Against Docker Swarm: The Rise of Enterprise Container Orchestration

Alex Susanu — Sun, 02 Aug 2026 13:50:36 +0000

In 2016, it wasn't obvious which container orchestration platform would win. Docker Swarm had the advantage of being built directly into the Docker CLI — if you already had Docker running, Swarm mode was one command away. Kubernetes, by comparison, was more complex to set up, had a steeper learning curve, and came out of Google's internal infrastructure rather than a tool most developers already used daily.
Five years later, the question wasn't a question anymore. Kubernetes had become the default answer to "how do we run containers in production," and Docker Swarm had faded into a footnote — still functional, still maintained, but no longer where the industry's attention or investment went.
Simplicity lost. Here's why.

1. Kubernetes Built an Ecosystem; Swarm Built a Feature

Docker Swarm was designed to do one thing well: orchestrate containers with minimal setup. That focus was also its ceiling. Swarm shipped with a fixed set of capabilities, and extending it meant working within Docker's own roadmap and release cycle.
Kubernetes took a different approach from the start: a small, stable core (the API server, scheduler, controller manager) surrounded by an extension model — Custom Resource Definitions, the Operator pattern, admission controllers — that let anyone build on top of it without waiting for Kubernetes itself to add a feature. That decision is what allowed Helm, Istio, Prometheus, cert-manager, and hundreds of other tools to grow up around Kubernetes rather than needing to be built into it.
Why it mattered: by the time enterprises were evaluating orchestration platforms in 2018–2019, one of them had a mature ecosystem of tooling for logging, service mesh, secrets management, and CI/CD integration — and the other expected you to build most of that yourself.

2. Kubernetes Became the Neutral Ground; Swarm Stayed a Docker Product

Docker Swarm's fate was tied to Docker Inc.'s fate. When Docker the company ran into business trouble in 2019 and sold off its enterprise division, Swarm's future became uncertain along with it — not because the technology stopped working, but because nobody was sure who was steering it.
Kubernetes had already avoided that problem by design. Google donated it to the newly formed Cloud Native Computing Foundation in 2015, turning it into vendor-neutral infrastructure governed by a foundation rather than a single company's product roadmap. That mattered enormously to enterprises: AWS, Microsoft, and Google could all build competing managed Kubernetes services (EKS, AKS, GKE) on the same open standard, and a customer's workloads stayed portable across all three.
Why it mattered: enterprises don't like betting infrastructure on a single vendor's continued existence. Kubernetes gave them a technology that no single company could take away or discontinue.

3. Kubernetes Took Self-Healing and Scaling Further

Both platforms could restart a failed container and scale a service up or down. But Kubernetes built its entire architecture around a reconciliation loop: you declare the desired state of your system, and controllers continuously work to make reality match that declaration — whether that means rescheduling a pod, replacing a node, or adjusting replica counts based on load.
Swarm's model was simpler and more imperative: closer to "run this many containers" than "continuously enforce this state no matter what changes." That simplicity was easier to reason about early on, but it meant Swarm couldn't easily support the more complex, self-healing behaviors that large-scale production systems increasingly needed — automatic horizontal scaling based on custom metrics, pod disruption budgets, sophisticated rolling update strategies with health-check gating.
Why it mattered: as workloads got more complex, the gap between "restart on failure" and "continuously reconcile toward a declared state" became the difference between manual firefighting and infrastructure that mostly took care of itself.

4. Kubernetes Had Broader Corporate and Community Investment

Docker Swarm was maintained largely by Docker Inc., a company with a limited engineering budget and, for a period, real questions about its own survival. Kubernetes had Google's original engineering investment, and — once it moved to the CNCF — contributions from Red Hat, Microsoft, AWS, IBM, and a rapidly growing base of independent contributors, all with a direct interest in the platform succeeding.
That difference in scale showed up everywhere: release cadence, documentation quality, security response time, the sheer number of people available to answer a Stack Overflow question at 2am. A technology maintained by an entire industry outpaces one maintained by a single struggling company, almost regardless of the original technical merits.
Why it mattered: enterprises evaluating a multi-year infrastructure bet look at who's behind a technology, not just how it works today — and Kubernetes had an entire industry's answer to "who happens if this company disappears."

5. Kubernetes Supported the Full Range of Enterprise Workload Types

Swarm was built primarily around one workload shape: stateless services that could be freely restarted and load-balanced. That covered a lot of real use cases, but enterprise environments also run databases, message queues, batch jobs, and daemon processes that need to run on every node — workloads with very different requirements around identity, storage, and scheduling.
Kubernetes shipped native primitives for each of these: Deployments for stateless services, StatefulSets for workloads needing stable identity and storage, DaemonSets for per-node processes, Jobs and CronJobs for batch and scheduled work. That range meant an enterprise didn't need a second orchestration platform for the workloads that didn't fit the "simple stateless service" mold — which is where a large share of genuinely important production workloads live.
Why it mattered: enterprises don't run one kind of workload. A platform that natively handled all of them was a simpler enterprise architecture than one that handled most of them well and needed workarounds for the rest.

The Underlying Pattern
None of Kubernetes's advantages were really about being easier to use — by almost every account, it wasn't, especially in its early years. It won because it was built to be extended, governed by more than one company, designed around continuous reconciliation rather than one-time commands, backed by an entire industry's engineering effort, and capable of running the full range of workloads a real enterprise actually has.
Docker Swarm optimized for the day-one experience. Kubernetes optimized for what a production system looks like three years in, with fifty engineers, six teams, and workloads nobody anticipated when the project started. In enterprise infrastructure, that's the bet that tends to win.

About the Author
I'm Alex Susanu, an IT Consultant focused on helping businesses and professionals navigate technology and solve real-world IT challenges.
🌐 Learn more about my work: https://alexsusanu.com/

The API Integration Problem Every Small Business IT Consultant Runs Into

Alex Susanu — Mon, 27 Jul 2026 13:58:56 +0000

Most small businesses don't run one system — they run five or six. A CRM for sales, QuickBooks for accounting, a scheduling tool, an email platform, maybe a POS system. Each one works fine on its own. The problem shows up the moment they need to talk to each other.
As an IT consultant, this is usually where the "quick fix" client call turns into a multi-week project. What looks like a simple request — "can you just connect our CRM to our invoicing tool?" — often uncovers a mess of mismatched data formats, missing documentation, and fragile workarounds someone built years ago and then left the company.
Here are five integration problems that come up again and again, and how to think about each one before you start writing code.

1. Authentication and API Key Chaos

The first wall most consultants hit isn't the integration logic — it's just getting authenticated. Small businesses rarely have a system for managing API keys. Keys get emailed, pasted into shared docs, hardcoded into scripts, and forgotten about. By the time you're brought in, nobody remembers which key belongs to which integration, or whether it's even still valid.
What this actually costs: hours spent guessing which credentials work, plus a security risk that outlives the project — an old key left active in a forgotten script is an open door.

What to check first:

● Does the client have a password manager or vault, or is this the moment to introduce one?
● Are keys scoped down to only the permissions the integration needs, or was someone handed a master key out of convenience?
● Is there a plan for rotating keys if one is compromised?

2. Rate Limits That Break Automations Silently

Most third-party APIs cap how many requests you can make per minute or per day. Small business tools rarely surface this clearly, and it's easy to build an integration that works perfectly in testing — then quietly starts failing in production once real transaction volume hits.
The worst version of this problem isn't a hard failure. It's a silent one: a batch sync skips half its records, and nobody notices until a client asks why last week's orders never showed up in the accounting system.
What this actually costs: lost trust when a client discovers missing data weeks later, and a debugging session that starts with no error logs to go on.

What to build in from day one:

● Retry logic with backoff, not just a single request-and-hope
● Logging that records failed calls, not just successful ones
● Batching that respects the provider's documented limits, even if the client's data volume seems too small to worry about it

3. Data Format Mismatches Between Systems

A customer's name field might be first_name / last_name in one system and a single full_name string in another. Dates might be stored as MM/DD/YYYY in one tool and ISO 8601 in another. None of this is exotic — but it's exactly the kind of small mismatch that breaks a sync at 2am and nobody can explain why.
This problem compounds with every new system added. What starts as "just map two fields" becomes an ever-growing translation layer nobody fully understands, often held together by a script one person wrote and nobody else has touched since.
What this actually costs: duplicate or malformed records that take longer to clean up than the original integration took to build.

What helps:

● A single, documented schema that every integration maps to and from — rather than direct system-to-system mappings that multiply as you add tools
● Validation on the way in, not just the way out, so bad data gets caught before it reaches a second system

4. Undocumented or Legacy APIs With No Versioning

Not every tool a small business relies on has a modern, well-documented API. Some integrations run against internal tools, old POS systems, or APIs that haven't been updated in years — with documentation that's outdated, incomplete, or simply doesn't exist.
Worse, an undocumented API can change without notice. A field gets renamed, an endpoint gets deprecated, and the integration breaks with no changelog to explain why.
What this actually costs: integrations that work today and fail unpredictably down the line, with no clear signal of what changed.

What reduces the risk:

● Testing against the live API directly rather than trusting existing documentation
● Building a thin adapter layer around any undocumented API, so a change only requires updating one place instead of every integration that touches it
● Setting client expectations up front that this kind of integration carries more ongoing maintenance risk than a well-documented one

5. No Error Handling for When an API Goes Down

Every third-party API has downtime eventually — a payment processor's API has an outage, a scheduling tool goes down for maintenance, a CRM has a bad deploy. If an integration has no plan for this, the failure doesn't stay contained. An order doesn't get logged, an invoice doesn't get sent, and the business only finds out when a customer complains.
What this actually costs: small outages turning into client-facing problems, and consultants getting blamed for a third party's downtime.

What a resilient integration needs:

● A queue or holding area for failed requests, so nothing is silently dropped
● Alerting that tells you (or the client) when something failed, instead of relying on someone noticing missing data
● A documented fallback — even a manual one — for when an integration is down longer than expected

The Underlying Pattern

None of these five problems are really about code. They're about the gap between how small businesses think their systems work ("it just syncs") and what's actually required to make that true reliably: credential management, rate awareness, shared data standards, resilience to undocumented change, and a plan for failure.
The consultants who do well with integration work aren't the ones who write the cleverest sync script — they're the ones who ask about authentication, volume, and failure handling before writing any code at all.

About the Author

I'm Alex Susanu, an IT Consultant focused on helping businesses and professionals navigate technology and solve real-world IT challenges.

🌐 Learn more about my work: https://alexsusanu.com/