Transforming monolith systems to microservices
•Download as PPTX, PDF•
0 likes•12 views
This presentation talks about the motivation of transforming monolithic systems to microservices system, and also describes some of the challenges in this process and how to overcome them.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Transforming monolith systems to microservices
Similar to Transforming monolith systems to microservices (20)
Recently uploaded
Recently uploaded (20)
Transforming monolith systems to microservices
- 1. 1 Division | Unclassified #Rafdocs Transforming Monoliths to Microservices Alon Yair Unclassified
- 2. 2 Division | Unclassified #Rafdocs • Motivation for transformation • Main challenges in transformation • Strategies and Techniques We will talk about…
- 3. 3 Division | Unclassified #Rafdocs From Monolith to Microservices: Our Story 3 Client Middleware Server DB API Gateway Web UI DS Service BE ServiceMonolith Unit Area Objects SDB MKRC Optimal Path Detection Domain Services Cassandra Kafka Infrastructure Services
- 4. 4 Division | Unclassified #Rafdocs • Large code base, hard to maintain • Longer development cycles • Any change require full release • Inaccessible capabilities from the outside • Fixed technology stack • High coupling between modules • Failure affects entire system • Scale requires full duplication (if possible) How Monolith is Born ? (Like a baby) I Do Something I do some other things I can do a lot of things Ok, I reached my limits Are you serious ?!? Monolithic Frame
- 5. 5 Division | Unclassified #Rafdocs Microservices Systems • Shorten development cycles • Accessible capabilities • Support frequent updates • Easy to scale and better performs • Make it easy to divide into teams • Allow teams to develop expertise • Reduces critical failure points • Faster boot times after failures (only the crashed service is booted)
- 6. 6 Division | Unclassified #Rafdocs Throw Away or Transform ? Big Ball of Mud Who are we ? Software Engineers What do we want ? Build from scratch Why we want it ? Because It’s FUN!
- 7. 7 Division | Unclassified #Rafdocs Throw Away or Transform ?
- 8. 8 Division | Unclassified #Rafdocs 1. Consider using a Framework • Significant bootstrap • Maintain suitable architectural principles • Friendly to the monolithic code • Plan end-to-end Proof of Concept 2. Adopt gradual approach • Start with one module • Prioritize by importance and complexity • New modules as microservices • Operate alongside the monolithic part Where to Start ?
- 9. 10 Division | Unclassified #Rafdocs Transformation Technique #1: Safety Net • Parallel operation of the new service alongside the monolithic part • Allows a gradual transition to the new service • Load dispersion before full service maturity • Used as a safety net in case of service failure • Relevant Patterns • Strangler Pattern • Branch By Abstraction Existing Module Service Proxy New Service Module Abstraction Inbound Call Monolith
- 10. 11 Division | Unclassified #Rafdocs Transformation Technique #2: The “Macroservice” • Variation Anti-Corruption Layer pattern • Wrapping monolith as one big service • Aligned to the Framework • Runnable on unified infrastructure • Uses same communication (monitoring) Monolith Service Monolith Microservice Microservice Microservice
- 11. 12 Division | Unclassified #Rafdocs Transformation Technique #3: Traffic Optimization #1 Significantly reduce chatter Using batch call… cautiously, Using caches #2 Distinguish internal communication Using efficient binary protocols (e.g. gRPC) • We tend to ignore network considerations • From 30 seconds to 30 Minutes! • About 900,000 calls between services
- 12. 13 Division | Unclassified #Rafdocs Maria: Crazy rollercoaster, I became better software engineer Varda: A unique adventure, I grew, developed and mainly enjoyed Yaniv: A long journey with a huge sense of satisfaction at the end
- 13. 14 Division | Unclassified #Rafdocs Alon Yair: alony@rafael.co.il
Editor's Notes
- How Monolith is Born Monoliths lives in frames… the Monolith’s Home At beginning doing on thing Then adding more things (“chores”) Monolith is doing great, even enjoys it (like a kid getting extra responsibility)… the monolithic frame supplies all his needs (compute, memory, storage…) At some point he reaches his limits… signals to us, but still capable We don’t have a choice, we need to add some more chores Monolith is unhappy… feeling squeezed, stressed, start to crash, doesn’t do what we ask him to do, unexpected… (just like a teenager) At this point we start experience unexpected behavior We try do understand what is going over on him… we do some profiling and optimization actions… likely in critical parts We manage to delay the inevitable… but that’s it… we only delay the inevitable… The wire is already set… and this whole thing is ready to explode…
- Microservices Architecture is relatively new but good design principles like SOLID were established decades ago Our monolith probably look like this (color stains) We have some polish diamonds in it… it’s only the monolithic frame that limits them We should migrate them to a new open, enabling, scalable architecture
- Legit end-state can be “multilith”… no need to get pure microservices architecture Transforming inner modules to services involves costs and should be decided according business value
- After transforming a module to service he still need to communicate the remaining monolityh We wouldn’t want to “pollute” him with the monolith’s communication protocol Traditional approach is to implement an Anti-Corruption Layer inside the new service Since we are going to transform several modules it is better to flip it the other way around… Instead of implementing ACL inside every service we can wrap the monolith as a service (Disguise it) After transforming several modules to services we wouldn’t want
- We don’t pay much attention to network issues, especially if we work on a monolith In our first trial we’ve demonstrated “huge improvement”… we gone from 30s to 30m Those 900K calls were just function calls till now… and we don’t try to save in function (on the contrary) The modules we transform weren’t designed to work with external communication… they are chatty