@aahoogendoorn | www.ditisagile.nl Microservices. The good, the bad and the ugly 1 @aahoogendoorn | www.ditisagile.nl Microservices. Stairway to heaven or highway to hell? Sander Hoogendoorn ditisagile.nl Mentoring ▪ Consulting ▪ Training Agile ▪ Software architecture ▪ Code
109
Embed
Microservices. Stairway to heaven or highway to hell
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 1
@aahoogendoorn | www.ditisagile.nl
Microservices.Stairway to heaven or highway to hell?Sander Hoogendoornditisagile.nlMentoring ▪ Consulting ▪ TrainingAgile ▪ Software architecture ▪ Code
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 2
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 3
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 4
As a project managerI would like to demo untested code so I embarrass myself
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 5
@aahoogendoorn | www.ditisagile.nl
Monoliths Hard to deliver, even harder to test and impossible to maintain
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 7
AdvantagesA single (layered) architectureA single technology stackA single code base maintained by multiple teams
DisadvantagesAll parts are interconnectedMany other systems are connected to your systemHard to change, hard to maintainLong time between releases, thereby increasing risksSlow innovationHard to move to newer technologiesDoesn’t scale very well
MonolithsAdvantages and disadvantages
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 8
Dependencies will kill youA typical systems landscape
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 9
@aahoogendoorn | www.ditisagile.nl
A brief history of components and services
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 10
Client server
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 11
Component based development
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 12
Service oriented architecture
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 13
Microservices
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 14
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 15
@aahoogendoorn | www.ditisagile.nl
MicroservicesBeyond the hype?
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 16
MicroservicesBeyond the hype?
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 17
Gartner hype cycle
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 18
@aahoogendoorn | www.ditisagile.nl
MicroservicesThe clear benefits
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 19
But first … a definition
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 20
In short, the microservice architectural style 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.
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
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 21
In short, the microservice architectural style 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.
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
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 22
In short, the microservice architectural style 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.
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
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 23
MonolithsScalability
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 24
MicroservicesScalability
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 25
MicroservicesScalability
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 26
MicroservicesRunning in their own processes
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 27
MonolithsPersistence
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 28
MicroservicesPolyglot persistence
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 29
Products not projectsScalableDecentralized governanceReplaceable partsHigh performanceTechnology independentPolyglot persistenceEasy to buildEasy to testEasier deployment than monoliths
MicroservicesPromises
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 30
What is a microservice exactly?How small is a microservice?Requirements in a microservice worldComponents or servicesWho owns a microservice?What technologies do you use?What protocols do you apply?How to define messagesHow to test microservicesHow to coordinate when business services run across components?How to build deployment pipelines?
MicroservicesBut…
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 31
Opinions, opinions, opinions
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 32
@aahoogendoorn | www.ditisagile.nl
Are microservicesa stairway to heaven?
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 33
@aahoogendoorn | www.ditisagile.nl
Or are they a highway to hell?
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 34
@aahoogendoorn | www.ditisagile.nl
Two real world cases
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 35
A major insurance companyCase 1
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 36
Where do we come from?Case 1
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 37
Where do we come from?Case 1
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 38
Outsourcing didn’t workCase 1
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 39
Where are we going to?Case 1
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 40
A product development companyCase 2
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 41
Where do we come from?Case 2
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 42
Where do we come from?Case 2
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 43
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 44
For the things we have to learn before we can do them, we learn by doing them
Aristotle
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 45
@aahoogendoorn | www.ditisagile.nl
So what did we learn?
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 46
Microservices require an evolutionary architecture
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 47
@aahoogendoorn | www.ditisagile.nl
Start with some guiding principles
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 48
We decided to go from hereClient thinks in business processes, so we implement business processesWe move away from the mainframe, to a new systems landscape, consisting of micro-applications and micro-componentsRequirements and documentation are modeled rather than writtenApplications implement a single (elementary) business processComponents serve a single purpose and offer servicesApplications and components all have their own bounded context – a domain modelApplications and components will have an similar internal software architecture to facilitate ease of maintenance and allow for harvesting re-useCommunication between applications and components will use a simple open protocol - REST
Our guiding principlesCase 1
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 49
@aahoogendoorn | www.ditisagile.nl
Business processes firstCase 1
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 50
Different levels of processes (and requirements)
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 51
Smart use cases
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 52
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 53
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 55
@aahoogendoorn | www.ditisagile.nl
Architecture firstCase 2
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 56
Current architectural layoutCase 2
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 57
New architectural layoutCase 2
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 58
New architectural layoutCase 2
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 59
Brownfield migration…Case 2
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 60
Questions, questions, questions
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 61
@aahoogendoorn | www.ditisagile.nl
Designing microservicesModular design and bounded contexts
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 62
Doing big up-front design is dumb,doing no design is even dumber
Dave Thomas
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 63
Bounded contexts
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 64
Single responsibility principle (SRP)
SOLID Single Responsibility Principle Open Closed Principle Liskov Substituion Principle Interface Segregation Principle Dependency Inversion PrincipleSingle Responsibility Principle Every module should have responsibility over a single part of
the functionality provided by the software, That responsibility should be entirely encapsulated by the
class All its services should be narrowly aligned with that
responsibilityTherefore Group together things that change together Separate things that change for different reason
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 65
Bounded context
Domain driven design The paradigm of designing software based on models
of the underlying domain The domain model helps the business and the
developers to reason about the functionality A model needs to be unified – internally consistent
without contradictions
Bounded context The bounded context is a central pattern in domain
driven design When you model larger domains, it becomes
progressively harder to create this single unified model So, instead of creating a single unified model, you
create several, all valid within their bounded context
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 66
The single unified domain model
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 67
Bounded contexts
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 68
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 69
@aahoogendoorn | www.ditisagile.nl
Modeling resources
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 70
Interpretations of interpretations interpreted
James Joyce(on REST)
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 71
Root resource (component)
GET the collection, but only limited to this representation (but with locations likely)
GET a single item from the collection, but with representation
Modeling resources
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 72
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 73
@aahoogendoorn | www.ditisagile.nl
Being RESTfulis not as easy as it seems
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 74
HTTP return codes cheat sheet
1**. Hold on 2**. Here you go
3**. Go away 4**. You fucked up
5**. I fucked up
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 75
Be conservative in what you send, be liberal in what you accept
Postel’s Law
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 77
@aahoogendoorn | www.ditisagile.nl
Testing microservices
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 78
If you fail, fail fast
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 79
A service development lifecycle
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 80
What to test
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 81
Even though you might have brilliant testers…
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 82
… please automate your tests
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 83
What about these services being independently deployable?
@aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 84