Pivoting your Pipeline from Monolithic to Microservices
summary
Claims that a shift from monolithic CI/CD to a Kubernetes pipeline forces many small repos and hundreds or thousands of workflows, moves the compile/link decision to runtime, and requires runtime routing and versioning instead of build-time linking. Cites tools: Jenkins, Nexus/Artifactory, Helm, Ansible, Red Hat operators, and service mesh for persona routing. Notes operational pain: Netflix-style ~40,000 releases/day, “haunted” or Frankenstein clusters. Presents a concrete countermeasure: a config/version registry concept implemented as DeployHub to map microservice versions to logical applications.
AI-written summary · about
chapters (19)
- 0:00Intro
- 0:15Welcome
- 3:17Todays Common Practice
- 5:28One Workflow
- 6:09Waterfall
- 6:56Modern architecture
- 8:09What is a microservice
- 9:46The challenge with microservices
- 10:16The Hipster Store
- 12:18Where did our application go
- 14:00Linking the application at runtime
- 14:37Moving away from waterfall
- 15:04Service Mesh
- 16:26Deploy Hub
- 17:41Domain Driven Design
- 18:54Problem Solving
- 21:25Collaboration
- 23:27Configuration Mapping
- 24:59Segments
related talks
32mEvent-based Continuous Delivery: The End of the Monolithic Pipeline
45mBecoming a Plumber: Building Deployment Pipelines
37mKnee Deep in Microservices
40mMicroservice Continuous Delivery
41mThe Pipeline-Driven Organization
27mMicroservices Are ‘Easy’, Dependencies Are Hard
21mWhere’s the Application? Understanding the Challenge of Your Microservice CD Pipeline- 40mMicroservice Continuous Delivery