Taming the beast - get rid of your monolith

Talk about changes needed in an organization if you go MicroServices in the context of Takeaway.com

Transcript

1. Takeaway.com brands Lieferando.de Lieferservice.at Lieferservice.ch Lieferservice.de Pizza.be Pizza.fr Pizza.lu Pyszne.pl Thuisbezorgd.nl and Vietnammm.com Ma#hias  Laug  
2. The Story Taming the beast – get rid of your monolith Exposition Who are the main actors? Climax Conflicts all over the place! Denouement A Happy Ending?
3. Exposition -  Founded 2009 -  Raised 25 Million -  Acquired by Takeaway in 2014 -  Founded 1999 -  Biggest player in continental Europe since acquisition of Lieferando -  Mainly organic growth
4. MIGRATION!!!!!!!!!!!   MERGING!!!!!!!!!!!   CONSOLIDATION!!!!!!!!!!!  
5. The Question! Why  MicroServices?   -­‐  Don’t  follow  the  Hype!   -­‐  Does  it  make  sense  for  our  business  model?  
6. The Questions! ? ? ? Why  MicroServices?   What  needs  to  change  in  the  organizaDon?   How  to  migrate?  
7. Why Micro Services? -  Fast deployment -  Loosely decoupled components -  High cohesion -  Scalable on three axis -  Dependency management by design -  Scalable infrastructure It  is  not  about  the  benefits,  its  about  the  drawbacks  
8. Still want to use MicroServices? -  Higher complexity -  Overhead in network -  Lot‘s of monitors -  The network is reliable. -  Latency is zero. -  Bandwidth is infinite. -  The network is secure. -  Topology doesn't change. -  There is one administrator. -  Transport cost is zero. -  The network is homogeneous.
9. The Benefits
10. Process Optimization -  Fast adaption of new business processes -  Quick response to failure and errors -  Stable optimization of processes
11. Same deployment for everything Micro   Services   APIs   Docker  
12. Climax But  then  there     were  people  
13. How big is a MicroService?
14. How big is a MicroService? -  Not more than x lines of code, where x varies between 100 – 10K -  Can be re-implemented within 2 weeks -  Can be managed by one person -  If a class is bigger than my head then it is too big -  Serves only a single purpose
15. Facts 2 2 Locations 50 Head Count 3 Philosophies
16. Needed Changes •  Communication •  Team Structure Conway’s  Law  
17. New Communication is needed
18. New Team Structures are needed Frontend   API   Processes  (Backend)   DevOps   P1   P2   P3  
19. Who is responsible for what? •  Before it was some big applications with assigned teams •  Now there are multiple applications you need to worry about
20. Responsibilities -  Developers take responsibility over what they build -  Developers build up their own context of responsibility -  For new employees it is easier to have them build new features, but hunting bugs -  So let’s talk about “bounded context”
21. Bounded Context A specific responsibility enforced by explicit boundaries h#p://www.sapiensworks.com/blog/post/2012/04/17/DDD-­‐The-­‐Bounded-­‐Context-­‐Explained.aspx  
22. Decomposing the monolith Shopping  Cart   Restaurant  Lists   Search   Checkout   Transmission  Protocols  
23. Attacking the peripherals L2   L1   Starting Point Two legacy Applications Both doing kind of the same thing
24. Attacking the peripherals API   L2   L1   MS   Adding a flow Adding an API Aggregator Adding a Bus Adding first MicroServices
25. Attacking the peripherals API   L2   L1   MS   Communication Don’t use the database!!!
26. Attacking the peripherals API   L2   L1   MS   Communication Use the bus Use your own database
27. Attacking the peripherals API   L2   L1   MS  
28. Denouement Get an agreement Structure the Team Conway’s Law Decouple and Cohesion It’s a Journey You will fail first time Think incremental Move things step by step Size matters! Understand the cost of changes
29. Follow me @matthiaslaug Pizza Time
30. Join us in Berlin or Enschede We are hiring!