Your browser does not support JavaScript.
Refactoring a monolith into microservices
Refactoring a monolith into microservices
Why would you neeused Microservices Architecture?
Microservices Architecture
Pros
- although “additional complexity”, it is alternative, different kind of “complexity”
- when something breaks, “monolith” breaks as a whole
- A service in a microservices architecture is small, responsibilities are minimal, the overall complexity is bounded (restricted)
- if service becomes overly complex and polluted over time, it is easy to refactor it into possibly few services, than to refactor huge monolith into another cleaner monolith
- The microservices architecture isolates complexity, allowing for smaller, more agile teams to create a service
- “two-pizza teams”, where the entire team — leaders and all — can be fed with only two pizza pies
- microservices architecture is flexible: individual services allow for a variety of platforms, languages, and tools to be used because these choices affect only a small team at one time
- You can rapidly make changes and build and release updates, and as long as Public APIs (or inputs and outputs) aren’t affected, developers can move fast without breaking things
Cons
- many moving parts (services) add extra complexity
- Compare smaller Public API of monolithic transactional “buy book” method with parameters “user” and “book”, with three-service non-transactional Public APIs with 1st method “reserve funds”, 2nd one “reserve book”, and 3rd “commit transaction and notify user”
Monolithic Architecture
- updates and releases become slow and painful
- over time, software tends to grow in complexity, it becomes “monster”
- monoliths are hard to scale: often one part of the monolith is particularly resource intensive
- no options to scale an individual part of the monolith
- most monoliths cannot be even replicated (Oracle Cluster vs. Master-Slave architecture)