If you're in DevOps, you know the word 'Kubernetes'. While saying that mouthful of a word (generally shortened to k8s in text) would have gotten you a weird look and someone asking if you need to lie down before 2017, it's been sacrilegious to even consider starting a project without architecting your solution on top of it in the last few years.
Originally, Kubernetes was created by Google to solve a problem. It evolved out of 'Borg', which was designed way back in the mid-00's to manage internal clusters running thousands of jobs. Googol sized problems, if you will. Kubernetes was open-sourced in mid-2014, taking advantage of these new-fangled 'containers' everyone was talking about at the time (along with the creation of the CNCF). Initially, corporations began dogpiling onto the k8s bandwagon. But, a couple years after the dust has finally settled, a sizable number of businesses have begun the search to replace Kubernetes in their stack.
What is driving them to seek alternatives?
As the ecosystem grew, so did the scope of Kubernetes - more companies meant more agendas, and more 'chefs in the kitchen'. Kubernetes is being stretched out to be everything for everyone. Yet, paradoxically, it's not everything out of the box. Kubernetes is the base, and you have to build out the rest of the Lego pieces to make something functional you can present to your boss. Even more paradoxically, the pieces you choose lock you into decisions you're making before you may even begin to understand the scope of the problems your business will face:
Deploying a k8s cluster requires a plethora of decisions to be made, a vast amount of knowledge and training on how to do so, and a staff willing to maintain and update the cluster regularly. A lot of the companies who have adopted Kubernetes because it was the hot new thing to do, have run into wall after wall, spending millions of dollars to support something that was advertised to them as a miracle drug to cure all their ailments.
There's another problem when it comes to Kubernetes - the long term management costs. Often people tell me, “Alex, it's not that hard to deploy Kubernetes. I can get a cluster up and running in under an hour!”. To that I say, they're right. If you have the background knowledge on deploying Kubernetes clusters, it's easy to get one up and running in short order. (The same way that a professional chef is able to create mouth watering dishes with seemingly zero effort.) That said, let's assume I was able to easily deploy my cluster and run my containers. Now what?
The classic blunder companies are making when adopting Kubernetes is thinking 90% of the cost and effort are in the initial deployment. For some reason, it's assumed that k8s will either self update or be so easy that it isn't worth considering. The truth is, 1% of the effort is spent on creating and deploying a cluster, while the remaining ~99% is in ongoing maintenance. We cite this study constantly, but the #6 insight by DataDog on their study of over 1.5 BILLION containers is that “most hosts use a Kubernetes release that's more than eighteen months old”.
Wow. Putting that into perspective, imagine if you ignored those 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 the stability of new releases and compatibility issues are so problematic that it's easier to wait more than a year before upgrading, maybe we should consider carefully if we want to hop on to that bandwagon.
If you continue scrolling down that study, you'll also see things like “over 30 percent of hosts running containerd use an unsupported version” and “access management is improving but continues to be a challenge” - all of which point to the true cost of adopting a Google-scale tool for a business at 'not-quite-Google-scale'. That is to say, deploying k8s is easy..keeping it updated with the latest security updates across dozens or hundreds of servers without bringing your business offline is incredibly difficult.
It's gotten to the point where it's prudent to ask the question: “Has Kubernetes made us a better business?” (or for those of you out there looking to try…will it?). Unless you're running a 'Google-sized' business, the answer is most likely…not.
There has to be a better way.
There is no question that containers - the portable, lightweight, processes that Kubernetes was built to support - are truly the holy grail of software deployment. Despite all the surrounding tooling, containers themselves are pure and good.
At least, that's how my co-founder Jake and I felt back in 2015 when we saw Kubernetes was being open-sourced. We had learned about Linux containers shortly before Kubernetes, and had begun work on what would later become Cycle. We were determined to build a platform on which anyone could build anything, and containers were going to be the engine that made that possible.
Fast forward to today, and Cycle has become an exceptional DevOps platform, focused on providing an incredible experience while addressing the pain points of Kubernetes and Kubernetes wrappers that exist today.
We've taken a completely different approach to enterprise-scale container orchestration. We built our orchestrator (and the rest of the platform for that matter) from the ground up, not tying ourselves to the path Docker and Kubernetes went down. What we are after instead, is a fully integrated approach to DevOps, powered by containers, that 'just works'.
Cycle's core principle is that the platform should be incredibly easy to use, but not sacrifice any of the functionality one would expect out of a full blown, professionally managed Kubernetes deployment.
One way we've been able to achieve this is by building the most important tools of DevOps - DNS, load balancing, security monitoring, service mesh, private and public encrypted networks, CI/CD, etc, directly into the platform. This vertical integration gives us the ability to ensure the quality of every component while guaranteeing that it will 'just work'. An experienced Kubernetes aficionado may be able to get a cluster up and running in under an hour, but an experienced engineer deploying to Cycle will have a load balanced web app with dozens of instances spread across 3 different cloud providers, with security monitoring and CI/CD integration set up in around half the time. Their cluster still has everything they need, but Cycle guarantees it works, and continues to work.
Funnily enough, by solving the decision fatigue, we've made things far more reliable and safe. You may put off the decision on which security monitoring tool to use just to get something up and running faster, but how often does something like that slip through the cracks? (Remember, there's nothing more permanent than a temporary fix.) When deploying on Cycle, the critical components are built in – adding security monitoring won't take any extra time because it's already there.
When it comes to many problems in life, having the flexibility to choose from a hundred different options can be a good thing. But that comes with a tradeoff of time investment, energy, and reliability. Sure, it's nice to choose which flavor of ice cream you want, but do you want to choose which kind of bolt is used on the drivetrain every time you go to purchase a vehicle? At a certain point, it's impractical to make every choice at every level, and you want something that you can trust will 'just work'. Your decisions when it comes to DevOps should be “how many instances do we deploy” and “where”, not “which load balancer integrates with the service mesh we picked?”.
Cycle is ALWAYS up to date. We've talked a lot about container orchestration, because that's the only thing Kubernetes really does. However, we've been glossing over the other major thing the platform takes care of that Kubernetes does not - infrastructure.
When using Cycle, your business owns the infrastructure Cycle runs on, the same as if you deployed a Kubernetes cluster. The difference though, is that Cycle will manage that infrastructure for you, keeping everything from the OS to the orchestration layer your containers run on stable and current, eliminating security vulnerabilities as fast as they can be patched. You get the best of both worlds. The security and stability of a centralized platform, and the freedom and peace of mind that comes with owning your own infrastructure.
Moreso, you deploy infrastructure through Cycle, so whether or not you're deploying to AWS, Google Cloud, or even your own server in the back of a utility closet, the process is the same. This eliminates the need for perfect knowledge of all providers to go hybrid or multi-cloud, and empowers you to run containers anywhere with ease (thus removing another pain point where decision fatigue is likely).
Once you've gotten past the initial deployment, Cycle truly does allow you to 'forget it', without putting your business in jeopardy.
It's taken a long time for our approach to container orchestration to be validated. I'd argue we were 'too soon' for a long time, because most businesses had not gone through the pain of deploying and managing their own Kubernetes clusters yet. As we approach mid-2023, that story has changed, and more people than ever are looking for an alternative that doesn't involve quite so much hair-pulling.
💡 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!