Microservices - Yet another buzzword?

Microservices architecture is garnering attention as a modern pattern for building application that scale well, deploy often, have better fault tolerance and can be built out of multiple technologies. We will go through the advantages and drawbacks of going Microservices way and when the pattern is a good fit. We will also touch on Docker, yet another buzzword, strongly emerging as a Microservices delivery mechanism for Linux based systems. If you are looking to refactor your monolithic application, to build a new cloud native application or simply to get your geek on this session is for you.

Transcript

1. Microservices - Yet another buzzword? Orlando Code Camp, 2015 Ovidiu Dimulescu @odimulescu www.odimulescu.com
2. The opinions and views expressed in this talk are my own, and do not necessarily reflect the opinions or views of my employer.
3. 3 Why bother?
4. * http://commons.wikimedia.org/wiki/File:Beer_growler.jpg
6. * http://microxchg.io/2015/index.html
7. ~1 out 5 sessions on Microservices directly or indirectly
8. * https://skillsmatter.com/conferences/6312-mucon
9. 9 * Wikimedia
10. * http://commons.wikimedia.org/wiki/File:Windows_Phone_8_Startscreen.png * http://commons.wikimedia.org/wiki/File:IPhone_5C_PSD.png
11. 11 Monolith App PM QA DEV DBA SA NetEng “On Premise” No / SQL (single datastore*)
12. 12 Monolith App UI Data Access Business Domain
13. 13 Monolith App UI Data Access Business Domain Comp I Comp II
14. 14 * http://commons.wikimedia.org/wiki/File:Gnome-emblem-package.svg * http://commons.wikimedia.org/wiki/File:Inkscape_icons_dialog_layers.svg
15. 15 Does the code reflect the architecture?
16. 16 ? * http://commons.wikimedia.org/wiki/File:Component-cables.jpg * http://commons.wikimedia.org/wiki/File:Gnome-emblem-package.svg
17. 17 APP UI Data Access Bussines Domain … APP UI Data Access Bussines Domain APP UI Data Access Bussines Domain Scalability model
18. 18 ESB WS-* SOAP XML Svc I Svc II Svc N PM QA DEV DBA SA NetEng “On Premise” No / SQL (single datastore *) …
19. 19 (Not so) Old world Layers oriented Scaling per app instead of per component Process oriented / friction prone Single language * Single datastore *
20. 20 * http://en.wikipedia.org/wiki/User:Shijauddin#/media/File:I_am_a_Programmer.png
21. 21 * http://en.wikipedia.org/wiki/User:Shijauddin#/media/File:I_am_a_Programmer.png
22. 22 * http://commons.wikimedia.org/wiki/File:Four_continents.png * http://en.wikipedia.org/wiki/User:Shijauddin#/media/File:I_am_a_Programmer.png
23. 23 * http://en.wikipedia.org/wiki/Conway%27s_law Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations Melvin Conway, 1968 Conway’s Law
24. 24 $$$ * http://commons.wikimedia.org/wiki/File:Gl%C3%BChlampe_42W_230V_E27_Effi_Klasse_C.jpg
25. 25 Web size Team size Team skills and geo distribution Systems Architecture Time to market Scalabilities
26. 26 Opportunities ?
27. 27 * http://commons.wikimedia.org/wiki/File:A_new_and_correct_map_of_the_world,_laid_down_according_to_the_newest_discoveries, _and_from_the_most_exact_observations_(8342680176).jpg
28. 28 PaaS APIs DevOps HTTP 2.0 JSON IaaS *aaS SQL + NoSQL (new datastores)
29. 29 Self - serve Convenience oriented / low friction Polyglot language and persistence Fast & affordable experimentation Uniform & disposable environments New world
30. 30 Old world - Good Parts
31. 31 UNIX Philosophy Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. Doug McIlroy * http://en.wikipedia.org/wiki/Unix_philosophy
32. 32 Initial Stands for (acronym) Concept S SRP [4] Single responsibility principle a class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class) O OCP [5] Open/closed principle “software entities … should be open for extension, but closed for modification.” L LSP [6] Liskov substitution principle “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract. I ISP [7] Interface segregation principle “many client-specific interfaces are better than one general-purpose interface.”[8] D DIP [9] Dependency inversion principle one should “Depend upon Abstractions. Do not depend upon concretions.”[8] * http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 SOLID (OOP)
33. 33 Discrete services that ‘do one thing and do it well’. Microservices
34. 34 SOA !?
35. 35 Microservices Micro is about scope not size Independently deployable (group level) Lightweight communication Single process (lightweight containers) Smart endpoints, dumb pipes
36. 36 Right tool for a job Different code changing speeds Organizational splits Multiple scaling profiles Multiple security zones Cross functionality Microservices - Pros
38. 38 Splitting / Merging / Defining boundaries Micro frameworks / containers availability & reliability Wiring complexity Configuration Management Testing / Deployment / Monitoring Data Management (MDM, Eventual Consistency) Cognitive complexity Org structure and culture Microservices - Challenges
39. 39 Conway’s Law Adrian Cockcroft (Battery Ventures, ex-Netflix) suggested that instead of designing software that copies our current organizational structure, figure out how we want our software to look, then (re) design the organization so it copies the software.
40. 40 Jeff Bezos, CEO, Amazon * http://commons.wikimedia.org/wiki/File:Pepperoni_pizza_(2).png Two Pizza Rule
41. 41 * http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ 1) All teams will henceforth expose their data and functionality through service interfaces. 2) Teams must communicate with each other through these interfaces. 3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared- memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. 4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care. 5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 6) Anyone who doesn’t do this will be fired. Jeff Bezos, CEO, Amazon - Big Mandate
42. 42 “You build it, you run it” Werner Vogels, CTO, Amazon * ACM Queue interview, 2006. https://queue.acm.org/detail.cfm?id=1142065
45. Native Boot2Docker Supported Platforms* Boot2Docker
46. Ecosystem Many more …
47. Startup speed Resource density Layered file system with changes tracking Hierarchical images with registry hub Portable Single process* Features
48. The Twelve-Factor App - www.12factor.net coding {the} architecture - www.codingthearchitecture.com Pass for Microservices - gilliam.github.io Martin Fowler - martinfowler.com/articles/microservices.html Chris Richardson - microservices.io/patterns/microservices.html High Scalability - highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html The Arm Blog - the-arm.com/2013/09/30/microservices-and-solid-principles-of-object-oriented-design/ Dare to dream blog - davidmorgantini.blogspot.com/2013/08/micro-services-introduction.html Charles Young Blog - geekswithblogs.net/cyoung/archive/2014/12/20/hexagonal-architecturendashthe-great-reconciler.aspx Docker Website - docker.com Google Search Engine - last but not least :) Resources
49. Questions ? Ovidiu Dimulescu @odimulescu www.odimulescu.com