Focus on the Right Thing about Containers: What the Workloads Perform, not How They Do It

cloud_security.jpg

Much attention has been placed on modern applications and containers, and perhaps to excess. People wrote and worried about the choice of container orchestration systems—whether it’s Kubernetes, Marathon, or Swarm.

Also silly are comparisons of containers as a replacement for virtual machines, or whether serverless systems, such as AWS Lambda, are the new replacement for containers. Much of that was due to misconceptions, a desire to see a horse race where none exists, or a side effect of in-fighting in the open source community, with sponsoring organizations or vendors in the sidelines.

What people really need to think about is how the new generation of applications is architected. They tend to be composed of micro-services and related programmatic and design patterns that enable modern workloads to fit into a new generation of infrastructure designed to support them. It needs to scale, be resilient, and work with modern development tools and infrastructure.

 

The key thing is that we need to understand what the workloads are, and not how they are constructed or implemented. Containers are part of the “how,” and less related to the “what.” We need to focus on the “what.”

 

Containers are a popular piece of the puzzle, but there are other factors such as designing for data access (whether it’s big data or fast data), or architecting the right network model to securely connect the containers, servers, or pods together—where you have popular interfaces such as CNI (Container Network Interface) with plug-ins, such as WeaveWorks.

 

Unlike a traditional, legacy architecture where one relied on a monolithic operating system that ran an instance of some application or service (such as a database), and the key interface for the application was the traditional OS API (such as Microsoft Win32/64, or Linux system calls and libraries) or a set of interfaces to access application services (such as Oracle RDBMS), we now have a plethora of services to architect our solutions from—which range from the traditional ones to modern ones such as Apache Spark, Cassandra, or NATS.

 

Once you have selected some services to underpin your applications, you also need to deploy them atop some underlying platform, which is the role traditional operating systems have held. That selection is important since it constrains which services you can run and whether they do so efficiency and reliably.

 

Those platforms are run at the low level, whether it’s Apache Mesos (commercialized as Mesosphere DC/OS), Apcera Platform, Cloud Foundry (commercialized by Pivotal), CoreOS Tectonic and Linux, various flavors of OpenStack, or Red Hat OpenShift. On the public cloud, you have AWS, Google Cloud and Microsoft Azure, which are platforms in their own right that will host apps natively, and can also host some of the platforms listed above. These systems act as a host (or OS, in old terminology) for the services that run within and support the apps.

 

The old notion of a highly curated platform-as-a-service (PaaS) is effectively dead because developers demand choices and the world is changing too rapidly to choose a narrow path. Some enterprises may choose a narrow "tool chain" and that's fine as long as they are willing to accept the limitations and lack of choice. Perhaps there are support or training issues that prevent a free for all, which will be an area of concern for some organizations.

 

The analogy would be the five-year plans of the old planned economies. The current world is too dynamic to go down such a narrow path.

 

Whenever someone starts to scream about some in-fighting between application or platform factions, step back and ask what they are really trying to accomplish. What matters are the workloads and services you need to run, and less how they are going to be deployed. Sometimes you choose one method and for other apps, you need another. You can't ignore some details such as what type of container orchestration you choose, but that alone cannot be the end-all. If you choose one orchestartor such as Kubernetes, that's fine, but that cannot be the sole design criteria, since so many pieces are required to work in concert to support the services and workloads.

 

Therefore, you need choice. The choices are not mutually exclusive. Containers can run within virtual machines, thus containers do not displace virtual machines. In the future, we will continue to see a variety of technologies run alongside each other, and the keeping the bigger picture of running appropriate platforms and services should be our focus rather than nit-picking on the details as an either/or decision.

 

 

 

 

campus network

Topics: Cloud Computing Networking containers