Microservices
Microservices are an architectural style in which an application consists of many small, business-aligned services. Each service is developed, deployed and scaled independently and communicates with the others via defined interfaces. Microservices increase flexibility and scalability — at the price of significantly higher operational complexity.
Characteristics of a microservices architecture
- Business-aligned decomposition: The services follow business domains — in the sense of domain-driven design (DDD) and bounded contexts — not technical layers.
- Own data ownership: Each service owns its data; other services access it only via interfaces.
- Independent deployment: Each service can be released individually — typically as a container (Docker) on an orchestration platform (Kubernetes) with automated CI/CD pipelines.
- Communication via APIs and events: synchronously via REST or gRPC, asynchronously via event streams (such as Kafka).
- Team autonomy: Small teams own their services end-to-end — from development to operations.
Microservices vs. monolith: the honest trade-offs
| Criterion | Monolith | Microservices |
|---|---|---|
| Deployment | one artifact — every change is a full release | services can be released individually, short release cycles |
| Scaling | only as a whole | targeted per service, according to actual load |
| Team organization | coordination on shared code required | autonomous teams with clear service boundaries |
| Consistency & transactions | simple — one database, local transactions | distributed data, eventual consistency, complex error handling |
| Operations & debugging | manageable | distributed system: observability, network latency, new failure patterns |
| Entry costs | low | high — container platform, automation and monitoring are prerequisites |
The table shows: microservices trade development and scaling flexibility for operational complexity. Those who do not have the necessary infrastructure or do not want to build it get the disadvantages without the advantages.
Microservices in legacy modernization
A common use case is the incremental untangling of grown monoliths — for example from outdated Java EE (EJB), C++ or .NET Framework — into cloud-native architectures. The strangler fig pattern has proven itself here: the new system grows around the old one and replaces it function by function, without a risky big bang; already migrated services deliver value immediately.
The most important pitfall is the wrong decomposition: those who split the monolith along technical rather than business boundaries end up with a distributed monolith — separately deployed but tightly coupled services, where every change affects several services. The domain decomposition is therefore the actual architectural work, not the technology.
Microservices in practice: when the monolith is the better choice
Microservices pay off when individual functions need to scale independently, many teams work in parallel or different release cycles justify the additional effort. For small teams and manageable domains, a well-structured, modular monolith is often the more economical choice — and with cleanly drawn module boundaries, later decomposition remains possible. In our experience, the right question is not “monolith or microservices?”, but: where do the business boundaries run — and which of them really need independent deployments?