thirty months of microservices. stairway to heaven or highway to hell

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



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



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


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 processComponents serve a single purpose and offer servicesApplications and components all have their own bounded context – a domain modelApplications and components will have an similar internal software architecture to facilitate ease of maintenance and allow for harvesting re-useCommunication between applications and components will use a simple open protocol - REST

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


SOLIDSingle Responsibility PrincipleOpen Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle

Single Responsibility PrincipleEvery “module” should have responsibility over a single part of the functionality provided by the software,That responsibility should be entirely encapsulated by that moduleAll its services should be narrowly aligned with that responsibility

The SOLID principlesUncle Bob Martin


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


Domain driven designThe paradigm of designing software based on models of the underlying domainThe domain model helps the business and the developers to reason about the functionalityA model needs to be unified – internally consistent without contradictions

Bounded contextThe bounded context is a central pattern in domain driven design When you model larger domains, it becomes progressively harder to create this single unified modelSo, instead of creating a single unified model, you create several, all valid within their bounded context

Bounded contextEric Evans


The single unified domain modelOr more often the humongous data model


Bounded contexts



Modeling resources


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



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



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


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

Live

Code v.2


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


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



In retrospectiveSome final thoughts


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


Will it work?


The hockey stick model


Minimal viable product



Allow your teams to learn continuously…



And never forgetto have fun



References and questions

www.sanderhoogendoorn.comwww.ditisagile.nlaahoogendoornaahoogendoorn [email protected]

thirty months of microservices. stairway to heaven or highway to hell

Software