Microservices: pros and cons

Microservices is an approach to application development that is growing in popularity. They allow for easier application management, flexible changes and scaling. Each microservice is a separate component that can be designed according to business needs and meet user requirements more precisely. In this post, I will discuss the essential aspects of microservices architecture, the basics of the DDD approach, communication between microservices and the implications of using this approach.

Microservices is an approach to application development in which you develop the whole system as smaller, independent modules. Each module is a separate application that can run independently of the rest. These modules are connected via a network, so they can communicate with each other and act together.

This approach enables greater flexibility, scalability and easier management of the application. The flexibility comes from the fact that each module is a self-contained component and you can easily replace it without affecting other parts of the system. You can also use different technologies for different services. In other words, microservices make it easy to change an application without modifying the entire system.

Scalability is another asset in a microservices architecture. With this approach, you can scale the application more precisely, i.e., if only a particular part of the system requires more resources, you can increase its computing power or expand its databases without affecting the entire application.

Microservices also allow independent development of functionality and better teamwork organization because different developers can develop services independently.

Where did the approach of creating microservices come from?

The approach of creating microservices emerged in the 1990s. when companies began to develop more and more monolithic applications. Over time, this type of application has proven difficult to maintain, and making changes to it is costly and risky. In response to these problems, the microservices approach was developed, which is based on creating smaller, independent modules that can operate independently and be easily replaced or substituted without affecting the overall system.


Monolithic architecture

Monolithic architecture is an approach to application development in which the entire system operates as a single, cohesive unit. All of its functionality is contained in a single program, and changes to one part of the system can affect the whole. This is a common approach in legacy applications that rely on simple structures and less functionality. However, as technology evolves and applications become more complex, the monolithic approach becomes less practical and effective.

Systems development vs. microservices, or how does their architecture meet their needs?

The microservices architecture addresses the needs of business and development teams as follows:

  • Flexibility: by dividing the application into smaller, independent modules, it is possible to quickly make changes to the application without modifying the entire system.

  • Scalability: with this approach, the application can be scaled in a more precise way, i.e. if only a particular part of the system requires more resources, you can increase its computing power or expand its databases without affecting the entire application.

  • Better team organization: each module can be developed independently by a different team.

  • Greater fault tolerance: an error in a microservice causes only the service where the error occurred to stop working.

  • Ability to use different technologies: different technologies can be used for each micro service.

  • Deployment: micro-services can be deployed independently, so changing one service necessitates deploying only that one service.

  • Scaling: when using microservices, only those services that require it can be scaled. This provides excellent opportunities for optimization.

Microservices - is it still a revolution and new quality or already a standard in projects?

Although microservices are no longer as new as a few years ago, it still can’t be said that this is the standard in projects. Many companies still use a monolithic approach, and microservices are mainly used for larger projects. However, with the increasing popularity of cloud technologies and the need to adapt quickly to changing market conditions, the microservices approach is gaining ground and can be expected to become the standard in large-scale projects soon (microservices architecture can be recommended for complex applications)

It's not always worth it to opt for microservices architecture

It’s not always worth it to opt for microservices architecture

Microservices architecture vs. monolithic architecture

MicroservicesMonoliths
FlexibilityThe application is divided into smaller, independent services that can operate independently and be easily replaced or substituted without affecting the overall system.All functionality is included in one program, and changes to one part of the system can affect the whole.
ScalabilityThe application can be scaled more precisely. You can scale only those services that require it.You need to scale the whole system
OrganizationBetter organization of the team. Different teams can work independently on other parts of the system.One large group for the entire system
DeployingMicroservices can be deployed separately.The minor change in code results in the need to deploy the entire application
CostsInfrastructure, software and licensing costs are increasingCosts are fixed, and there are fewer "building blocks."
Debugging and testingIt is more difficult because the system is distributedEasier to test because everything is in one place
SecurityTraffic is over the network between systems, so you have to secure the communication.Most communication is inside the system, making it easier to handle security.
PerformanceCommunication over the network causes delays and unexpected crashesWith less latency caused by the network, the application runs in a more predictable way
Monitoring and analyticsThe system is distributed, so monitoring it is more complicated. Integration with external systems is not as easy as with monolith.Simple, everything is in one place.
Consistency of dataEvery service can have a database, and transactivity is hard to achieveOne database, transactional operations at your fingertips

Disadvantages of microservices

The above table shows some disadvantages of microservices, I will summarize some more below the problems that strike from the very beginning of the microservices adventure:

  • System complexity: splitting into smaller modules and multiple services results in more processes, which increases system complexity.

  • Required skills: employees must be skilled in microservices troubleshooting and service management.

  • Costs: infrastructure, software and licensing costs are rising, but flexibility and application scalability can pay dividends.

  • Problems with maintaining data consistency: when data is scattered across different services, maintaining data consistency becomes more difficult and requires additional work.

  • Testing problems: testing a multi-service system is more complex and requires more resources.

  • Security issues: microservices communicate over the network, which requires attention to the security of transmitted data so that only authorized services can use it.

The choice of microservices architecture has pros and cons. Decide for yourself which architectural style is best for your project

The choice of microservices architecture has pros and cons. Decide for yourself which architectural style is best for your project.


Microservices vs. DDD approach

The Domain-Driven Design (DDD) approach focuses on designing and developing applications according to business needs and requirements. DDD is a set of practices for creating systems architecture with the business domain and its problems in mind.

Microservices are often used in the DDD approach because they allow applications to be easily broken down into smaller, more understandable parts that are more related to specific business domains. Thus, microservices can be designed according to business needs and meet user requirements more precisely.

In the DDD approach, microservices are designed to represent specific parts of the business domain. Each microservice is responsible for one specific functionality or business domain, allowing for easier team organization and a better understanding of the business.

It is worth noting that although microservices are often used in the DDD approach, they are not the only way to design applications according to this approach. DDD assumes that application design should be flexible and tailored to specific business needs, meaning that different approaches can be used depending on the situation.

Business domain analysis

A business field is an area in which a company or organization operates. It encompasses all the company’s processes, systems, procedures and departments that affect its operation and success. In the DDD approach, the business domain is central to application design because it helps understand user needs and requirements and enables the application to be designed according to business needs.

A business subfield is a smaller part of a business field that focuses on a specific aspect of a company or organization. Each microservice is responsible for one specific functionality in a business domain or even an entire business sub-domain.


Bounded Context

Bounded Context is a certain level of abstraction at which we design our system. It is responsible for isolating the specific functional areas (in a business context) in which our application operates. Each of these areas is separate from the other and has its own specific requirements. Thus, microservices can be designed according to business needs and meet user requirements in a more precise way.

The introduction of the DDD approach brings with it a lot of changes in the work of teams

The introduction of the DDD approach brings with it a lot of changes in the work of teams


Communication between microservices

Microservices interact over the network using various protocols and data formats. There are various approaches to microservices communication, including REST, gRPC, AMQP and many others.

One popular approach to communication between microservices is REST (Representational State Transfer). REST is an architecture that enables the exchange of resources between clients and servers. For microservices, REST enables the communication between different services via standard HTTP and JSON protocols.

Another popular approach to communication between microservices is gRPC. gRPC is an open-source framework for remote procedure calling (RPC) developed by Google. gRPC allows communication between different services via HTTP/2 protocol and binary protocol format.

AMQP (Advanced Message Queuing Protocol) is another approach to communication between microservices. AMQP is a communication protocol that allows messages to be sent between different services. This protocol allows asynchronous message exchange between services, which can be helpful for applications with many users.

There are many other approaches to microservices communication. The choice of a particular approach depends on many factors, such as business requirements, the scale of the application and developer preferences.

Abstracting from protocols and data formats, communication between services can be divided into two basic types:

  • synchronic (blocking)

  • asynchronous (non-blocking)

Growing number of microservices complicates communication between them

A growing number of microservices complicates communication between them


Will microservices architecture work for my project?

Microservices architecture can be a good choice if you are developing an extensive application with a lot of complex functionality or need flexibility and scalability in application management. Microservices make it easy to change an application, scale it, and better manage it. Microservices also allow flexible organization of the team’s work, resulting in greater efficiency and speed. However, before making a decision, it is worthwhile to carefully analyze the needs of your project and consider whether microservices are the best solution for your case.


Consequences of using a microservice architecture

Everything in architecture is a trade-off. The choice of a particular architecture has consequences. Today I want to show you the consequences of choosing a micro-service architecture.

Ability to use different technologies

You can use different technologies for each microservice. Nothing prevents one from having a relational database and the other a non-relational database. In one, your program is in NodeJS; in another, your program is in Java. It could be even better: one microservice in Java and another in JavaScript. It really is possible.

On the other hand, the micro-service architecture favors the introduction of new technologies. In a monolithic architecture, it is rather impossible to replace the programming language, and most changes will usually be very expensive. Besides, adding a new (unknown) technology involves a high risk of error. With micro-services, you can experiment without taking a lot of risks because you are working on a much smaller scale.

Why wouldn't a programmer want to work in modern technologies?

Why wouldn’t a programmer want to work in modern technologies?


Complexity

Each microservice adds to the complexity of the system. The complexity of the system also increases the difficulty of the programmer’s daily work. You can efficiently run and develop the monolith in your local environment. When CI comes to running 50 microservices on the premises, it stops getting fun.

The complexity of the technology can also be overwhelming for developers. The introduction of microservices is often used by companies to experiment with new technologies and programming languages. All of this comes with significant challenges, and it certainly takes a lot of time to understand the novelties, technical innovations and new architecture.

Greater fault tolerance

Making a mistake in a monolithic system can mean the whole system explodes and stops working. An error in a microservice will cause only the service where the error occurred to stop working.

Complicated testing

The e2e tests of microservices cost more by being more challenging to set up and losing reliability, as the application may stop working, for example, during a network connection problem during testing.

Deploy

Microservices can be deployed independently, so changing one service necessitates deploying only that one service.

Scaling

When using microservices, you can scale only those requiring it. This provides excellent opportunities for optimization.

Costs

The cost of infrastructure, software, and licenses is increasing. At the same time, the cost of education is increasing. Is anything declining? Indeed the pace of work at the beginning of the implementation of microservices. Costs only decrease over time, and you have to wait a long time for good results from your choice of microservices. The natural question then is whether a microservice architecture is suitable for startups.

Use of microservices is seen in infrastructure costs

The use of microservices is seen in infrastructure costs

Flexibility

Microservices give flexibility. Unfortunately, nothing is free. When deciding on microservices you are buying this flexibility. What are the costs? You have already read the paragraph above.

Data consistency

Database transactions work great in monolithic systems. Doing something similar in a microservices architecture is no longer a simple task.

Analytics

In a monolithic system, you have one database. You can monitor this database and quickly extract the information you need from it. In microservices, you keep data in multiple databases, making analyzing data more difficult.

Monitoring

Same with analytics - instead of monitoring one system, you must monitor several microservices. Finding the error and the problem is more difficult than with a monolith.

Security

Microservices communicate over the network. This means paying attention to the security of the transmitted data so that only authorized services can use it.

Delays

The consequences of communicating over the network are delays that slow down the entire system and sometimes cause it to operate unpredictably.


Summary

Microservices architecture is an approach to application development that allows for greater flexibility, scalability and more accessible application management. With this approach, you can develop and maintain the application more easily, which is especially important for large projects. However, the choice of a particular architecture always carries consequences.

With microservices, system complexity and infrastructure cost increase, and testing and monitoring become more complicated. On the other hand, microservices allow teams to organize their work flexibly, easily make changes to the application, scale it and better manage it.

Before deciding on an architecture, it’s a good idea to carefully analyze the needs of your project and consider whether microservices are the best solution for your case.

After reading this article, you already know what microservices are, despite this, there is still a lot to discover before you!

After reading this article, you already know what microservices are. Despite this, there is still a lot to discover before you! Sign up for my newsletter to deepen your knowledge of microservices and architecture.

Subscribe my blog