Cloud-Native Paradigm - { Microservices / Docker-Container / Kubernetes }

Cloud-Native is the new paradigm which is fast catching traction, which it should, given the phenomenal rise of cloud adoption over the last few years. Today, enterprises are more comfortable with their mission-critical applications on cloud than ever before. Enterprises, almost all of them have their 1 eye on cloud and the other eye on their legacy architecture and infrastructure. They not convincing that cloud is the way to go, but its always a tiff between current customer priorities, Q-on-Q revenue targets, getting that budget for cloud migration and the challenging business climate, that puts some spanner in the work.

The vast majority of CIO's do understand all the benefits and value on moving to the cloud - lock, stock and barrel, at the same time retaining all the flexibility to fall back on a hybrid format of either a mixed cloud or part on-prem whatever is required to give that comfort feeling.

With the above as the base, let's set the context for why Cloud-Native has been garnering som much focus and attention. This will require to understand the triad of - Microservices, Containers and Container Services to be able to understand how the cogs are attached and how the architecture looks like for getting the desired results.

Again, what are we looking for from this paradigm move - we are looking for speed, agility, efficiency, no lock-in, easy of the move, ease of scale, customer and market-responsive. All great things to have and shoot for. So, let's get into the triad that makes it possible.

Microservices

Microservices is an easy giveaway. The name is coined beautifully to depict, how any feature, functionality - broadly called SERVICES, is given its own independence and is able to act as a service provider in its own small way. Hence the term - Microservices. This could be as small as a piece like - login, user authentication, logging, timer or whatever can be a small and discrete part in the entire large complex enterprise software bundle.

Now, why do this? What are the advantages? With microservices, now we can have small set of developers focus on all their piece of service and provide them full de-coupling w.r.t what language they want to use, what tools, platform, their schedule of publishing and release as far as they use the same HTTP/REST API to communicate between their other microservice peers. This allows for independent and parallel work streams with greater autonomy for teams to build what best suits them and only worry about that service and ensure they do it best. This will also ensure that these services can now potentially my moved anywhere either individually or as a group and can be scaled easily as well.

The diagram above also nicely shows how the microservice architecture looks like compared to the older legacy monolithic architecture, where there are User-Interface layer, Database layer and the entire business logic and everything else will be one huge blob. With microservices, each service will be its own mini code suite and have its own DB or share with other microservices, depending on logic.

Now, let's look at the second leg of the triad - Container.

Docker (Container)

The container is also a self-explanatory term, meaning it Contains. In this context, it contains any application piece or service that's put into it. The most popular container software is DOCKER, which is widely popular and used. Now DOCKER is similar yet different from Virtualization or VM's as depicted by the diagram below. In VM its a full package which is abstracted from the Hardware including the operating system meaning you could have a Linux box, load it up with Hypervisor and then build a full application exe along with Windows OS. In essence, we have simulated a Windows computer on a native Linux Hardware. You could multiple of such things on the same hardware. But with Container it allows for bundling the apps and the libraries as one set and allowing for multiple such containers with a node or a machine. It does not touch or needs to chase the native or Host Operation System. Now, with this what we have done is made the native environment redundant or Don't-Care, thus allowing to create a paradigm where you can easily move the container blobs from anyplace to anywhere, any on-prem hardware to any cloud or a hybrid of those, it simply does not matter. Each of the containers provides a cocoon for the functionality, or microservices to do its job and run without needing to know or bother about the underlying resources - who's providing it, where is it coming up & the best part is, it can ask for any amount of resource either to upscale or downscale at will, depending on the usage pattern.

Now let's move to the final leg of the triad, the orchestrater or Container Service also called Container Orchestration Service

Kubernetes ( Container Orchestration Service)

Container Orchestration is actually the key to ensuring the advantages of the container (Docker) comes to the fore. After all, having the nice stuff of container is not much use, unless we have an administrative and scheduling logic/ layer that will allow administrators to run these microservices, scale them, tear them down and also add complex business logic of when this should be done. There could be various business triggers of when certain service/ containers need to be highly available (e.g morning time is when you would expect lot of user login functionality, so there has to be lot more instance of this service or container suite only for that time range and then scale it down to lesser number of instances per the traffic).

Kubernetes is the most popular container scheduling and orchestration tool that's in vogue, given the flexibility and ease that it provides, which includes a dashboard based visual UI to administer nodes. Kubernetes works in a cluster form at its highest level and employs a master-slave mechanism, each the master and slave running on nodes (or computers). Each node, in turn, runs one or more containers (which in turn has application or services internally). The master node, manages and controls all the node elements and drives everything from start/stop of container services to manage them seamlessly. The administrator can now schedule and deploy containers through this framework, thus having fine-grain control or which services to scale-up and which to scale-down, either manually or auto trigger-based of predefined logic.

Hope this gives a high-level view of how the software architecture is moving from tightly coupled, single place, on-prem, one big chunk to a leaner, meaner, efficient and highly mobile and scalable architecture using - Microservices, Docker (Container) & Kubernetes ( Container Services).