If you’re in DevOps, you know the word ‘Kubernetes’. Before 2017, saying that mouthful (usually shortened to k8s) would have earned you a weird look. In the last few years, it’s been sacrilegious to start a project without architecting on top of it.
Kubernetes evolved out of ‘Borg’, which Google designed in the mid-00’s to manage internal clusters running thousands of jobs. Googol sized problems, if you will. Google open-sourced Kubernetes in mid-2014, riding the wave of these new-fangled ‘containers’ (and the creation of the CNCF), and corporations dogpiled onto the bandwagon. Now that the dust has settled, a sizable number of businesses are searching for a way to replace it.
What is driving them to seek alternatives?
Decision Fatigue
As the ecosystem grew, so did Kubernetes’ scope - more companies meant more agendas, and more ‘chefs in the kitchen’. It’s being stretched to be everything for everyone, yet it isn’t everything out of the box. Kubernetes is the base, and you build out the rest of the Lego pieces yourself. Worse, the pieces you choose lock you into decisions before you understand the problems your business will face:
- What service mesh are we using?
- What cloud provider are we going with?
- How are we handling DNS?
- What UI are we going to use?
- What monitoring tools are we implementing?
- Do we want to run services on premises as well as in the cloud?
- What about load balancing?
- How often will the cluster be updated?
Deploying a k8s cluster demands a plethora of decisions, deep knowledge, and a staff willing to maintain it. Many companies that adopted Kubernetes because it was the hot new thing have run into wall after wall, spending millions to support something sold to them as a miracle drug.
The Calm Before The Storm
There’s another problem: long term management costs. People often tell me, “Alex, it’s not that hard to deploy Kubernetes. I can get a cluster up in under an hour!” They’re right, if they have the background knowledge, the same way a professional chef makes mouth watering dishes look effortless. But say I’ve deployed my cluster and I’m running my containers. Now what?
The classic blunder is assuming 90% of the effort is in the initial deployment, and that k8s will either self update or be easy to keep current. In reality, about 1% of the effort goes into deploying a cluster and ~99% goes into ongoing maintenance. We cite this study constantly, but the #6 insight from DataDog’s study of over 1.5 BILLION containers is that “most hosts use a Kubernetes release that’s more than eighteen months old”.
Wow. Imagine ignoring the update requests on your personal PC for 1.5 years (you’re definitely not doing that…right?). Enterprise software controlling our banks, our economy, maybe even our lives…is statistically likely to be years behind on security updates? If upgrading is so painful that waiting more than a year is easier, maybe think carefully before hopping on that bandwagon.
The same study finds “over 30 percent of hosts running containerd use an unsupported version” and “access management is improving but continues to be a challenge”. That’s the true cost of a Google-scale tool for a ‘not-quite-Google-scale’ business. Deploying k8s is easy. Keeping dozens or hundreds of servers patched without taking your business offline is incredibly difficult.
So ask yourself: “Has Kubernetes made us a better business?” (or, if you’re considering it…will it?). Unless you’re ‘Google-sized’, the answer is most likely…not.
There has to be a better way.
The Better Way
There’s no question that containers - the portable, lightweight processes Kubernetes was built to support - are the holy grail of software deployment. Strip away the surrounding tooling, and containers themselves are pure and good.
That’s how my co-founder Jake and I felt in 2015 when Kubernetes was open-sourced. We’d discovered Linux containers shortly before and had begun work on what would become Cycle: a platform on which anyone could build anything, including platforms of their own, with containers as the engine.
Today, Cycle is the platform for building platforms, built to fix the pain points of Kubernetes and its wrappers. If your business delivers its product through a website, an API, a mobile app, a CLI, or an MCP server (with plenty of moving parts underneath), we built Cycle for you.
We built our orchestrator, and the rest of the platform, from the ground up instead of following the path Docker and Kubernetes went down. The goal is a fully integrated, container-powered approach to DevOps that ‘just works’, so teams spend their time building their platform instead of babysitting the one underneath it.
Eliminating Decision Fatigue
Cycle’s core principle: the platform should be incredibly easy to use without sacrificing any functionality you’d expect from a full blown, professionally managed Kubernetes deployment.
To get there, we built the most important DevOps tools - DNS, load balancing, security monitoring, service mesh, private and public encrypted networks, CI/CD, and more - directly into the platform. That vertical integration lets us guarantee every component ‘just works’. A Kubernetes aficionado might stand up a cluster in under an hour. In around half that time, an experienced engineer on Cycle will have a load balanced web app with dozens of instances across 3 cloud providers, with security monitoring and CI/CD in place, and Cycle guarantees it keeps working.
Funnily enough, solving decision fatigue also makes things more reliable and safe. Put off choosing a security monitoring tool to ship faster, and how often does that slip through the cracks? (There’s nothing more permanent than a temporary fix.) On Cycle, security monitoring is already there, so it takes no extra time.
Having a hundred options can be a good thing, but it costs time, energy, and reliability. It’s nice to choose your ice cream flavor, but do you want to pick the bolts on the drivetrain every time you buy a car? Your DevOps decisions should be “how many instances do we deploy” and “where”, not “which load balancer integrates with the service mesh we picked?”.
Eliminating the Never-Ending Management Nightmare
Cycle is ALWAYS up to date. We’ve focused on container orchestration because that’s all Kubernetes really does. But there’s another major thing Cycle handles that Kubernetes doesn’t: infrastructure.
With Cycle, your business owns the infrastructure, the same as with a Kubernetes cluster. The difference is that Cycle manages it for you, keeping everything from the OS to the orchestration layer stable and current, and patching security vulnerabilities as fast as fixes are available. You get the security and stability of a centralized platform with the freedom of owning your own infrastructure.
You also deploy infrastructure through Cycle, so the process is the same whether you’re on AWS, Google Cloud, a server in a utility closet, or hardware at a customer’s site. You don’t need perfect knowledge of every provider to go hybrid or multi-cloud, and that’s one less place for decision fatigue to creep in.
Once you’re past the initial deployment, Cycle truly lets you ‘forget it’ without putting your business in jeopardy.
Manage Deployments and Infrastructure with AI
Taking decisions off your plate has always been the point, and Cycle's Hosted MCP is our latest step. Connect it to the AI tool your team already uses, and you can deploy applications, diagnose issues, search logs, and manage infrastructure on Cycle just by describing what you want.
Like everything else on Cycle, it just works without adding risk. The MCP sits outside the platform as another interface, like the portal, and updates automatically alongside the Cycle API. With an API key, it inherits the roles and capabilities you’ve already configured, and every change goes through double verification, so nothing happens without your explicit approval.
Remember when we said your DevOps decisions should come down to “how many instances” and “where”? With the MCP, that’s the whole conversation. Ask your AI tool to scale a container or stand up a new environment, review the plan, and give it the green light.
Cycle: The Best Platform for Building Platforms
It’s taken a long time for our approach to be validated. I’d argue we were ‘too soon’, because most businesses hadn’t yet felt the pain of running their own Kubernetes clusters. Today that’s changed, and more people than ever want an alternative with a lot less hair-pulling.
For teams building platforms of their own, that alternative is Cycle. You bring the product, and we’ll keep the foundation underneath it stable, current, and out of your way, whether you manage it from the portal, the API, or your favorite AI tool.