Practice : Microservices Architecture

Purpose and Strategic Importance

Microservices Architecture is a design approach where systems are built as a collection of independently deployable, loosely coupled services. Each service encapsulates a specific business capability and can be developed, deployed, and scaled independently.

This architectural style promotes team autonomy, scalability, fault isolation, and flexibility in technology choices. It supports continuous delivery by enabling rapid iteration with lower blast radius and more focused ownership.

Description of the Practice

  • Each microservice is responsible for a single domain or bounded context.
  • Services communicate via lightweight APIs (e.g. REST, gRPC, messaging).
  • Data ownership is decentralised - each service owns its data store.
  • Services are independently deployed and versioned, often with their own CI/CD pipelines.
  • Observability, service discovery, and resilience mechanisms are essential components.

How to Practise It (Playbook)

1. Getting Started

  • Identify domain boundaries using Domain-Driven Design (DDD) and map to service candidates.
  • Start small - carve out one service that can be isolated and independently deployed.
  • Define clear service APIs and contracts; avoid tight coupling to internal systems.
  • Establish CI/CD pipelines and observability tooling for each service.

2. Scaling and Maturing

  • Adopt service mesh, API gateways, and identity/access controls to manage communication.
  • Embrace patterns like event-driven architecture, eventual consistency, and circuit breakers.
  • Create platform capabilities (e.g. templates, monitoring, scaffolding) to support teams.
  • Track service health and quality metrics independently (e.g. latency, error rate, SLOs).
  • Regularly refactor services to manage growth, reduce complexity, or rebalance boundaries.

3. Team Behaviours to Encourage

  • Align teams with the services they own - empower autonomy and accountability.
  • Embrace “you build it, you run it” for each microservice.
  • Collaborate on API design and change management across service boundaries.
  • Treat inter-service dependencies as contracts - plan and version responsibly.

4. Watch Out For…

  • Too many services too early - avoid microservice sprawl.
  • Tight coupling via shared databases or hidden dependencies.
  • Inconsistent logging, tracing, or security practices across services.
  • High operational overhead from fragmented deployments without platform support.

5. Signals of Success

  • Services are owned, maintained, and evolved by aligned, cross-functional teams.
  • Delivery speed improves through independent deployments.
  • Failures in one service do not cascade across the system.
  • Teams feel confident evolving service boundaries based on real feedback.
  • System architecture mirrors the organisation’s business structure and needs.