CONCEPT Cited by 1 source
Microservices migration¶
A microservices migration is the organisational and architectural transition from a monolithic codebase + shared database deployment model to many independently-deployed services owned by small teams. The migration is rarely a purely technical exercise — it cascades into team structure, on-call, release cadence, and observability requirements.
The cascading costs¶
Zalando's 2016 retrospective names the second-order costs directly. The move to the cloud and microservices meant:
- Teams become end-to-end responsible — design, develop, test, deploy, and operate. The majority of engineers were not experienced in the "operate" half. (Source: sources/2021-09-12-zalando-tracing-sres-journey-in-zalando-part-i)
- Service count grows faster than team headcount. The existing on-call rotation (5 teams for the monolith fleet) could not scale.
- Low standardisation across services — monitoring, alerting, deployment, and runtime conventions diverge per team. Responders now cover services they've never touched.
- Reliability gaps materialise — timeout defaults, circuit-breaker policy, retry strategy, overload handling all become per-team decisions made (often badly) under time pressure.
Why it drives SRE adoption¶
These second-order costs are what make microservices migrations a typical driver of SRE organizational evolution. Pre-migration, reliability can live implicitly in the monolith's shape + a small ops team. Post-migration, reliability is distributed across N teams and needs explicit investment — either as embedded SRE, shared primitives, or a dedicated department.
Seen in¶
- sources/2021-09-12-zalando-tracing-sres-journey-in-zalando-part-i — 2016 Zalando migration as backdrop for the first SRE attempt.