thirty months of microservices. stairway to heaven or highway to hell? - sander hoogendoorn -...

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

@aahoogendoorn | www.ditisagile.nl

Thirty months of microservices

Sander Hoogendoornditisagile.nl

@aahoogendoorn | www.ditisagile.nlDesigning, developing, testing and deploying microservices 2

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 [email protected]


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


Dependencies will kill youA typical systems landscape



A brief history of components and services


Client server


Component based development


Service oriented architecture


Microservices



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



These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized managementof these services, which may be written in different programming languages and use different data storage technologies.

Martin Fowler



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


Opinions, opinions, opinions


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


First law of distributed objectsDo not distribute your objects!

Martin Fowler



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



Business processes first


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


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


Some examples

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 microservicesFailing fast


Fail fast, fail often, fail forward


A (typical) service development lifecycle


What to test?


Even though you might have really brilliant testers…


User acceptance testingMinimize to the max

ZZZZZ



Deploying microservicesContinuous integrationand build pipelines


A typical build pipelineIn different (virtual) environments


Build pipelines in Jenkins


Microservices Building multiple deployment pipelines

CodeDeveloper

TestTest

Acceptance Test

Acceptance Live

CodeDeveloper

TestTest

Acceptance Test

Acceptance Live

CodeDeveloper

TestTest

Acceptance Test

Acceptance Live

CodeDeveloper

TestTest

Acceptance Test

Acceptance Live


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?

What are we going to benefit from the most?Polyglot

persistence?

Scalability?

SmallIncrements?

Enforcemodular design?

Delivering more often?

Bounded Contexts?


Will it work?


The hockey stick model



Allow your teams to learn continuously…



And never forgetto have fun



References and questions

www.sanderhoogendoorn.com

www.ditisagile.nl

aahoogendoorn

aahoogendoorn

[email protected]

thirty months of microservices. stairway to heaven or highway to hell? - sander hoogendoorn -...

Technology