Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The art of decomposing monoliths

2,022 views

Published on

Microservices are the new black. You've heard about them, you've read about them, you may have even implemented a few, but sooner or later you'll run into the age-old conundrum: How do I break my monolith apart? Where do I draw service boundaries?

In this talk you will learn several widely-applicable strategies for decomposing your monolithic application, along with their respective risks and the appropriate mitigation strategies. These techniques are widely used at Wix, took us a long time to develop and have proven consistently effective; hopefully they will help you avoid the same battle scars.

Published in: Engineering

The art of decomposing monoliths

  1. 1. Kfir Bloch The Art of 
 Decomposing Monoliths Head of Backend Engineering @ Wix @kfirondev To microservice or not to microservice
  2. 2. Wix in Numbers Over 72M users (website builders) Static storage is >2PB of Data 3 data centers + 3 clouds (Google, Amazon, Azure) 2B HTTP requests/day 1,000 people work at Wix @kfirondev
  3. 3. Wix R&D ●  Scala ●  React ●  Angular ~350 engineers in 3 locations (Tel Aviv, Dnipropetrovsk & Vilnius) ●  TDD ●  Continuous delivery @kfirondev
  4. 4. Wix and Microservices In the past 3 years we migrated to a Microservices architecture. It helps us: •  Scale our software •  Scale our people •  Meet product and marketing life cycle •  Embrace ownership and maintain a “startup-ish” culture ~150 different services @kfirondev
  5. 5. @kfirondev
  6. 6. Microservices is the 
 new black @kfirondev
  7. 7. In computing, microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building. @kfirondev
  8. 8. Microservices characteristics Protocol Circuit Breaker SOA Service Discovery Cascading Failure Replaceable Units Service Graph Scalable Units Documentation www.maplecityrubber.com@kfirondev
  9. 9. But I will talk about: When (and when NOT) to decompose your monolith @kfirondev
  10. 10. Why do you think it is important to know when to decompose? @kfirondev Sometimes less is more
  11. 11. Microservices have trade-offs @kfirondev
  12. 12. Each I/O hop is a failure point Partial deployment Strong interfaces between services are harder to refactor Ops complexity End-to-end testing is challenging @kfirondev
  13. 13. Mitigations ●  I/O hops are failure points ○  Proper HTTP configurations (timeouts, async, etc.) ○  Retry mechanism ○  Idempotent API ○  Circuit breakers ○  Monitoring ○  Eventual consistency when needed @kfirondev
  14. 14. Mitigations ●  Partial deployment ○  Feature toggle mechanism @kfirondev
  15. 15. Mitigations ●  Ops complexity ○  Automation ○  Developers own the Ops @kfirondev
  16. 16. Mitigations ●  Strong interface – hard to refactor ○  Backward / forward compatibility ○  Strong build system - dependency ○  Proper contact tests @kfirondev
  17. 17. There is no way to avoid the additional risk
 Another service == Another failure point @kfirondev
  18. 18. Once we accept our limits, we go beyond them. - Albert Einstein @kfirondev
  19. 19. To microservice
 or not to microservice? @kfirondev
  20. 20. Decompose to gain resource isolation for high availability 01
  21. 21. File Upload Client Web File Storage Items (CRUD) Items DB Items Catalog Service Network problem @kfirondev Server threads are busy on I/O Server cannot accept any more requests Client cannot perform critical missions like deleting an item
  22. 22. Different APIs have different SLAs ●  Some are near real time & some are not ●  Some are eventually consistent ●  Some are not critical and can fail ●  Some should respond within X ms @kfirondev
  23. 23. Decompose to avoid competition on shared resources @kfirondev
  24. 24. File Upload Client Web File Storage Items (CRUD) Items DB Items Catalog Service @kfirondev
  25. 25. File Upload Client Web File Storage Items (CRUD) Items DB Items Service Files Service @kfirondev
  26. 26. Decompose by 
 different life cycles 02
  27. 27. 4 PM Deploy – Items catalog feature BI Storage Items (CRUD) Items DB Items Catalog Service Coupons @kfirondev 5 PM Deploy – Coupon feature 6 PM Deploy – Coupon feature 9 PM Deploy – Coupon feature 12 AM Rollback – Due to bug in items catalog THE COMPANY LOSES MONEY
  28. 28. Items (CRUD) Items DB Items Catalog Service Coupons @kfirondev B1 Storage
  29. 29. B1 Storage Items (CRUD) Items DB Coupons Service Items Catalog Service @kfirondev
  30. 30. 03 Decompose to 
 reuse and share logic
  31. 31. Google Items DB Items Catalog Service Geo Geo (3rd party) Geo DB Geo User Management Service Geo User DB Items DB Geo User Management Service User DB @kfirondev
  32. 32. Google Items DB Items Catalog Service Geo (3rd party) Geo DB Geo User Management Service User DB Geo Service Fetch GeoFetch Geo @kfirondev
  33. 33. Google Items DB Items Catalog Service Geo Geo (3rd party) Geo DB Geo User Management Service Geo User DB @kfirondev WILL FAIL AT SOME POINT Common mistake to avoid
  34. 34. Each service must have its own DB @kfirondev
  35. 35. DB Service A An example when not to decompose Extract Cookie Info DB Service B Extract Cookie Info @kfirondev
  36. 36. Microservices are deployable artifacts that have Ops or I/O dependencies @kfirondev
  37. 37. Tested code that is CPU-bound is more secure and consistent @kfirondev
  38. 38. 04 Decompose to have 
 single team responsibility
  39. 39. Did you know that 90% of R&D projects fail?
 ○  Because of content ○  Because of bugs ○  Because of time to market Do you know how to reduce it to 70%? ○  3-5 developers on 1 team ○  3-5 months per project @kfirondev
  40. 40. @kfirondev Decompose to support organization scalability
  41. 41. Large teams cannot efficiently handle a large code base @kfirondev Small teams embrace responsibility and accountability
  42. 42. Decomposition helps your culture remain startup-ish when your size is corporate-ish @kfirondev
  43. 43. Decomposition allows each small team to have ownership of a service @kfirondev
  44. 44. Wix Org chart - “Guilds & Gangs” @kfirondev Microservices is the only way to support this HR methodology
  45. 45. 01 Resource Isolation 
 by service level Decompose to avoid competition of shared resources 02 Different release cycles Decompose to meet your product’s life cycle strategy 03 Reuse and share logic Decompose to share logic with dependencies 04 Develop & maintain by a single team Decompose to meet your HR needs @kfirondev When to break the monolith
  46. 46. Microservices start from a monolith and should be created with caution @kfirondev
  47. 47. From monolith to microservices: Practices to start with
  48. 48. Make changes gradually www.livbit.com@kfirondev
  49. 49. @kfirondev Don’t start with your most critical service
  50. 50. Confidence is built slowly
  51. 51. Use proper monitoring from day one www.capacitysolutionsplatform.com @kfirondev
  52. 52. Talk about failures and their causes
  53. 53. The secret of getting ahead is getting started. - Mark Twain @kfirondev
  54. 54. Q&A linkedin/in/blochkfir github.com/kfiron@kfirondev kfirb@wix.com Kfir Bloch
  55. 55. Thank You Wix Engineering Blog http://engineering.wix.com/ We are hiring http://jobs.wix.com Kfir Bloch @kfirondev email jobs@wix.com

×