microservices. stairway to heaven or highway to hell

@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]


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


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


We decided to go from hereClient 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

Our guiding principlesCase 1



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


Questions, questions, questions



Designing microservicesModular design and bounded contexts


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

Dave Thomas


Bounded contexts


Single responsibility principle (SRP)

SOLID Single Responsibility Principle Open Closed Principle Liskov Substituion Principle Interface Segregation Principle Dependency Inversion PrincipleSingle Responsibility Principle Every module should have responsibility over a single part of

the functionality provided by the software, That responsibility should be entirely encapsulated by the

class All its services should be narrowly aligned with that

responsibilityTherefore Group together things that change together Separate things that change for different reason


Bounded context

Domain driven design The paradigm of designing software based on models

of the underlying domain The domain model helps the business and the

developers to reason about the functionality A model needs to be unified – internally consistent

without contradictions

Bounded context The bounded context is a central pattern in domain

driven design When you model larger domains, it becomes

progressively harder to create this single unified model So, instead of creating a single unified model, you

create several, all valid within their bounded context


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 but continuous improvements create long-lasting results (Kaizen)W. Edwards

Deming(sort of)


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


An approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button.

Aimed to make releases boring, so we can deliver frequently and get fast feedback on what users care about.

Jez Humble


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


Will it work?


One last thought…


What will you do in 2020?


You can be anything you want…


Because…


With passion you can achieve amazing things…


Writing code is the best job in the world



And don’t forgetto have fun



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

[email protected]

@aahoogendoorn