What Is Microservices? Concepts, Design Guidelines, Integration Patterns, and Trade‑offs

What Is Microservices?

Microservices Architecture is an architectural style where a large, complex software application is composed of one or more independent microservices. Each microservice can be deployed separately, is loosely coupled, focuses on a single business capability, and does that job well.

The concept originated from Martin Fowler’s March 2014 article “Microservices”.

Monolithic Architecture

Enterprise applications often accumulate many features into a single monolithic system (e.g., ERP, CRM). As functionality grows, the monolith becomes increasingly difficult to develop, release, troubleshoot, scale, and upgrade.

Monolithic deployment packages depend on the language: Java applications are packaged as WAR files for Tomcat/Jetty or as executable JARs with Spring Boot; Rails and Node.js apps are packaged as directory structures.

Most enterprises use SOA to address monolithic problems, grouping related functions into services. However, SOA introduces many services, message formats, and standards, and often still results in a complex, single‑runtime deployment similar to a monolith.

Typical characteristics of monolithic applications include:

Design, development, and deployment as a single unit.

Increasing complexity leading to difficult maintenance, upgrades, and feature addition.

Hard to adopt agile development and continuous delivery.

Partial updates require redeploying the entire application.

Horizontal scaling must be done at the application level, causing resource conflicts.

Failure of a single component can affect the whole system.

Innovation is constrained by a homogeneous technology stack.

Operations and impact analysis become cumbersome.

Microservices Architecture

The core idea of microservices is that an application consists of many small, independent services that run in their own processes, have no deployment dependencies, communicate via lightweight mechanisms (e.g., RPC, HTTP), can be scaled independently, and may be implemented in different programming languages by separate teams.

Microservice Design Guidelines

Key design recommendations include:

Single Responsibility Principle – focus each service on a specific business capability.

Define the business scope early in the design phase.

Consider service size based on functional boundaries, not on arbitrary limits.

Keep service interfaces and message protocols simple, unlike complex SOA contracts.

Start with broader service boundaries and iteratively split them as the system evolves.

Microservice Messaging

In monolithic systems, components communicate via method calls or tightly coupled protocols. SOA often uses SOAP, which is heavyweight. Microservices prefer lighter mechanisms.

Synchronous Messaging – REST

Clients wait for a response; REST is the default synchronous style, using HTTP and resource‑oriented APIs.

Asynchronous Messaging – AMQP, STOMP, MQTT

Clients do not block; messages are delivered via protocols such as AMQP, STOMP, or MQTT.

Message Formats – JSON, XML, Thrift, ProtoBuf, Avro

Microservices typically use simple text formats like JSON or XML, and binary formats like Thrift, ProtoBuf, or Avro when needed.

Service Contracts – Swagger, RAML, Thrift IDL

REST‑based services often describe APIs with Swagger or RAML, while non‑REST services (e.g., Thrift) use IDL specifications.

Microservice Integration (Inter‑service Communication)

Most microservices communicate via standard protocols (RPC, HTTP, JSON). Integration can also use lightweight message buses or API gateways.

Point‑to‑Point

Each service exposes a REST API and calls others directly.

While feasible for simple scenarios, this approach becomes hard to maintain as the system grows.

API‑Gateway

All clients and consumers access microservices through a unified gateway that handles non‑functional concerns (security, monitoring, rate limiting) and routes requests to the appropriate services.

Provides a unified abstraction for service APIs.

Enables lightweight routing and format conversion.

Centralizes security, monitoring, and throttling.

Keeps individual services lightweight, focusing on business logic.

The API‑gateway pattern is currently the most widely adopted design in microservice architectures.

Message‑Broker

Asynchronous communication uses queues and topics; services publish messages to a broker and other services consume them, decoupling direct calls.

Typical protocols include AMQP, STOMP, and MQTT.

Data Decentralization

In monolithic systems, all modules share a central database. In microservices, each service owns its private database, inaccessible to other services, allowing independent technology choices (SQL, NoSQL, etc.).

Key points of data decentralization:

Each microservice persists its own business data.

Services can only access their own databases.

Cross‑service transactions must be coordinated via service calls, not direct database access.

Decentralized data reduces coupling and enables each service to use the most suitable storage technology.

Advantages of Microservice Architecture

Each service is simple and focuses on a single business function.

Loose coupling provides higher flexibility.

Teams can choose the best language and tools for each service.

Independent teams can develop services without affecting each other, accelerating time‑to‑market.

Facilitates continuous delivery, allowing frequent releases while keeping the rest of the system stable.

Disadvantages of Microservice Architecture

While conceptually appealing, practical implementation introduces complexity.

Increased operational overhead and cost due to many services, processes, and heterogeneous environments.

Requires strong DevOps skills and knowledge of diverse storage technologies.

Implicit interfaces and versioning create coordination challenges and higher release risk.

Potential code duplication across services.

Distributed‑system concerns such as latency, fault tolerance, serialization, and load balancing must be addressed.

Asynchronous programming and cross‑service transactions become more complex.

Testing and observability are harder in dynamic, distributed environments.

Choosing Microservices: Trade‑offs

When the project and team are suitable, the benefits outweigh the costs.

Recognize the challenges before adopting microservices.

Avoid adopting microservices for its own sake.

Start by applying selective microservice principles to existing systems rather than a full rewrite.

Contact

Author: Peng Lei

Source: http://www.souyunku.com/2017/09/17/MicroServices/

Email: [email protected]

All rights reserved; please credit the author when reproducing.

WeChat: Follow the public account “搜云库” for development technology research and knowledge sharing.