Microservices
Microservices explained
A shop wants to develop its product search while keeping ordering stable. Separate services may help. Splitting software into many small programs is not enough, however: business responsibilities must be capable of genuinely independent development.
Microservices communicate through defined interfaces. A service can be changed or scaled separately when its dependencies permit. If one service fails, the others need to handle that condition. Distribution does not prevent errors; it changes where they occur and how they are investigated.
For a smaller application, a well-structured shared codebase may be more appropriate. Identify which capabilities actually need separate release cycles, capacity or teams. More services do not automatically mean less effort. Several purchased tools do not, by themselves, constitute a coherent microservice architecture.
Our Creative Engineering criterion is the usable whole. An elegant search service offers little value if prices become inconsistent on the way to the basket. Assess architecture through complete journeys, clear ownership and understandable costs. Automation supports development and testing without replacing that responsibility.
Examples
Hypothetical application
A retailer separates product search from ordering. Before release, the team checks not only search results but outdated product data, timeouts and the handover to the basket. Only after these conditions are handled appropriately can the value of separate changes be assessed.
Key Points
- Define services around business capabilities.
- Independent deployment must work in practice.
- Plan for failures, data consistency and overall operation.
Practical application
Choose a capability with a clear need for change. Compare the of separation with additional interfaces, tests and operating tasks.
Useful measures
Ability to change
Check whether a capability can change without a coupled whole-system deployment.
Journey reliability
Measure complete user journeys, including partial failures.
Overall operation
Record support, troubleshooting, infrastructure and coordination effort.
Common mistakes
- Using service count as a measure of quality.
- Leaving dependencies and data handovers until after construction.
- Promising fixed time or cost savings without a project comparison.
Sources and context
- Microsoft: Microservices architecture
Explains independently deployable services and the additional complexity of distributed systems.
Frequently Asked Questions about Microservices
No. The appropriate architecture depends on the task, team and change requirements. A manageable shared application can be simpler to operate.
Only with consideration for interfaces, data and dependencies. A replacement still needs to meet the required agreements.
Whether a specific capability really needs independent changes, and whether the team can handle the additional operations and coordination.
Related links
Loading related terms…
All TermsArticles about Microservices
Marketing as an Operating Discipline: Why Almost Every CMO Talks About AI and Few Have Built It
The gap between intent and execution is not a technology problem, it is an operating model problem. How to move marketing from a project organisation to an operating discipline with systems, roles and cadence.
GEO in practice: Customer questions and evidence
A practical GEO review: choose customer questions, check content gaps and technology, add evidence and assess suitable enquiries.
AI as a Conversation Partner
When people ask AI for advice, it's not about technology – it's about trust. What brands should learn from this.