01 Architecture's Evolution

01 Architecture’s Evolution #

Traditional Monolithic Application Architecture #

Over a decade ago, the mainstream application architecture was monolithic. The deployment involved a single server with a database. In this architecture, operations personnel carefully maintained the server to ensure service availability.

1.png ▲ Monolithic Architecture

Challenges of Monolithic Application Architecture #

With the growth of business, this simple monolithic application architecture quickly faced two problems. Firstly, with only one server, if it fails, such as hardware damage, the entire service becomes unavailable. Secondly, as the business volume increases, a single server quickly becomes unable to handle all the traffic.

The most direct way to solve these two problems is to add a load balancer at the traffic entry point, enabling the monolithic application to be deployed on multiple servers simultaneously. This solves the single point of failure issue and provides horizontal scalability to the monolithic application.

2.png ▲ Monolithic Architecture (Horizontal Scalability)

Microservices Architecture #

1. Evolution to Microservices Architecture through General Services #

With further business growth, more developers join the team to develop features on the monolithic application. However, due to the lack of clear physical boundaries within the monolithic application’s codebase, conflicts arise, requiring manual coordination and numerous conflict merge operations, which greatly reduces development efficiency.

Therefore, developers started breaking down the monolithic application into independent microservices that can be developed, tested, and deployed separately. The services communicate with each other through APIs, such as HTTP, gRPC, or Dubbo. The microservices architecture, based on the Bounded Context split in domain-driven design, greatly improves development efficiency for medium and large teams.

2. Challenges for Operations with Microservices Architecture #

As the application transitions from a monolithic architecture to a microservices architecture, from a physical perspective, distributed systems become the default option. This poses new challenges for application architects to deal with the complexities of distributed systems. In this process, various distributed services and frameworks are introduced, such as caching service Redis, configuration service ACM, coordination service ZooKeeper, message service Kafka, communication frameworks like gRPC or Dubbo, and distributed tracing systems.

Besides the challenges brought by the distributed environment, microservices architecture also presents new challenges for operations. Previously, developers only needed to manage one application, but now they may need to manage ten or even more applications. This means that workloads related to security patches, capacity assessment, fault diagnosis, and other tasks increase exponentially. Consequently, the importance of application distribution standards, lifecycle standards, observability standards, and automated elasticity capabilities becomes more prominent.

3.png ▲ Microservices Architecture

Cloud-Native #

1. Architecture Based on Cloud Products #

Whether an architecture is cloud-native depends on whether it is rooted in the cloud. This is a simple understanding of “cloud-native.” “Rooted in the cloud” does not simply mean using IaaS-level services in the cloud, such as basic computing and storage services like ECS and OSS. It should be understood as whether the architecture uses distributed services in the cloud, such as Redis and Kafka, which directly impact the business architecture. In a microservices architecture, distributed services are essential. Previously, organizations either developed and maintained such services themselves or relied on self-supported versions of open-source services. However, in the era of cloud-native, businesses can directly use cloud services.

Two other technologies that are worth mentioning are Docker and Kubernetes. Docker standardized the application distribution process, enabling applications written in different technologies like Spring Boot and Node.js to be distributed as containers. On the other hand, Kubernetes, building on the Docker technology, defined the standard application lifecycle, establishing uniform standards from application startup to deployment, health checks, and shutdown.

2. Application Lifecycle Management #

With standardized application distribution and lifecycle, cloud providers can offer standardized application hosting services, including version management, release, observation after deployment, and self-healing capabilities. For stateless applications, the failure of an underlying physical node no longer affects development because the application hosting service, based on standardized application lifecycles, automatically handles the relocation of containers. It takes down containers on the faulty physical node and starts an equivalent number of containers on a new physical node. Cloud-native further unlocks value dividends.

Moreover, application hosting services can sense data during the runtime of an application, such as concurrency of business traffic, CPU load, and memory usage. Businesses can configure scaling rules based on these metrics, and the platform can execute these rules, increasing or decreasing the number of containers based on the actual business traffic. This basic functionality is known as auto scaling. It helps users avoid resource limitations during business low-peak periods, saves costs, and improves operational efficiency.

Conclusion #

During the evolution of architecture, developers and operations personnel gradually shift their focus away from machines, hoping that platform systems can manage the machines rather than relying on human management. This is a simple understanding of serverless.

About the Author #

Xu Xiaobin is a Senior Technical Expert at Alibaba Cloud. Currently, he is responsible for the development and operations of the Alibaba Group’s serverless platform. Prior to this, he was responsible for microservices architecture, the Spring Boot framework, and improving development efficiency at AliExpress. He is the author of “Maven in Action” and was once a maintainer of the Maven Central Repository.