Docker has a storied history of being one of the most widely used developer toolings of all time. In the early days of containers, it was the only thing being used for local container development, and their contributions will be forever remembered as a major factor in the speed at which container technology was adopted.
Docker also created a container orchestration platform called Docker Swarm. The Swarm platform was widely used in development environments, but due to Docker's other offering at the time called "Docker Enterprise" (an early kubernetes alternative), Swarm was mostly kept off the production side of things.
Docker Enterprise wasn't met with quite the same warmth as their dev tooling and in order to fully focus on their local platform they offloaded the entire enterprise suite to Mirantis. When this happened "Swarm Classic" was retired and over time Mirantis started offering "Swarm" alongside its Mirantis Kubernetes Engine package.
With Swarm Classic retired, and Mirantis Swarm only running on the Mirantis Container Runtime, Docker wanted a way to cluster multiple Docker engines together (even if its goal was not enterprise adoption). They released "Swarm Mode" as part of the Docker toolset and used that offering to bring back access for folks that wanted to run Docker Swarm on top of the Docker engine.
So what exactly is Swarm? In its essence, Swarm is a way to manage multiple Docker engines as a single, virtual Docker engine. Most iterations of this product integrate natively with the Docker Engine, aiming to provide a more seamless experience for deploying and managing a cluster of Docker nodes.
A Swarm cluster has:
Cycle is a platform that is an alternative to Docker Swarm, Kubernetes, ECS, Cloud Run, and others. While many of the simplicity-first promises that Swarm makes are comparable with our own Cycle manifesto, the strategies for realizing these goals differ significantly.
Built from the ground up, without a single line of Docker or Kubernetes, Cycle takes an approach to container orchestration and infrastructure management that leaves far less burden on the end user. The "Bring Your Own Infrastructure" model remains the same between the two, but there is no differentiation between manager nodes and worker nodes on Cycle, as the platform maintains its own control plane. This is neatly abstracted from the user, reducing operational overhead massively.
Cycle users consume a single, vertically aligned platform. We call our approach, LowOps, as it is sophisticated enough for modern architectures but approachable enough for developers that don't have DevOps expertise. This is achieved by exposing primitive building blocks that users can compose together to achieve the deployment that's right for their product.
Classic Swarm is an archived project and Docker Swarm mode isn't really meant for production. While that hasn't kept many organizations from using it to get started, at a certain point those organizations naturally outgrow Swarm.
Let's take a look at some common situations and their outcomes for teams moving from Swarm to Cycle.
Managing Swarm isn't a zero cost endeavor. An image still needs to be shipped to each node, balancing worker and manager nodes needs to be overseen, upgrades need to be rolled out (to multiple environments). At a certain point, Swarm outgrows itself because at scale it loses touch with its original implementation promises and complexity becomes burdensome.
With Cycle, the infrastructure layer is completely standardized and automated across all compute nodes. All updates are delivered automatically, and there's never a question of compatibility with a new release.
Yes there are zero downtime deployments available, but again the operational knowledge needed to manage a growing fleet of services and then also manage how those services are redeployed can become a "Ops" problem. Swarm lacks the maturity in tooling to manage this, and when teams start feeling this, they look elsewhere for platforms like Cycle which offer full deployment automation.
Using Cycle Deployments combined with Pipelines, users can quickly and intuitively set up rainbow deployments through the portal, API, or soon through the CLI.
The final point here, and one many teams consider deeply, is that Swarm doesn't really have a cohesive long term, production focused vision. Classic Swarm is retired, Docker itself is ultra focused on the local developer and while Mirantis does offer Docker Swarm, it is only available adjacent to their Kubernetes offering. So, the community, or at least the members we've been exposed to, just don't see where it might go.
On average, the Cycle platform has received an update every 2-3 weeks for the last 5+ years and we're just getting started. Our vision is to provide a solution to the growing complexity in DevOps, and provide a beautiful middle ground between "customize everything" and "one-click simplicity".
More companies than ever are migrating from platforms like Swarm, ECS, Fargate, and even Kubernetes to Cycle. If you're one of these teams, or, you're just interested in learning more about how Cycle could help your team, we'd love to chat!
💡 Interested in trying the Cycle platform? Create your account today! Want to drop in and have a chat with the Cycle team? We'd love to have you join our public Cycle Slack community!