[Assembled Architecture Design] A Brief History of Architecture Evolution

Introduction: Step by step from monomer to SOA, from microservices to cloud native backend architecture evolution history

What is software architecture

The word Architecture comes from the construction industry and originally means "the process and product of the planning, design and construction of buildings or other structured objects". It is also an art that expresses the characteristics of each civilization.

Back in the software industry, software architecture refers to describing the basic structure of a software system, and how to create a way to build that structure. Although it originated from the construction industry, it has many differences. This article briefly introduces the evolution history of software architecture and a key factor driving its evolution.

Key factors driving architectural evolution

Functional requirements are often a very core part of a software, and many architects and developers tend to focus on the implementation of these functions, while ignoring some non-functional requirements. But these non-functional requirements are key factors in determining product architecture. Recall that some of the software functions we have made can also be implemented through a single application? Or is it possible to use other architectures as well? So why is the software the way it is now? It is often because of non-functional requirements such as performance, availability, and reliability that drive us to make one decision or another, and finally let our software have the current architecture.

Since non-functional requirements are a key factor in determining software architecture, what does it include? According to the ISO/IEC 25010:2011 standard, among the eight characteristics for measuring software quality, the seven characteristics except "functional matching degree" are all non-functional characteristics:

Architecture Evolution History

Monolithic Architecture

Monolithic architecture is also called Monolithic Application in many places, and it is also borrowed from the term Monolithic Architecture in the construction industry. In the software industry, it is a single program that combines functions such as user interface and data access.

The description here is actually not very consistent with the definition of monolithic architecture. Although monolithic architecture can easily lead to "hodgepodge", it does not rule out that a monolithic architecture program can maintain good maintainability (good layering and modularity) . Moreover, the most basic of the subsequent architectural patterns can also be regarded as programs running independently in a single process. These programs should also follow some basic architectural principles, such as the classic three-tier architecture.

In many cases, a monolithic software is sufficient. At this time, over-design should be avoided, and the splitting of microservices forcibly in pursuit of fashion should be avoided. So under what factors will we split the monolithic architecture into a microservice architecture?

· Maintainability: With the development of the business, the functions of the software are bound to increase, and the corresponding R&D team will also increase. Many people develop many functions in the same application, which will bring about a decline in maintainability, including the impact on modularity, testability, and operation and maintenance;

· Performance: Different functions in a single piece of software are more or less different in performance and resource utilization. For example, for functions oriented to background management operations, their performance requirements are often not very high, and some operations are very resource-intensive; the functions on the main business link have relatively high requirements on performance indicators such as concurrency, throughput, and response time. If these two types of functions are placed in a single application, when horizontal expansion is carried out, the utilization of resources and the isolation of resources cannot be well supported, and it also limits the specific application of different business functions. the possibility of optimization;

Reliability: This is also a factor that affects the evolution of a monolithic architecture to a microservices architecture. But it is not a key factor. After all, some applications with a single architecture can also be deployed in clusters to improve reliability.

SOA

SOA (Service Oriented Architecture) defines a set of standards, including how to make software components reusable, how to interact between components through interfaces, and so on. Enterprises based on SOA can adapt to market changes faster and more efficiently.

Development History
1. Presented by Gartner in 1994 (reference);

2. In 2006, the OSOA Alliance was established to promote relevant industry standards;

3. In 2007, OSOA was transformed into the Open CSA international organization that develops industry standards;

ESB

ESB (Enterprise Service Bus) was also proposed by a member of Gartner in 2002. The core idea is to use a centralized component to handle the interaction and integration between various applications. It is built on SOA and is part of the standard.

Microservice Architecture

The microservices architecture was presented at a conference under the name "Micro-Web-Services" as early as 2005, and the official name "microservices" was used in 2011.

Microservice architecture is a software that combines many loosely coupled and independently deployable small services to meet business requirements. These services tend to have the following characteristics:

· Services can have their own different technology stacks, and also include their own independent databases and data management models;

· The communication between services is mainly through API and messages;

· Organizations that serve in business capabilities (bounded contexts).

Wait, this definition sounds familiar, reminiscent of UNIX-style pipelining:

· Each command is a separate program, running in its own process. They may be written in different languages ​​and manage synchronized data;

Communication between commands through standard input and output and pipeline;

· Organization of commands in the function of the smallest atom (KISS principle).

In fact, the birth of the microservice architecture is also based on the UNIX-style pipeline, so the real history of the microservice architecture may have to be pushed back decades.

Microservices vs SOA

Does Service Oriented Architecture (SOA) and Microservice Architecture sound very similar, in fact they are also inextricably related. But through an analogy, we can probably understand their essential differences. SOA is like the current EJB, which is a strict and closed standard proposed by a series of big manufacturers, and the product is like spring and snow; and microservices are like Spring from the open source community, open, free and full of vitality. There is a huge difference in maintainability (implementation & maintenance cost) between the two, and in the end both Spring and Microservices beat EJB and SOA.

cloud native

In my opinion (only my opinion), cloud native is not a complete architecture generation (unlike changes from monolith to SOA, microservices). Cloud computing has brought a lot of changes to the underlying (IaaS/PaaS/SaaS) of our system development, and the most fundamental reason driving this change is cost considerations. In order to better adapt to these changes, we need to make more considerations in the architecture design to achieve a better price/performance ratio. When this consideration reaches an extreme, that is, the architecture is 100% based on cloud computing design, it can be called "cloud native". For example, Snowflake is a typical cloud-native architecture. It is 100% based on various AWS cloud services from the time of its design. It can make full use of the various benefits brought by cloud computing and achieve the ultimate cost reduction and efficiency increase; while at the same time Although other data warehouse products can also be used on the cloud, they essentially just simulate a traditional IDC environment on the cloud, which is not enough to use.


Cloud computing has also developed for so many years, and there are various manufacturers of various sizes at home and abroad, but each has different products and implementations. After we select a cloud, it is often difficult to migrate/adapt to another cloud due to various limitations. Therefore, CNCF (Cloud Native Computing Foundation) came into being, which standardizes all aspects of cloud native, and inspects and incorporates products that meet the standards. Products designed based on the standard architecture of CNCF are not only cloud-native in theory, but can also be migrated/adapted to multiple clouds.


Summarize

After understanding so many architectures, the final conclusion is one sentence: there is no best architecture, only the most suitable architecture. We need to comprehensively consider various business requirements, especially non-functional requirements, and choose a more suitable architecture. Once a certain architecture is adopted, the system is not static. As long as the business is developing, we need to maintain the activity of the architecture, and we can make adjustments at any time, or even overturn the previous architecture decisions.