Lowering the risk of monolith to microservices
7 likes1,884 views
This document summarizes one organization's journey from a monolithic application architecture to a microservices architecture. It describes some of the pains of maintaining a monolithic application. It then discusses strategies for breaking the monolith into independently deployable microservices at low risk, including identifying module boundaries, deploying and releasing services independently, virtualizing data integration, and using traffic mirroring. The goal is to increase development velocity while lowering risk.
Ad
More Related Content
What's hot (20)
Similar to Lowering the risk of monolith to microservices (20)
Ad
More from Christian Posta (19)
Ad
Recently uploaded (20)
![Download Wondershare Filmora Crack [2025] With Latest](https://cdn.slidesharecdn.com/ss_thumbnails/neo4j-howkgsareshapingthefutureofgenerativeaiatawssummitlondonapril2024-240426125209-2d9db05d-250419-250428115407-a04afffa-thumbnail.jpg?width=560&fit=bounds)
Lowering the risk of monolith to microservices
- 1. LOWERING THE RISK OF MONOLITH TO MICROSERVICES One organization’s journey to microservices @christianposta Chief Architect, Cloud applications 8 May, 2018
- 2. Christian Posta Chief Architect, cloud application development Twitter: @christianposta Blog: http://blog.christianposta.com Email: [email protected] Slides: http://slideshare.net/ceposta • Author “Microservices for Java developers”, “Introducing Istio Service Mesh”, and other • Committer/contributor to open-source projects • Blogger, speaker, writer
- 5. @christianposta Low Risk “The existence of more than one possibility. The “true” outcome/state/result/value is not know” “A state of uncertainty where some of the possibilities involve a loss, catastrophe, or other undesirable outcome” - Douglas Hubbard
- 6. @christianposta Monolith An existing large application developed over the course of many years by different teams that provides proven business value. Its structure has eroded insofar it has become very difficult to update and maintain.
- 7. @christianposta Microservice A highly distracting word that serves to confuse developers, architects, and IT leaders into believing that we can actually have a utopian application architecture.
- 8. @christianposta Microservice A highly distracting word that serves to confuse developers, architects, and IT leaders into believing that we can actually have a utopian application architecture. An architecture optimization that treats the modules of an application as independently owned and deployed services for the purposes of increasing an organization’s velocity
- 9. @christianposta We can now assert with confidence that high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share. https://puppet.com/resources/whitepaper/2014-state-devops-report
- 12. @christianposta Goal We want to use microservices architecture, where it makes sense, to help speed up an organization’s development velocity while lowering the chances of bad things happening or being able to understand and recover quickly if it does.
- 13. MEET OUR CASE STUDY
- 15. @christianposta
- 16. @christianposta Some pain maintaining a monolith: • Making changes in one place negatively affects unrelated areas • Low confidence making changes that don’t break things • Spend lots of time trying to coordinate work between team members • Structure in the application has eroded or is non-existant • We have no way to quantify how long code merges will take
- 17. @christianposta Some pain maintaining a monolith: • Development time is slow simply because the project is so big (IDE bogs down, running tests is slow, slow bootstrap time, etc) • Changes to one module force changes across other modules • Difficult to sunset outdated technology • We’ve built our new applications around old premises like batch processing • Application steps on itself at runtime managing resources, allocations, computations
- 18. QUICK INTERLUDE: WHEN TO DO MICROSERVICES
- 19. @christianposta Microservices is about optimizing for speed
- 20. @christianposta So, do we microservices all the way down?
- 21. @christianposta Ask a very honest, and critical, question: Is our application architecture the bottleneck for being able to go faster?
- 22. @christianposta “No”, “Not really”, “Not yet”… then stop Go find out what is. Improve that. Then come back.
- 23. MEANWHILE…
- 24. @christianposta How do you break this thing up?
- 25. @christianposta Some ramblings… • Do one thing and do it well • Single responsibility principle • Organize around nouns • Organize around verbs • Bounded context • Products not projects • Unix philosophy
- 26. @christianposta Reminds me of yesteryear https://www.infoq.com/presentations/SOA-Business-Autonomous-Components
- 27. @christianposta Try one more time… • Identify modules, boundaries • Align to business capabilities • Identify data entities responsible for features/modules • Break out these entities and wrap with an API/service • Update old code to call this new API service
- 28. @christianposta Identify modules Break out API Rinse, repeat
- 29. @christianposta Generally good; misses a lot of detail!
- 30. @christianposta Try one more time… • Not easy to “re-modularize” a monolith • Tight coupling/integrity constraints between normalized tables • Difficult to understand which modules use which tables • We cannot stop the world to perform migrations • there will be some ugly migration steps that cannot just be wished away • there is probably a point of diminishing returns where it doesn’t make sense to break things out of the monolith
- 31. @christianposta Make sure… • You have test coverage for existing project (ie, passing tests, CI processes, etc) • Consider Arquillian for integration testing • Make sure you have some level of monitoring to detect issues / exceptions / etc • Have some level of black-box system tests in place / load testing (JMeter, Gattling) • Can deploy reliable to an environment (ideally OpenShift/ Kubernetes!) • Have some kind of CI/CD to be able to make changes economical
- 32. OUR MONOLITH
- 34. @christianposta Break out UI (if applicable)
- 35. @christianposta Deployment v release gives us flexibility
- 36. QUICK INTERLUDE: DEPLOYMENT VS RELEASE
- 37. @christianposta Decoupling deployment from release Here, we’ve deployed Orders v1.1 Orders v1.1 does NOT take traffic
- 38. @christianposta Decoupling deployment from release Here, we’ve begun a release of Orders v1.1 Using traffic control, we can direct a fraction of traffic to v1.1
- 39. Meet Istio.io http://istio.io An open-source service mesh @christianposta
- 41. @christianposta
- 42. MEANWHILE…
- 43. @christianposta Let’s call it backend now…
- 44. @christianposta Introduce a new Orders service
- 45. @christianposta Introducing new service API • We want to focus on the API design / boundary of our extracted service • This may be a re-write from what exists in the monolith • We should iterate on the API and share with our collaborators • We can stub out the service with Microcks/Hoverfly • This service will have its own data storage • This service will not receive any traffic at this point • Put in place “walking skeleton” to exercise CI/CD pipeline
- 46. @christianposta apicur.io for designing the API
- 48. @christianposta Shared data • New service will share concepts with monolith • We will need a way to reify that data within the microservice • The monolith probably doesn’t provide an API at the right level • Shaping the data from the monolith’s API requires boiler plate code • Could create a new API for the monolith • Could copy the data • Could connect right up (yuck!)
- 49. @christianposta Virtualize the data? • Focus on the new service’s domain model • Eliminate any boiler plate code • Read only virtual view of the monolith’s data • Read/write our own database, without changing data model • Part of a series of steps that ends with eliminating the virtual view
- 51. QUICK INTERLUDE: BOILERPLATE DATA INTEGRATION
- 54. @christianposta Set up Spring Boot
- 55. @christianposta
- 56. @christianposta
- 57. MEANWHILE…
- 58. @christianposta Mirror traffic to new service
- 59. @christianposta Mirror traffic to new service
- 61. @christianposta Mirror traffic with Istio
- 62. @christianposta Traffic compare/tap with Diffy https://github.com/twitter/diffy
- 63. MEANWHILE…
- 64. @christianposta Feature flags for runtime kill switch
- 65. @christianposta Async Change Data Capture with Debezium.io?
- 66. @christianposta Eliminate dependency on monolith DB
- 67. @christianposta Recap • Write lots of tests (for monolith if you can; especially new service) • Use advanced deployment techniques (canarying, tap compare, mirroring) • Use fine-grain traffic control to separate deployment from release • Reduce boiler plate code for data integration in initial service implementation • Use technical debt to your advantage • Have lots of monitoring in place • Leverage your deployment and release infrastructure to experiment and learn!
- 68. Quick demo? BTW: Hand drawn diagrams made with Paper by FiftyThree.com ☺ Twitter: @christianposta Blog: http://blog.christianposta.com Email: [email protected] Slides: http://slideshare.net/cepostaFollow up links: • http://openshift.io • http://launch.openshift.io • http://blog.openshift.com • http://developers.redhat.com/blog • https://www.redhat.com/en/open-innovation-labs • https://www.redhat.com/en/technologies/jboss-middleware/3scale • https://www.redhat.com/en/technologies/jboss-middleware/fuse