Microservices, a bittersweet symphony

Code is better served in small portions. Unfortunately most of the time we build systems consisting of a monolithic application.

Let's look at microservices and decide whether they're a good approach or not given the problem and resources at hand.

Presented at: RailsConf 2015

1. A BITTERSWEET SYMPHONY Microservices
2. @sebasoga
4. WHAT ARE MICROSERVICES?
5. “A particular way of designing software applications as sets of independently deployable services” M. Fowler & J. Lewis
6. SOA Microservices
7. HOW BIG SHOULD A MICROSERVICE BE?
8. • Lines of code • Team size
9. Cognitive Load
10. Cognitive Limit
11. Cognitive Load Cognitive Limit <
20. Sorry!
23. The End
24. THE MONOLITHIC APPLICATION
25. Single Rails app Monolithic app ≠
26. Poor OO design Monolithic app =
28. “Integrated systems”
31. WHEN TO DO IT?
33. When I realize I have a monolith?
34. No
36. “If you can’t build a structured monolith, what makes you think micro- services is the answer!?” Simon Brown
37. So when?
38. When you need to scale a specific part of your monolith
39. A part needs to be easily replace
40. Independently deployable parts
41. Technology heterogeneity
42. M .Fowler & J. Lewis
43. • Rapid provisioning • Basic monitoring • Rapid application deployment
44. DOWNSIDES
45. Devops intensive
46. Log files from many microservices
47. Expect Failure
48. Network partitions
49. A B C E D
50. A B C E D
51. Unavailable services
54. All services have an uptime of 99.9%. And you have 40 services. The probability of something failing in a particular time period 96.1%. Which means there is around a 4% chance that something going wrong.
55. Data inconsistencies
56. CAP theorem
57. WHAT TO DO?
58. Use the Bounded Context pattern
59. M .Fowler & J. Lewis
60. Write services specification as executable contracts that can be used for testing
61. Go for asynchronous over syncronous calls as they make it easier to deal achieve CAP
62. Use schema based data formats over schema-less ones
63. Code Climate’s blog
64. rails new my_great_microservice —api
65. WHAT NOT TO DO?
66. Never share databases
67. Avoid being biased by Conway’s Law
68. M .Fowler & J. Lewis
69. Don’t break the “golden rule” of microservices
70. “You need to able to make a change to a service and deploy it by itself without changing anything else” Sam Newman
71. “I strongly believe that there is a law of conservation of complexity in software.” Michael Feathers
72. “When we break up big things into small pieces we invariably push the complexity to their interaction.” Michael Feathers
73. Go for microservices if they allow you to better manage the complexity of the system YOU are building
74. Bye @sebasoga
75. PICS AND IMAGES CREDITS • Turner field panorama: https://www.flickr.com/photos/lulek/ 11729694316 • Conway’s Law image: http://martinfowler.com/articles/ microservices.html • Minimal requirements image: http://martinfowler.com/articles/ microservices.html