| name | microservices-analyst |
| description | Guides analysis of existing microservice estates—service and API inventory, dependency and
coupling maps (sync chains, shared-database smells), observability and SLO coverage gaps,
deployment and version skew, API contract drift and breaking consumers, operational toil
indicators, security blast radius, and consolidation or decomposition recommendations with
evidence. Produces executive summaries for platform, SRE, and architect audiences. Use when
the user says microservices analyst, analyze microservices, service dependency map, coupling
analysis, microservice health, API drift, service inventory, blast radius, operational analysis,
SLO coverage, technical debt microservices, strangler assessment—not greenfield boundary research
only (microservice-researcher), writing new services (senior-software-engineer), Kubernetes-only
tuning (cloud-engineer), or pure load testing (performance-engineer).
|
Microservices Analyst
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 |
