With the growth of the code base and extending the functionality of software projects, there comes a necessity to manage the complexity of an application. A well-thought structure and correct division of an application into modules can help to solve the given task. One of variants is to build monolithic application architecture where all or the most part of business tasks have one code base.
An alternative is to create an application based on micro services where the general business task is split into separate parts, each of which has its own independent application (microservice) with its code base. Among the companies that use microservices in their applications are Amazon, Netflix and The Guardian. Below we will tell you about the pros and cons of such architecture compared to a monolithic application.
What are microservices?
These are small modules divided on the principle of performing a single business task or single class of tasks. The main purpose of such division is the possibility to change a particular microservice without affecting any of the components connected to it. The business logic of the application is split up into separate parts and each of them is a small application with a single responsibility. The number of such applications is unlimited and they communicate with each other by using API based, for example, on HTTP.
What are the benefits of using microservices?
1. We get rid of high code coupling by splitting the app into microservices.
If one of the microservices fails it is quite possible that the most part of the application will still be workable and this partial system crash won't result in serious consequences for users. Restoring the operability of one microservice takes much less time than restoring and locating errors in a monolithic application.
2. Easy scaling.
It can be done by locating services on different servers. If an application spans several microservices with moderate computational requirements, they can reside on one host. For more demanding microservices, it is better to opt for a more powerful host. Microservices which perform non-blocking tasks can be paralleled.
3. Different services can be developed by separate development teams.
It is especially interesting for remote development of an application, when various microservices are developed by different teams.
4. Each microservice can use any technology which is applicable within the scope of the given task.
For example, in web applications developers can use Ruby (Sinatra) for some microservices and node.js for others because they are isolated from each other and the technology used for their implementation won't affect the behavior of the application on the whole.
The difficulties of using microservices architecture.
1. It is more difficult to implement the general behavior for all the microservices (authorization of requests, aggregation of data from different microservices).
Technically, it is harder to handle the authorization or use a specific model that requires to aggregate data from different microservices. If the system uses objects built by collecting various data from a number of applications, it makes sense to think about changing the architecture. Otherwise, it may result in a large number of non-optimal calls to different services.
2. Microservices can add some extra side effects when processing user requests.
It's worth to note that when there is a sequence of synchronous requests from one microservice to others, the standby time for the user increases greatly. The solution to this problem lies in using asynchronous requests for calls to other microservices or in limiting the number of synchronous requests from a microservice per one user request.
3. Keep in mind, that any of the microservices can be unavailable at any moment.
Such situation should be processed correctly, so that it will not cause a crash of the entire system. A well-designed system allows to disable any of the services without halting the whole operation of the system. One more benefit of this approach - when you add new temporary functions, you can easily delete them when the time comes.
- Martin Fowler: Microservices.
- Sam Newman. Building Microservices. Designing Fine-Grained Systems. O'Reilly Media, 2015.