The microservice architecture is one of the most recent approaches to developing enterprise software applications. The concept of this style of software architecture has been discussed since 2011, and it has been establishing itself quickly. However, there have been many doubts about what microservice is; when, how and where to use it.
The following is the concept of microservice architecture by Martin Fowler and James Lewis:
“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
— James Lewis and Martin Fowler
That is, simple services are created which offer the desired functionality when combined instead of developing an application as a large monolith.
Why use this approach that seems to be much more complex than the traditional application development model, whose functionalities are available in a single component?
Why microservices?
There are three main motivations for using the microservice approach when building applications, and two of them are related to cloud computing.
Firstly, cloud computing favors the scalability of applications by implementing the concept of dynamic elasticity, and microservices allow an optimal adjustment of the variation of computational resources to suit the demand fluctuation.
The ease of allocation and release of computing resources offered by cloud computing (such as virtual machines and containers) allows applications to adjust to demand. In this manner, when there is a peak usage (of a website or a mobile application, for example), all you need is to allocate more resources and trigger new instances of the application, then release those resources when usage decreases.
In the case of applications built as monoliths, triggering new instances requires the entire application (and the entire code referring to its various functionalities) to be replicated. However, it is more common that only certain functionalities of the application have peak demand. For example, in a checking account application, the balance inquiry function is much more used than the request for detailed bank statements of the last six months.
When the application is built by combining microservices and each microservice is responsible for a specific set of functionalities, only the microservices related to the most used functionalities need to be replicated.
Thus, the microservice approach for building applications saves computational resources – and reduces costs – by allowing a more precise adjustment between the demand curve and the use of these resources.
The second motivation for using microservices relates to the current requirement of digital businesses to constantly improve their systems. Last-minute functionality changes, promotions, A/B testing, error correction… Given that cloud computing along with the automation of the build and deploy process streamlines the process of making new versions of systems available in a production environment, it is frustrating to recompile and perform exhaustive tests on very large systems, which greatly slows down the production process of a new version of an application, especially if only a small part of that application has been changed. Microservices allow you to break down the issue and update only the changed functionality without having to work on the rest of the application.
In addition, it is difficult to maintain the structure of the application over time, especially with regard to its modularity. In this way, the maintenance of large applications has become more complex, and frequently corrections of a certain part impair other functionalities, therefore minimal changes demand more and more time.
The third motivation for adopting microservices relates to the error tolerance of a distributed model. In a single system, the error of a certain functionality generally makes the application unavailable as a whole. In the microservice model, the error of a certain functionality does not mean that other available functionalities are stopped, which minimizes the impact of such error.
Microservices have very specific fundamental properties, in addition to characteristic architectural concepts that allow you to extract the best results from this software development approach.
Related Articles:
Microservices Architecture – Understanding all the moving parts
Subscribe now!
All news in your inbox
