Microservices, a bittersweet symphony

Code is better served in small portions. Unfortunately most of the time we build systems consisting of a monolithic application that gets bigger and scarier by the day. Everyone talks about how good microservices are, let's see if they are a good idea or not.

Presented at: wroc_love.rb 2015

Transcript

1. A BITTERSWEET SYMPHONY Microservices
2. @sebasoga
12. Sorry!
15. The End
17. The monolithic application
18. Monolithic Big ball of mud ≠
19. Bad OO design Big ball of mud =
20. Each new feature, means adding more code
22. WHAT ARE MICROSERVICES?
23. “A particular way of designing software applications as sets of independently deployable services” Fowler & Lewis
24. AREN’T MICROSERVICES JUST SOA?
25. Started on the right direction and ended up everything and nothing at the same time
26. SOA Microservices
27. HOW BIG IS A MICROSERVICE?
28. If I had the time, would I like to extract at least one other service from this codebase?
30. WHAT TO DO?
31. Start with a monolith
32. Get your design right
33. “If you can’t build a structured monolith, what makes you think micro-services is the answer!?” Simon Brown
34. THE BOUNDARY PROBLEM
35. SOLID Principles Package Cohesion Principles
36. “Perfect is the enemy of great” Don’t be afraid to iterate
37. Write services specification as executable contracts that can be used for testing
39. WHAT NOT TO DO?
40. Never share AR models
41. Avoid Conway’s Law
43. Don’t overload a small team with all the operational cost of this particular architecture
44. Don’t violate the golden rule of micro services
45. You need to able to make a change to a service and deploy it by itself without changing anything else
46. The key property of a component is the notion of independent replacement upgradeability
48. WHEN TO DO IT?
50. • Rapid provisioning • Basic monitoring • Rapid application deployment
51. Once an app crosses the HCM threshold it has to be broken up
52. “Human Cognitive Mass (HCM)” Evan Phoenix
53. When you need to scale a specific part of your monolith
54. When functionality is duplicated in more than one app
56. WHY?
57. Services are easy to replace
58. Independently deployable services
59. Technology heterogeneity
60. DOWNSIDE
61. Interservice communication
62. Expect Failure
63. Log files from many microservices
64. Devops intensive
65. Devops intensive
67. RECAP
68. At the application level we tend to prefer having smaller focused objects
69. At the system level we tend to prefer having to smaller focused services
70. Microservices won’t fix your software design problems
71. They solve a lot of common problems, but bring some new ones to the table
73. Both at the application level and system level we tend to prefer building small pieces
74. “I strongly believe that there is a law of conservation of complexity in software.” Michael Feathers
75. “When we break up big things into small pieces we invariably push the complexity to their interaction.” Michael Feathers
76. Use microservices if they allow you to better manage the complexity of building YOUR system
77. The less trivial the problem you’re solving is, the faster you will get to that point
78. THANK YOU! @sebasoga
79. PHOTOS CREDITS • Wroclaw Old Town Panorama: https://www.flickr.com/photos/lulek/ 14529759709/ • Car Poolers: https://www.flickr.com/photos/mujitra/8274336207 • Finding my way around the city center: https://www.flickr.com/photos/ gastaum/16191352076/ • Wroclaw Stadium: https://www.flickr.com/photos/lulek/14598337699 • Wroclaw, the station: https://www.flickr.com/photos/smif/3507659008 • Millenium Bridge: https://www.flickr.com/photos/andischmeling/ 2553801137
80. PHOTOS CREDITS • Wroclaw Old Town: https://www.flickr.com/photos/lulek/11729694316 • Plac Grunwaldzki: https://www.flickr.com/photos/ 22788809@N07/4034005069 • Sunset over Old Town: https://www.flickr.com/photos/lulek/ 12346882023 • Wroclove.rb: https://www.flickr.com/photos/jandudulski/8603608067/ • Conway’s Law image, minimal requirements image: http:// martinfowler.com/articles/microservices.html