Microservices. The good, the bad and the ugly.

@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 Hoogendoorn
ditisagile.nl
Mentoring ▪ Consulting ▪ Training
Agile ▪ Software
architecture ▪ Code

Sander Hoogendoorn
Me
Dad
Mentor, trainer, software architect,
programmer
Books, articles, conferences
Work
Owner ditisagile.nl
CTO Klaverblad Insurances
Web
www.sanderhoogendoorn.com
@aahoogendoorn
sander@ditisagile.nl

Monoliths
Hard to deliver,
even harder to test
and impossible to maintain

Advantages
A single (layered) architecture
A single technology stack
A single code base maintained by multiple teams
Disadvantages
All parts are interconnected
Many other systems are connected to your system
Hard to change, hard to maintain
Long time between releases, thereby increasing risks
Slow innovation
Hard to move to newer technologies
Doesn’t scale very well
Monoliths
Advantages and disadvantages

Dependencies will kill you
A typical systems landscape

A brief history
of components
and services

Client server

Component based development

Service oriented architecture

Microservices

Microservices
Beyond the hype?

Gartner hype cycle

Microservices
The clear benefits

But first … a definition

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

Martin Fowler

Monoliths
Scalability

Microservices
Scalability

Microservices
Running in their own processes

Monoliths
Persistence

Microservices
Polyglot persistence

Products not projects
Scalable
Decentralized governance
Replaceable parts
High performance
Technology independent
Polyglot persistence
Easy to build
Easy to test
Easier deployment than monoliths
Microservices
Promises

What is a microservice exactly?
How small is a microservice?
Requirements in a microservice world
Components or services
Who owns a microservice?
What technologies do you use?
What protocols do you apply?
How to define messages
How to test microservices
How to coordinate when business services run
across components?
How to build deployment pipelines?
Microservices
But…

Opinions, opinions, opinions

Are microservices
a stairway to
heaven?

Or are they
a highway to hell?

Two real world
cases

A major insurance company
Case 1

Where do we come from?
Case 1

Case 1

Outsourcing didn’t work
Case 1

Where are we going to?
Case 1

A product development company
Case 2

Case 2

For the things we have to learn
before we can do them,
we learn by doing themAristotle

So what did
we learn?

Microservices require
an evolutionary architecture

Start with some
guiding principles

Business
processes first
Case 1

Different levels of processes (and requirements)

Smart use cases

Architecture first
Case 2

Current architectural layout
Case 2

New architectural layout
Case 2

Brownfield migration…
Case 2

Designing
microservices
Modular design and
bounded contexts

Doing big up-front design is dumb,
doing no design is even dumber
Dave Thomas

Bounded contexts

The single unified domain model

Bounded contexts

Modeling
resources

Interpretations of
interpretations interpreted
James Joyce
(on REST)

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

Being RESTful
is not as easy
as it seems

HTTP return codes cheat sheet
1**. Hold on
2**. Here you go
3**. Go away
4**. You fucked up
5**. I fucked up

Be conservative in what you
send, be liberal in what you
acceptPostel’s Law

Testing
microservices

If you fail, fail fast

A service development lifecycle

What to test

Even though you might have brilliant testers…

… please automate your tests

What about these services
being independently deployable?

Deploying
microservices
Continuous integration
and build pipelines

A typical build pipeline

Build pipelines in Jenkins

There is no one tool to rule them all
We tried Jenkins, Bamboo, Team City, GoCD and then Jenkins again…

Deploying
microservices
Kaizen, minimal viable
products and continuous
delivery

Small increments or big releases?
What if Twitter…

Roadmaps over plans
While there is value in the items on the right, we value the items on the left more

Minimal viable product

From projects to continuous delivery

You build it, you run it
Werner Vogels

Moving towards DevOps is not easy
It feels like showing up at the wrong re-enactment

In retrospective
Some final thoughts

Microservices are not for everyone

Minimal viable product

Allow your
teams to learn
continuously…

The hockey stick model

And don’t forget
to have fun

References
and questions
www.sanderhoogendoorn.com
www.smartusecase.com
www.speedbird9.com
sander@ditisagile.nl
@aahoogendoorn

Microservices. The good, the bad and the ugly.

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Microservices. The good, the bad and the ugly.

Similar to Microservices. The good, the bad and the ugly. (20)

More from Sander Hoogendoorn

More from Sander Hoogendoorn (15)

Recently uploaded

Recently uploaded (20)

Microservices. The good, the bad and the ugly.