Microservices vs. Monoliths:The Definitive Shootout

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

What are Microservices?

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Modules Macro / Micro Architecture Independent Continuous Delivery Pipeline Resilience Integration & Communication Authentication & Metadata Standardized Operations Standards: Interface only Container Independent Systems Architecture

Slide 10

Slide 10 text

What are Monoliths?

Slide 11

Slide 11 text

Monolith • Deployment monolith • Deploy the whole system at once • Internal structure: Might be great or not so great… • A valid architecture

Slide 12

Slide 12 text

The Shootout

Slide 13

Slide 13 text

Compare Software Architectures? • Microservices and monoliths: valid architectures • How can you compare software architectures? • What is software architecture?

Slide 14

Slide 14 text

Software Architecture • Technical solutions • ...to the problem at hand. • Home-grown definition • Broad definition • See my talk on Thursday • Need to understand the problem!

Slide 15

Slide 15 text

Compare Software Architectures? • How does an architecture solve a specific problem better? • What problem?

Slide 16

Slide 16 text

Problem 1: Standard Software • Deployed at many customers • Looking for a better modularization • Outdated technologies

Slide 17

Slide 17 text

Problem 2: Internal System • Increase deployment frequency to multiple per day • …for better time-to-market • …for less risk

Slide 18

Slide 18 text

Deployment

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Microservices: Deployment • Deploy individually • Requires automated deployment • Easy with Docker, Kubernetes… • Requires decoupled components & tests • Enables faster deployments & tests • Enables frequent deployments

Slide 21

Slide 21 text

Monolith / Standard Software: Deployment • No too frequent deployment • Deployment at customer site is complex anyways • Not every customer might use every new version.

Slide 22

Slide 22 text

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?

Slide 23

Slide 23 text

Monolith / Internal System: Deployment • Multiple deployments per day with a monolith? • Main problem: test the whole system • No option

Slide 24

Slide 24 text

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?

Slide 25

Slide 25 text

https://puppet.com/resources/whitepaper/state-of-devops-report

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Higher Deployment Frequency Improves Lead Time Reliability New Work % dramatically

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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.

Slide 31

Slide 31 text

No Silver Bullet

Slide 32

Slide 32 text

No Silver Bullet Except for more frequent deployments?

Slide 33

Slide 33 text

How to improve from once a month (low) to multiple times a day (elite) without microservices?

Slide 34

Slide 34 text

Operation

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Monolith / Standard Software: Operation • Customer are used to operate deployment monoliths • …and it is relatively easy

Slide 38

Slide 38 text

Microservices / Standard Software: Operation • Customer will have to operate many microservices • Challenge • You should not make the life of your customers hard… • Show stopper

Slide 39

Slide 39 text

Microservices / Standard Software: Operation • Might change when Kubernetes/Istio is ubiquitous • Could try to hide the microservices i.e. automated deployment with environment + microservices

Slide 40

Slide 40 text

Monolith / Internal System: Operation • The usual approach • Operations can easily support it.

Slide 41

Slide 41 text

Microservices / Internal System: Operation • Requires investment in new infrastructure • …but commodity nowadays. • Or use the cloud?

Slide 42

Slide 42 text

Changeability

Slide 43

Slide 43 text

Changeability • Changes should be limited to one module. • Changing multiple modules are harder.

Slide 44

Slide 44 text

Modules Microservice System

Slide 45

Slide 45 text

Modules Deployment Monolith

Slide 46

Slide 46 text

Modules Microservice System

Slide 47

Slide 47 text

Modules Deployment Monolith

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

Changeability • Monolith vs. microservices is just two ways to implement modules. • How does it influence changeability?

Slide 50

Slide 50 text

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.

Slide 51

Slide 51 text

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.

Slide 52

Slide 52 text

Monolith / Standard Software: Changeability • Better changeability is a major goal. • Old system had a deteriorated structure. • Well aware of the risk • Establish architecture management?

Slide 53

Slide 53 text

Microservices / Standard Software: Changeability • Would provide architecture firewalls • Architecture management not really needed

Slide 54

Slide 54 text

Monolith / Internal System: Changeability • Considerable risk to mess up the system • However, might still work out.

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Microservices / Internal System: Changeability • Willing to take the risk of deployment issues. • Strong boundaries help.

Slide 57

Slide 57 text

Migration

Slide 58

Slide 58 text

Migration • Your technology choices will be outdated sooner or later. • Migrate to a new technology

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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.

Slide 62

Slide 62 text

Microservices / Standard Software: Migration • Much better chances for technology updates. • Stepwise • Option to migrate just parts

Slide 63

Slide 63 text

Monolith / Internal System: Migration • Actually not too important • But still a potential issue

Slide 64

Slide 64 text

Microservices / Internal System: Migration • Nice additional benefit

Slide 65

Slide 65 text

Organization

Slide 66

Slide 66 text

Organization • Scale the organization • More people • More communication • Limit communication needs. • Also see: Changeability • Changeability might limit communication needs.

Slide 67

Slide 67 text

Monolith: Migration • One common technological foundation • Must coordinate technical decisions • One deployment • Must coordinate deployment i.e. features

Slide 68

Slide 68 text

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?

Slide 69

Slide 69 text

Monolith / Standard Software: Organization • Close coordination is a huge problem at the moment. • Hard to decide about the features that go into a release.

Slide 70

Slide 70 text

Microservices / Standard Software: Organization • Less coordination • Constant stream of new features

Slide 71

Slide 71 text

Monolith / Internal System: Organization • Close coordination • No way to do experiments

Slide 72

Slide 72 text

Microservices / Internal System: Organization • Same as standard software • Easy to experiment with new technologies and features

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

2 2 1 3 2

Slide 75

Slide 75 text

3 2 4 1

Slide 76

Slide 76 text

That was easy! J

Slide 77

Slide 77 text

If it is easy, it is probably wrong.

Slide 78

Slide 78 text

Conclusion • Standard Software = less frequent deployments • …and operations at the customer • This makes all the difference • Consider your scenario! • SaaS would be very different.

Slide 79

Slide 79 text

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.

Slide 80

Slide 80 text

Conclusion • Did not talk about many other benefits of microservices • Scalability • Security • Robustness • Technology freedom • See Microservices Primer