Microservices vs. Monoliths: The Definitive Shootout

2350801025b8e8592dbaa8dd98a24cbb?s=47 Eberhard Wolff
November 06, 2018
240

Microservices vs. Monoliths: The Definitive Shootout

Shows how to choose between microservices and monoliths.

2350801025b8e8592dbaa8dd98a24cbb?s=128

Eberhard Wolff

November 06, 2018
Tweet

Transcript

  1. Eberhard Wolff Fellow INNOQ @ewolff http://ewolff.com

  2. http://continuous-delivery-buch.de/ http://continuous-delivery-book.com/

  3. http://microservices-buch.de/ http://microservices-book.com/

  4. http://microservices-buch.de/ ueberblick.html http://microservices-book.com/ primer.html FREE!!!!

  5. http://microservices-praxisbuch.de http://practical-microservices.com/

  6. http://microservices-praxisbuch.de/ rezepte.html http://practical-microservices.com/ recipes.html FREE!!!!

  7. What are Microservices?

  8. Independent Systems Architecture: ISA http://isa-principles.org/

  9. Modules Macro / Micro Architecture Independent Continuous Delivery Pipeline Resilience

    Integration & Communication Authentication & Metadata Standardized Operations Standards: Interface only Container Independent Systems Architecture
  10. What are Monoliths?

  11. Monolith • Deployment monolith • Deploy the whole system at

    once • Internal structure: Might be great or not so great… • A valid architecture
  12. The Shootout

  13. Compare Software Architectures? • Microservices and monoliths: valid architectures •

    How can you compare software architectures? • What is software architecture?
  14. Software Architecture • Technical solutions • ...to the problem at

    hand. • Home-grown definition • Broad definition • See my talk on Thursday • Need to understand the problem!
  15. Compare Software Architectures? • How does an architecture solve a

    specific problem better? • What problem?
  16. Problem 1: Standard Software • Deployed at many customers •

    Looking for a better modularization • Outdated technologies
  17. Problem 2: Internal System • Increase deployment frequency to multiple

    per day • …for better time-to-market • …for less risk
  18. Deployment

  19. Monolith: Deployment • Deploy all at once • Simpler? •

    It is hard to deploy a large system • Tests are even harder • Tests and deployment can take loooooong – days, weeks, months • So large infrequent deployments • Risky
  20. Microservices: Deployment • Deploy individually • Requires automated deployment •

    Easy with Docker, Kubernetes… • Requires decoupled components & tests • Enables faster deployments & tests • Enables frequent deployments
  21. Monolith / Standard Software: Deployment • No too frequent deployment

    • Deployment at customer site is complex anyways • Not every customer might use every new version.
  22. Microservices / Standard Software: Deployment • Push out a large

    number of microservices to many customers? • Hard • …or a competitive advantage? • How many deployments on your mobile phone each day?
  23. Monolith / Internal System: Deployment • Multiple deployments per day

    with a monolith? • Main problem: test the whole system • No option
  24. Microservices / Internal System: Deployment • Deploy and test each

    microservice in isolation. • Much less tests • Very fast deployment • How can you do multiple deployments per day without microservices?
  25. https://puppet.com/resources/whitepaper/state-of-devops-report

  26. None
  27. Deployment Frequency: Results • Elite Performers vs. Low Performers •

    Multiple times per day vs. once per week / month • 2.555x better lead time for change • 2.604x better time to restore service • 7x better change failure rate • 50% vs 30% time spent on new work
  28. Higher Deployment Frequency Improves Lead Time Reliability New Work %

    dramatically
  29. MAERSK COST OF DELAY POWER LAW CURVE 200K 10 30

    60 70 80 20 50 40 Number of Requirements 1.2MM 2.2MM 400K 1.4MM 2.4MM 600K 1.6MM 2.6MM 1MM 2MM 1.8MM 2.8MM Cost of Delay/Week Source: State of DevOps Report, blackswarmfarming.com
  30. No Silver Bullet Essence and Accident in Software Engineering Frederick

    P. Brooks, Jr. There is no single development... which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.
  31. No Silver Bullet

  32. No Silver Bullet Except for more frequent deployments?

  33. How to improve from once a month (low) to multiple

    times a day (elite) without microservices?
  34. Operation

  35. Monolith: Operation • One process • One source for logging,

    monitoring … • But: complex interaction with many 3rd party systems • What most operations team know and support best
  36. Microservices: Operation • Requires federated logging, monitoring … • Commodity:

    Elastic stack, Prometheus, Istio… • Each microservice has limited interaction with 3rd parties • Easy to scale just one microservice
  37. Monolith / Standard Software: Operation • Customer are used to

    operate deployment monoliths • …and it is relatively easy
  38. Microservices / Standard Software: Operation • Customer will have to

    operate many microservices • Challenge • You should not make the life of your customers hard… • Show stopper
  39. Microservices / Standard Software: Operation • Might change when Kubernetes/Istio

    is ubiquitous • Could try to hide the microservices i.e. automated deployment with environment + microservices
  40. Monolith / Internal System: Operation • The usual approach •

    Operations can easily support it.
  41. Microservices / Internal System: Operation • Requires investment in new

    infrastructure • …but commodity nowadays. • Or use the cloud?
  42. Changeability

  43. Changeability • Changes should be limited to one module. •

    Changing multiple modules are harder.
  44. Modules Microservice System

  45. Modules Deployment Monolith

  46. Modules Microservice System

  47. Modules Deployment Monolith

  48. None
  49. Changeability • Monolith vs. microservices is just two ways to

    implement modules. • How does it influence changeability?
  50. Monolith: Changeability • Far too often badly structured. • …even

    though there could be well structured monoliths. • Reason: Easy to cross module boundaries. • Even changes to many modules can be deployed in one deployment.
  51. Microservices: Changeability • Microservices have strong boundaries i.e. a REST

    API. • Support good structure • Higher Risk: Badly structured microservices system is hard to change and deploy. • Microservices: Harder to mess up …but severe consequences if messed up.
  52. Monolith / Standard Software: Changeability • Better changeability is a

    major goal. • Old system had a deteriorated structure. • Well aware of the risk • Establish architecture management?
  53. Microservices / Standard Software: Changeability • Would provide architecture firewalls

    • Architecture management not really needed
  54. Monolith / Internal System: Changeability • Considerable risk to mess

    up the system • However, might still work out.
  55. Microservices / Internal System: Changeability • Can not just change

    the software… • …but put it into production more easily • …where it generates value. • Changes not in production = waste
  56. Microservices / Internal System: Changeability • Willing to take the

    risk of deployment issues. • Strong boundaries help.
  57. Migration

  58. Migration • Your technology choices will be outdated sooner or

    later. • Migrate to a new technology
  59. Monolith: Migration • Changing the technology means updating the full

    monolith. • “Big Bang” • Even updating from a standard to a new standard might be hard. • E.g. Java EE
  60. Microservices: Migration • Each microservice might use a different technology.

    • Easy to migrate stepwise • Can keep outdated technologies in less relevant microservices …to save money. • Easy to experiment with new technologies
  61. Monolith / Standard Software: Migration • Old system had an

    outdated technology stack • Technology update driver to look for alternatives. • Monoliths would still be hard to keep up to date.
  62. Microservices / Standard Software: Migration • Much better chances for

    technology updates. • Stepwise • Option to migrate just parts
  63. Monolith / Internal System: Migration • Actually not too important

    • But still a potential issue
  64. Microservices / Internal System: Migration • Nice additional benefit

  65. Organization

  66. Organization • Scale the organization • More people • More

    communication • Limit communication needs. • Also see: Changeability • Changeability might limit communication needs.
  67. Monolith: Migration • One common technological foundation • Must coordinate

    technical decisions • One deployment • Must coordinate deployment i.e. features
  68. Microservices: Migration • Technical decision can be made per microservice.

    • Can still enforce standards. • Deployment per microservice • …no need to coordinate releases • Remember the separated continuous delivery pipelines?
  69. Monolith / Standard Software: Organization • Close coordination is a

    huge problem at the moment. • Hard to decide about the features that go into a release.
  70. Microservices / Standard Software: Organization • Less coordination • Constant

    stream of new features
  71. Monolith / Internal System: Organization • Close coordination • No

    way to do experiments
  72. Microservices / Internal System: Organization • Same as standard software

    • Easy to experiment with new technologies and features
  73. None
  74. 2 2 1 3 2

  75. 3 2 4 1

  76. That was easy! J

  77. If it is easy, it is probably wrong.

  78. Conclusion • Standard Software = less frequent deployments • …and

    operations at the customer • This makes all the difference • Consider your scenario! • SaaS would be very different.
  79. Conclusion • More frequent deployments has many advantages. • Lead

    time to change, stability, more new work • Consider more frequent deployments! • Standard software -> SaaS? App Store? • Microservices are a prerequisite for more frequent deployments.
  80. Conclusion • Did not talk about many other benefits of

    microservices • Scalability • Security • Robustness • Technology freedom • See Microservices Primer