By - admin

In search of Cluster Compute Clarity – Part-2

In part-1 AI in micro services we discussed at a high-level the various components of development and integration, with a real-world example of optimizing customer care dynamics with predictability. I also pointed out the need for a blue-print on separation of Concerns in a hybrid cloud multi-vendor enterprise environment and the need for a common collaborative platform based on Infrastructure as Code from the very beginning of micro services design. It is in this context we will discuss in detail Container Orchestration of Micro services design pattern and components as below.

1.    API design 2. Deployment 3. Service Discovery & State 4. Consumers 5. Command center ops (Monitor, document and facilitate Collaborate)

Building and operating containerized software is a vertical ascent for most enterprises on path of digital transformation, so is the reason why there are sprout of tools and technologies in the market to choose from. One advantage is there are many choices and one need not have to live with a single tool or tool chest to orchestrate, and one don’t ave to move or throw away all the investment made as par tof CI/CD and dev-ops architectures. In the world of micro services at scale Dev-ops evolved as more dynamic templates or blueprints of IaC infrastructure as Code:

The concept of infrastructure as code gained importance in the ever-growing cluster compute in enterprises. IaC is not a new concept and has its roots deep into Configuration Management {Codifying server, Storage, networking etcc} 

Conceptualizing IaC when designing micro services is a an important first step, though it breathes in as tail-wind in the composite architecture at the time of deployment. If we all believe in Zen of Code ( from the philosophy of Zen of python )

ü Code is Version controlled.ü Code is a medium of collaboration ü Code is not completed without documentation, and documentation doubles as code increases.ü Code is reproducible.Which emphasizes the need to think every part of any architecture pattern as Code.  

In this part-2 of the series our focus is container orchestration which is built on the foundations of Infrastructure as Code from leading cloud providers. But before that let us first ask a simple question why Containerization of micro services?

  1. Ideal for packaging micro services
  2. Provides isolation
  3. Micro services are Light weight, so dedicated VM can be expensive.
  4. Cost optimization: one VM for each micro service vs Container

Cloud providers such as Microsoft provides container hosting service through Azure Container service based on Apache mesos, AWS through Elastic Container Service over Elastic Cloud Compute (EC2) along with proprietary orchestration service, Google through Google Kubernetes Engine. However, the unicorn in the orchestration market is Kubernetes which can be deployed on all cloud platforms, through its cloud provisioning interface which makes it a defacto standard for hybrid cloud environments.

Well there are a ton of L-100 to L-300 courses and material on the internet mainly focusing how-to-do, but there is a clear lack of clarity of thought on orchestration. My idea is to clear the abstraction and pave way for innovation in digital transformations.

The space is wide open with choices – Azure Container service, Docker Swarm, Mesos, Pivotal Cloud foundry, like I said one can easily live with multiple tech tools in the world of containerization. However, orchestrating these containers is the key to successful deployment of micro services.

We will focus mainly on Kubernetes as this is now the defacto standard for hybrid cloud environments, with tons of code. The main focus of Kubernetes is container orchestration and scheduling, these containers are workloads executing specific business tasks running on physical or Virtual wares. Kubernetes is

 HipoH {Input to Hardware Orchestrate process to Hardware output} Kubernetes can run on Bare metal or virtual machines or both.


Kubernetes is a portable, extensible, open-source for managing containerized workloads and services by facilitating both declarative configuration and automation

.Kubernetes itself follows a cluster architecture consists of “etcd cluster, kuber api server, kube-controller-manager, cloud-controller-manager, scheduler. The client or worker nodes composed of kube-proxy and kubelet component.


Take a closer look at the figure below for a bit of history around the orchestration evolution  

Advantages of Kubernetes for microservices ( )

  • Service discovery through DNS or IP adress and automatic load balancing
  • Storage orchestration local storage or cloud provisioned.
  • Automated rollouts and rollbacks : Automated way to create update and migrate all the container resources to new containers
  • Automatic bin packing
  • Self-healing
  • Secret and configuration management

Leave a Reply

Your email address will not be published.