Not all “Microservices frameworks” are made the same

Delivered at NDC Sydney 2020 by Dasith Wijesiriwardena (@dasiths) - https://dasith.me

Developing a distributed system is hard. Understanding the domain is harder. Therefore it makes sense not to reinvent the wheel and use ready made solutions to help build your microservices right? or does it? Turns out the there is a lot to consider here. We will look at how to leverage the right tools to help you achieve a good outcome and a sustainable growth path. We will also explore strategies to not get locked in “frameworks” that only give you short term wins. We will see how our choices can have a long lasting impact and what to consider when making them.

Transcript

1. Not All “Microservices Frameworks” Are Made The Same Dasith Wijes @dasiths 12-16 Oct 2020
2. hello! I am Dasith Wijes I am here because I have a love hate relationship with distributed systems 2
3. Complexity is in the Domain 3 • Focus on solving business problems • Technology must be secondary • Better to refactor later than overengineer now @dasiths
4. Frameworks 4 @dasiths
5. Frameworks 5 @dasiths
6. Frameworks 6 @dasiths
7. Frameworks 7 @dasiths
8. Frameworks 8 @dasiths
9. Frameworks vs Libraries 9 @dasiths
10. Frameworks define the hole, which we then fill with our code. Frameworks vs Libraries 10 @dasiths
11. Frameworks define the hole, which we then fill with our code. Frameworks vs Libraries We define the shape of the problem and compose many libraries together to come up with a solution. 11 @dasiths
12. How We End Up With “Frameworks” @dasiths
13. Re-inventing the wheel and all things How We End Up With “Frameworks” 13 We have problems that are unique to us. Let’s create an edifice where we define some patterns and shoehorn all our business problems inside it. What could go wrong? @dasiths
14. Re-inventing the wheel and all things How We End Up With “Frameworks” When in doubt use a sledgehammer 14 We don’t know what we are building yet. But let’s use a “power tool” and materials for it. By the way, be careful because it can be dangerous if used incorrectly. Thank me later. We have problems that are unique to us. Let’s create an edifice where we define some patterns and shoehorn all our business problems inside it. What could go wrong? @dasiths
15. Bike Shedding Focussing on the less important stuff 15 @dasiths
16. Scope For Creativity When you have a hammer everything looks like a nail 16 @dasiths
17. Language Lock-in Microservices without the agility 17 @dasiths
18. Heavy Dependencies Frameworks create their own gravity 18 @dasiths
19. Not Composable You can only fill a specific hole. Frameworks fall apart if you try to make them extensible. 19 @dasiths
20. 20 @dasiths
21. Distributed Pain 21 • Do you need to solve the non-trivial complexities like fault tolerance, circuit breakers and telemetry? • Do you need a “framework” to solve them? @dasiths
22. Platforms & Runtimes 22 @dasiths
23. Frameworks vs Runtimes/Platforms in Context of Microservices 23 @dasiths
24. Frameworks vs Runtimes/Platforms in Context of Microservices ✘ Focus Frameworks provide us with a set of solutions to shoehorn our problems into. Runtimes are often an invisble layer that doesn’t dictate how to solve business problems. 24 @dasiths
25. Frameworks vs Runtimes/Platforms in Context of Microservices ✘ Focus Frameworks provide us with a set of solutions to shoehorn our problems into. Runtimes are often an invisble layer that doesn’t dictate how to solve business problems. ✘ Flexibility Frameworks have features coupled together. Things get difficult when you want to replace a part. Runtimes allow us to layer business features on top of it and compose a solution. 25 @dasiths
26. Frameworks vs Runtimes/Platforms in Context of Microservices ✘ Focus Frameworks provide us with a set of solutions to shoehorn our problems into. Runtimes are often an invisble layer that doesn’t dictate how to solve business problems. ✘ Flexibility Frameworks have features coupled together. Things get difficult when you want to replace a part. Runtimes allow us to layer business features on top of it and compose a solution. ✘ Maintainability Frameworks require you to build on top of hard-to-reason abstractions as the solution grows. Runtimes allow you to express clear intent in your code while not having to solve “difficult and boring” network problems. 26 @dasiths
27. Example of a Runtime 27 ✘ Codifies the best practices for building microservice applications into open, independent, building blocks. ✘ Each building block is completely independent, and you can use one, some, or all of them in your application. ✘ Platform agnostic and can run locally or on k8s. @dasiths
28. 28 @dasiths
29. 29 @dasiths
30. 30 @dasiths
31. 31 @dasiths
32. 32 ✘ Service discovery ✘ State ✘ Pub/sub ✘ Bindings ✘ Middleware ✘ Secret stores ✘ Tracing exporters @dasiths
33. ✘ Service discovery ✘ State ✘ Pub/sub ✘ Bindings ✘ Middleware ✘ Secret stores ✘ Tracing exporters 33 Pluggable Implementations @dasiths
34. ✘ Service discovery ✘ State ✘ Pub/sub ✘ Bindings ✘ Middleware ✘ Secret stores ✘ Tracing exporters 34 ✘ Redis Streams ✘ Kafka ✘ Azure Service Bus ✘ RabbitMQ ✘ Azure Event Hubs ✘ GCP Pub/Sub ✘ MQTT Pluggable Implementations @dasiths
35. Example of a Platform 35 ✘ Focused API with higher level abstractions for common app use-cases. ✘ Pluggable components let you bring your own logging and monitoring, networking, and service mesh. ✘ Loosely coupled features let you use the pieces you need. @dasiths
36. 36 https://www.youtube.com/watch?v=krBxJswojjI @dasiths
37. 37 https://www.youtube.com/watch?v=krBxJswojjI @dasiths
38. Conclusions 38 @dasiths
39. Key Take-aways 39 @dasiths
40. Key Take-aways Complexity is our enemy. So keep it simple. Over the long run, an easy to understand system results in more agility. 40 @dasiths
41. Key Take-aways Complexity is our enemy. So keep it simple. Over the long run, an easy to understand system results in more agility. Composability is better than all-in- one solutions. No one solution will satisy every requirement. Keep your options open. 41 @dasiths
42. Key Take-aways Complexity is our enemy. So keep it simple. Over the long run, an easy to understand system results in more agility. Composability is better than all-in- one solutions. No one solution will satisy every requirement. Keep your options open. You don’t have to solve all the problems. Distributed system problems are hard to solve. Leverage runtimes and platforms to handle network layer. 42 @dasiths
43. 43 @dasiths
44. “ We are all apprentices in a craft where no one ever becomes a master. 44 ― Ernest Hemingway, The Wild Years @dasiths
45. Any questions? https://www.nationalgeographic.com/travel/destinations/asia/sri-lanka THANKS! Join Azure Community Newsletter: https://aka.ms/DevNewsletterJoin Claim your Azure swag*: https://aka.ms/AzureDeveloperSwag
46. Credits Special thanks to all the people who made and released these awesome resources for free: ✘ Presentation template by SlidesCarnival ✘ Photographs by Unsplash 46 @dasiths