Microservices: Building for Change

The strongest case for microservices in most organisations is integration rather than greenfield development.

What microservices actually are

Microservices are small, independent, loosely coupled applications, each with its own codebase, each maintainable by a single small team.

The definition sounds like an architectural preference. It is really an organisational one — the point of the boundaries is that teams can build, deploy and change their own service without coordinating a release with everyone else.

The core benefits

• Independent deployment. A change to one service does not require the whole application to be released.
• Scalability where it is needed. You scale the service under load, not the entire system.
• Fault isolation. One failing service degrades one capability rather than taking everything down.
• Technology choice per service, so a new component is not constrained by a decision made a decade ago.
• Smaller, ownable codebases, which is what makes teams fast.

Where it fits with best-of-breed

The strongest case for microservices in most organisations is integration rather than greenfield development. Best-of-breed means running the best system for each function and accepting that they came from different vendors — which only works if they can be made to behave as one.

Service boundaries and APIs are how that is done: each system is wrapped and integrated through a defined contract, so replacing one later is a bounded piece of work rather than a re-platforming exercise.

Implementing it without regret

The sequence that works is deliberately conservative:

1. Start from the monolith, not from a blank page. Identify the parts that change most often or scale differently.
2. Define boundaries around business capabilities, not technical layers.
3. Extract one service, with its own data, and prove the pattern.
4. Build the operational base — deployment automation, monitoring, tracing — before there are twenty services rather than after.
5. Then continue, one boundary at a time.

Reporting across services without a monolith

Splitting a system into services creates a reporting problem: the data that used to sit in one database is now scattered across many. The fix is not to share databases between services — that recreates the coupling microservices were meant to remove — but to push data from each service into a data lake through the same APIs and event streams used for everything else.

Each service publishes its own data in a standard, agreed shape. An integration layer picks it up asynchronously, so a slow or failing report pipeline never blocks the service itself. From there, transformation and normalisation bring the data into a consistent model that a BI tool can sit on top of, giving one place to see the whole system rather than twenty different views.

Being honest about the cost

Microservices trade a complex codebase for a complex operating environment. Distributed systems bring network failure, eventual consistency, and debugging across service boundaries — problems a monolith simply does not have.

That trade is worth making when the constraint is release coordination between teams, or when parts of the system have genuinely different scaling needs. It is not worth making because the architecture is fashionable. A well-structured monolith beats a badly-bounded set of services every time.