Microservices

Before we plunge into Microservices, do remember that this is one of the most popular trends for deploying applications in today’s Modern world where everyone is engaged in a race of Digitization or Digital revolution as we call it, and every new application is built using this approach so without any further ado lets dive into Microservices.

The good cannot be understood if we don’t know what is bad, similarly Microservices cannot be understood if you don’t understand Monolith. The Difference is pretty simple, in a Monolith application all the services/modules are built in a Single Package or Build (a single file) and in Microservices all the services modules have their own package /builds (multiple files) which can be managed/updated/scaled/troubleshooted without disturbing the other services in the application.

To further explain let's take an example, In our previous sections we learnt how applications are developed and built by typing code using a programming language and creating a package / build out of it and then deploying or running that package on an Application-server, this package starts with an initial version of V1 then when you want to add more features or functionality you again change the code and then redeploy package in the application server, now just imagine that this application is a Web application, which has many modules or independent services, refer the diagram depicted which shows a Microsoft website and imagine each of the tabs/buttons are hosting some module and this entire web application along with all the modules are a part of a single Build or package, this kind of an application is called a Monolith application which has all the Modules built in a single package with tight coupling amongst them and if you even want to make a change in a single module you have to change the entire build and redeploy impacting all the other modules / services

So instead of having all these modules coded into a single Build we can develop individual packages for every service and host it in a loosely coupled format where the integration between these services can happen over API connections and if there is a change planned in any of the services that can be independently done on that particular service only; without impacting or down-timing other services, this kind of approach is called Microservices.

So basically, Microservices is an approach to software development in which a large application is built as a suite of modular services which communicate over standard protocols and well-defined interfaces, instead of developing one monolith application hosting multiple services in a single package "build", these multiple services are built as separate builds and can be independently managed, developed, upgraded and maintained without impacting/disturbing the other services.

So, how are these microservices deployed?, During the initial days of the advent of microservices the systems were designed using a traditional method of using different VMs for different modules, these modules would support the OS and the application platform for that particular module and can be managed, deployed, redeployed without affecting the other modules which are running on different VMs and the interconnectivity between these VMs would be by using standard API connections; of course this design was not so efficient as we were using a lot of hardware resources for services which didn’t require that much of dedicated VM resources plus every Service had to be managed and monitored separately, not to mention about the (scale in scale out” which was again a hassle

So, what is the best solution or technology to build a microservices design, the answer is Containers, so instead of using the inefficient traditional approach of deploying the individual services on VMs we would be deploying it on something called as Containers. In the subsequent sections i have written more about containers and their platforms

Some advantages of Microservices:

· Coding for the individual modules can be done without disturbing other modules resulting in amazingly fast software development.

· Developers can focus on single service/module resulting in efficient Software development.

· No need to have the same technology stack for all the services it can be different, for e.g., one can run on Java, another on Python.

· Scaling can be done for the exact microservices where there is an expected surge.

· Microservices images are portable and can be moved around without any issues.