The journey to selecting a container platform is a fun and exciting time in any organization. Container technology abstracts away so many problems from cloud 1.0 VM based approach, and puts engineering teams back in the distributed drivers seat.
As containers continue to mature and adoption becomes ubiquitous, there are many lessons to learn and ideas to consider before inevitably choosing Cycle.
Let's take a look at Cycle alongside the other types of container platforms:
Docker, well known for being the catalyst for container popularity, is an approachable technology meant for local development. Over the years, many companies have moved to wrap Docker (and its other pieces like swarm and compose) in additional layers making it somewhat more viable to run in production settings.
If your organization is looking to run many single node deployments or very simple workloads on a small number of servers, Docker or a Docker wrapper could be a decent choice for you.
AWS, GCP, Azure, and others all offer different services when it comes to running your containerized workloads. The interesting thing is, outside of kubernetes offerings (which we will cover in the Kubernetes wrappers section), none of the big 3 can really agree on the best way to run those workloads.
AWS has ECS and Fargate.
GCP has Cloud Run and Anthos.
Azure has Azure Container Service.
Each one of these services has a different approach to running containerized workloads, with their respective parents' flavor mixed in. None of them are bad choices, but in conversations I've had over the past half decade I can say that almost always people admit to using these services because they, “didn't want to use anything more complex and still wanted to use containers”, and generally just aren't excited about the service itself.
The onslaught of k8s wrappers that have come out in the last 5 years is almost as large as the promises they tend to make around making kubernetes easier, simpler, more manageable, less complex, etc, etc. And the irony, at least from where I'm sitting, is that the mainstream k8s diehards still wont admit to themselves that these issues exist… Even in the face of a growing number of organizations building their entire business around that premise.
In the space between IaaS container services and kubernetes is a platform built for developers, promising to maintain simplicity at scale through its opinionated standardization and automation layers.
When choosing a container platform the following items should be top of mind.
It might come to some as an afterthought but technical debt, especially new downstream technical debt, is a major factor when it comes to container platforms.
Kubernetes, specifically, will not only cost you a huge amount of $$ to maintain, but all the other technologies you'll have to adopt to piece together a complete solution will cause a web of technical debt that cannot be avoided.
I won't argue that there are applications that require this level of complexity (inherently) BUT, I would say that the vast majority of products don't need anything close to it.
I think a simple way to reason about the impact each platform could have on your long term technical debt is to consider what your team will be responsible for maintaining and what the platform abstracts.
Common things in this space are:
With Cycle, your team will never need to deal with managing networks, services, infrastructure or OS (updates or upgrades). So when considering the impact that choosing Cycle would have on your long term technical debt you can eliminate those categories completely from your evaluation, as the platform will fully manage them in every capacity.
Using Docker wrappers or IaaS specific tooling you may get abstractions on pieces of these things but generally you'll still need to manage, upgrade, update, and interact with the underlying infrastructure, OS, and package itself as part of your weekly / monthly engineering workload.
One of the most overlooked and yet still critically important piece of this puzzle is team composition. If you make a decision based on what's best for someone else's team (maybe someone with far more resources than you have at your disposal) it can be a recipe for disaster.
It's also important to look at how your team might change when making this move. Questions such as the following are important to ask:
The real picture you're trying to paint here is one that takes into account the constraints of your workforce, the demands of your organization on new features and existing responsibilities, and really the total impact that this new platform will have on the engineering org as a whole.
If you're evaluating a new, greenfield project, OR, if you're already containerized and just looking to shift platforms... feel free to skip this section.
There are three popular migration strategies:
While each of these has their advantages, one thing you may want to keep in mind is the idea that targets will change. While you might initially set out to fully refactor your application, issues may arise that force you back into a re-platforming stance. Will the container platform you choose be flexible enough to handle that change in course?
Vertical integration is a big topic these days. Tesla, Apple, SpaceX, Amazon, Netflix… all these companies make vertical integration a top priority.
For container platforms, vertical integration and completeness come hand in hand. If it all just came down to putting containers on servers and that was it, IaaS services would just win every project. But there's so much more than that.
Cycle users get access to a growing range of these additional services, knowing that each service was developed to work perfectly with its complementary pieces.
The tighter the timeline the more restricted your choice may be. If you're already containerized and just moving to a new container platform, this may not be as much of an issue as if you're a monolith on a VM looking to adopt microservices, BUT, regardless of the situation, keeping a close watch around the timeline constraint is essential to meeting targets and forecasts.
Choice isn't an issue the way it used to be. More and more of these options are maturing in a positive direction and container adoption has become somewhat of a necessity for new organizations or organizations modernizing through digital transformation.
Hopefully this guide will help you develop an better sense of the platform that will work best for your team!
💡 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!