Microservices Gone Wrong
summary
Company builds a second product from scratch with a 23→35 person team, moves from a half‑million‑line monolith with 600 database tables and ~1,150 cron jobs to a microservice platform using Tyco as an API gateway, RabbitMQ as an event store, Mesos/Marathon for containers and Zipkin/Data Dogg for ops. About 50 services appear in a year, deploys happen 4–5 times/day, local dev spin‑up takes ~15 minutes and nobody adopts it, unordered RabbitMQ events corrupt data, and the hard lesson is large services first, automate local dev, smoke test end‑to‑end.
AI-written summary · about
chapters (7)
- 0:00Start
- 6:42To Refactor? Or To Rebuild?
- 33:29Does this look familiar?
- 35:02What Was Built
- 43:07The Product Was Changing
- 46:07Service Calls Are Unreliable
- 53:03Managing complexity is vital to long-term success.
related talks
35mSeven years with microservices: a critical review
01h 00mMicroservices, Where Did It All Go Wrong?
55mMicroservices, Where Did It All Go Wrong
45mDesigning, building, testing and deploying microservices
44mMicroservices, Where Did It All Go Wrong
43mGo micro with Microservices
10mMicroservices, Messaging, and Failure: How Simplifying Our Architecture Saved Us
23mMICROSERVICES ARCHITECTURE AS IF YOU MEANT IT