Common Problems with Container Platforms

Containers are nearly ubiquitous in software these days. Outside of abstractions like fully managed services (RDS, Dynamo, Cloud SQL), everything engineering teams are responsible for, mostly, land in containers.

For many, deciding what platform to run those containers on is a burning question.

Choosing the wrong container management solution can be a real headache. Two popular options – Kubernetes and IaaS services (ex: Fargate or ECS) made big promises early on, but have come up short for many.

The innovative Cycle platform continues to gain market share against these two, and for good reason.

Lets check out some common issues with k8s and IaaS managed container services, then talk more about Cycles approach and where we've been able to make the biggest impact.

Kubernetes

Released by Google in 2015, this project was ultra popular from 2018 - 2022. With techs major shift from "exponential growth at all costs" to profitability as the true north, Kubernetes has lost a huge amount of steam.

Costs and Maintenance

A basic Kubernetes deployment needs at least 2 full time DevOps engineers to maintain, and those engineers carry a high salary of 130k. Given that, getting started on k8s would bring with it a total cost to the organization of $386,490 when factoring the cost to pay the employee for the employer and a small management fee, as someone has to manage all this.

So, back when it was easy to raise 40 million dollars as a pre revenue startup, it was all the rage because… who cares, money is free. But as things continue to kareem back to sanity, more organizations than ever are taking a second look at the total cost of ownership.

Upgrades and Complexity

In 2020 there was a report by DataDog showing that the average Kuberenetes cluster was 17 months behind… Nowadays, a lot of companies choose not to even upgrade their existing clusters but to just “roll new ones” using some flavor of IaaS K8s, locking them in at the vendor level. The number of clusters also seems to be growing exponentially, as many teams are talking about managing hundreds, or even thousands of clusters.

This path can lead to deep networking or other issues. Trying to make all these clusters play nicely together is a bit like rocket science, but without the fun (although explosions will still occur). And yes, all this can be thwarted with enough team members with exceptional experience and skills, but I invite you to re-read the cost per engineer and extrapolate that out into what revenue numbers your team would need to be hitting in order to make the whole thing work.

IaaS Solutions

AWS, GCP, and Azure all have container solutions that are, what we can call “reasonable” to deal with. There's not a huge barrier to entry and these services are FAR easier to deal with than Kubernetes, BUT, there are still some major issues to watch out for.

Vendor Lock

I think the first thing that comes to most people's minds is vendor lock, which might not be as much of a problem for a startup as an existing business. Recently, a Cycle user shared a story from their experience from a time they were using ECS:

“When we went to move into Euro and Asian markets there were some compliance standards that required we put all of our services in data centers in specific countries. With our current provider (AWS) we couldn't do that (the way we wanted to) but because we were using ECS we had no choice but to hobble together a solution”

Scaling without Specialist

While it's not as difficult as Kubernetes, there's no question that architecting a successful, scalable solution on IaaS platforms is still a challenge. Networking, auto-scaling, integrations, high-availability, load balancing… just about every piece of the puzzle is there for you BUT very tightly wound to provider specific knowledge.

So just like Kubernetes, it's likely that you'll need to hire some type of cloud engineer, consultant, or specialist just to get up and running. There are plenty of good reasons to go this route, and I'm not pretending like these services don't have a place… but I do want to highlight the fact that almost no one stays with these services throughout the lifespan of their product. It's a very similar story to what you might hear from someone that's outgrown Heroku, Rendr, or any of the other “good places to start”, it just isn't a good fit for their long term vision.

The Cycle Difference

Cycle isn't a silver bullet for every ailment of a cloud native world. There are plenty of products that need unlimited host level control, others that have a small team that already has decades of IaaS vendor specific experience, and just some people that want to roll their own solution from scratch.

But for those that are looking for a platform that can take them into the upper stratosphere of moderninity, while still keeping a lean, agile, and foremost profit centric approach to building their products… we've created a platform that optimizes for the following things.

Simplicity

If I said simplicity is a complex word, that should make you giggle a bit. But in reality, the idea that something is simple is often misconstrued with the idea that it's basic. Instead, I offer you an invitation to consider simplicity elegant.

With Cycle, simplicity means that things that can be standardized are standardized. Things that can be automated are automated. Your engineers won't need to be specialists to understand the core concepts of managing the platform, however, there will always be room to grow and improve on what you've already got in place.

For example:
On Cycle, an engineer creates an environment, and with that environment a new network is created along with the appropriate services (load balancer, discovery, and VPN). Adding infrastructure to that environment is alway an automatic process, there's never engineering intervention that needs to be done. The same is true about the clean up (if that server is removed from a cluster, etc). The network itself always has the same shape and assignments to containers and instances are always made in the exact same way.

An engineer, working in one Cycle environment has a good idea of the networking primitives used in every other Cycle environment that's ever been, or ever will be created and can reason about those other environments as if they were the same as the one they are working on.

That is simplicity, and at Cycle it's multi-cloud native.

Scalability

Recently I wrote an article about scaling engineering teams and the impact that onboarding new engineers can have in an organization.

When you have an elegantly simple platform, scaling can become much more reasonable in all aspects of technical products (infrastructure, services, employees, etc). Instead of facing the need to hire specialists, Cycle users are able to focus more on bringing in software engineers and getting them up to speed on Cycle generally takes only days.

Flexibility

Being multi-cloud native means being able to use the compute options and IaaS platform that's right for your organization at any stage of its journey.

AWS, GCP, Vultr, colo, on-prem, hybrid, multi… who knows what will be the best architecture for your infrastructure in the future. With Cycle, you're not completely avoiding vendor lock (as it will eventually take some amount of integration with our platform to use it), but you're also leaving the most amount of choice on the table as it comes to architecture choices, without causing a complete rewrite of the application deployments.

LowOps

We use the term LowOps to describe our take on what's necessary to be successful on the platform. This means, while you'll still be responsible for some of the operations decisions, the platform itself takes care of MOST things for you.

For example:

If you're starting a project from scratch there may be 100 or 1000 questions to answer during the architecture phase. Cycle users start at question 80 or 800 (80% of the way there). These choices represent the “opinionated” part of our opinionated platform and provide standardization at the platform level, which makes it incredibly easy to reason about, debug, maintain, and programmatically integrate with.

Theres No One Size Fits All

There is no one size fits all solution for every one of your engineering woes. However, I can say that Cycle is a rock solid choice for any project that aligns with these ideals and wants a tested, stable platform that's getting big new features monthly.

💡 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!