From Monolith to Service Mesh: Evolution of Modern Cloud‑Native Architecture

Architecture Evolution

There is no absolute standard for architectural evolution.

Monolithic Application: The first stage is a single, self‑contained application.

Vertical Application: As business grows, the monolith is split into independent applications; a Web MVC framework becomes the key.

Front‑end/back‑end separation, caching, and database/service separation are introduced, but services remain isolated and may duplicate code.

Distributed Application: With many vertical applications, inter‑application interaction is inevitable. Core business is extracted as independent services, and a distributed RPC framework becomes essential.

Cluster, read/write separation, reverse proxy, acceleration, distributed databases, NoSQL, service splitting, and messaging are handled.

Service calls and code reuse are achieved.

Elastic Flow Computing: As services proliferate, capacity planning and resource utilization require a scheduling center based on real‑time load, improving cluster utilization. A resource‑scheduling and governance center (SOA) becomes critical.

A registration center eliminates manual maintenance of call relationships.

Dubbo embodies the SOA concept, focusing on RPC and service governance.

Microservices: Implemented with Spring Cloud, Docker, Kubernetes, etc., addressing operational concerns of microservices.

Microservices are a refined form of SOA, emphasizing finer‑grained service decomposition.

Additional concerns include monitoring, logging, security, scheduling, and fault tolerance.

At this point it can already be considered a form of “microservice”, typically using SpringBoot.

Microservices and SOA

Microservices are more fine‑grained than SOA; they run as independent processes without affecting each other.

Microservice interfaces are more universal (HTTP RESTful), language‑agnostic, and rely on API contracts rather than code‑level dependencies.

Microservices favor decentralized deployment and data storage, allowing diverse database technologies.

Operations use Docker and Kubernetes for automated deployment and centralized management.

Comparison of SOA and Microservices:

Service granularity: SOA – coarse; Microservices – fine‑grained.

Deployment difficulty: SOA – redeploy the whole application; Microservices – each service can be built and deployed independently.

Communication overhead: SOA – low because most modules reside in one app; Microservices – higher due to remote calls.

Storage: SOA – shared data store; Microservices – each service may have its own store.

Business onboarding: SOA – requires understanding the whole app; Microservices – easy per service but overall system complexity remains.

Communication protocol: SOA – heavy protocols like SOAP, AMQP; Microservices – lightweight HTTP/REST.

Scalability: SOA – difficult; Microservices – container technology makes scaling easy.

Microservices and Distributed Systems

Distributed systems focus on separating services for deployment (vertical + horizontal splitting). Microservices focus on how finely a service should be split.

Spring Cloud and Dubbo

When discussing microservices, two major frameworks inevitably appear.

Differences

Positioning

Dubbo is a product of the SOA era, concentrating on service invocation, traffic distribution, monitoring, and circuit breaking – essentially RPC and service governance.

Spring Cloud emerged in the microservice era, addressing all aspects of microservice governance and leveraging the Spring and Spring Boot ecosystems; it forms a complete microservice ecosystem.

Service Discovery

For service discovery, availability outweighs data consistency; the AP model prevails, and Eureka follows this principle.

Transport Methods

Dubbo uses Netty (NIO) over TCP with Hessian serialization for RPC communication.

Spring Cloud relies on HTTP + REST for remote calls.

HTTP incurs larger payloads but offers flexibility; REST decouples client and provider via contracts, suitable for fast‑evolving microservices.

Module Differences

Dubbo consists of a service registry, providers, consumers, and a governance center.

Spring Cloud provides a full‑stack solution: service registry, providers, consumers, dashboard, circuit breaker, distributed configuration, message bus, tracing, etc.

Architecture – Spring Cloud

Process flow:

All requests go through an API gateway (Zuul) to reach internal services.

The gateway obtains available services from the registry (Eureka).

Ribbon performs load balancing and forwards requests to specific instances.

Feign handles inter‑service communication.

Hystrix manages timeout and circuit breaking.

Turbine monitors calls and circuit‑breaker metrics.

Architecture – Dubbo

Spring Cloud and Kubernetes

What Microservices Care About

About half of the concerns are operational. Spring Cloud is a development framework and cannot handle deployment or scheduling, whereas Kubernetes is an operations platform. Spring Cloud + Cloud Foundry versus Kubernetes shows that Spring Cloud is intrusive and language‑specific, while Kubernetes is non‑intrusive and language‑agnostic.

Differences

Spring Cloud’s features are a subset of what Kubernetes provides.

Feature comparison:

Self‑healing & auto‑scaling: Spring Cloud – none; Kubernetes – kube‑controller‑manager.

Scheduling & release: Spring Cloud – none; Kubernetes – kube‑scheduler + Deployment.

Configuration management: Spring Cloud – Spring Cloud Config/Nacos; Kubernetes – ConfigMap.

Service discovery & load balancing: Spring Cloud – Eureka/Nacos; Kubernetes – Service + CoreDNS / Istio.

Resilience: Spring Cloud – Hystrix/Resilience4j; Kubernetes – Istio.

API gateway: Spring Cloud – Zuul / Spring Cloud Gateway; Kubernetes – Ingress / Istio Gateway.

Service security: Spring Cloud – Spring Cloud Security; Kubernetes – Istio.

Tracing: Spring Cloud – Sleuth + Zipkin; Kubernetes – Istio + Jaeger / Zipkin.

Metrics monitoring: Spring Cloud – actuator + Spring Boot Admin; Kubernetes – Istio + Prometheus.

Log collection: Spring Cloud – Sleuth + ELK; Kubernetes – fluentd / Istio.

Both solutions are fairly complete. Before Istio, Kubernetes only offered basic service registration and discovery; Istio adds a full microservice capability. Cloud providers tend to favor Kubernetes because it is non‑intrusive and decouples platform from application.

Service Mesh

Introduction

Also called “service mesh”, it is the infrastructure layer for inter‑service communication, handling network calls, rate limiting, circuit breaking, and monitoring.

Istio

Istio is the most popular open‑source implementation of a service mesh.

Feature comparison (Spring Cloud vs. Istio):

Service registration & discovery: Spring Cloud – based on Eureka, Consul, etc.; Istio – uses XDS and virtual service routing.

Link monitoring: Spring Cloud – Zipkin, Pinpoint, SkyWalking; Istio – sidecar proxy records network requests.

API gateway: Spring Cloud – Zuul or Spring Cloud Gateway; Istio – Ingress gateway and egress.

Circuit breaker: Spring Cloud – Hystrix; Istio – declarative configuration translated to routing rules.

Service routing: Spring Cloud – gateway layer; Istio – iptables rules.

Security policies: Spring Cloud – Spring Security (auth, authz, encryption); Istio – RBAC on Kubernetes with encryption.

Configuration center: Spring Cloud – Spring Cloud Config; Istio – not supported.

Performance monitoring: Spring Cloud – built‑in monitoring components; Istio – sidecar metrics adapters.

Log collection: Spring Cloud – client for ELK; Istio – sidecar log adapters.

Service Mesh Basics

A service mesh consists of a data plane (sidecar proxies attached to each service) and a control plane that configures those proxies.

Control Plane vs. Data Plane

Control plane does not parse packets directly; it communicates with proxies to push policies, provides visualization, and offers APIs/CLI for versioned configuration.

Data plane is typically stateless, handles inbound/outbound packets, performs routing, load balancing, health checks, authentication, authorization, and emits telemetry, all transparent to the application.

Changes Brought by Service Mesh

1. Decouples microservice governance from business logic by extracting most capabilities into sidecar processes.

2. Enables unified governance of heterogeneous systems across languages and frameworks.

Technical Advantages

Observability: Captures telemetry (source, destination, protocol, URL, status, latency) for all service calls, providing black‑box monitoring.

Traffic control: Supports intelligent routing (blue‑green, canary, A/B testing), retries, circuit breaking, fault injection, and traffic mirroring.

Security: Provides service authentication, encrypted communication, and policy enforcement.

Platform independence: Istio runs on Kubernetes, Mesos, bare metal, and multi‑cloud environments.

Extensibility: Policy execution components can be customized and integrated with existing ACL, logging, monitoring, quota, and audit solutions.

Service mesh is considered the second generation of microservice architecture, but it also introduces complexity, operational skill requirements, latency overhead, and integration challenges.

Conclusion

From the earliest monolithic applications to distributed systems, microservices, containerization, container orchestration, and finally service mesh and serverless, the architectural path shows increasing modularity and infrastructure abstraction.

Kubernetes is exploding as the de‑facto container orchestration platform. As Kubernetes‑based applications grow in scale and complexity, service mesh becomes essential for managing them effectively.

With continuous evolution of service mesh technologies like Istio, they are poised to replace traditional microservice frameworks and become the preferred architecture for enterprises moving to the cloud.