Containers And Micro Services - Essential terminologies for CXOs

You heard the news - Embracing the world of Micro Services and Containers is essential to help you make your organisation's IT operations more agile, providing immediate operational benefits. Let us have a look at few essential concepts to help you start a conversation with your own internal IT, Developers and Vendors.

Micro services

Well, as Martin Fowler put it, "Micro-services - yet another new term on the crowded streets of software architecture”, is what everybody is talking about.

In simple terms, Micro service architecture enables packaging (mentally and physically) each unit of functionality into a service, and you can distribute and scale these services independently. In a traditional monolithic web or enterprise application, if you need to change a simple functionality, you have to rebuild and redeploy the whole application. In a Micro service architecture, you can individually deploy and scale services. 

Now, this has got multiple advantages. You can scale only the services you need to distribute the load effectively - i.e, if you see that your customers are using your Order service more than others, you can scale up only the Order service instances from 10 to 20. Though this is nothing new, the evolution of container technologies accelerated Micro service based systems, and enabled organizations to adopt a very agile, continuous delivery based workflow to build and deploy applications faster.

Containers

‘Container’ is probably the most abused term in this year after the term ‘locker room talk’. In it’s original sense as it is used today in Dev Ops, the term emerged from LXC (Linux Containers). LXC is an OS level virtualization method for running multiple isolated Linux systems (containers) on a control host using a single Linux kernel.

What is the difference between LXC and Virtual Machines? As you are aware, standard virtualization systems (like KVM, VirtualBox etc) lets you boot full operating systems of different kinds, even non-Linux systems. The main difference between this and Linux Containers is that virtual machine require a separate kernel instance to run on - i.e almost a full standalone OS.

How ever, multiple LXCs can be deployed on top of the same Kernel (Ah, Microsoft didn’t see that coming oops) - So, LXCs are much cheaper to create and destroy (from a memory and processor foot print perspective) compared to Virtual Machines. One Linux Container (LXC) can run a single process, and as long as you don’t give root permissions for the process you run, you can impart some level of security to the process your container is running. To be fancy - you can group containers to Pods, and run them in Nodes. (Side note - Microsoft recently announced Windows Containers - have a look)

Platforms like Docker provides an easy workflow for developers to package their application to a container ‘image’, to spin off instances of this container later in a very easy way.

Pods

In simple terms - containers that need to co-exist in the same Kernel/Virtual Machine/Node and related run time information is grouped together as a Pod. So, a Pod is essentially a group of containers that should co-exist. And typically an application running in one container can access another container via the ‘localhost’ as long as both the containers are in the same pod. Containers with in the same pod will also mostly share the same storage context - much like two applications running in a virtual machine.

Volumes

A Volume is an abstraction you can use for storage, and can be used by containers to read/write data. So, containers of the same Pod can use a ‘Volume’. From Kubrnetes perspective, Volumes are attached to Pods - so even if a container crashes, the files etc related to restart the container can be kept in the Volume. But when you remove/delete a Pod, normally you throw away the volume related to the Pod as well (in simple scenarios).

Nodes

You can consider a Node as a worker machine (either a Virtual Machine or a bare metal physical machine). Nodes can run Pods and multiple nodes are managed by one or more master nodes to form a cluster.

Clusters

A cluster is a large group of containers, some of them grouped into pods and some of them not. A cluster normally has one or more master nodes that manages the pods/containers deployed in the nodes - the master is responsible for ensuring the requested number of container instances are up and running all the time, and also providing API access to the containers in the cluster.

Cluster Federations

Typically, a cluster runs in a single on premise data center, or in a single availability zone in case of cloud providers - now what if these clusters can be tied to each other and federate them? This will enable interesting use cases like ability to overflow your work loads from one cluster to another. For example, an application can run in a private/one-premise cloud and burst into a public cloud when the demand of compute overflows a specific limit (typically mentioned as Cloud-Busting). The easiest way is to start with Kubernetes Cluster Federations

Why Micro services Pattern Love Containers?

As containers are easy to spin up and down, this became the favorite model of packaging and shipping your micro services. You can create a service, and package it to a container - and deploy them independently. Docker because so popular because of its ability to build, package and deploy applications/services using a light weight container. You can use a Docker image to spin off multiple container instances.

Kubernetes, Docker Swarm etc went one step further, allowing you to define and deploy containers at scale to form a whole cluster of pods with containers. For example, container orchestration engines like Kubernetes will let you specify the whole cluster configuration - including how many containers you need per service/application and how exactly they should talk to each other.

So, start from here and think how to be more agile - and re-architect your own enterprise to build and deliver business benefits faster, in an agile way, embracing containerization .

PB- This is a very evolving space, and there are lot of players and platforms in the market. Most of the time an apple to apple comparison is not possible between the tools and platforms. But if you are looking for going one step further,  have a look at the container platforms like OpenShift (https://www.openshift.com/), Cloud Foundry (https://www.cloudfoundry.org/) etc. Macro level platforms/orchestration tools like Fabric8 https://fabric8.io/ are also becoming mature - allowing you to spin off your entire dev-ops pipe line as a platform - and optimize and manage everything using a unified user experience.