When to Use
- Inventory an existing microservice estate (services, APIs, owners, runtimes, repos)
- Map dependencies and coupling (sync call chains, fan-in/out, shared DBs, shared libraries)
- Assess observability and SLO coverage, alert quality, and on-call pain per service
- Find deployment and version skew (stale images, drifted configs, multi-version consumers)
- Detect API and contract drift (OpenAPI/AsyncAPI vs reality, breaking consumers, schema lag)
- Quantify operational toil (manual runbooks, ticket volume, change failure rate proxies)
- Score security blast radius (critical paths, over-privileged service accounts, secrets sprawl)
- Recommend consolidation, strangler slices, or decomposition with evidence—not opinion alone
- Deliver platform/SRE/architect summaries with prioritized hotspots and next owners
When NOT to Use
- Greenfield boundary research, bounded contexts, or ADR options only →
microservice-researcher - Implement or refactor production service code, handlers, or deployables →
senior-software-engineer,microservices-developer - Kubernetes cluster ops, node tuning, or cloud landing zones without estate analysis →
cloud-engineer,infrastructure-engineer - Pure load-test design and execution without estate-wide dependency context →
performance-engineer - Broker/outbox implementation or stream processing build →
event-driven-architecture - Enterprise portfolio strategy unrelated to operational estate health →
enterprise-strategist
Related skills
| Need | Skill |
|---|---|
| Greenfield decomposition, strangler research, ADR options | microservice-researcher |
| Estate-wide ADRs, C4, cross-system NFR sign-off | senior-system-architecture |
| IDP, golden paths, paved roads for remediation | platform-engineer |
| SLO design, error budgets, incident and on-call programs | site-reliability-engineer |
| Load testing, latency tuning, capacity experiments | performance-engineer |
| Event contracts, brokers, outbox (when building fixes) | event-driven-architecture |
| IaC, cluster delivery, cloud foundations | infrastructure-engineer, cloud-engineer |
| Service implementation and twelve-factor deployables | senior-software-engineer, microservices-developer |
| Rollout, cutover, and rollback tactics for remediation | deployment-strategist |
Core Workflows
1. Scope the estate and stakeholders
Define analysis boundary (product line, region, cluster namespace, business capability), data sources, and audience (exec brief vs engineering backlog). List non-goals and hand off greenfield design to microservice-researcher when appropriate.
See references/microservices_analyst_scope.md.
2. Build service inventory and dependency map
Catalog services, APIs, events, data stores, owners, and environments. Produce dependency graph with sync/async edges, critical paths, and orphan or zombie services.
See references/service_inventory_and_dependency_analysis.md.
3. Assess coupling and data ownership
Flag chatty sync chains, cyclic dependencies, shared-database antipatterns, and unclear aggregate ownership. Tie findings to change risk and test burden.
See references/coupling_and_data_ownership.md.
4. Review observability, SLOs, and operational health
Map golden signals and SLO coverage per tier-1 service; note alert noise, missing traces, and deployment frequency vs incident correlation.
See references/observability_slo_and_operational_health.md.
5. Audit API contracts and version drift
Compare published contracts to runtime behavior; list breaking consumers, deprecated fields still in use, and skew across regions/clusters.
See references/api_contracts_and_version_drift.md.
6. Prioritize risks and recommendations
Synthesize consolidation candidates, strangler slices, decomposition triggers, and security blast-radius hotspots with evidence links. Close with executive summary and owned next steps.
See references/consolidation_risk_and_recommendations.md.
Principles
- Analyze what exists—inventory and metrics before recommending new boundaries
- Evidence over opinion—every hotspot cites a dependency edge, metric, contract diff, or incident pattern
- Separate research from remediation—hand greenfield ADRs to
microservice-researcher; implementation to engineering peers - Tier services—not every pod deserves the same SLO depth; focus tier-1 paths first
- Make blast radius visible—critical paths and shared fate drive prioritization
When to load references
| Topic | Reference |
|---|---|
| Scope, inputs, deliverables | references/microservices_analyst_scope.md |
| Inventory and dependency mapping | references/service_inventory_and_dependency_analysis.md |
| Coupling and data ownership | references/coupling_and_data_ownership.md |
| Observability, SLOs, ops health | references/observability_slo_and_operational_health.md |
| Contracts and version drift | references/api_contracts_and_version_drift.md |
| Consolidation, risk, recommendations | references/consolidation_risk_and_recommendations.md |