Continuously delivering containerized, highly available microservices
summary
Argues that moving a monolith into a few services (start with two or three services) succeeds if teams adopt container images (Docker), a messaging queue for asynchronous integration, centralized logging with correlation IDs, circuit breakers and automated pipelines for continuous delivery. Shows concrete tradeoffs: start small, instrument monitoring and alerts, expect eventual consistency via local replicated views (CQRS), and treat services as disposable — claim: it speeds delivery and is provable when pipelines and monitoring are in place.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:13What microservices are and are not
- 4:44Bounded context in DDD
- 6:30Microservice challenges
- 7:54Monitoring and logging
- 10:00Asynchronous integration
- 13:13Technology standards
- 15:22Why you don’t need to be Google or Netflix
- 16:48Docker and containerization
- 19:16Microservices and continuous delivery
- 22:08DevOps culture
- 24:38Team autonomy via bounded context
- 27:50Experimentation with microservices
- 32:28Service splitting guide
- 33:32Q&A
related talks
29mDevOps and Microservices Better Together
37mKnee Deep in Microservices
01h 08mWhy you should never build Microservices - and why we do it anyway
50mEmbracing Microservices
31mMicroservices and Docker at Scale: the PB&J of Modern Application Delivery
57mEmbracing Microservices
23mMicroservices and containers
01h 03mMicroservices: Decomposing Applications for Testability and Deployability