Microservices Architecture — What It Is 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?

Compared to typical monolithic architecture, microservices architecture consists of a collection of services where each service has a particular business capability. We can imagine this microservice as a small application that handles only a 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 often saw common functionalities in projects we have been working on but programming them again and again was very inefficient. With a rising demand for complex information systems, we needed to bring more reusability into the development process. The basic development approach wasn’t satisfying our needs anymore because it led to doing the same work more than once. An approach with reused and shared parts called microservices would bring more efficiency to our development process and would make our solutions ready to meet customers’ requirements.

What benefits do we see?

The 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. A good example is the registration and activation process of a user account in the “user module” that can be instant in one project but based on an email with an activation link in another. In complex information systems, some parts have to deal with a higher load than others. It isn’t a problem anymore since we can allocate more resources for the specific microservice. When it comes to processing large amounts of data, scalability in the form of multiple instances of the microservice helps to solve the well-known common problems 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, the process is not as complicated and painful as it is in monolithic architecture. This aspect improved by developing these kinds of integrations as standalone microservices with defined input and output interfaces so their replacement in the future is much simpler and safer. The same applies to libraries and frameworks. When a 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 the 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 most independently 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 financial resources 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 Roštecký, Tibor Hanesz