preface

Monomer and microservice is a commonplace topic in software architecture. It is not that monomer is necessarily bad and microservice is necessarily good. In addition to pure technology, comprehensive consideration should be taken in combination with business scenarios and business development stages. This article describes the application scenarios and the advantages and disadvantages of single and micro service racks

monomer

Monolithic architecture is where the entire system is developed as a single unit, packaged and deployed, and all the code is in a repository

advantages

In the early stages of the business, a single structure is a reasonable choice because it has the following benefits:

  • Test development is easy: only use this application, local testing does not need to start multiple services for debugging
  • Simple deployment: Deploy only one application
  • High performance: High performance because there is no need to communicate between instances and most are local method calls
  • High availability: Because there is no need for communication between instances, this instance is less likely to become unavailable when external services are unavailable

disadvantages

However, with the development of the business, the increase of application functions, the expansion of the code base, and the expansion of the R&D team, the single application will have some disadvantages:

  • Increased complexity: Since the code is in a repository, it is bound to become more complex, especially if it is not structured in modules. This makes it difficult for developers to understand all the code logic
  • Slow development: Both local startup, commit to test, pipeline, compile, and deploy will slow down, resulting in slower development and testing
  • High expansion cost: Different modules in the program may require different hardware resources. For example, the report module requires more memory, while the regular computing module requires more CPU. Because different modules are in the same process, the server needs to meet all their requirements at the same time, increasing the deployment cost
  • Lack of fault isolation: Because different modules are in the same process and instance, the failure of any one module may cause the entire program to break down, resulting in low stability

To be clear, the above mentioned issues are non-functional requirements. Business needs can also be met with a single structure, so some systems may be shiny on the outside, but on the inside they may be a single “big ball of mud” that the internal developers are already struggling with.

But having these non-functional capabilities, higher scalability, maintainability, and testability means faster and better software delivery. Let’s look at the microservices architecture

Micro service

In contrast to a standalone architecture, microservices architecture divides business functions into a set of services, each containing the full functionality within its business

advantages

The microservices architecture has the following characteristics:

  • High maintainability: Because each service is smaller, it is easier for developers to understand the code logic
  • High scalability: Each service can be independently expanded. For example, if the homepage module has a large number of visits, the homepage module can be independently expanded instead of the back-end report module
  • High fault tolerance: The microservice architecture can achieve better fault isolation. The failure of one service does not affect other services. Sometimes, the microservice architecture needs to be combined with service degradation and circuit breaker to achieve this
  • Low coupling: In principle, services interact with each other only through the API, and the class definitions, methods, and even the database inside the service are invisible to the outside world, and the outside world does not need to care. Therefore, under the condition that the API is not changed, the internal code and database structure can be changed without considering the external, which is the embodiment of high cohesion and low coupling. If you need to change the API for various reasons, it is best to make compatibility changes, such as adding optional fields

disadvantages

Of course, no single technology can be called a “silver bullet,” and microservices architecture has its drawbacks and challenges:

  • Service unbundling: The first problem with microservices is the unbundling of services. It is a technical task to unbundle those modules into a single service. The overall strategy is to make the split services have the characteristics of high cohesion and low coupling, and avoid splitting a “distributed monomer”.

  • System complexity: Developers must deal with the complexity of distributed systems, such as:

    • Interprocess communication, which is more complex than intra process method calls, requires additional consideration for handling cases where external services are locally faulty and unavailable
    • Data consistency: Since each service has its own database, it is not possible to use a database local transaction for data consistency like a single application. Instead, you need to consider distributed transactions
    • Deployment complexity: Microservices architectures typically require multiple services to be deployed, and the order in which each service is deployed requires strict implementation of the release plan

conclusion

This article provides a brief overview of the pros and cons of the two software architectures, single and microservices. The architect or developer needs to consider when to decide to use microservices as a trade-off between rapid business growth and elegant architecture. At the beginning of a program, a single structure is usually chosen. When nonfunctional features start to hinder iterative business development, you need to refactor the units into microservices

Reference documentation

1. Microservice structure design mode