The Evolution of Architecture: Monolithic vs. Microservices

Leapcell: The Best of Serverless Web Hosting In-depth Analysis of Software Architecture Evolution and Selection I. The Development History of Architecture Understanding software architecture technology cannot merely rely on comparison tables. It is necessary to deeply explore its background of emergence, the problems it solves, the derived challenges, and the reasons for being replaced. The following, combined with the research of scholars such as Martin Fowler, sorts out the evolutionary context of the architecture. 1.1 The Era of Original Distributed Architecture The distributed architecture emerged earlier than the monolithic architecture. In 1971, Intel launched the first microcomputer, the MCS-4, and computers began to be applied in commercial production. However, the computing power of a single computer's hardware was limited, which restricted the scale of information systems. Universities, research institutions, and enterprises began to explore solutions for multiple computers to jointly support the same software system. Taking remote calls as an example, the DCE/RPC remote service call specification formulated by the Open Software Foundation and mainstream manufacturers is one of the origins of modern RPC. Its design follows the UNIX "simplicity first principle" and attempts to make service calls and resource access transparent in a distributed environment. But in practice, it faces many technical challenges such as service discovery, load balancing, circuit breaking, and authentication. Although a large number of protocols were built to achieve a certain degree of transparency, network performance issues became a fatal flaw. The development logic is as follows: insufficient hardware performance → adoption of distributed services → performance degradation caused by remote calls → developers manually optimize network performance (contrary to the original intention of transparency) → human capabilities become a constraint on the software scale. With the rapid improvement of hardware performance in the 1980s, the distributed architecture was gradually replaced by the monolithic architecture. Summary of the Advantages and Disadvantages of the Original Distributed Architecture: Advantages: Break through the performance limitations of a single computer and achieve system scale expansion. Disadvantages: High network performance loss, complex technical implementation, and high development difficulty. Simulated Architecture Diagram (in a simple text-based form similar to bash style): +-----------------+ +-----------------+ | Computer A || Computer B | +-----------------+ +-----------------+ | Service 1 | | Service 2 | +-----------------+ +-----------------+ 1.2 The Era of Monolithic Architecture Before the emergence of microservices, the monolithic architecture was not regarded as a special architecture because it was so natural. The main feature of the monolithic architecture is that all process calls within the system are intra-process communications. Regarding the view that "the monolithic architecture is not convenient for expansion", from the perspective of performance expansion, it can be achieved through deploying multiple service replicas and load balancing; from the perspective of functional expansion, large systems usually adopt a layered architecture (such as the MVC pattern) and modular design, and each module can be iterated independently. However, the monolithic architecture also has obvious limitations. For example, its technical stack scalability is poor, and it is not as flexible as microservices when integrating different technologies (such as implementing AI functions in a C++ system); the isolation is poor, and a single failure may cause the entire process to crash. As the scale of the system and the team expands, the disadvantages of the monolithic architecture become more and more obvious. The exploration of splitting large monolithic systems has formed three typical architectures: Silo Architecture: The system is split into independent subsystems without business interaction. However, in practice, each subsystem usually has a demand for resource sharing, so it is less applied. +-----------------+ +-----------------+ | Subsystem A | | Subsystem B | +-----------------+ +-----------------+ Microkernel Architecture: Concentrate data, resources, and public services into the core, and business systems exist in the form of plugin modules. For example, the Eclipse IDE and some insurance systems. The limitation is that plugins can only interact with the kernel and cannot communicate directly. +-----------------+ | Microkernel | +-----------------+ | Plugin A | +-----------------+ | Plugin B | +-----------------+ Event-driven Architecture: Realize message publishing and subscription between subsystems through the event queue pip

Apr 30, 2025 - 12:01

The Evolution of Architecture: Monolithic vs. Microservices

Leapcell: The Best of Serverless Web Hosting

In-depth Analysis of Software Architecture Evolution and Selection

I. The Development History of Architecture

Understanding software architecture technology cannot merely rely on comparison tables. It is necessary to deeply explore its background of emergence, the problems it solves, the derived challenges, and the reasons for being replaced. The following, combined with the research of scholars such as Martin Fowler, sorts out the evolutionary context of the architecture.

1.1 The Era of Original Distributed Architecture

The distributed architecture emerged earlier than the monolithic architecture. In 1971, Intel launched the first microcomputer, the MCS-4, and computers began to be applied in commercial production. However, the computing power of a single computer's hardware was limited, which restricted the scale of information systems. Universities, research institutions, and enterprises began to explore solutions for multiple computers to jointly support the same software system.

Taking remote calls as an example, the DCE/RPC remote service call specification formulated by the Open Software Foundation and mainstream manufacturers is one of the origins of modern RPC. Its design follows the UNIX "simplicity first principle" and attempts to make service calls and resource access transparent in a distributed environment. But in practice, it faces many technical challenges such as service discovery, load balancing, circuit breaking, and authentication. Although a large number of protocols were built to achieve a certain degree of transparency, network performance issues became a fatal flaw. The development logic is as follows: insufficient hardware performance → adoption of distributed services → performance degradation caused by remote calls → developers manually optimize network performance (contrary to the original intention of transparency) → human capabilities become a constraint on the software scale. With the rapid improvement of hardware performance in the 1980s, the distributed architecture was gradually replaced by the monolithic architecture.

Summary of the Advantages and Disadvantages of the Original Distributed Architecture:

Advantages: Break through the performance limitations of a single computer and achieve system scale expansion.
Disadvantages: High network performance loss, complex technical implementation, and high development difficulty.

Simulated Architecture Diagram (in a simple text-based form similar to bash style):

+-----------------+     +-----------------+
| Computer A      |<--->| Computer B      |
+-----------------+     +-----------------+
| Service 1       |     | Service 2       |
+-----------------+     +-----------------+

1.2 The Era of Monolithic Architecture

Before the emergence of microservices, the monolithic architecture was not regarded as a special architecture because it was so natural. The main feature of the monolithic architecture is that all process calls within the system are intra-process communications.

Regarding the view that "the monolithic architecture is not convenient for expansion", from the perspective of performance expansion, it can be achieved through deploying multiple service replicas and load balancing; from the perspective of functional expansion, large systems usually adopt a layered architecture (such as the MVC pattern) and modular design, and each module can be iterated independently. However, the monolithic architecture also has obvious limitations. For example, its technical stack scalability is poor, and it is not as flexible as microservices when integrating different technologies (such as implementing AI functions in a C++ system); the isolation is poor, and a single failure may cause the entire process to crash.

As the scale of the system and the team expands, the disadvantages of the monolithic architecture become more and more obvious. The exploration of splitting large monolithic systems has formed three typical architectures:

Silo Architecture: The system is split into independent subsystems without business interaction. However, in practice, each subsystem usually has a demand for resource sharing, so it is less applied.

+-----------------+     +-----------------+
| Subsystem A     |     | Subsystem B     |
+-----------------+     +-----------------+

Microkernel Architecture: Concentrate data, resources, and public services into the core, and business systems exist in the form of plugin modules. For example, the Eclipse IDE and some insurance systems. The limitation is that plugins can only interact with the kernel and cannot communicate directly.

+-----------------+
| Microkernel     |
+-----------------+
| Plugin A        |
+-----------------+
| Plugin B        |
+-----------------+

Event-driven Architecture: Realize message publishing and subscription between subsystems through the event queue pipeline, which solves the interaction problem of plugins in the microkernel architecture and is widely used in fields such as e-commerce systems.

+-----------------+     +-----------------+     +-----------------+
| Subsystem A     |     | Event Queue     |     | Subsystem B     |
+-----------------+     +-----------------+     +-----------------+
| Publish Message |---->| Receive/Forward |---->| Process Message |
+-----------------+     +-----------------+     +-----------------+

Summary of the Advantages and Disadvantages of the Monolithic Architecture:

Advantages: Simple development and debugging; high intra-process communication efficiency; low initial cost.
Disadvantages: Limited technical stack; poor isolation, and a large impact range of failures; difficult maintenance of large systems.

1.3 The Era of SOA Architecture

While the monolithic architecture was evolving, the development of distributed technology gave birth to the Service-Oriented Architecture (SOA). In SOA, a "service" is an independent unit that contains complete business function code and data, with a relatively coarse granularity. The core goal is to achieve service reuse. By formulating unified interface standards and architecture patterns, it accelerates the development of new applications.

SOA has solved many problems in a distributed environment at the technical level. For example, it uses the SOAP protocol for remote calls and realizes communication between subsystems through the Enterprise Service Bus (ESB). However, due to its overly strict specifications, complex technical stack, and high implementation cost, it has gradually been phased out. Taking the SOAP protocol as an example, it tried to solve all the problems of distributed computing and built a large protocol family, but finally withdrew from the historical stage due to its high learning and usage costs.

Summary of the Advantages and Disadvantages of the SOA Architecture:

Advantages: Emphasize service reuse and improve development efficiency; unified interface standards make system integration easier.
Disadvantages: Complex specifications and high implementation difficulty; insufficient flexibility and slow response speed.

Simulated Architecture Diagram (in a simple text-based form similar to bash style):

+-----------------+     +-----------------+     +-----------------+
| Service A       |<--->| ESB             |<--->| Service B       |
+-----------------+     +-----------------+     +-----------------+
| Business Logic A|     | Message Routing |     | Business Logic B|
+-----------------+     +-----------------+     +-----------------+

1.4 The Era of Microservices Architecture

The microservices architecture began to rise in 2014. Initially, it was a lightweight alternative to SOA, aiming to abandon cumbersome constraints and return to the transparency and simplicity of the distributed architecture. Now it has developed into an independent architecture style, emphasizing replacing "specification standards" with "practical standards" and giving developers the flexibility to freely choose solutions.

Driven by cloud computing, the microservices architecture has achieved the coordination between software and hardware, reducing the difficulty of deploying and operating distributed systems. But at the same time, it puts forward higher requirements for the capabilities of architects, involving complex technologies such as service registration and discovery, load balancing, and link tracing.

Summary of the Advantages and Disadvantages of the Microservices Architecture:

Advantages: Services can be deployed independently, which is convenient for expansion; support multiple technical stacks; strong fault isolation.
Disadvantages: High system complexity and difficult operation and maintenance; increased communication costs between services; increased development and testing costs.

Simulated Architecture Diagram (in a simple text-based form similar to bash style):

+-----------------+     +-----------------+     +-----------------+
| Microservice A  |<--->| Microservice B  |<--->| Microservice C  |
+-----------------+     +-----------------+     +-----------------+
| Business Logic A|     | Business Logic B|     | Business Logic C|
+-----------------+     +-----------------+     +-----------------+
| Independent Data|     | Independent Data|     | Independent Data|
+-----------------+     +-----------------+     +-----------------+

1.5 The Serverless Era

The serverless architecture benefits from the development of cloud computing technology. In this mode, developers do not need to manage server resources and can focus on implementing business logic. The backend infrastructure is provided by cloud service providers, and business logic runs in the form of functions. Although it is still in the development stage, its concept has had a profound impact on traditional architectures.

Summary of the Advantages and Disadvantages of the Serverless Architecture:

Advantages: No need to manage servers; pay as you use, and the cost is controllable; simple deployment and operation and maintenance.
Disadvantages: High dependence on cloud service providers; difficult to debug and monitor; not suitable for all scenarios.

Simulated Architecture Diagram (in a simple text-based form similar to bash style):

+-----------------+     +-----------------+
| Business Logic  |<--->| Infrastructure  |
+-----------------+     +-----------------+
| Function        |     | Log/Storage     |
+-----------------+     +-----------------+

II. Monolithic or Microservices

2.1 Application Scenarios of Microservices

Restriction of Team Capabilities: When the team is large and the members' levels vary, microservices can reduce the impact of individual mistakes on the system through service isolation.
Restriction of Technical Stacks: When it is necessary to integrate multiple technical stacks (such as AI development), microservices can achieve independent deployment and management.
Restriction of Organizational Structure: When the organizational structure is frequently adjusted and the monolithic architecture is difficult to adapt to cross-team collaboration, microservices have more advantages.

2.2 Implementation Conditions of Microservices

Professional Talents: The team needs to have experts who are familiar with microservices architecture design and operation and maintenance.
Automated Operation and Maintenance: A complete automated deployment, monitoring, and measurement system is required to cope with the operation and maintenance challenges brought about by the increase in the number of services.

2.3 Practical Suggestions

Small-scale Teams: Give priority to the monolithic architecture to reduce initial costs and gradually evolve as the business develops.
Large-scale Teams: Divide system modules through domain modeling, adopt the microservices architecture to achieve independent deployment, and decentralization of data is recommended.

III. Conclusion

Neither the monolithic nor the microservices architecture is a "cancer". Instead, they are technical choices in different historical stages and according to different business needs. In actual projects, factors such as business scale, team capabilities, and technical requirements should be comprehensively considered to select the architecture that is most suitable for the current development stage and maintain the flexibility and evolvability of the architecture.

Leapcell: The Best of Serverless Web Hosting

Finally, I would like to recommend a platform that is most suitable for deploying services: Leapcell