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

API Contracts and Version Drift

Contract artifacts to collect

Drift categories

Compatibility analysis workflow

1. Export runtime schema (gateway, mesh, reflection) where allowed. 2. Diff against published contract (git tag or registry version). 3. List consumers per API version (mesh, logs, client SDK repos). 4. Classify changes: safe additive, deprecated, breaking. 5. Note missing deprecation headers, sunset dates, or consumer outreach.

Breaking-change consumer map

Unknown consumers → flag as discovery gap (tracing, gateway logs, static search).

Version skew across estate

Check:

• Mobile/web clients pinned to old API versions
• BFFs calling deprecated internal routes
• Event schema versions mixed in one topic
• Feature flags masking half-migrated contracts

Contract testing maturity

Recommend target level per tier-0 API—not blanket level 3 everywhere.

API gateway and mesh signals

• Routes pointing to retired services
• Timeout/retry defaults masking failures
• Rate limits absent on tier-0 paths
• mTLS identity mismatch between documented and actual callers

Deliverables

• Drift report per service (summary + diffs)
• Consumer compatibility matrix
• Deprecation backlog with owners and dates
• Standardization gaps for platform (lint rules, registry) → platform-engineer

Handoffs

• Greenfield versioning strategy (not estate audit) → microservice-researcher
• Implementing registry, breaking-change CI → senior-software-engineer, microservices-developer

Consolidation, Risk, and Recommendations

Risk hotspot taxonomy

Blast-radius analysis

For tier-0/1 paths:

1. Trace failure propagation (sync retries, circuit breakers absent?). 2. List shared infrastructure (DB, cache, broker cluster, identity provider). 3. Identify secrets reused across services. 4. Score maximum concurrent impact (users affected, $ at risk if known).

Output: top 5 shared-fate nodes with mitigation options (isolate, replicate, degrade gracefully).

Consolidation candidates

Recommend merge or retire when evidence shows:

Each item needs: effort (S/M/L), risk, dependencies, rollback.

Strangler and decomposition triggers

Analyst defines where to cut; researcher defines how and options.

Recommendation record template

## REC-001: [Short title]
- **Type:** consolidate | retire | decouple | observability | security
- **Services affected:** ...
- **Evidence:** [metric, graph edge, incident ID, contract diff]
- **Impact if unaddressed:** ...
- **Proposed action:** ...
- **Effort:** S/M/L | **Risk of change:** low/med/high
- **Owner:** team | **Dependencies:** REC-00x
- **Success metric:** ...

Prioritization matrix

Impact = customer/revenue/availability/security; adjust weights with stakeholders.

Executive summary (1 page)

1. Estate snapshot — service count, tier-0 count, map thumbnail 2. Top 5 risks — one line each with evidence pointer 3. SLO/observability gap — % tier-0 with full coverage 4. Contract drift — count of breaking/unknown consumers 5. 90-day focus — 3–5 REC items with owners 6. Explicit non-goals — what this analysis did not cover

Program sequencing

Typical order:

1. Inventory + dependency map (facts) 2. Tier-0 SLO and critical-path traces (visibility) 3. Contract drift on external and payment paths (stability) 4. Shared DB and sync-chain remediation (architecture debt) 5. Consolidation/retire quick wins (cost/toil)

Peer handoffs

Coupling and Data Ownership

Coupling types (assess existing estate)

Shared-database smell checklist

Flag when two or more services:

• Write to the same relational schema or collection
• Share ORM models across repos
• Use DB views as integration API
• Bypass service APIs with direct SQL from another team's job

Document: which team owns the schema, migration process, and who approves cross-service queries.

Data ownership matrix

Gaps (no single writer) are P1 architecture debt until resolved or explicitly accepted.

Cyclic dependency detection

Cycles in sync call graphs (A→B→C→A) block independent deployment. Mitigations to recommend (not implement here):

• Introduce async boundary or read model
• Collapse cycle into one deployable temporarily
• Extract shared kernel with strict versioning

Library and platform coupling

Recommend contract-first artifacts (OpenAPI, events) over shared business libraries when drift is observed.

Change-risk scoring (lightweight)

Use scores to order remediation backlog—not as precise math.

Consolidation vs decomposition signals

Consolidate candidate when:

• Services always deploy together, share DB, low independent value
• Operational cost (on-call, pipelines) exceeds benefit of separation

Decompose candidate when:

• Single service owns unrelated aggregates with conflicting change rates
• Team cognitive load or incident frequency concentrated in one repo

Hand detailed boundary design to microservice-researcher after identifying the candidate.

Evidence to attach

• Call graph screenshot or export
• Schema ownership doc or migration history
• Incident tickets citing cross-team DB changes
• Deploy correlation (services released in lockstep)

Microservices Analyst — Scope

Role

Analyze existing microservice landscapes: what runs today, how services depend on each other, where operations hurt, and which changes reduce risk or cost. Output is assessment and prioritization, not greenfield architecture research.

Distinction from Microservice Researcher

Cross-link both skills when a program needs research then assessment, or assessment then targeted research on one boundary.

In scope

• Service and API inventory (name, owner, tier, repo, runtime, environments)
• Dependency and coupling analysis (sync chains, events, shared stores)
• Observability and SLO coverage gaps, alert quality, on-call load proxies
• Deployment and version skew across regions/clusters
• Contract drift (REST, gRPC, GraphQL, AsyncAPI) and consumer compatibility
• Operational toil indicators (manual steps, ticket themes, change failure signals)
• Security blast radius on critical paths (not full pentest—factual surface map)
• Consolidation / strangler / decomposition candidates with evidence

Out of scope

• Greenfield bounded-context design only → microservice-researcher
• Writing or shipping new microservices → senior-software-engineer, microservices-developer
• Cluster/node performance tuning without estate framing → cloud-engineer
• Dedicated load-test campaigns → performance-engineer
• Full penetration test or compliance attestation → penetration-tester, compliance-engineer

Stakeholders and deliverables

Required inputs (gather early)

• Service catalog or CMDB export (even partial)
• API gateways, service mesh, or ingress route lists
• APM/traces, metrics, logs retention pointers
• CI/CD deploy history per service (frequency, failure rate if available)
• OpenAPI/AsyncAPI/Protobuf repos or registry
• Recent incident themes and postmortems (redacted)
• Org chart or team-to-service mapping

Analysis phases

1. Bound the estate (product, env, region, namespace). 2. Inventory services, APIs, data stores, and owners. 3. Map dependencies and classify coupling. 4. Measure health (SLOs, deploys, drift, toil). 5. Recommend with evidence, effort, and owner handoffs.

Quality bar

• Every finding links to evidence (edge in graph, metric, contract diff, ticket count).
• Distinguish fact vs hypothesis; label confidence.
• Prefer actionable next steps with a single accountable team per item.

Observability, SLO, and Operational Health

Golden signals per service

For each tier-0/1 service, verify coverage of:

Mark gaps explicitly (e.g., "no traces on checkout→payment edge").

SLO coverage assessment

Produce a coverage matrix: service × {SLI defined, dashboard, alert, runbook, owner}.

Alert quality heuristics

Deployment and change health

Proxy metrics when formal DORA data exists:

Highlight version skew: multiple prod versions, stale sidecars, config drift between regions.

Operational toil indicators

Qualitative and quantitative themes:

• Manual steps in runbooks (scale, failover, data fix)
• Recurring ticket categories (quota, cert, cache flush)
• "Hero" on-call knowledge not in docs
• Frequent hotfix deploys outside pipeline

Summarize as toil themes with estimated engineer-hours/month if data exists.

Incident correlation

Map last 90 days (or available window):

• Incidents touching multiple services (shared fate)
• Repeat root causes (timeouts, DB locks, contract mismatch)
• Services with no incidents but no SLOs (unknown risk)

Operational health scorecard (example)

Grades drive narrative; define rubric in appendix for transparency.

Handoffs

• SLO program design, error budgets → site-reliability-engineer
• Load/latency deep dives → performance-engineer
• Platform observability standards → platform-engineer

Service Inventory and Dependency Analysis

Inventory template

Capture one row per deployable (service, worker, batch job with HTTP/gRPC surface):

Discovery sources

Dependency map rules

1. Node = deployable + major data store (if owned). 2. Edge = observed traffic (sync) or subscription (async); label protocol and direction. 3. Weight edges by RPS, error contribution, or business criticality when data exists. 4. Mark synthetic edges (config-only, no recent traffic) separately from active edges.

Dependency graph outputs

• System context (1 diagram): actors and top external integrations.
• Container/service map: all in-scope services with tier coloring.
• Critical path overlay: user-journey services highlighted.
• Fan-in / fan-out table: services with >N inbound or outbound deps (coupling smell).

Sync chain analysis

Document chains longer than 3 hops on tier-0/1 paths:

Client → BFF → Order → Inventory → Pricing → Legacy

For each chain record: p99 latency budget, timeout cascade risk, partial failure behavior, and idempotency gaps.

Zombie and orphan detection

Inventory quality checks

• [ ] Every tier-0/1 service has an owner and on-call
• [ ] Every external API has a contract pointer or "missing contract" flag
• [ ] Shared data stores list all writers (not just primary)
• [ ] Environments documented; prod-only deps called out

Handoffs

• Unclear domain boundaries for a hotspot → microservice-researcher
• Missing platform golden paths for standardization → platform-engineer
• Mesh/gateway misconfiguration remediation → infrastructure-engineer, cloud-engineer