Wednesday, March 29

Microservices Architecture Part II

This is Part II of our series of blog posts targeting building applications using Microservices Architecture. This post will cover the benefits of Microservices architecture.

Decomposing your monolithic application into microservices has its benefits.

Development Agility & Speed

With Microservices a service can be architected, implemented, and deployed without affecting other microservices. The application can be modified in a continuous way as frequently as daily in some scenarios especially when used with Containers and a Devops culture. Since microservices represent a specific business functionality the changes are limited to a much smaller codebase. This makes it easy to add a new service to the application or retire the old implementation of a service without affecting the other services, thus enabling rapid development and innovation.

Also since each microservice is independently developed and maintained by an independent team and with the codebase that performs one business function only, it is far more easy for every member of the team to understand the code and make changes at a more faster pace. Any changes to the microservice can be tested independently and in much smaller time since it is decoupled from other services.


Right Language/Framework

While the recommendation engine service could be better written in Java the catalog service could be better suited in Python. Microservices Architecture supports this freedom to choose what is right for the microservice whether it's the language, framework or tool. One can have technology diversity within the application as each of the service teams can choose the best technology that is most appropriate for the service while interacting with the rest of the services through APIs.

Resilient And High Availability

Every now and then we encounter bugs that bring down our applications. With microservices architecture, these bugs only affect a single service and the rest of the applications still works normally. One need to design microservices for unavailability of other microservices within the application thus making them more resilient.

The smaller codebase also makes it easier to track down and fix bugs. For example, if an alert notification microservice goes down, the rest of the functionality still work normally and the impact is limited to users not being notified about events. Nowadays Microservices are used with containers. In this scenario, the container orchestration frameworks provides added resiliency by starting a new container when one container fails, thus restoring full redundancy.


Scalability and extensibility

In order to scale out the capacity of the application or to add new features, microservices can be added easily and seamlessly to an existing application. With microservices since you can scale only that particular service that is in demand gives you more flexibility in deployment. This allows to scale specific microservices independently and push things faster into production.

Cost Efficiency

Organization are always trying to bring down their development and hosting costs as they develop more complex applications. Microservices help control costs since each service can be scaled independently as required.

When a particular functionality for e.g. Orders is in demand, one need to scale up only the particular Orders microservice without scaling the other services. This saves on the infrastructure resources. In contrast a monolith application would need the entire application to be scaled up which would have far more resource requirements and hence higher cost as well.


Faster Time To Market

The speed at which new features are introduced by the businesses give them a crucial advantage. A monolithic application makes it very difficult to introduce any kind of change big or small in the application as it requires testing the entire application for any regressions thus resulting in longer release cycles.

With microservices, any kind of change to a service can be deployed in a short period of time as there is almost no chance of the change breaking the code outside the service. This makes the testing of the service very precise and limited to the service boundary and hence making the testing. Also since one only need to deploy the particular microservice and not a big monolith application makes the deployment faster.


Development collaboration

Each microservice is owned by an independent team that is responsible for the development, testing, deployment and support of the service. This break up into smaller services that have strong module boundaries and owned by independent teams enables the development of a large application through very loose collaboration of a large number of small teams.

Deployment & Rollback

Deployments and rollbacks are faster & simpler due to the independent speed of delivery by the different teams. At a time one needs to deploy just the one microservice that has changed making it easier to deploy. Also when coupled with containers and a container management framework like Kubernetes it become alot more easier.