Choosing A Container Platform

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:

1. Docker Wrappers
2. IaaS Services
3. Kubernetes Wrappers

Docker Wrappers

Pros:

• Low barrier to entry
• Easy to launch (trivial on a single server)

Cons:

• Less straightforward to scale
• Requires dedicated talent to manage/maintain

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.

IaaS Services

Pros:

• IaaS backed service
• Native level integrations with other services

Cons:

• Deep vendor lock
• More expensive as you scale

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.

Kubernetes Wrappers

Pros:

• Incredibly flexible and dynamic container orchestration
• Huge amount of open source support pushing forward

Cons:

• Minimum 500k a year to maintain
• Only 1 part of larger puzzle needed for complete solution

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.

Cycle

Pros:

• Standardization enforced by default
• Developer friendly
• Provider agnostic
• Remains simple (elegant), even at massive scale

Cons:

• Giving up a small amount of control for more efficiency
• Non-native providers require integration
• Not enough tickets come in for on call engineers

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.

Evaluating Your Position

When choosing a container platform the following items should be top of mind.

1. Technical debt
2. Team composition
3. Migration strategy
4. Completeness

Technical Debt

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:

• Networks
• Services (Load Balancers, Discovery)
• Infrastructure (updates/upgrades)
• Operating System (updates/upgrades)

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.

Team Composition

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:

• How many engineers do you have on your team and do any of them have DevOps experience?
• How long will it take to onboard your engineers to the new platform?
• How many team members will be able to administer changes on the new platform?
• How much time are we willing to invest in upkeep and maintenance?

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.

Migration Strategy

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:

1. Re-host or "Lift and Shift" is a quick, low-risk strategy of moving applications to a containerized environment with minimal changes, but may not fully leverage containerization benefits.
2. Re-platform or "Lift, Tinker, and Shift" involves making moderate adjustments to applications to adapt to container features, striking a balance between speed and leveraging container advantages.
3. Re-factor or "Application Modernization" demands re-architecting and re-coding applications to fully harness container benefits, though resource-intensive, it leads to better scalability, performance, and maintainability.

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?

Completeness

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.

• DNS Management
• Image Management
• Load Balancing / Ingress Controllers
• Telemetry
• Logging
• Observability

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.

Honorable Mention: Timeline

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.

What's Right for You?

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!