![In short, the microservice
architectural style [1] is an
approach to developing a
single application as a suite
of small services, each
running in its own process
and communicating with
lightweight mechanisms, often
an HTTP resource API.
-- Martin Fowler](https://image.slidesharecdn.com/microservices-and-checklistsreactive-summit-20161-161011223256/85/Microservices-The-danger-of-overhype-and-importance-of-checklists-9-320.jpg)
Microservices: The danger of overhype and importance of checklists
- 1. 1 MICROSERVICES AND CHECKLISTS OVERHYPE AND IMPORTANCE Katrin Shechtman, Lightbend / @katrinsh
- 2. 2 MY RELEVANT BACKGROUND 2003 - 2004 OpenMP, MPI, distributed Matlab 2006-2012 J2EE, Spring Proprietary Distributed Computing software in C/C++ 2012-2016 Play, Scala,
- 3. Akka 3 THEN CAME MICROSERVICES I THOUGHT MICROSERVICES ARE A PRIVATE CASE OF DISTRIBUTED SYSTEM THEY APPLY WHEN POLYGLOT COMPONENTS ARE REQUIRED AND SOME LATENCY COULD BE TOLERATED IN FAVOUR OF SCALABILITY
- 4. 4 WHY THIS TALK THE AMOUNT OF MISPERCEPTION SUGGESSTIONS SUCH AS 'DEVELOP MONOLITH AS LONG AS YOU CAN' EXPECTING DIFFERENT RESULTS FROM DOING THE SAME WITH SAME TECHNOLOGIES
- 6. 6 A PERFECT SERVER DI with same resolution JPA with less than ideal performance 5% CPU utilization
- 7. PERFECT UNTIL LOAD INCREASES BUT WHAT ABOUT HORIZONTAL SCALING?
- 8. 78 WHAT ABOUT COST EFFICIENCY? AT LEAST YOU MADE SOMEONE HAPPY
- 9. In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. -- Martin Fowler
- 10. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. -- Martin Fowler
- 11. 910 11 MICROSERVICES TO THE RESCUE Shopping cart and search are services Different departments are services I don't care what language to use (for the sake of this talk ...)
- 12. 12 PERFECT MICROSERVICES ? HOW LONG DOES SEARCH TAKE? 100 millis X N of services
- 13. 13 "LESS THAN PERFECT" MICROSERVICES BUT CONTINUE HOW LONG DOES SEARCH TAKE? 100 millis X N of healthy services + time 1 X unhealthy service 1 + ...
- 15. 15 MULTI-THREADING, ASYNC I/O 1 thread x threads Synch I/O 100 mls x N of services 100 mls * ceil(N of services / x) Asynch I/O 100 mls 100 mls
- 16. 16 MICROSERVICES DID NOT FAIL WE JUST DID IT WRONG, LET'S DO IT RIGHT QUIZ: HOW LONG DOES SEARCH TAKE NOW?
- 17. 17 MICROSERVICES - PERFECT AGAIN ? NO, WELCOME TO DISTRIBUTED MONOLITH
- 18. 18 SHORT DEFINITIONS WON'T SUFFICE CLOUD, CHANGE CYCLES OR SCALING ARE NOT A GOAL NOR IS IT A COMPLETE LIST
- 20. 20 RESILIENCE, SCALABILITY AND CONTINUOUS DELIVERY ARE CORE DESIGN PRINCIPLES UMBRELLA FOR MORE NESTED PRINCIPLES
- 21. 21 SKIPPING OVER ISN'T AN OPTION
- 22. 22 CONTINUOUS DELIVERY GOAL: VELOCITY Code isolation Independent deployment DevOps
- 23. 23 SCALABILITY GOAL: RESPONSIVINESS CPU utilization Componentization Disclaimer: according to Google Componentization is ... Quiz: AR vs BC ? Data isolation DevOps
- 24. 24 RESILIENCE AT ALL LEVELS GOAL: RESPONSIVINESS Asynchronous Communication Question: What is asynchronous communication? Componentization DevOps
- 25. 25 ELASTICITY System could both expand and shrink dynamically COST EFFICIENCY Scalability Appropriate infrastructure on-prem or wise choice of cloud provider
- 26. 26 CLOUD COST EFFICIENCY AND WE USUALLY RENT IT FURNISHED
- 27. ALL PRINCIPLES ARE IMPORTANT
- 29. 29 MICROSERVICES' PRICE TAG We should design again We should be smart, it is not only about right configuration anymore We should consolidate: monitoring, logging, etc (but not databases remember?) We should support DevOps or become one: deployment, cluster management etc, right technologies are super important Debugging is not hard, we just need to do it differently and we need tools
- 30. 30 CHOICE OF TOOLS THE RULE: THE TOOL(S) SHOULD NOT BREAK ANY PRINCIPLE MENTIONED BEFORE Take a look at Lagom, not the song, the opinionated (based on principles) microservices framework
- 31. 31 THANK YOU! QUESTIONS? MORE INFO ABOUT LAGOM: HTTP://WWW.LAGOMFRAMEWORK.COM Twitter: @katrish