Plan Andrew-style microservice architecture and migration by checking whether microservices truly fit, cutting service boundaries around real business responsibilities, evolving systems incrementally instead of rewriting, and engineering platform, runtime, and delivery capabilities as first-class architecture. Use when deciding whether to adopt microservices, decomposing a monolith, planning migration, choosing shared infrastructure, containerizing services, or defining the CI/CD and operability baseline needed to run many services safely.
Plan Andrew-style microservice architecture and migration by checking whether microservices truly fit, cutting service boundaries around real business responsibilities, evolving systems incrementally instead of rewriting, and engineering platform, runtime, and delivery capabilities as first-class architecture. Use when deciding whether to adopt microservices, decomposing a monolith, planning migration, choosing shared infrastructure, containerizing services, or defining the CI/CD and operability baseline needed to run many services safely.
Andrew Microservice Architecture
Overview
Use this skill when the question is not only how to build one service, but how to shape the whole application and platform so multiple services can evolve, deploy, and operate safely together.
Microservices are not the goal. They are one way to solve maintenance, deployment, scaling, and organizational-fit problems. Start from the pain that justifies service boundaries, move in small steps, and only add infrastructure that the team can actually run.
Working Style
Write in Traditional Chinese when the user or repo context is Chinese.
Start from the business problem, maintenance pain, and team capability before proposing microservices.
Treat microservice architecture as a socio-technical design, not only a code decomposition exercise.
Align service boundaries with business flow and organizational responsibility, not only technical layers.
Cut only as far as the system gains real independence or operability.
Prefer refactoring and staged extraction over rewrite-from-scratch.
Use mature external services when they solve the problem better than custom code.
Treat API gateway, service discovery, messaging, logging, health, and deployment flow as part of the architecture, not afterthoughts.
Prefer container and packaging models that make start, stop, deploy, and rollback predictable.
Ask whether a capability needs runtime computation at all. If not, move it to build time or use simpler hosting.
Validate risky changes with focused spikes and runnable POCs before institutionalizing them.
Workflow
1. Problem Framing And Fit
Define the actual pain the architecture must solve:
maintenance cost
deployment friction
fault isolation
scale-out need
mixed hosting environments
team ownership boundaries
State why a monolith or modular system is not already sufficient.
Check whether the team has enough baseline capability in:
source control
build and release
monitoring
deployment automation
production diagnosis
Ask whether some parts of the system do not need runtime processes and should remain static or build-time generated instead.
2. Service Boundary And Responsibility
Identify candidate boundaries from real business or organizational seams.
Define each service by the one responsibility it should own end to end.
Prefer boundaries that improve deployability, operability, and ownership together.
Avoid over-splitting just because the code can be split.
Decide where technical heterogeneity is worth the operational cost.
Decide where a mature third-party service is better than a custom-built one.
Ensure each service can be understood as a meaningful capability, not only a thin technical wrapper.
3. Migration And Transitional Architecture
Do not rewrite everything from scratch unless there is a very strong reason.
Stop making the monolith larger before trying to split it.
Move upward through reuse levels deliberately:
source code
library
component
service
Modularize first if direct service extraction is still too expensive.
Use transitional glue code when it lowers migration risk, but treat it as disposable.
Choose the first cut by impact and feasibility, not by fashion.
Keep the system shippable while the migration is in progress.
4. Platform Capability Plan
Decide which shared capabilities are required now and which can wait:
API gateway
service discovery
health check
communication and event system
centralized log or trace
configuration management
For service discovery, define:
registration
query
health signal
metadata or tags
Choose control style deliberately:
client-side discovery for maximum caller control
server-side discovery for centralized routing and lower client intrusion
Plan how internal and external traffic will be routed without exposing unnecessary internal topology.
Use service metadata when workload tier, region, or SLA class must affect routing.
5. Runtime And Hosting Model
Design the runtime topology, not only the code topology.
Decide which roles exist around one capability, such as:
public API
worker
scheduler
reverse proxy
SDK
Choose hosting style based on lifecycle control, not habit.
In containerized environments, prefer runtime models that let the service control its own startup, shutdown, health, and deregistration precisely.
Treat one process per container as the default unless there is a clear reason not to.
Let orchestration handle restart, placement, and scaling instead of duplicating those concerns inside each service host.
Keep storage mounts, ports, health probes, and startup dependencies explicit.
6. Delivery And System-As-Code Model
Decide the minimum reliable delivery flow before buying more tooling.
Keep these foundations in place:
version control
automated build and tests
artifact management
release management
Use package feeds or image registries as the release backbone.
Do not let developer laptops become the source of production deployment artifacts.
Keep branch strategy only as complex as the release process needs.
Treat deployment definitions, routing rules, templates, static site generation, and operational scripts as source-controlled code.
If a capability can be rendered ahead of time, prefer static output plus simple hosting over a permanent runtime service.
7. POC And Incremental Validation
Run spikes for the risks that could sink the migration, such as:
API compatibility
packaging and deployment
service discovery integration
container lifecycle behavior
external-service replacement
mixed cloud or on-prem hosting
Prefer runnable slices over slideware.
Validate both architecture fit and team operability.
Fail early in the POC stage, not after the organization is already committed.
8. Evaluation
Compare candidate architectures by:
reduced maintenance complexity
deployment independence
operational simplicity
platform fit
team skill fit
migration risk
long-term extensibility
Prefer the design that solves the current pain without forcing premature infrastructure complexity.
Name which later signals would justify more splitting, more platform investment, or rollback to a simpler approach.
Design Checks
Revisit the plan if microservices are proposed without a clearly named pain they solve.
Revisit the boundary if the cut follows technical layers but not business or team ownership.
Revisit the split if a service cannot operate independently enough to justify being a separate service.
Revisit the migration if rewrite is being chosen only because the old code is unpleasant.
Revisit the platform plan if the infrastructure list is larger than the team's operational ability.
Revisit the runtime model if service registration, shutdown, and health cannot be aligned with process lifecycle.
Revisit the build-vs-run decision if a service exists only to serve mostly static or precomputable content.
Revisit the delivery model if production artifacts can still be created ad hoc from a developer machine.
Revisit the architecture if every problem is being solved by custom code even when mature services already exist.
Default Output Shape
When the user asks for microservice architecture or migration design, respond in this order unless they request another structure:
Problem Analysis
Microservice Fit
Service Boundaries
Migration Strategy
Platform Capabilities
Runtime And Hosting Model
Delivery And Operability Model
POC
Evaluation
Risks And Refactor Triggers
Use these expectations for each section:
Problem Analysis: define the current pain, constraints, and organizational context.
Microservice Fit: state why microservices are or are not justified now, and what entry conditions matter.
Service Boundaries: define candidate services, responsibilities, autonomy, and build-vs-buy decisions.
Migration Strategy: define extraction order, transitional glue, compatibility boundaries, and how to keep shipping.
Runtime And Hosting Model: define roles, container or host model, lifecycle control, and health behavior.
Delivery And Operability Model: define source control, CI/CD, artifacts, registry usage, and static-vs-runtime decisions.
POC: propose the smallest validation slices that prove technical and operational feasibility.
Evaluation: compare options and state the recommendation.
Risks And Refactor Triggers: name what scale, org, or reliability changes would force the next architectural step.
References
Read references/microservice-fit-and-boundary-principles.md when the task is about whether microservices fit, where to cut boundaries, autonomy, technical heterogeneity, or why over-splitting is dangerous.
Read references/microservice-evolution-and-build-vs-buy-principles.md when the task is about staged migration, modularize-then-serviceize strategy, transitional glue code, mature third-party service adoption, or avoiding hype-driven rewrites.
Read references/microservice-platform-and-discovery-principles.md when the task is about API gateways, service discovery, registry patterns, service metadata, internal routing, health checks, or messaging infrastructure.
Read references/container-driven-runtime-principles.md when the task is about container-driven design, runtime roles, self-host vs IIS-style hosting, service lifecycle control, or health and shutdown behavior.
Read references/delivery-and-system-as-code-principles.md when the task is about CI/CD baseline, artifact and package management, infrastructure or site definitions as code, or replacing unnecessary runtime systems with static generation and simpler hosting.
Keep article-specific notes in references/.
Promote only stable cross-article guidance back into this SKILL.md.
