Microservices Analyst

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

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