193 Easy Steps to DevOpsing Your Monolith
summary
Ticketmaster recounts a failed 2015 rewrite and then describes a multi‑year effort to evolve the core ticketing monolith rather than replace it, using Wardley maps to move the transaction engine from custom snowflake toward commodity utility. Specifics include killing in‑platform chat, treating compute as repeatable services, keeping legacy experts as roaming SMEs advising customers, and the verified‑presale work that required diverting engineering effort to new features while preserving reliability. The goal is more architectural space to build relationship services on top.
AI-written summary · about
chapters (13)
- 0:00Introduction and 193 steps
- 1:29Ticketmaster’s rewrite attempt
- 3:13Service pivot and relationships
- 5:24Monolith evolution and history
- 7:12Enabling relationships over transactions
- 10:03Wardley mapping explained
- 12:56Industry vs internal mismatches
- 15:27Moving components to commodity
- 16:52Evolving people and processes
- 19:41Mapping processes like technology
- 21:26Maintenance vs metabolizing new info
- 22:52Respect for legacy systems
- 24:45Q&A
related talks
36mDoubling Down on DevOps: Global Transformation at Ticketmaster
28mDevOps in the Enterprise: A Transformation Journey
23mDevOps and Legacy Code
31mDOES14 - Shakeel Sorathia - Ticketmaster
01h 01mStrangling The Monolith: Applied Patterns & Practices From The Trenches
44mVax to K8s: Ticketmaster's Transformation to Cloud Native Devops
28mMy Monolith is Melting: Lessons from Legacy
30mKeeping Your DevOps Transformation from Crushing Your Ops Capacity