Microservices, a bittersweet symphony

A story of how we got from initial architectural patterns to the microservice architecture.

How we did it wrong and what we should really care about.

Presented at: RockyMountainRuby Conference 2015

Transcript

1. MICROSERVICES
2. MICROSERVICES a bitter sweet symphony
3. HOW AN ARCHITECTURE TREND created a disaster
4. HOW DID THIS HAPPEN?
5. THE STORY STARTS 30 years ago
6. BUILT APPLICATIONS THAT RUN ON A MAINFRAME THE BEGINNING
7. THREE TIER ARCHITECTURE YOUNG ARCHITECTURE
8. Three tier architecture YOUNG ARCHITECTURE
9. WE BUILT DISTRIBUTED SYSTEMS AND WEREN’T AWARE ABOUT IT YOUNG ARCHITECTURE
10. THE MOORE LAW STILL STAND AT THE TIME YOUNG ARCHITECTURE
11. THE SCALING PROCESS WAS STILL EXTREMELY SLOW AND EXPENSIVE YOUNG ARCHITECTURE
12. EVERYONE WAS GOING ONLINE THE INTERNET
13. DISTRIBUTED DATA STORAGE AND PROCESSING THE INTERNET
14. COMMODITY HARDWARE WAS A REALITY THE INTERNET
15. MONOLITHIC APPLICATIONS BECAME POPULAR THE MONORAIL
16. BREAKING DOWN THEIR BIG APPLICATIONS INTO SERVICES SERVICES
18. MICROSERVICES AND THE START OF THE END MICROSERVICES
20. Microservices…
21. Services independently ˝ deployed
22. Infrastructure automation
23. Strong module boundaries
25. THIS IS WHERE A LOT OF APPLICATIONS TURN INTO HELL THE DISASTER
28. MICROSERVICES ARE ABOUT GOOD OBJECT ORIENTED DESIGN AT AN APPLICATION LEVEL THE DISASTER
29. TRUE
30. YOU WILL BENEFIT FROM A MICROSERVICE ARCHITECTURE IF YOU HAVE clear boundaries WITHIN YOUR APPLICATION
31. FALSE
38. MICROSERVICE PREMIUM: microservices impose a cost on productivity that can only be made up for in more complex systems. MARTIN FOWLER
39. TL;DR
40. We tend to get excited about implementing new ideas
41. We don’t realise that doing it the old way might be good enough
42. Why are we talking about microservices if they are so terrible?
43. They’re not
44. WHEN A SPECIFIC PART OF YOUR APPLICATION CHANGES MORE FREQUENTLY THAT THE REST WHEN TO MICROSERVICES
45. WHEN YOU NEED TO SEPARATE DATA AND ADD MORE CAREFUL SECURITY TO THE DATA WHEN TO MICROSERVICES
46. When your team is ready WHEN TO MICROSERVICES
47. WHEN YOU NEED TECHNOLOGY DIVERSITY WHEN TO MICROSERVICES
48. MICROSERVICES =
49. LESSON LEARNED?
50. We solve problems and add value to the companies/clients we work for
51. Microservices are useful only when they allow us to add value faster
52. ARCHITECTURAL DESIGN OPTIONS ARE NOT BLACK AND WHITE RECOMMENDATIONS
53. FOCUS ON CODE QUALITY, COMMUNICATION AND COLLABORATION RECOMMENDATIONS
55. @sebasoga Thanks