From monolith to decoupled…wait, why is that one getting bigger?!?
Monolithic apps are getting broken down left and right into dedicated services and teams, all under the banners of separating concerns, higher efficiency, and more. The strategy that is implemented will be crucial to ensure decoupling is a beacon of efficiency and not a migration nightmare.
Platform.sh presents Build Anything Together @SymfonyCon 2022
Keynote by Shawna Spoor
In this talk, we’ll discuss how decoupling following the strangler fig approach will seem counter-intuitive, as your monolith continues to grow alongside your new decoupled architecture. But this approach, when done right, makes dismantling a monolith a process that is structured and safe, slow but agile, and without major service interruptions or massive interface changes that shock and discombobulate users. We will look at the experience of Platform.sh’s customer experience engineering team who are midstream on moving from a monolith to a decoupled suite of mircroservices that support every aspect of user interaction with our products.
Learn more: https://platform.sh/blog/how-micro-is...
Key moments:
0:00 - Intro
• Shawna introduces herself and her role at Platform.sh.
• Mentions the transition from monolith to microservices at Platform.sh.
• Raises questions about the suitability of microservices for all scenarios.
• Highlights the Strangler Fig approach as a method for transitioning from monoliths.
2:21 - What is a monolith?
• Defines a monolith as a complex application fulfilling multiple functions with a large codebase.
• Discusses the advantages of monoliths, such as ease of development, testing, and deployment.
• Identifies challenges of monoliths, including scaling issues, debugging complexities, and lengthy testing processes.
6:10 - Microservices
• Introduces microservices as discrete services with reusable code fulfilling specific functions.
• Highlights benefits like loose coupling, independent deployability, easier scaling, and potentially increased reliability.
• Discusses downsides, including latency issues, complex integration testing, and dependency management challenges.
11:36 - Strangler fig approach to decoupling
• Introduces the Strangler Fig approach as a structured methodical approach to modernizing monoliths.
• Discusses the trade-offs of stability and uninterrupted service versus speed in modernization efforts.
• Outlines the iterative nature of the process prioritizing architecture health.
12:41 - Establish a proxy
• Explains the first step of the Strangler Fig approach, which involves setting up a proxy.
• Emphasizes that this step lays the groundwork for major changes without impacting users.
• Advises breaking down the monolith into manageable buckets before establishing the proxy.
• Provides a real example of breaking down functionality, such as user profile management, into distinct microservices.
16:15 - Create a new decoupled service
• Identifying the need for a new decoupled service.
• Importance of maintaining functionality in the monolith while transitioning.
• Flexibility provided by the Strangler Fig approach.
• Starting to architect the new microservice based on identified functionality.
• Challenges of dealing with duplication and shifting goal posts during the process.
20:40 - Route the traffic through the proxy
• Flipping the switch to route traffic through the new microservice.
• Discussion on feature flags versus feature branches for rolling out new functionalities.
• The impact of adding new code to the monolith and the need for adaptation.
22:13 - Repeat until your Monolith is a series of microservices
• Continuing the process of decoupling and repeating until the monolith is fully replaced.
• Importance of keeping microservices lean and resisting the temptation to add unnecessary functionality.
• Challenges in maintaining a dynamically changing system and the impact on developers.
• Considerations for data architecture and schema evolution during the transition.
• The Strangler Fig pattern as a method for gradual decoupling while retaining stability and user satisfaction.
26:42 - Questions
29:09 - Ending