Microservices: Utopian mystery

Goto Copenhagen 2016
Video of the accompanying talk: https://youtu.be/OIqcR5yi_to?t=32s

Transcript

1. Microservices: A Utopian Mystery Praveena Fernandes @praveenasekhar
4. Praveena Fernandes Software Engineer @ Neo @praveenasekhar =>
5. Microservices (µservices) Software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. @praveenasekhar
6. 6 @praveenasekhar
7. 7 @praveenasekhar
8. • Quick Deployments • Adapt to feedback quickly • High Scalability • Easier to enhance features • Add features quickly to assess market
9. What about age old systems? @praveenasekhar
10. • 20 year old system written in C. • Team with no business analysts. • Reverse engineer code. • Takes months of work to see changes propagated. • Prove the success of the new platform, to the old platform. • Tight deadlines @praveenasekhar
11. It’s the future @praveenasekhar
12. Definitions Utopia : An imagined place or state of things in which everything is perfect. Mystery: Something that is difficult or impossible to understand or explain. @praveenasekhar
13. http://www.slideshare.net/ngbinh1/building-microservices-web-application-using-scala-akka @praveenasekhar
14. 1 4 @praveenasekhar
15. Lesson 1: Keep it small @praveenasekhar
16. 1 6 How small is µ? @praveenasekhar
17. 1 7 How long does it take to rewrite? @praveenasekhar
18. 1 8 ≈ 2 Weeks @praveenasekhar
19. Source: Pinterest @praveenasekhar
20. 2 0 When did you ever have to rewrite something? @praveenasekhar
21. 2 1 How long does a story take to reach production? @praveenasekhar
22. Source: Pixabay @praveenasekhar
23. @praveenasekhar
24. Source: Pixabay @praveenasekhar
25. Why should my story to improve query performance be blocked because of a UI bug? @praveenasekhar
26. • 20 year old system written in C. • Team with no business analysts. • Reverse engineer code. • Takes months of work to see changes propagated. • Prove the success of the new platform, to the old platform. • Tight deadlines @praveenasekhar
28. Smaller codebase leads to smaller contexts to change leads to autonomous delivery @praveenasekhar
29. Small isn’t just beautiful, it’s practical. @praveenasekhar
30. Lesson 2: Focus on autonomy from design to deployment @praveenasekhar
31. Definitions Autonomy: The right or condition of self government. @praveenasekhar
32. How does autonomy look like? @praveenasekhar
33. No choreographed deployments @praveenasekhar
34. How can something be small enough but not have dependencies on other services? @praveenasekhar
35. @praveenasekhar
36. Want: No choreographed deployments Need: Easy choreographed deployments @praveenasekhar
37. No Easy choreographed deployments. @praveenasekhar
38. @praveenasekhar
39. Make a conscious decision to think about your deployment strategy when you start with a story and slowly you’ll see deployment patterns evolve. @praveenasekhar
40. Lesson 3: Plan for contingency measures aka breaking changes @praveenasekhar
41. How do you avoid breaking changes? @praveenasekhar
42. • Semantic Versioning • Tolerant Reader • Lock step deployment • Feature Toggles @praveenasekhar
43. @praveenasekhar
44. What about age old systems?
45. Heterogenous architecture @praveenasekhar
46. • ChatOps • Kibana Dashboards • Quick fix stories • Automating the support scripts @praveenasekhar
47. Lesson 4: Pay attention to bounded context @praveenasekhar
48. Bounded Context @praveenasekhar
49. Webapp AuthService { “authToken” : “token123”, “username” : ”John”, “age” : 28 } @praveenasekhar
50. Webapp AuthService { “authToken” : “token123”, “username” : ”John”, “age” : 28 } { “user” : { “name” : ”John”, “age” : 28 } } @praveenasekhar
51. Lesson 5: Choose what works for you and document your reasons @praveenasekhar
52. 5 2 Constraints vs Principles @praveenasekhar
53. 5 3 Ex: It is ok to duplicate validations @praveenasekhar
54. 5 4 Some duplications are better than other duplications. @praveenasekhar
55. 5 5 Shared libraries/shared clients? @praveenasekhar
56. 5 6 @praveenasekhar
57. 5 7 Good abstraction: Managing negative ttl caching can be abstracted to a shared library. @praveenasekhar
58. 5 8 Bad abstraction: Abstract models into shared libraries. @praveenasekhar
59. Sharing Customer, Product models is a bad idea. @praveenasekhar
60. Lesson 6: Embrace Conway’s Law @praveenasekhar
61. Conway’s law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. @praveenasekhar
62. Horizontal slicing: UI Team, Platform team, Feature team. Vertical slicing: Feature team with developers, testers, platform, UI developers and product owners. @praveenasekhar
63. @praveenasekhar
64. SCS: Self contained systems Product Owners vs Gatekeepers for change @praveenasekhar
65. Lesson 7: Take monitoring seriously @praveenasekhar
66. @praveenasekhar
67. • Business Metrics • Application Metrics • System Metrics @praveenasekhar
68. • Kibana • Grafana • Graphite • Turbine • Riemann @praveenasekhar
69. @praveenasekhar
70. @praveenasekhar
71. Lesson 8: Testing; Do it.
72. Practice testing and release in QA @praveenasekhar
73. Marry monitoring and testing @praveenasekhar
74. • Chaos monkey • Health checks to check for dependent services. • System status dashboards. @praveenasekhar
75. Unit Tests Integration Test Functional Test Journey Tests @praveenasekhar
76. Unit Tests Integration Test Functional Test Service Test Contract Tests Journey Test @praveenasekhar
77. Note: Tests are to validate constraints, they shouldn’t be constraints themselves. @praveenasekhar
78. Lesson 9: Invest in infrastructure @praveenasekhar
79. Invest in infrastructure @praveenasekhar
80. @praveenasekhar
84. Lesson 10: Embrace new technology @praveenasekhar
85. Evolving ecosystem @praveenasekhar
86. Digital Disruption • Uber • Airbnb • Facebook • Netflix • … @praveenasekhar
87. New kids on the block • Containerisation. • Service Registry. • AWS Lambda. • Ephemeral Containers. • *aaS @praveenasekhar
88. Dan Pink’s Drive : https://www.youtube.com/watch?v=u6XAPnuFjJc @praveenasekhar
89. Why do it? • Improve in iterations • Have autonomy, take control for business as well as technology. • High cohesion and loosely coupled. • Embrace Conway’s law. Don’t fight it. • Have fun. @praveenasekhar
90. Summary 1. Keep it small. 2. Focus on autonomy, from design to deployment. 3. Plan for contingency, aka breaking changes. 4. Pay attention to your bounded context. 5. Choose what works best for you and document your reasons. 6. Embrace Conway’s law. 7. Take monitoring seriously. 8. Testing; Do it. 9. Invest in infrastructure. 10. Embrace new technology. @praveenasekhar
91. Resources 1. Microservices Envy https://www.thoughtworks.com/de/radar/techniques/microservice-envy 2. Microservices Premium http://martinfowler.com/bliki/MicroservicePremium.html 3. Microservices Prerequisites http://martinfowler.com/bliki/MicroservicePrerequisites.html 4. Microservices – Not a free lunch http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html 5. Building Microservices http://www.amazon.de/Building-Microservices-Sam-Newman/dp/1491950358 6. Domain Driven Design http://www.amazon.de/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215 7. Release IT! https://pragprog.com/book/mnee/release-it 8. Your code as a crime scene https://pragprog.com/book/atcrime/your-code-as-a-crime-scene 9. Phoenix Project http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262509 10. Art of Scalability http://www.amazon.de/The-Art-Scalability-Architecture-Organizations/dp/0134032802 @praveenasekhar
92. Image Credits https://unsplash.com/ Dan Pink https://jon.dk/2012/02/boghjornet-anmelder-drive/ @praveenasekhar
93. Thank You ☺ @praveenasekhar