/ docker

Creating Cloud Agnostic Container Workloads

The Cloud race continues down the path of least resistance. Least resistance you may ask. Yes, with every day the three major Cloud providers Amazon AWS, Microsoft Azure and Google GCP make it easier to move workloads from your data center to the Cloud. However, without proper research and preparation, your migration could land you right back where you started, in vendor lock-in jail.

The Cloud Native Computing Foundation (CNCF) is responsible for managing projects such as Kubernetes, Prometheus and ContainerD just to name a few of the growing list of Open Source projects that they manage. However, CNCF doesn't stop with just being the Open Source projects steward. They are also forming a community which is developing common technical standards defining Cloud Native Architecture and Applications to ensure we protect ourselves from vendor lockin-in jail.

Cloud Native Mission Statement

OK, so how do containers play a role in Container Native Applications and Architecture? I'm glad you asked. Let's take a look at Mission Statement of the CNCF to get a better understanding:

Cloud native systems will have the following properties:
(a) Container packaged. Running applications and processes in software containers as an isolated unit of application deployment, and as a mechanism to achieve high levels of resource isolation. Improves overall developer experience, fosters code and component reuse and simplify operations for Cloud Native applications.
(b) Dynamically managed. Actively scheduled and actively managed by a central orchestrating process. Radically improve machine efficiency and resource utilization while reducing the cost associated with maintenance and operations.
(c) Micro-services oriented. Loosely coupled with dependencies explicitly described (e.g. through service endpoints). Significantly increase the overall agility and maintainability of applications. The foundation will shape the evolution of the technology to advance the state of the art for application management, and to make the technology ubiquitous and easily available through reliable interfaces.

Containers are the key component to Cloud Native. Packaging applications into containers provide versatility, seamless migrations between Clouds and more importantly portability. More portability permits more flexibility and moves further away from the vendor lock-in jail which we are desperately trying to avoid.

Let's cover the next property in the CNCF missions statement, Dynamically Managed. In other words, the containers require an Orchestrator such as Docker Swarm or Kubernetes to manage, schedule and provision containers across multiple hosts. Orchestrators allow us to create an environment that is easily reproducible across multiple cloud providers.

Finally, Cloud Native Applications should be Micro-Service oriented. Since our applications are container based the next logical step is to break apart monolithic applications into microservice architectures. Micro-services gives us even greater flexibility and less dependence on the underlying infrastructure thus moving us further in the direction of Cloud Native.

Why Container Portability is Important?

Recently, Cloudify released the results of a recent survey about the state of Enterprises using multiple clouds.. What is interesting about the results is that 49% of the 600+ respondents utilize a single cloud while 51% have two or more clouds. In the recent Enterprise projects that I worked on the trend of Multi-Cloud is becoming more than just a buzzword and is forming into a reoccurring requirement for new projects.
How Many Clouds
Ensuring that our applications/architectures adhere to the CNCF mission statement Containerized Applications, Dynamically Orchestrated and Micro-Service gives us portability. With portable container workloads, we can quickly move our workload to other Cloud providers to take advantage of price reductions, increased capacity, new features, or disaster recovery.

Portable = Flexibile

What is common between Clouds?

As more companies transition to Cloud, it will increase the need for the CNCF standards to be adopted. Since each Cloud provider uniquely exposes services, it is important to draw a line in the infrastructure indicating where we can differentiate Cloud provider-specific services versus standard services across all providers. The graphic below displays where the divide could be between the Cloud provider specific components and cloud application shared components.

Cloud_Application_Architecture

Conclusion

It has become overwhelmingly clear that conforming to the CNCF standards will not only increase flexibility and portability but also gives us a way forward to adopting Multi-Cloud in a proper way. At the time of this writing Amazon AWS and Oracle have just become members of the CNCF. This shows both that the industry understands the need as well businesses and users like you and me are driving the standards.