Microservices adoption practical lessons with examples by Dmitry Lebedev

Transcript

1. MICROSERVICES ADOPTION PRACTICAL LESSONS WITH EXAMPLES 2016 3.3 Riga Dmitry Lebedev
2. DMITRY LEBEDEV • Software engineer • 20 years in software development • Dozens of project delivered • Couple of projects failed • Still learn how to solve problems • Works for Norwegian company AMBITA
3. WHAT THIS PRESENTATION IS ABOUT? MAY BE IT’S TIME TO CHANGE THE ROOM?! ☺
4. MICROSERVICES CAN HELP • To grow in a balanced way • Separate the responsibilities • Define the boundaries • Adapt to new challenges
5. CONCEPT • Relatively small pieces of software • Working together as a separate isolated system • Which is highly adaptable due to it’s nature Copyright © 2014 Chris Richardson microservices.io
6. BENEFITS • Easy to scale development • Easy to deploy changes • Fault isolation • Technology diversity
7. WE’RE DONE WITH MICROSERVICES!
8. BUT THERE ARE SOME … EXPERIENCES… YOU KNOW…
9. THE PROBLEM WITH SUCCESS STORIES HARD TO VERIFY, THOUGH
10. PERSONAL EXPERIENCE
11. PROBLEM #1 HOW TO EXPOSE OURSELVES TO OUTER WORLD?!
12. PROBLEM #2 DO WE REALLY NEED TECHNOLOGY DIVERSITY?
13. PROBLEM #3 HOW TO FIND WHAT IS REALLY BROKEN?
14. PROBLEM #4 HEY, MICROSEVICE! WHICH VERSION ARE YOU?
15. PROBLEM #5 WHERE DATA IS COMING FROM?
16. PROBLEMS TO ADDRESS • How to expose services to outer world? • Do you need technology diversity? • How to find what is really broken? • Which version of components are deployed? • Where data is coming from?
17. INTERMEDIARY CONCLUSION • API design principles • Failure strategy • Deployment / dep management tools • Service discovery • Health-check services
18. API DESIGN • External API should not be UI driven (if you expose it) • Think how to have different versions of same API • Think how to reflect failures
19. FAILURE STRATEGY • Gradation of a failure (total, partial, just delayed data) • 3rd party end-points unavailable • ‘Circuit breaker’ pattern
20. DEPLOYMENT / DEP MANAGEMENT • Deploy one specific version to specified instances • Check if all dependencies are in place • Deploy missing components • Register deployed components at service registry • Environment provisioning
21. SERVICE DISCOVERY • Services got registered when deployed/started • Services got de-registered when stopped/undeployed • Client-side discovery • Server-side discovery
22. HEALTH CHECK SYSTEMS • Log aggregation and search • System dashboard (number of instances, versions & etc) • Statistics (throughput, response time, load)
23. PUTTING IT ALL TOGETHER
24. ANOTHER BIT Copyright © 2014 Chris Richardson microservices.io
25. HIGHLY OPINIONATED PART DO WE NEED THESE MICROSERVICES AT ALL?!
26. WHEN NOT TO USE
27. SINGLE POINT OF FAILURE IN YOUR DESIGN Source http://cmx.io/#5745532
28. LOAD IS EQUALLY DISTRIBUTED
29. WE DON’T NEED 99.999 UPTIME
30. WE DON’T NEED DYNAMIC SCALING
31. NO RELEVANT INFRASTRUCTURE By Ness Kerson/madNESS Photography for AusAID, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=32165089
32. WHEN TO USE
33. MULTIPLE DATASOURCES By Frank Vincentz - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=5638446
34. DIFFERENT LOAD AND SIZE By Eddy Van 3000 - Flickr: Friends, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=32821544
35. HIGH AVAILABILITY REQUIRED By ŠJů, Wikimedia Commons, CC BY 4.0, https://commons.wikimedia.org/w/index.php?curid=41179082
36. COMPONENTS FROM DIFFERENT DOMAINS
37. MANY TEAMS ARE WORKING TOGETHER
38. YOU HAVE THE INFRASTRUCTURE
39. RE-CAP: WE DON’T NEED IT • Load is equally distributed • 99.999 availability is not required • Dynamic scaling is not required • No infrastructure that supports microservices
40. RE-CAP: WE NEED IT • Data comes from different sources • High availability required • Several teams are working together • Infrastructure is in place
41. WHERE TO GO NEXT? • Microservices.io • Infoq.com • nginx.com • Microservices-stuff.com
42. WHAT ABOUT CLOUD?
43. THAT IS ALL FOR TODAY!