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.

.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith to Microservices

30 views

Published on

For the past couple of years it seems that Microservices is all the rage. We want to use Microservices, we want to decompose into Microservices and we want Microservices to be a part of our world. While modern tools and platforms such as Docker, Kubernetes, Service Mesh and the public cloud help in implementing and maintaining such systems, the reality is that many fail even before the first line of code was written. This can happen for many reasons; Perhaps you chose a Microservices architecture for the wrong reasons? Maybe the organization wasn't ready for it? Or just possibly - the proposed architecture didn't embrace the true meaning of Microservices?
As the CTO of a software services company I get tackle these questions a lot. Join me in this session as I provide my perspective on transitioning from Monolith to Microservices through lessons learned in the real world, while architecting and implementing multiple Microservices based software systems at various customers.

Published in: Education
  • Be the first to comment

  • Be the first to like this

.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith to Microservices

  1. 1. 6 Lessons I Learned on my Journey from Monolith to Microservices Eran Stiller Chief Technology Officer erans@codevalue.net @eranstiller https://stiller.blog https://codevalue.net
  2. 2. Agenda ▪ The Hype of Microservices ▪ Lessons Learned in the Real World ▪ Do It for the Rights Reasons ▪ Evolution or Revolution, That Is the Question! ▪ DevOps, Organizational Change & Culture Change ▪ Steep Technology Learning Curve ▪ No Anarchy ▪ Learn the Essence of What Is Microservices ▪ Q&A 3
  3. 3. About Eran Eran Stiller ▪ @eranstiller ▪ CTO & Founder at CodeValue ▪ Software architect, consultant and instructor ▪ Microsoft Regional Director & Azure MVP ▪ Founder of Azure Israel Meetup 4
  4. 4. The Hype of Microservices
  5. 5. 6
  6. 6. Microservice Architecture (MSA) Evolution
  7. 7. Microservice Architecture – Some Principles ▪A microservice should be less then 100 lines of code ▪100 is just a number that emphasizes: small ▪Usually can be developed in one scrum sprint ▪Easy to understand, fast to deploy, and cheap to reimplement ▪A microservice should be independently developed & deployed ▪A microservice should have private data ownership ▪Eventual Consistency ▪Versioning
  8. 8. MSA – Accessing Data 10
  9. 9. Eventual consistency “The value across all nodes will be consistent with the last update that was made -- eventually” The sunlight that you see indicates that the sun was still there eight minutes ago! When you see in a shopping site that a product is available, is it?
  10. 10. The Hype of Microservices 12
  11. 11. Lessons Learned in the Real World
  12. 12. Lessons Learned in the Real World ▪ Do It for the Rights Reasons ▪ Evolution or Revolution, That Is the Question! ▪ DevOps, Organizational Change & Culture Change ▪ Steep Technology Learning Curve ▪ No Anarchy ▪ Learn the Essence of What Is Microservices 14
  13. 13. Lessons Learned in the Real World ▪ Do It for the Rights Reasons ▪ Evolution or Revolution, That Is the Question! ▪ DevOps, Organizational Change & Culture Change ▪ Steep Technology Learning Curve ▪ No Anarchy ▪ Learn the Essence of What Is Microservices 15
  14. 14. Why Move to Microservices? 16
  15. 15. Answer #1 – It’s Cool! 17
  16. 16. Answer #2 – It’s Easier/Faster 18
  17. 17. There is a Learning Curve… 19
  18. 18. Answer #3 - Scale 20
  19. 19. Answer #4 - Agility 21
  20. 20. Do It for the Right Reasons ▪ Don’t make the transition because: ▪ Microservices are cool ▪ Microservices are easier or faster to develop ▪ Do make the transition because: ▪ When done right, it can scale better ▪ When done right, it makes the development more agile 22
  21. 21. Lessons Learned in the Real World ▪ Do It for the Rights Reasons ▪ Evolution or Revolution, That Is the Question! ▪ DevOps, Organizational Change & Culture Change ▪ Steep Technology Learning Curve ▪ No Anarchy ▪ Learn the Essence of What Is Microservices 23
  22. 22. Evolution or Revolution, That Is the Question! 24 http://cdaworldhistory.wikidot.com/europe-faces-revolutionshttps://commons.wikimedia.org/wiki/File:Human_evolution.svg
  23. 23. Case Study – Breaking the Monolith (Evolution) 25 A large scale multitenant trading system
  24. 24. Case Study – Rewrite (Revolution) 26 https://www.flickr.com/photos/meyyappan_tirupur/9498661067 An old advanced 2D/3D CAD MFC based application
  25. 25. Lessons Learned in the Real World ▪ Do It for the Rights Reasons ▪ Evolution or Revolution, That Is the Question! ▪ DevOps, Organizational Change & Culture Change ▪ Steep Technology Learning Curve ▪ No Anarchy ▪ Learn the Essence of What Is Microservices 27
  26. 26. DevOps 28 If I have to give you one piece of advice, DevOps would be it.
  27. 27. What is DevOps? 29 Taken from https://commons.wikimedia.org/wiki/File:Devops-toolchain.svg
  28. 28. Main DevOps Practices Dev/Commit Unit-Tests Integration- Tests Continuous Integration Dev/Commit Unit-Tests Integration- Tests Acceptance Tests Continuous Delivery Dev/Commit Unit-Tests Integration- Tests Acceptance Tests Production Continuous Deployment 30
  29. 29. How Agile is Agile? 32 Source: “Accelerate: State of DevOps 2019 Report” https://cloud.google.com/devops/state-of-devops/ Aspect of Software Delivery Performance Elite High Medium Low Deployment frequency On-demand (multiple deploys per day) Between once per day and once per week Between once per week and once per month Between once per month and once every six months Lead time for changes Less than one day Between one day and one week Between one week and one month Between one month and six months Time to restore service Less than one hour Less than one day Less than one day Between one week and one month Change failure rate 0-15% 0-15% 0-15% 46-60%
  30. 30. How Agile is Agile? 33 Source: “Accelerate: State of DevOps 2019 Report” https://cloud.google.com/devops/state-of-devops/
  31. 31. DevOps is Key – Elite vs. Low Performers 34 Source: “Accelerate: State of DevOps 2019 Report” https://cloud.google.com/devops/state-of-devops/
  32. 32. Tool Usage By Performance Profile 36 Source: “Accelerate: State of DevOps 2019 Report” https://cloud.google.com/devops/state-of-devops/ Low Medium High Elite A mix of proprietary tools, open source, and commercial off-the-shelf (COTS) software 30% 34% 32% 33% Mainly open source and COTS, heavily customized 17% 8% 7% 10% Mainly open source and COTS, with little customization 14% 21% 18% 20% Primarily COTS packaged software 8% 12% 8% 4% Primarily developed in- house and proprietary to my organization 20% 6% 5% 6% Primarily open source, heavily customized 6% 7% 5% 12% Primarily open source, with little customization 5% 12% 24% 15%
  33. 33. Automation is King 38 Source: “Accelerate: State of DevOps 2019 Report” https://cloud.google.com/devops/state-of-devops/ Low Medium High Elite Automated build 64% 81% 91% 92% Automated unit tests 57% 66% 84% 87% Automated acceptance tests 28% 38% 48% 58% Automated performance tests 18% 23% 18% 28% Automated security tests 15% 28% 25% 31% Automated provisioning and deployment to test env 39% 54% 68% 72% Automated deployment to production 17% 38% 60% 69% Integration with chatbots / Slack 29% 33% 24% 69% Integration with production monitoring and observability 13% 23% 41% 57% None of the above 9% 14% 5% 4%
  34. 34. Lessons Learned in the Real World ▪ Do It for the Rights Reasons ▪ Evolution or Revolution, That Is the Question! ▪ DevOps, Organizational Change & Culture Change ▪ Steep Technology Learning Curve ▪ No Anarchy ▪ Learn the Essence of What Is Microservices 39
  35. 35. Steep Technology Learning Curve ▪ Microservices ≠ new programming language ▪ Example – A .NET shop company wanted to move to Node.JS ▪ They’ve heard that this is the right way for MSA ▪ We convinced them to move to .NET Core ▪ They still needed to learn a lot: Architecture, Docker, K8S, … 40
  36. 36. Wind of Change ▪ Sometimes it’s an opportunity ▪ Utilizing a better technology for a microservice is an advantage ▪ A chance to make some technological progress ▪ Do what is best to your organization culture ▪ Consider that you must plan an education phase 41
  37. 37. Lessons Learned in the Real World ▪ Do It for the Rights Reasons ▪ Evolution or Revolution, That Is the Question! ▪ DevOps, Organizational Change & Culture Change ▪ Steep Technology Learning Curve ▪ No Anarchy ▪ Learn the Essence of What Is Microservices 42
  38. 38. Microservices Are NOT the Wild West… 43
  39. 39. Microservices Are NOT the Wild West… ▪ “Let’s just start and add services as required” ▪ “Services can arbitrarily call each other” ▪ “Let’s just throw the old code away” ▪ “The transition to Microservices is a strictly technical issue” 44
  40. 40. Microservices Need to be Governed ▪ Microservices, like Monoliths, start with good intentions ▪ Both become convoluted over time when not properly governed ▪ And then you’re back in square one, but this time with a distributed system 45
  41. 41. Microservices Architecture 46
  42. 42. Lessons Learned in the Real World ▪ Do It for the Rights Reasons ▪ Evolution or Revolution, That Is the Question! ▪ DevOps, Organizational Change & Culture Change ▪ Steep Technology Learning Curve ▪ No Anarchy ▪ Learn the Essence of What Is Microservices 47
  43. 43. Learn the Essence of What Is Microservices High Cohesion Low Coupling 48
  44. 44. Real-World Example ▪ A new system that was based on a Microservice Architecture ▪ The service decomposition was relatively good ▪ High cohesion ▪ Many small services that ▪ Use Kafka to path messages ▪ The message schema is shared among the services ▪ A single DB schema served all microservices ▪ Use k8s to host and monitor single service instances for robustness ▪ The result – The Microservice monolith 49
  45. 45. Real-World Example – The Fix ▪ Split the shared schema ▪ Multiple schemas with versioning ▪ Break the central DB ▪ Remove the state from the services ▪ Allow multiple instances ▪ Decide when it is right to use Kafka vs. other mechanisms 50
  46. 46. Summary 51
  47. 47. MSA – The hype and the reasons ▪ It’s a fashion, it’s the future, it’s cool!!! ▪ It’s software engineering’s ultimate goal ▪ Low Coupling and High Cohesion for free !? ▪ We all want to: ▪ Develop in a faster cadence ▪ Deploy any feature as soon as its finished ▪ Have the ability to immediately rollback ▪ Have versioning independent code ▪ Have abilities to monitor our system and conduct a canary or A-B testing ▪ But does it is really come for free? 52
  48. 48. Takeaways ▪ MSA – extreme low coupling and high cohesion ▪ With cost and responsibility ▪ Do it right or don’t ▪ Use infrastructure and tools ▪ Decide whether to migrate (evolution) or restart (revolution) ▪ Consider the learning curve ▪ Architecture, technology, DevOps ▪ It is not just a technology change – it is a major culture change ▪ Goes very well with the agile methodology 53
  49. 49. Takeaways 54
  50. 50. Eran Stiller Chief Technology Officer erans@codevalue.net @eranstiller https://stiller.blog https://codevalue.net

×