Microservices Architecture — What It Is And Why We Use It (Part 1)
You’ve probably heard something about that term. Monolithic architecture is a well-known standard but there are also some alternatives. There is no perfect choice, and everything depends on the use case, because every architecture has both advantages and 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 the entire information system's functionalities. For instance, one microservice handles user management, including registration, login, password recovery, and profile editing, while another handles the product catalogue, categorization of products, and related tasks.
Our motivation
We often encountered standard functionalities in projects we have worked on, but reprogramming them repeatedly 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 was no longer satisfying our needs because it led to repeating the same work multiple times. An approach that utilizes reused and shared components, known as microservices, would bring greater efficiency to our development process and make our solutions better equipped to meet customers’ requirements.
What benefits do we see?
The reusability of microservices means that we need to develop them generic and configurable. By modifying their configuration, they can be prepared for various use cases without requiring code changes. A good example is the registration and activation process of a user account in the “user module,” which can be instant in one project but may require an email with an activation link in another. In complex information systems, specific components must handle a higher workload than others. It isn’t a problem anymore since we can allocate more resources in the particular 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, as maintaining one microservice does not affect the others, which 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 third-party service to replace the currently used service, the process is not as complicated or painful as it is in a monolithic architecture. This aspect was 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 can react very quickly and update the 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 utilize a technology that best suits its functionality, independently of others.
Conclusions
Now you have a basic overview of the differences between architectures, and you understand how the microservices architecture can help deliver faster results, save customers’ financial resources, and provide higher-quality software. In the next part of this series on microservices architecture, we will guide you through the changes we made to our processes and how we, as developers, adapted to them.
Authors:Dávid Ondruš,Richard Roštecký, Tibor Hanesz
