Migrating a monolith to Cloud-Native and the stumbling blocks that you don’t know about
summary
Company migrates by containerizing apps and then discovers costs rise and complexity explodes: containers land on Kubernetes/OpenShift/Nomad but the Java monolith is simply stuffed as a war file in Java Docker so a Java scheduler runs inside a pod and causes one node hit 99.99% utilization. Teams double up on load balancers and schedulers, CI/CD is often missing, rotating one engineer per sprint speeds cross-team knowledge, and cloud credit lock‑in inflates OpEx.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:53Why migrations fail
- 3:59Containers vs VMs myth
- 5:47Pre-migration questions
- 7:32Architectural changes needed
- 9:35Cultural shift challenges
- 11:39Redundant systems
- 13:43Automation complications
- 15:29Microservices scale
- 16:30Debugging outages
- 17:34Cultural shift
- 18:59CI/CD trust issues
- 20:02True collaboration
- 21:27Monitoring visibility
- 21:49Economic impact
- 22:30Open source reliance
- 23:11Avoid cloud-native
related talks
31mMigrating a monolith to Cloud-Native (and the stumbling blocks)
34mFrom monolith to Cloud Native
44mMigrating a Monolith to Kubernetes
43mFrom a legacy monolith to a scalable SaaS application
50mJourneys To Cloud Native Architecture: Sun, Sea & Emergencies
36mPractical Cloud Native: What Works, What Doesn't
46mIt Doesn't Always Have to Be Kubernetes
53mFrom Legacy to Cloud Native, Without Kubernetes