Geecon Prague 2016 - Thirty months of microservices

@aahoogendoorn | www.ditisagile.nlThirty months of microservices. Stairway to heaven or highway to hell? 1
@aahoogendoorn | www.ditisagile.nl
Thirty months of
microservices
Stairway to heaven
or highway to hell?
Sander Hoogendoorn
ditisagile.nl

Sander Hoogendoorn
Me
Dad, software architect, agile coach,
programmer, trainer, speaker, writer
Books, articles, conferences, courses
Work
Owner ditisagile.nl
Former CTO insurance company
Former global agile thoughtleader Capgemini
Web
www.sanderhoogendoorn.com
aahoogendoorn
aahoogendoorn
sander@ditisagile.nl

As a project manager
I would like to demo untested code so I embarrass myself

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

Who has a system that is too big
and that really should be broken up?

Dependencies will kill you
A typical systems landscape

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

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?
How does integration really work?
Containers anyone?
Microservices
But…

Opinions, opinions, opinions

Oh and by the way…
Doing microservices means that
you are building a distributed system

Are microservices
a stairway to
heaven?

Or are they
a highway to hell?

From the trenches
Microservices in real life

Where do we come from?

Outsourcing didn’t work

Where are we going to?

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 software architecture

Start with some
guiding principles

Client thinks in business processes, so we implement business
processes
We move away from the mainframe, to a new systems
landscape, consisting of micro-applications and micro-
components
Requirements and documentation are modeled rather than
written
Applications implement a single elementary business process
Applications and components all have their own bounded
context
Applications do not have storage, and only talk to other
applications and components
Components have their own storage (database), and only talk
to other components
Communication between applications and components uses a
simple open protocol – JSON on REST
Avoid transactional behavior as much as possible
Some guiding principles

Client thinks in business processes, so we implement business
processes
We move away from the mainframe, to a new systems
landscape, consisting of micro-applications and micro-
components
Requirements and documentation are modeled rather than
written
Applications implement a single elementary business process
Applications and components all have their own bounded
context
Applications do not have storage, and only talk to other
applications and components
Components have their own storage (database), and only talk
to other components
Communication between applications and components uses a
simple open protocol – JSON on REST
Avoid transactions as much as possible
Some guiding principles

Designing
microservices
Modular design and
bounded contexts

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

Bounded contexts

Single responsibility principle
Group together things that change together
Separate things that change for different reason

Bounded context
When you model larger domains, it becomes progressively
harder to create this single unified model.
Instead of creating a single unified model, you create
several, all valid within their bounded context

The single unified domain model
Or more often the humongous data model

Bounded contexts

RESTfulness
is not as easy
as it seems

A small quiz
Guess the HTTP status codes…
Get
localhost:8080/countries
Get
localhost:8080/countries/42
localhost:8080/countries/GRC
localhost:8080/countries/isocode/GRC
localhost:8080/countries?isocode=“GRC”
Post or put?
localhost:8080/countries
localhost:8080/countries/38

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 accept
Postel’s Law

Testing
microservices

Fail fast, fail often, fail forward

A (typical) service development lifecycle

What to test?

Even though you might have really brilliant testers…

… please automate all your tests

User acceptance testing
Minimize to the max

Deploying
microservices
Continuous integration
and build pipelines

Microservices. Building a deployment pipeline
Code DeveloperTest Test AcceptanceTest Acceptance Live

Microservices. Pipeline hell?
Codev.2 DeveloperTestv.2 Testv.2 AcceptanceTestv.2 Acceptancev.2
Testv.2 AcceptanceTestv.2 Acceptancev.2 Livev.2
DeveloperTest Test AcceptanceTest Acceptance Live
Codev.3 DeveloperTestv.3
Live
Codev.2

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

Some tooling
we use
IntelliJ
SonarQube
Jenkins
Git & Gitlab
Infrastructure as code

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

Infrastructure as code (often Groovy)
And guess what … we know how to do that

In retrospective
Some final thoughts

Microservices are not for everyone (yet)
How do we benefit from implementing microservices?

Will it work?

The hockey stick model

Allow your
teams to learn
continuously…

And never forget
to have fun

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

Geecon Prague 2016 - Thirty months of microservices

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (12)

Semelhante a Geecon Prague 2016 - Thirty months of microservices

Semelhante a Geecon Prague 2016 - Thirty months of microservices (20)

Mais de Sander Hoogendoorn

Mais de Sander Hoogendoorn (13)

Último

Último (20)

Geecon Prague 2016 - Thirty months of microservices