How Microservices Evolved: From Monoliths to Cloud‑Native Architecture

Background of Microservice Architecture

In the early Web 1.0 era most applications were monolithic, built by small teams to serve static webpages or news portals. With the advent of Web 2.0 and massive user growth, e‑commerce and social platforms required larger development teams and more complex traffic, exposing the inefficiencies of monoliths such as low development velocity.

SOA emerged as a precursor to microservices, introducing centralized components like ESB and early frameworks (e.g., Alibaba HSF, Double). The mobile‑Internet boom further accelerated the need for highly scalable, independently deployable services, giving rise to the microservice concept.

Monolithic Era 1.0

Early systems used a single entry point (e.g., an SLB load balancer) that routed requests to a single virtual machine (ECS) hosting a monolithic service sharing one database.

Monolithic Era 2.0

SOA introduced a “divide‑and‑conquer” mindset, splitting business logic into separate services, yet still sharing a single database, so the architecture remained effectively monolithic.

Microservice Era

Clients now reach a gateway (via SLB) that forwards requests to individual services. Each service has its own database or cache and registers with a service registry such as Nacos for discovery and configuration management.

Microservice Technology in Cloud‑Native Era

Cloud‑native relies on containers and orchestration (Kubernetes). Containers standardize runtime environments, allowing heterogeneous microservices (different languages, runtimes) to be deployed uniformly. Kubernetes abstracts compute, storage, and networking, acting as an operating system for cloud‑native workloads.

Pods group one or more containers, coupling their lifecycles. Sidecar containers provide auxiliary functions such as logging, networking, or authentication, enhancing stability and observability without altering the main service.

Traffic Governance

Microservices turn static communication into dynamic runtime interactions, requiring dedicated traffic management. Service mesh (e.g., Istio) solves cross‑language, cross‑environment traffic governance by inserting sidecar proxies (Envoy) that handle request routing, load balancing, and observability.

Service mesh also provides policy enforcement, security, and telemetry, enabling fine‑grained control over service‑to‑service traffic.

Microservice + Serverless Best Practices

Serverless originated with AWS Lambda (2014) and later matured into platforms like Alibaba Cloud Function Compute and SAE. Combining microservices with serverless abstracts away server management, allowing developers to focus solely on business logic. A request‑driven model standardizes incoming requests, routes them, and manages processing, aligning closely with serverless principles.

Microservice Architecture Pain Points

Microservices increase system complexity: service discovery, configuration, and observability introduce new components. While containers and Kubernetes help, they also add operational overhead, steep learning curves, and deployment challenges such as image management and component maintenance.

Summary

Microservice architecture has progressed from monolithic deployments on physical IDC hardware, through virtual machines (ECS), to the cloud‑native era where containers, Kubernetes, and service mesh abstract away operational concerns. This evolution enables developers to concentrate on business logic, achieve elasticity, and reduce costs while confronting new challenges in stability and complexity.