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 Hoogendoornditisagile.nlMentoring ▪ Consulting ▪ TrainingAgile ▪ Software architecture ▪ Code


Sander Hoogendoorn

MeDadMentor, trainer, software architect, programmerBooks, articles, conferences

WorkOwner ditisagile.nlCTO Klaverblad Insurances

Webwww.sanderhoogendoorn.com@[email protected]



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


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


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




Martin Fowler


MonolithsScalability


MicroservicesScalability


MicroservicesRunning in their own processes


MonolithsPersistence


MicroservicesPolyglot persistence


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?

MicroservicesBut…


Opinions, opinions, opinions



Are microservicesa stairway to heaven?



Or are they a highway to hell?



Two real world cases


A major insurance companyCase 1


Where do we come from?Case 1


Outsourcing didn’t workCase 1


Where are we going to?Case 1


A product development companyCase 2


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 architecture



Start with some guiding principles



Business processes firstCase 1


Different levels of processes (and requirements)


Smart use cases



Architecture firstCase 2


Current architectural layoutCase 2


New architectural layoutCase 2


Brownfield migration…Case 2



Designing microservicesModular 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 RESTfulis 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 accept

Postel’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 microservicesContinuous integrationand build pipelines


A typical build pipeline


Build pipelines in Jenkins


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



DeployingmicroservicesKaizen, minimal viable products and continuous delivery


Small increments or big releases?What if Twitter…


Roadmaps over plansWhile 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 itWerner Vogels


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



In retrospectiveSome final thoughts


Microservices are not for everyone


Minimal viable product



Allow your teams to learn continuously…


The hockey stick model



And don’t forgetto have fun



References and questionswww.sanderhoogendoorn.comwww.smartusecase.comwww.speedbird9.com

[email protected]

@aahoogendoorn