From Monolith to Microservices

Transcript

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 Francisco…
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.
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. www.stylight.com follow me : @romefort follow Stylight Tech : @codetailors