Microservices architecture — what is it and why we use it (part 1)
You’ve probably heard something about that term, right? Monolithic architecture is a well-known standard but there are also some alternatives. There is no perfect choice, everything depends on the use case because every architecture has some advantages and also some disadvantages.
What’s the difference compared to monolithic architecture?
Microservices architecture in a comparison with typical monolithic architecture consists of collection of services where each service has particular business capability. We can imagine this microservice as a small application that handles only specific subset of functionalities of the whole information system. For instance, one microservice handles user management such as registration, login, password recovery and profile editing but another one handles product catalogue, categorization of products and everything else around them.
Our motivation
We repetitively saw common functionalities in projects we develop but programming them again and again wasn’t effective. With a rising demand for complex information systems we needed to bring more reusability into the development process. Basic development approach wasn’t satisfying our needs anymore because it leaded to doing the same work more than once. Approach with reused and shared parts called microservices would bring more effectivity to our development process and would make our solutions ready to meet customers’ requirements.
What benefits do we see?
Reusability of microservices means that we need to develop them generic and configurable. Just by modifying their configuration, they need to be ready for various use cases without changing the code. Good example is the registration and activation process of user account in “user module” that can be instant in one project but based on email with activation link in another. In complex information systems some parts have to deal with higher load than others. It isn’t a problem anymore since we can allocate more resources for the specific microservice. When it comes to the processing large amount of data, scalability in the form of multiple instances of the microservice helps to solve well-known common problem of giant applications dealing with big data. High availability is also a natural outcome because while maintaining one microservice, others aren’t affected and continue to serve their functionalities.
Updates and security
Complex information systems often include integrations with 3rd party services (e.g. fiscal systems, email providers, SMS gateways, etc.). When there is a need for another 3rd party service that should replace the currently used service, it’s not so painful as it was in monolithic architecture. This aspect improved by developing these kinds of integrations as a standalone microservices with defined input and output interfaces so their replacement in the future is much simpler and safer. The same applies for libraries and frameworks. When security update is announced, we are able to react very quickly and update affected parts of the system individually. We don’t risk breaking another functionality while keeping application secure and up-to-date. This involves not only existing parts of the system but also the new ones. Every new service can use a technology that will suit its functionality the most independent of others.
Conclusions
Now you have a basic overview of the differences between architectures and you know how microservices architecture can help to deliver faster, save customer’s money and provide higher quality software. In the next part of this series about microservices architecture we will guide you through the changes we had to make to our processes and how we, developers, adapted to them.
Authors: Dávid Ondruš, Richard Rostecky, Tibor Hanesz
