When to run it
A part of the monolith - billing, notifications, search - that changes often, scales differently, or blocks other teams, and that nobody fully understands anymore.
Carve the module out.Keep the lights on.
Extracting a service from a legacy monolith
The playbook in one paragraph
A module inside the monolith needs to become its own service. Ana documents what the module really does, defines the contract, builds the service behind a strangler route, and proves parity before any traffic moves.
Works with
- The monolith repository
- Target runtime and framework
- API gateway or router for the strangler pattern
- Your CI/CD and IaC
What Ana needs from you
- Which module, and the target language/runtime
- Data ownership decisions (shared DB vs. owned store)
- Non-functional targets: latency, throughput, availability
How Ana runs it
Step by step.
5 steps from trigger to done - each one visible to your team as it happens.
- 01
Reverse-engineer the module
Ana maps every entry point, call site, table and side effect of the module and produces documentation and a sequence of how requests flow today.
- 02
Define the contract
Ana drafts the new service API from real usage, with the edge cases it found, for your architects to approve before any code is written.
- 03
Build the service
Ana scaffolds the service in the target stack, ports the logic, writes unit and contract tests, and adds the IaC and pipeline to deploy it.
- 04
Prove parity
Behind a strangler route, Ana compares old and new responses on the same inputs and reports every difference until there are none that matter.
- 05
Plan the cut-over
Ana proposes a staged traffic shift with rollback steps, and removes the dead code from the monolith once the new path is the only path.
Who approves what
Approval gates
- API contract
- Architecture review
- Each traffic increase
- Service owner
- Removing code from the monolith
- Monolith owners
What you get
Deliverables
- 01Module documentation and request flows
- 02Approved API contract
- 03The new service with tests, IaC and pipeline
- 04Parity report and cut-over plan
What usually goes wrong
And how Ana handles it.
Risk
Undocumented side effects
Ana traces writes, events and external calls, not just return values, before declaring parity.
Risk
Shared database coupling
Data ownership is decided up front and the plan reflects it - Ana does not silently split a schema.
FAQ
Common questions.
No. The strangler route lets traffic move in steps with a rollback at each one.
Keep going
Related playbooks.
Software
Upgrading a framework across dozens of services
A major framework or runtime version is going end-of-life and it touches every service. Ana plans the migration, upgrades each service in its own branch, fixes what breaks, and hands your team small, tested pull requests instead of one terrifying diff.
Read the playbook →Software
Burning down a stale bug backlog
Every team has a backlog of real but low-priority bugs that never win a sprint. Ana triages them, reproduces the ones that are still real, fixes them with tests, and closes the rest with evidence.
Read the playbook →Security
Turning a pentest report into merged fixes
A penetration test lands as a PDF with dozens of findings. Ana parses it, confirms which findings are reachable in your code and cloud, writes the fixes with regression tests, and hands the auditor evidence for every closure.
Read the playbook →See it in your stack
Run this playbook on your systems.
Thirty minutes, your repositories and cloud, one real instance of this job.