How To Build a Python Microservice Without Losing a Job
summary
Argues that microservice migration needs concrete choices not slogans and recommends starting with one or two platforms to avoid a polyglot epic zoo, showing specific Python stacks: Flask, Falcon, Tornado and containerizing with Docker. Recommends three concrete patterns to implement cross‑language concerns: sidecar for logging, ambassador for DB access, adapter for health checks, plus a service mesh for discovery and ACLs. Emphasizes investing in distributed tracing and logs (Datadog/New Relic) over clever short‑circuit hacks.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 0:35Premature Optimization
- 1:27Stage Zero
- 3:23Microservices
- 4:32Stacks
- 14:19Python
- 14:43Sidecar
- 14:56Sidecar Example
- 16:15Ambassador Location
- 17:27Adapter Location
- 17:49Adapter Example
- 19:00Functionality
- 19:50Network communication
- 20:15Service mash
- 23:49Questions
- 24:23Frameworks
related talks
34mPython Micro-service Architecture
44mPython in the MicroServices world
52mMicroservices: A Utopian Mystery
47mHitchhikers Guide to the Microservcies
39mConsidering Migrating a Monolith to Microservices?
33mLessons learned building Python microservices
43mGo micro with Microservices
54mThe Long Sad History of Microservices