Why adopting Microservices is key

Microservices architecture is a software architecture where an application is decomposed into a set of small, independent services that communicate between each other using lightweight communication protocols, such as HTTP. Each service has its own database. In this article, we will walk you through some of the benefits and drawbacks of adopting it. At the end of the article, we will share about our experience of adopting the so called architecture.

As mentioned before, microservices architecture consists of decomposing a big application into a small and concise set of services that communicate between each other using both synchronous and asynchronous communication technics to fullfil the business need behind the application.

A service is a standalone, independent component that takes responsibility on one functionality within the distributed system. A service could be the billing system if we are talking about an e-commerce application, or an authentication service. Each service does one thing, and it is good at it.

Well designed microservices architecture brings with it a lot of benefits, including;

Adopt Continuous Integration/Deployment (CI/CD) easily

CI/CD is a key practice in DevOps. DevOps culture is a set of practices that makes deploying and delivering software fast, frequent and reliable. CI/CD relies heavily on automated tests.

In microservices architecture, services are small compared to monolithic applications. This makes automated testing possible and affordable and prepares the ground for CI/CD.

Moreover, in DevOps culture, we deploy software frequently. This becomes easy with microservices architecture because services are independent and deployed independently from each other. If a developer has a change that impacts a service internally, he can deploy it without coordinating with other developers.

Maintainability is made easy

Each service in a microservices architecture is small and maintained by a small team (two pizzas team ). This makes it easy for a developer to understand and maintain the application, i.e. the service he is working on.

Modularity is reinforced

In a microservices architecture, inter-services communication is done most of the time using HTTP or gRPC and each service has its own code base. Thus, it is impossible for a service to access internal classes of another service. In monolithic applications, we can achieve modularity too. But, it would be a pain to maintain it.

Scale cost-efficiently

In monolithic applications, scaling means adding multiple instances of the whole application even if only a small set of feature that needs to.

The fact each service in microservices architecture is deployed independently from the others makes scaling very cost-efficient because we only need to scale services that needs to. Moreover, we can choose the appropriate hardware for each service depending on its resource requirements.

As Chris Richardson said in his book "Microservices Patterns", no technology is silver bullet. Adopting microservices has many drawbacks resulting from its distributed nature among others:

Synchronization between services

For example, many features served by an application could involve several services. Each new deployment requires coordination and synchronization between development teams responsible on these services.

Architecture complexity

Another issue could be complexity level of such architecture. Developers have to handle distributed systems, write fault-tolerant services, handle inter-communication (synchronous and asynchronous) between services and be resilient to unavailability of services. This requires for sure extra learning.

Withing our R&D teams, we have adopted microservices architecture on one of our applications used for financial products pricing. The results are very satisfying.

On one hand, we are able to scale our service in no time to handle more several millions of requests per day. On the other hand, we have full control over our production costs since we use an ephemeral infrastructure (pay-as-you-go) on Microsoft Azure. We use various features of the cloud provider to implement architecture, including:

• Azure Service Fabric ?for managing packaging and deployment of our services
• Azure Virtual Machine Scale Sets ?for managing and scaling up virtual machines of Azure Service Fabric cluster
• Azure Queue Storage ?to handle asynchronous messaging between our microservices.
• Azure Blob Storage ?to store requests content, processing information and results.

Note

This article written by Mohamed H. , R&D Software Factory Team Leader is mainly inspired by the book?Microservices patterns , by Chris Richardson . He strongly recommends the read if you are interested in getting deeper into the topic