Over a million developers have joined DZone.

The Myth of a ''Best Container Platform''

DZone's Guide to

The Myth of a ''Best Container Platform''

Like mots development, it's not about looking for the best tool, but rather finding which tool work best for you. See how to pick the container that will serve you best.

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

Most games, whether played on a board or on the field, are what’s known as zero-sum games: one winner, one loser. Fortunately, that’s not always the case in the real world. It’s certainly not the case in the container platform ecosystem.

Container platforms can be as different as “Candyland” and “Risk” are — and that’s a good thing. Think about any other technology sector out there — there are always multiple solutions in every space. The same goes for container technology. When you create something that is super scalable, the drawback is that it’s not going to be a one-size-fits-all approach. However, one person’s drawback is another person’s advantage.

Decisions, Decisions

If you want a fun, colorful game that relies on chance and is suitable for young children, you don’t get out the Risk board. In the same vein, you don’t set down lollipop tokens in front of a group of experienced adult gamers. In each of these scenarios, you choose what’s appropriate at that time. The same logic applies to container platforms.

The first step in the decision process is figuring out whether you want to build something from scratch, to make it as truly customizable as possible, or whether you’d prefer to use an existing solution and custom-fit it to your needs. Neither is the better choice — it’s a matter of different choices.

It can be dizzying to wade through all these different container platform offerings if you don’t know the right criteria to drill down into. Fortunately, there are a few basic questions that will help you in the decision-making process.

Off-the-Shelf or DIY?

As a developer, it’s important to consider what’s best for the project or business. For instance, if your stack consists of several web services and common databases, you don’t necessarily want a system that will require lots of integration and tuning work. In this case, an easy-to-use solution might be the best option, as opposed to something that requires more hands-on management.

The reason container platform vendors exist is that it’s extremely time-consuming and difficult to create a container platform of any kind. At first, it might seem you’ll find all the bits and pieces from various open source projects, but making this complex stack of technologies work nicely together while making it maintainable as a platform is very difficult.

Important Questions

As the developer, you must ask yourself the seemingly obvious but foundationally important question: what do I want to do with this platform? Many people find themselves unsure about what can actually be achieved with a container platform, which makes this an integral criterion to consider.

Will you use the platform to run your web services? Is it primarily for running your Big Data databases? What is the scale you need today? It’s important to understand that there are platforms for different needs; the platform geared toward Big Data is not necessarily a good choice to run your web services. The platform designed to serve Google-scale deployment might add unnecessary complexity and difficulty if your scale is not at Google scale.

Container platforms differ in the features and functionality they offer, addressing different kinds of developer needs. Pinpointing the use case for which you need a container platform makes navigating the options much simpler.

Right-Sizing Your Containers

Is your Risk tournament for five people, or 5,000? If your company is running some of the biggest workloads in the world, the needs will be different than those of a smaller company. According to a recent study, 66 percent of setups require fewer than 50 nodes. At the same time, many of the most popular container platforms out there are designed for setups with hundreds, even thousands, of nodes. Using one of these for a smaller scale can be overkill; choosing to scale will ultimately make your life much easier in the long run.  A mismatch between size and business needs makes training and installation far more time-consuming. Likewise, spending less time on needlessly consuming training and installation gives developers more energy and time to actually build on their existing skills without getting bogged down in the muck.  

Additional Factors

Other factors will come into play regarding your choice of container platform. You need to consider what operating system you’re using, what type of cloud infrastructure you are using and what tools you will need to be able to integrate with. From there, you can do your research and determine the best fit.

One of the great things about containers is that you don’t need to stick with a platform that does not suit your needs because containers are ultra-portable across any underlying execution environment. You can always switch to some other platform since the most difficult part is already done: your software is packaged and deployed as containers.

Just as there are many board games to choose from, there are many container platforms to consider. Rather than becoming overwhelmed and developing a severe case of decision fatigue, though, focus on the core considerations. Will you build or buy your solution? How many nodes do you need? What other tools and infrastructure come into play? Answering these questions will help you find the container platform that makes sense for your company.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.

containers ,developers ,platform ,container deployment ,container orchestration

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}