Enabling Microservice Success • Sarah Wells & Sam Newman

Size of microservices should be based on team boundaries and domain context rather than arbitrary numbers - around 10 services per development team of 15 people is reasonable

Production readiness and operability are critical for microservice success - teams need proper monitoring, logging, runbooks and support processes in place

Out-of-hours support needs careful consideration - having formal rotas, clear expectations, and the ability to opt-out helps get developer buy-in

Service classification (Bronze, Silver, Gold, Platinum) helps prioritize which services need what level of support and resilience based on business criticality

Start with a monolith before moving to microservices - splitting too early before understanding domain boundaries leads to problems

Cultural and organizational aspects are as important as technical ones - team structure, operations capabilities, and developer experience matter

Standardization and guardrails help teams succeed - having common approaches for logging, monitoring, deployments reduces cognitive load

Change happens gradually - architectural transitions take time and teams may move at different paces

Testing in production is vital - synthetic monitoring and testing real flows provides more value than extensive pre-production testing

Having visibility into service health and compliance helps drive improvements - metrics and scorecards encourage teams to meet operational standards

Developer autonomy balanced with guardrails works better than strict standardization - let teams make choices within agreed boundaries