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 microservicesStairway to heaven or highway to hell?

Sander Hoogendoornditisagile.nl

Sander Hoogendoorn

MeDad, software architect, agile coach, programmer, trainer, speaker, writerBooks, articles, conferences, courses

WorkOwner ditisagile.nlFormer CTO insurance companyFormer global agile thoughtleader Capgemini

Webwww.sanderhoogendoorn.comaahoogendoornaahoogendoorn sander@ditisagile.nl

As a project managerI 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 bigand that really should be broken up?

Dependencies will kill youA typical systems landscape

MicroservicesBeyond the hype?

Gartner hype cycle

MicroservicesThe 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

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 projectsScalableDecentralized governanceReplaceable partsHigh performanceTechnology independentPolyglot persistenceEasy to buildEasy to testEasier deployment than monoliths

MicroservicesPromises

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

MicroservicesBut…

Opinions, opinions, opinions

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

Are microservicesa stairway to heaven?

Or are they a highway to hell?

From the trenchesMicroservices 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 them

Aristotle

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 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 processApplications and components all have their own bounded contextApplications do not have storage, and only talk to other applications and componentsComponents have their own storage (database), and only talk to other componentsCommunication 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 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 processApplications and components all have their own bounded contextApplications do not have storage, and only talk to other applications and componentsComponents have their own storage (database), and only talk to other componentsCommunication between applications and components uses a simple open protocol – JSON on REST Avoid transactions as much as possible

Some guiding principles

Designing microservicesModular design and bounded contexts

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

Dave Thomas

Bounded contexts

Single responsibility principleGroup together things that change togetherSeparate things that change for different reason

Bounded contextWhen 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 modelOr more often the humongous data model

Bounded contexts

RESTfulnessis not as easy as it seems

A small quizGuess the HTTP status codes…

Getlocalhost:8080/countries

Getlocalhost: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 testingMinimize to the max

Deploying microservicesContinuous integrationand build pipelines

Microservices. Building a deployment pipeline

Code Developer Test Test Acceptance Test Acceptance Live

Microservices. Pipeline hell?

Code v.2 Developer Test v.2 Test v.2 Acceptance Test v.2 Acceptance v.2

Code Developer Test Test Acceptance Test Acceptance Live

Test v.2 Acceptance Test v.2 Acceptance v.2 Live v.2

Developer Test Test Acceptance Test Acceptance Live

Code v.3 Developer Test v.3

Code v.2

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

Some tooling we useIntelliJSonarQubeJenkinsGit & GitlabInfrastructure as code

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

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

In retrospectiveSome 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 forgetto have fun

References and questions

www.sanderhoogendoorn.comwww.ditisagile.nlaahoogendoornaahoogendoorn sander@ditisagile.nl

geecon prague 2016 - thirty months of microservices

Software

20161020 geecon continuous delivery

geecon 2012 hurdle run through ejb testing

geecon krakow 2015 - grails and the real-time world

geecon 2013 paths to innovation - amazon...

automated jasmine tests for javascript, geecon 2014

the social developer @ geecon 2014

geecon 2017 anatomy of java vulnerabilities

geecon - cargo culting and memes in java

need for speed: tools for jvm tuning for geecon prague 2016

of microservices and microservices

cassandra 3 new features @ geecon krakow 2016

ratpack 101 - geecon 2015

geecon - improve your tests with mutation testing

distributed algorithms for big data @ geecon

geecon prague 2014 keynote

java bytecode for discriminating developers - geecon 2011

software developer career unplugged - geecon 2013

advance a/b testing - geecon krakow 2015

geecon 2011 -- regex by staffan nöteberg

geecon - improve your android-fu with kotlin