Microservices Architecture’s Influence on Team Organization
summary
Company OSS for telecoms builds a microservices stack (API gateway/AG proxy, ZooKeeper, Keycloak, REST) and splits UI into a separate team that supplies a contract. Two production wins: a German merger algorithm removes redundant transceivers using topology and population data; a Brazilian fiber planner reconciles planned vs observed multi‑state network data. Teams reorganize into product teams owning domain microservices, move QA into teams, enforce stateless scalable packages and ops checks including static analysis. Warns of data consistency issues, heavy communication overhead, and a suggested 30 developers threshold before adopting microservices.
AI-written summary · about
chapters (15)
- 0:00Intro
- 1:15Telecommunications business
- 2:07Comarch OSS Network Planning
- 5:17Architecture
- 6:43Long, long time ago...
- 7:41Teams v 1.0
- 8:47Production Process vs teams
- 13:59Problem solving
- 14:24Conways Law
- 15:05Goal
- 15:48Product = another dimension?
- 19:32Teams vs Ops
- 25:47Microservices are difficult
- 32:29Architects
- 33:51Teams vs Teams
related talks
46mWhy Cross-Functional Teams Build Better Microservices
01h 01mMicroservices Gone Wrong
52mMicroservices & the Inverse Conway Maneuvre
35mSeven years with microservices: a critical review
23mMicroservices Architectures: Agility vs Complexity
58mMicroservices and the Inverse Conway Manoeuvre
37mEvolutionary Architecture & Microservices
26mPros/Cons of Microservices