Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices: The danger of overhype and importance of checklists

290 views

Published on

It is a hard to argue that microservices is a new hotness in the world of software. Technical teams in seemingly all new startups are planning to develop their product using microservices, while architects in Fortune 500 are managing tireless conversations about which microservices technology is best to use for their next generation platform. The overhype of microservices is here and with that comes a danger to loose the true meaning of the word, which soon might be labeled as overrated. Before it happens, let's talk about what microservices architecture is, what it can offer, what it gets us into, what its price tag and how to create a checklist for choosing right tools that would help solve the complexity instead of sugarcoating it.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Microservices: The danger of overhype and importance of checklists

  1. 1. 1 MICROSERVICES AND CHECKLISTS OVERHYPE AND IMPORTANCE Katrin Shechtman, Lightbend / @katrinsh
  2. 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. 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. 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
  5. 5. 5 IMAGINARY E-COMMERCE
  6. 6. 6 A PERFECT SERVER DI with same resolution JPA with less than ideal performance 5% CPU utilization
  7. 7. PERFECT UNTIL LOAD INCREASES BUT WHAT ABOUT HORIZONTAL SCALING?
  8. 8. 78 WHAT ABOUT COST EFFICIENCY? AT LEAST YOU MADE SOMEONE HAPPY
  9. 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. 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. 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. 12 PERFECT MICROSERVICES ? HOW LONG DOES SEARCH TAKE? 100 millis X N of services
  13. 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 + ...
  14. 14. 14 DID MICROSERVICES FAIL ?
  15. 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. 16 MICROSERVICES DID NOT FAIL WE JUST DID IT WRONG, LET'S DO IT RIGHT QUIZ: HOW LONG DOES SEARCH TAKE NOW?
  17. 17. 17 MICROSERVICES - PERFECT AGAIN ? NO, WELCOME TO DISTRIBUTED MONOLITH
  18. 18. 18 SHORT DEFINITIONS WON'T SUFFICE CLOUD, CHANGE CYCLES OR SCALING ARE NOT A GOAL NOR IS IT A COMPLETE LIST
  19. 19. 19 THE GOAL IS RESPONSIVINESS
  20. 20. 20 RESILIENCE, SCALABILITY AND CONTINUOUS DELIVERY ARE CORE DESIGN PRINCIPLES UMBRELLA FOR MORE NESTED PRINCIPLES
  21. 21. 21 SKIPPING OVER ISN'T AN OPTION
  22. 22. 22 CONTINUOUS DELIVERY GOAL: VELOCITY Code isolation Independent deployment DevOps
  23. 23. 23 SCALABILITY GOAL: RESPONSIVINESS CPU utilization Componentization Disclaimer: according to Google Componentization is ... Quiz: AR vs BC ? Data isolation DevOps
  24. 24. 24 RESILIENCE AT ALL LEVELS GOAL: RESPONSIVINESS Asynchronous Communication Question: What is asynchronous communication? Componentization DevOps
  25. 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. 26 CLOUD COST EFFICIENCY AND WE USUALLY RENT IT FURNISHED
  27. 27. ALL PRINCIPLES ARE IMPORTANT
  28. 28. 2728 PRICE OF SKIPPING
  29. 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. 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. 31 THANK YOU! QUESTIONS? MORE INFO ABOUT LAGOM: HTTP://WWW.LAGOMFRAMEWORK.COM Twitter: @katrish

×