Microservices have been around for some time now but have recently once again gained a lot of momentum in becoming the preferred way software products and applications are being built. A lot of the recent surge in its trend has to do with the rise of serverless computing which makes infrastructure management a thing of the past and allows software engineers to focus on building the core functionality of the product. Since serverless infrastructure and architectures are microservices-based by default, it has helped fuel the fire. This is all a good thing, as microservices have proven to be the superior way to build scalable & maintainable applications. Let’s understand why that is the case by diving into some of their features.
We touched on it briefly in the introduction, but it is worth taking a closer look as to why it is easier to build and maintain large applications by adopting a microservices-based approach.
Each feature of the application and the functions within that feature are written in isolation from one another. Their fixed scope makes it easier to spec, write and test the code without having to rely on the rest of the application’s state. They are also easier to host and maintain as microservices can run inside their own containers which comprise of all the required libraries, runtimes and dependencies that the service needs. It is an all-encompassing container which can run the services within it without any needing any further intervention or knowledge from entities outside it. This also helps reduce risk as if the container goes down, only that microservice (or services) hosting within the container will be offline, allowing the rest of the product to continue without it (if it is not a critical component).
Since these microservices are hosted within several containers, it allows the infrastructure to scale a lot better as well. Different areas of the application will have different workloads based on their scope and business logic.
Smart orchestration layers can be implemented that allow spinning up new instances of containers that are experiencing heavy workloads, allowing the application to serve more users by only adding resources to the area of the infrastructure that requires it and not the entire stack (as would be the case in a monolithic application).
Another massive advantage of using a microservices based approach is that the services can be written in different languages and have their own unique stacks. This would not be possible in the case of a monolith as it would need to be consistent across the board. This enables engineers to build services using the best tool for the job, for example, a microservice that is focused on executing machine learning or data science tasks might be written in Python, whereas the rest of the services may be REST APIs written in C# using the ASP.NET Core framework. This is entirely possible (and a common use-case) with a microservices based approach. The different services would simply have their own unique containers which would comprise of the runtime and libraries needed to execute their code.
