Microservices, Monorepos, and the Efficient Build Processes
summary
Over 15 years the company moves from a monolith to 30+ services then back into a single consolidated repository to solve on‑prem release pain: CI becomes one pipeline that uses a monorepo with change-function to run only impacted builds, making quarterly on‑prem releases tractable; key rewrites are in Go for hooks and log ingestion with gRPC, Postgres and RabbitMQ, deployment on GKE, Helm and Replicated; result is faster builds, simpler onboarding, and a working on‑prem delivery workflow.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:03CI/CD infrastructure evolution
- 3:55Scaling challenges
- 7:45Microservices and Go
- 10:42Kubernetes stability
- 12:54Microservices benefits
- 16:27Independent deployments
- 18:12On-prem compliance
- 20:41Monorepo for releases
- 23:12Monorepo advantages
related talks
44mLooking back on migrating 30 microservices to a monorepository
40mMonorepo or Polyrepo: What's the Right Choice for You?
23mMicroservices within a Monolith
23mMicroservices – Sean Smith
47mMicroservices? Monoliths? An Annoying Discussion!
10mMicroservices, Messaging, and Failure: How Simplifying Our Architecture Saved Us
01h 01mMicroservices Gone Wrong
43mBreak Up the Monolith: Testing Microservices