From Monolith to Microservices

From Monolith to Microservices


Johann Romefort

April 28, 2016


  1. From Monolith to Microservices September 2015 01 Johann Romefort

  2. About Johann • 15+ years in IT • 7 years

    in San Francisco doing Startups • in Germany for 1 year • Tech Evangelist @Stylight • Overuse of Meme pictures 2
  3. Before I got to Stylight..

  4. I built Monoliths for a living 4

  5. Sounds cool! What is Monolith and how do I build

    one? 5 • It’s when you whole system is one big application that can fit on one server! • They are much easier to build than distributed applications! • You generally build one without even thinking about it • By the time you realize that you have one you’re in trouble.
  6. Are monoliths thaaaaat bad? 6 • Not if you just

    want to do a throw away project or a prototype. • Only if you promise that you won’t keep adding to the monolith and eventually put it in production • For simple apps they are probably best • and remember: Distributed apps are hard
  7. On being a CTO for a hot startup in San

  8. None
  9. My first year as a CTO 9 • Put a

    monolithic prototype in production • Almost no monitoring • No analytics • Almost no automated testing • Reminder: It will almost never stay a prototype, think about it.
  10. 10

  11. I crashed Techcrunch

  12. Codebase after a year • Fails from everywhere • Fixing

    one part lead to more bugs • Developers scared to touch it 12
  13. Deploys become HELL • Most likely they mean
 being down

    for a few hours • A lot of time a rollback is necessary • it feels like russian roulette 13
  14. Hire a QA Manager • Create a Staging env •

    No deploy unless it’s tested • Feared by the devs, hated by the CEO 14
  15. Add an “Ops guy” • Create the build • Prepare

    the deploy • Locks everything so dev
 can’t play around with prod • Wake up when server is on fire • feared by the dev as well. 15
  16. Impact on dev • Frustrated of slow release process •

    Chain of command too long • Feeling powerless • Low trust & autonomy 16
  17. Impact on product • Frustration of not executing fast enough

    • Frustration of having to ask for everything (like metrics) • No autonomy • Don’t understand the engineers 17
  18. Big Bang Refactoring! • Rewriting everything from scratch • Developers

    love this idea. • Do the right thing: Don’t do it • Unless you can • Unless you really have to - it happened to me :) 18
  19. What you should do instead 19 • Break down application

    into smaller autonomous units • Break down teams into smaller autonomous units • Automating what can be automated • Continuous Integration and Continuous Deployment
  20. Stylight - Make Style Happen

  21. We help people find a style they like 21 •

    Search engine for style: we aggregate products from a lot of stores • Digital magazine for inspiration • in 15 countries • 200+ employees • 3 offices • 6000 brands • 360 partners shops
  22. Historical Architecture @ Stylight 22 Backend Frontend products transfer SEO

    QA Machine Learning Feed import API Webapp Ranking bizdev One big app with one big database One big app with one big database
  23. Cross functional teams

  24. What is a cross- functional team? • Autonomous team •

    Different set of skills but working together • Own metrics and KPIs • Own software / DB • But new challenges… 24
  25. Stylight aims to become a Teal organization 25 • Each

    unit is autonomous • a unit is generally 5 to 10 people (so called- pizza team) • it mimics a living organism
  26. 30 seconds meditation on Conway’s law: 26 organizations which design

    systems ... are constrained to produce designs which are copies of the communication structures of these organizations — M. Conway[2]
  27. Moving to a service-based architecture 27 • Monoliths don’t work

    well in cross-functional teams • Monoliths don’t work well for complex system either • We extracted main components from the Core, mostly defining their boundaries by teams
  28. 28 Architecture evolution @ Stylight Backend DB Frontend DB products

    transfer SEO QA Machine Learning Feed import API Webapp Ranking bizdev
  29. Moving to a Microservices architecture

  30. Our architecture is evolving toward full micro services, mimicking our

    org 30 30 SEO QA Machine Learning Feed import API Webapp Ranking bizdev
  31. Microservices - an example 31

  32. Monolith vs Microservices - Storage 32

  33. Monolith vs Microservices - servers 33

  34. Why is it hard? 34 • Subject to the the

    8 fallacies of distributed computing ————————-> • Full devops model: Good tooling needed • Needs to be designed for resiliency • Harder to test Fallacies of distributed computing • 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.
  35. Why is it worth it?

  36. From an engineering perspective 36 • Easier to do CI/CD

    (we deploy 10 times / day) • resilient to failure (one service down does not bring the whole system down) • Easier to refactor • Easier to understand - you don’t need to know
 the whole system to get things done.
  37. Impact on dev • Autonomy • Not afraid to try

    new things • Confident in codebase • Bugs don’t have to linger around until there’s a release 37 Impact on Product and Bizdev • Iterate faster on features • Can make, bake and break hypothesis faster • Product gets improved incrementally everyday
  38. Where we’re heading…

  39. Pets vs Cattles, or Scaling up vs Scaling out

  40. Pets • Have cute names • Tuned and groomed •

    Take them to the vet when they are sick • when it comes to server: Scale up 40
  41. Cattle • Cattle is given a unique random id •

    They are identical to others • Got ill? Kill it and get another one. • when it comes to server: Scale out 41
  42. From Stateless to Immutability • Immutable systems are easier to

    reason about • Immutable data • Immutable infrastructure 42
  43. Messaging Queue as a database 43 • Each event in

    the system is writing into a time organised immutable log • Let you embrace immutable data where your database is transformed into materialised views • Let you replay your log in case of failure or if you need a different view on your data
  44. Docker 44 • Container technology • Eliminate discrepancies between dev,

    staging, prod • helps to create immutable units easy to deploy and scale • Fits devops paradigm
  45. CoreOS • Immutable File System • Auto-update • Run on

    Bare Metal or VMs • Minimal footprint OS • Tailored for container deployments 45
  46. follow me : @romefort follow Stylight Tech : @codetailors