The Journey from Monolith to Microservices: a Guided Adventure
3 likes2,381 views
The document provides a guide on migrating from monoliths to microservices, discussing the necessary steps, goals, and considerations throughout the process. Key steps include validating client behavior, understanding bounded contexts, breaking out components, and promoting the first microservice, all while managing the complexities that come with distributed systems. It emphasizes designing systems for scalability and flexibility, allowing multiple teams to deliver business value quickly.
The Journey from Monolith to Microservices: a Guided Adventure
- 1. MONOLITH -> MICROSERVICES A GUIDED ADVENTURE @MIKEGEHARD, @PIVOTAL
- 2. ABOUT ME ▸ Working with clients to migrate legacy monoliths -> microservices ▸ Worked on the Spring Cloud Services team ▸ Trying not to be a Chief Principal Senior Consultant Scientist
- 3. ABOUT YOU ▸ Have a monolith that needs migrating? ▸ Actively migrating a monolith? ▸ Building microservices net new? ▸ This talk has a little bit for all of you…
- 4. AGENDA ▸ Where did these ideas come from? ▸ Which comes first? ▸ What is the path?
- 5. BACKGROUND
- 11. THIS SHOULD NOT BE REVOLUTIONARY
- 15. IT DEPENDS…
- 17. MODULAR MONOLITH
- 18. IF YOU CAN’T BUILD A WELL STRUCTURED MONOLITH, WHAT MAKES YOU THINK YOU CAN BUILD A WELL STRUCTURED SET OF MICROSERVICES? UNKNOWN TEXT
- 20. BOUNDARIES?
- 21. BOUNDED CONTEXTS
- 22. 2003 2013
- 23. SOUND FAMILAR?
- 24. HOW DO I GET THERE?
- 26. GOALS ▸ Migrate a monolith that was in production, making money, to a more sustainable solution for the future. ▸ Architect for scalability of app in the future. ▸ Allow multiple teams to deliver business value quickly. ▸ Allow for addition of resources without overcrowding.
- 27. CURRENT STATE ▸ API servers ▸ Multiple clients, including JavaScript front end ▸ Some dead code ▸ Lack of comprehensive, current API tests
- 32. GOAL: VALIDATE YOU DON'T BREAK ANY CLIENT FACING BEHAVIOR WHILE MIGRATING STEP 1: API LEVEL TESTS
- 34. DESIRED END STATE CLIENT CLIENT CLIENT CLIENT OLD API OLD API OLD APIOLD API
- 38. RESULT: YOU NOW KNOW WHEN YOU HAVE BROKEN USER FACING BEHAVIOR BEFORE YOU GO INTO PRODUCTION
- 39. GOAL: BEGIN TO UNDERSTAND WHAT BOUNDED CONTEXTS EXIST STEP 2: ARRANGE APPLICATION SO YOU CAN SEE YOUR DOMAIN
- 42. STEP 2: ARRANGE APPLICATION SO YOU CAN SEE YOUR DOMAIN ▸ Minimizes the number of directories where changes happen. ▸ Less costly to experiment with/evolve bounded contexts. ▸ Delaying architecture decisions.
- 43. GOAL: GIVE MORE SPACE IN THE CODEBASE AND SOLIDIFY DEPENDENCIES/BOUNDARIES. STEP 3: BREAK OUT COMPONENTS
- 46. WHAT ABOUT DATABASES? ▸ Application manages? ▸ Component manages? ▸ “It depends…”
- 47. RULE: MIGRATIONS ONLY TOUCH ONE TABLE.
- 48. WHY?
- 49. STEP 3: BREAK OUT COMPONENTS ▸ More room in the codebase for multiple teams. ▸ Strict boundaries between framework code and domain code. ▸ Moving closer to microservices without the overhead of multiple processes. ▸ Stopping here gives you a lot of benefits without overhead of microservices.
- 50. GOAL: IT DEPENDS… STEP 4: PROMOTE YOUR FIRST MICROSERVICE
- 51. WHY EXTRACT A MICROSERVICE? ▸ Scaling a certain bounded context becomes an issue. ▸ You want to deploy one bounded context more frequently. ▸ Many, many other reasons that I won’t cover here.
- 53. WHY NOT EXTRACT A MICROSERVICE? ▸ Cost of managing the service outweighs the benefits. ▸ Dysfunctional communication patterns in the org ▸ Many, many other reasons that I won’t cover here.
- 54. BILLING EMAIL
- 55. BILLING EMAIL
- 56. STEP 4: EXTRACT YOUR FIRST MICRO SERVICE ▸ Congratulations you now have a distributed system!!! ▸ And with that distributed system come new costs: ▸ Billing now needs to know how to contact the email service. ▸ Network communication between billing and email will fail at some point.
- 57. GOAL: ABSTRACT LOCATION AND QUANTITY OF SERVICE INSTANCES SERVICE DISCOVERY
- 59. SERVICE DISCOVERY ▸ Service calls are most loosely coupled to location and number of instances. ▸ Client side load balancing can reduce number of network calls. ▸ But there is an additional applications to run and monitor.
- 60. GOAL: PROTECT AGAINST CASCADING FAILURES THAT CAUSE SYSTEM DOWNTIME CIRCUIT BREAKER
- 63. CIRCUIT BREAKERS ▸ Increased resiliency of system when the network or a service fails...because they will. ▸ Increased visibility of health of system as a whole. ▸ But there is an additional applications to run and monitor.
- 64. CONGRATULATIONS YOU ARE THE PROUD OWNER OF A SET OF MICROSERVICES!!
- 65. NEXT STEPS ▸ Break out more microservices as necessary. ▸ Change up the communication interface...maybe use a message queue? ▸ Don't do anything and continue to make money. ▸ The choice is up to you!
- 66. SOURCE CODE ▸ https://github.com/mikegehard/ journeyFromMonolithToMicroservices (Java) ▸ https://github.com/mikegehard/user-management- evolution-kotlin (Kotlin)