A Monolith, a Microservices, and a Function Walk into a Bar
summary
Claims that no single architecture is ideal and that incremental evolution matters and then shows a concrete pipeline: a missing‑people image platform built as a monolith running in Docker on three pods, the face‑encoding piece extracted to a microservice on Kubernetes and scaled independently (demo scales encoder to four instances), then an alert function deployed to KNative via Google Cloud Run that posts Slack messages; the live demo runs and validates the migration pattern and scaling benefits.
AI-written summary · about
chapters (12)
- 0:00Start
- 5:46Single Process
- 6:21Quick to Build
- 6:59Maintenance
- 7:50Proof of Concept / Prototype
- 9:00Flexible Design
- 9:57Complexity
- 10:47Many teams
- 12:27Cost Savings
- 13:20Vendor Lock In
- 14:00Event Based Architectures
- 19:37Find the seam
related talks
48mFrom Monolith to Micro-services with Kubernetes
33mFireside chat - Monoliths, Microservices & Modernization – Practical Strategies
31mMonolith to Microservices: A Guide to Seamless Transitions
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
45mThe Evolution From Monolith to Microservices to Serverless and Beyond
24mPatterns of Evolution from Monolith to Microservices
18mRe-Architecting Monoliths Into Kubernetes Microservices at Million-User Scale: Hard...
39mConsidering Migrating a Monolith to Microservices?