Services taste better in small disposable cups

Let's review the micro-services architecture consisting of a particular way of designing systems as suites of independently deployable services. Aiming to allow us to have lower code coupling, to deploy fearlessly, change code easier and move forward faster.

Presented at: Nickel City Ruby 2014

Transcript

1. Services in small taste better disposable cups
2. @sebasoga Sebastián Sogamoso
5. Burroteca
7. Donkey Discoteque +
9. Chiva
12. Chivateca
16. Too much going on
17. Feels dangerous
18. The monolithic application
19. Monolithic Big coupled monstrosity ≠
20. Bad OO design = Big coupled monstrosity
21. “If you can’t build a structured monolith, what makes you think micro-services is the answer!?” ! Simon Brown
22. The boundary problem
23. Package Cohesion Principles
24. 1 The Common Closure Principle
25. 2 The Common Reuse Principle
26. Existing packages or modules
27. Logical divisions within the problem domain
28. “Perfect is enemy of good” Don’t be afraid to iterate
29. Never share AR models
30. Share through services not libraries
31. Avoid Conway’s Law
32. The key property of a component is the notion of independent replacement and upgradeability
33. Services
34. Macro Big Small Micro Nano Medium
35. Services in small taste better disposable cups
36. MicroServices
37. “The term ‘Microservice Architecture’ has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services.” ! Folwer, Lewis
38. Multiple languages
39. Isolate code bases
40. Boundaries for bad design
41. Services that easy to replace
42. Really hard to create coupling
43. Act as Unix programs
44. Pitfalls
45. Deployment automation
46. Degradation issues
47. Interservice communication
48. Log files from many micro-services
49. Route individual call across different micro-services for troubleshooting
50. When?
51. “Human Cognitive Mass” (HCM) Evan Phoenix
52. “No single app can be larger than HCM threshold. Every app that crosses it will have to be broken up”
53. “Every sufficiently complex domain will require an app larger than HCM”
54. Rapid provisioning Basic monitoring Rapid deployment
55. RECAP
56. Micro-services won’t save you from poor object oriented design
57. Forces components to be decoupled
58. Allows components to be deployed independently and to easily replace them
59. Use different programming languages
60. Is not a free lunch, comes with a big operational cost
61. Adopt it when the benefits outweigh the cost
62. Thanks! @sebasoga
63. Credits • Me at RubyConf Uruguay: https://secure.flickr.com/photos/94260666@N05/14251620082/ ! • Burroteca: http://www.jackmag.com.co/articles/burroteca/ ! • Chiva: https://www.flickr.com/photos/ese_oso/3326116381/in/photolist-kWSb57-4fQ6qz-64Vdwa-ayRZ3N-4r69rq-8efmYi-61sZ3m-38GFcv-DFCWK-aiTdKh-B3pNK-av2SgN- auZvPe-61oNun-53Ky43-v6aHf-uoXb4-a96u5J-9mfoue-55N1QS-9SNZ6j-5Lhe6e-6qPJGg-7qSTDD-6aAEjj-eh2kp2-3d8Edo-FWJHU-4UFGtg-8twVhg-5UpL43-aiQmxn-aiTaZm-aiQmFT-cNSE33- cd6JQ7-8qTGhV-6QDX8b-38MgX7-8qWKYC-8qTR7c-8qWS6N-8qWTbj-8qTAWP-8qTKcn-8qWNDm-8qWLBE-8qWW6Y-8qTDZB-8qTPxM ! • Full chiva: https://www.flickr.com/photos/onbluewings/38964268/sizes/z/ ! • Chivateca 1: http://robertovelasquez83.blogspot.com/2008/08/hola-companeros-del-341s-no-olviden.html ! • Chivateca 2: http://guayaquilunacajadesorpresas.blogspot.com/2011_08_01_archive.html ! • Golden Gate Bridge: https://www.flickr.com/photos/salim/402620871/in/photolist-gxzCVN-3gHR9W-5Wkky-7L2Rdu-7uys1-5R11B1-e7CfhP-6DZhWn-38B3gv-4tN2Xq-kAVAG- dUSUQy-6zLofj-Bzxaa-4jmZiD-Bxufq-bfCFgT-5V84Y-n3nkmB-Bzxus-Bzwuu-bVnpiR-n8Vxzv-axiND-ekFJyQ-h881MJ-bdn9iB-dX8ZeH-ba8H-dZcoQ1-5eikhM-cdFJjh-BzwPa-iW215d-5cTsTq- aPkLxV-6u7c4x-eD5M4-hFTq1W-78nwcX-sXd8e-fCMz9o-813icF-39Wstq-ev17J3-nPu9UG-c6bssC-6EDRSs-dQjTmN-axiXV ! • Microservices requisites: martinfowler.com/bliki/MicroservicePrerequisites.html