Migrating a monolith to Cloud-Native and the stumbling blocks that you don’t know about.
summary
Claim: simply stuffing a war file in a container and pushing to Kubernetes is not cloud‑native — it raises OPEX and leaves you not using schedulers, ingress, or autoscaling. The real path is replatform → repackage into microservices → refactor with the strangler pattern. Concrete gotchas: a Java app with a scheduler inside pod causes node hotspot until refactored; hardware load‑balancers become redundant once ingress replaces F5; expect to build CI/CD, shared contracts, advanced monitoring, and cross‑team rotation to remove tribal knowledge.
AI-written summary · about
chapters (14)
- 0:00Introduction to migration
- 1:09Why containerization fails
- 3:39Who containerized your app
- 5:45Where to deploy your app
- 7:33Repackaging into microservices
- 8:39Refactoring with strangler pattern
- 9:41Architectural advantages
- 11:47Scheduling and load balancing
- 14:33Complexity and automation
- 15:56Debugging as murder mystery
- 17:23Cultural shift and collaboration
- 19:50Visibility and monitoring
- 20:56Economic impact of OPEX
- 22:20Tangible next steps
related talks
30mMigrating a monolith to Cloud-Native and the stumbling blocks
46mIt Doesn't Always Have to Be Kubernetes
53mFrom Legacy to Cloud Native, Without Kubernetes
53m(Mis)Understanding Cloud Native
09mThe cloud native elephant in the room
45mThe Ultimate Checklist to Make Your Applications Cloud Native
30mApplication Modernization Using Cloud Strangler Pattern and DevOps Best Practices
14mEverything Worked Before Kubernetes