For boundaries drawn around teams, not diagrams
Microservices
Microservices solve a team scaling problem, and applying them without that problem just adds distributed systems complexity for no benefit. This practice draws boundaries around how your teams actually work. That might mean decomposing a monolith that blocks velocity, building services correctly from day one, or fixing operations that became painful after the fact.
How service boundaries actually get drawn
Around team ownership, not an idealised domain diagram.
90 secSample frame · video pending01Before drawing a single boundary
Microservices solve an organisational problem first.
The technical benefits are real but secondary. Four tests decide whether decomposition is actually warranted yet.
Are multiple teams blocked by one codebase?
If one team owns the whole system comfortably, microservices add operational cost without a team-velocity benefit to offset it.
Do different parts of the system scale differently?
Uniform load across a monolith rarely justifies the operational complexity of splitting it. Divergent scaling needs are a real signal.
Can your team operate distributed systems?
Tracing, service discovery and distributed debugging are real skills. Adopting microservices before the team can run them trades one problem for a worse one.
Is the monolith actually the bottleneck?
Sometimes the real problem is process, not architecture. A monolith with good module boundaries and clear ownership can move fast for years.
| Well-structured monolith | Microservices | |
|---|---|---|
| Team independence | Limited by shared deploy | High, if boundaries fit teams |
| Operational complexity | Low | Real, ongoing cost |
| Right for | Small teams, uniform scale needs | Multiple teams, divergent scale needs |
| Common failure mode | Becomes tangled without discipline | Boundaries drawn wrong, or too early |
02Agreed before extraction starts
The ledger that keeps decomposition honest
Microservices engagements fail when extraction happens without a clear ownership model. The ledger below pins the service boundaries we take on, the artefacts you receive, and the operational control that never leaves your side.
- Your side
You bring
- The monolith and its current team structure
- Where teams collide most often
- Any prior attempts at decomposition and why they stalled
- Our side
We build
- Service boundaries drawn around team ownership, not just code structure
- A staged extraction plan starting with the highest-friction area
- Contracts between services that let teams deploy independently
- Your side
You receive
- Extracted services teams can own and deploy alone
- A reduction in cross-team coordination overhead
- A pattern the remaining monolith can follow later
Never leaves you
- Team structure and reporting lines
- Product priorities across every service
- The pace of further decomposition
Where the line sitsService boundaries are drawn around how your teams actually work, not around an idealised domain model. A boundary nobody's team owns just becomes a second monolith.
03From boundary to independent deploys
Four stages, each closing on evidence
Decomposition done wrong creates a distributed monolith, which is worse than the original. This system closes every stage with something your teams can verify.
Map boundaries to team structure
Service boundaries are drawn around who actually owns each capability, not around an idealised domain model that ignores your org chart.
Boundaries drawn around ownershipDefine contracts first
Interfaces between future services are agreed before extraction begins, so teams can build against a stable contract rather than a moving target.
Contracts before extractionExtract in stages, prove each one
Each extraction runs behind the existing system until proven equivalent, so a bad boundary decision surfaces early and costs one stage, not the whole programme.
One boundary at a time, provenBuild observability in from the start
Tracing and correlated logging ship with the first extracted service, not retrofitted after the first 2am incident nobody could diagnose.
Operations that survive an incident
04What actually moves the number
Four drivers, priced from the estate
Microservices work is priced against the assessment, because these four factors change scope by multiples.
Coupling in the existing system
Tightly coupled code costs more to separate safely than a monolith that already has reasonable internal module boundaries.
Data ownership complexity
Shared databases across future service boundaries are usually the hardest part of decomposition, harder than the code itself.
Operational tooling maturity
Teams without existing observability infrastructure need that built alongside the services, which is real, separate effort.
Number of services and team count
More services means more contracts, more deployment pipelines and more operational surface area to build and maintain.
05Evidence and proof
Boundaries that made teams faster, not just distributed.
Microservices proof is team velocity and incident recovery time, not service count. Every record here waits for written client approval before production.
Explore case studies
A monolith split along team lines, not domain lines, in three waves.
Three product teams shared one deploy pipeline and blocked each other constantly. Boundaries drawn around team ownership let each team ship independently within two quarters.
- Deploy blocking incidents
- Reduced sharply
- Teams deploying independently
- 3 of 3
Distributed tracing that cut incident diagnosis from hours to minutes.
Aster North's services were already split, but debugging cross-service issues took hours of manual log correlation. Tracing infrastructure made root cause visible immediately.
- Incident diagnosis time
- Hours to minutes
- Services instrumented
- All production services
They told us two of our four proposed services should stay merged. That advice against more services was worth more than the extraction itself.
Sample · pending client approval
06Read this first
When microservices are the wrong architecture
Recommending decomposition to a small team with one deployable would cost us the engagement's real value and yours. The exits are marked plainly. Where microservices are justified, the work runs on Kubernetes, Docker, gRPC and message queues alongside your existing stack.
One team owns the whole system
If a single team ships comfortably today, the coordination problem microservices solve does not exist yet for you.
- Software architecture
The domain model is still unstable
Drawing service boundaries around a domain that is still being discovered locks in the wrong boundaries. Stabilise the model first.
- Team extension
You need platform engineers, not a redesign
If the boundaries are right and the gap is operational capacity, team extension adds hands without adding another redesign.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Boundary assessment | You need to know if decomposition is warranted | Whether to proceed | The analysis and recommendation |
| Staged decomposition | Boundaries are agreed and extraction can begin | Priorities and go decisions per stage | Extraction, contracts, operations |
| Team extension | Your leads own the architecture | Direction and standards | Named platform engineers |
07Straight answers
Asked before a decomposition programme starts.
01How do we know if we actually need microservices?
The honest test is whether multiple teams are genuinely blocked by sharing one codebase and deploy pipeline. If one team ships comfortably, microservices add real operational cost without the team-velocity benefit that justifies it.
02How do you decide where to draw service boundaries?
Around team ownership and genuine domain boundaries, discovered through mapping how work and data actually flow through your organisation, not from a generic reference architecture applied uniformly.
03Can you decompose a monolith without stopping feature work?
Yes, and that is the standard approach. Extraction happens in stages behind the existing system, so feature development continues while decomposition proceeds in parallel, not instead of it.
04What is monolith to microservices migration going to cost us in downtime?
Ideally none. Each extracted service runs in parallel with the existing path until proven equivalent, and cutover happens per service with a rehearsed rollback rather than a single risky migration event.
05Do you set up Kubernetes and service mesh for us?
Where warranted by your actual scale and team size, yes. Service mesh adds real operational complexity that many teams do not yet need, and the assessment says so plainly when that is the case.
06What does microservices consulting cost?
Priced against system coupling, data complexity and existing operational maturity from the assessment. A boundary assessment alone costs less than a full staged decomposition programme.
07Can you fix operational pain in services we already built?
Yes, this is a common entry point. Distributed tracing, better deployment tooling and service mesh adoption are frequently the actual need when teams already have services but operating them is miserable.