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

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

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

sander@ditisagile.nl

@aahoogendoorn

Microservices. Stairway to heaven or highway to hell

Software

Transcript of Microservices. Stairway to heaven or highway to hell

Hieroglyphic Stairway of Copán, Honduras Hieroglyphic Stairway of Copán, Honduras Study Results and Conservation Proposals The Hieroglyphic Stairway of Copán, Honduras a project

Heaven STAIRWAY TO

Storyboard - The Stairway from Hell

Microservices: Aren't Microservices Just SOA?

Combisafe Site Stairway - Kerrect Groupkerrect.com.au/assets/combisafe_temporary_stairway.pdf · development of the Combisafe Site Stairway The Combisafe Site Stairway has been ...

Stairway to Heaven or Highway to Hell: Liquidity, Sweat Equity, and ...

Craneway Stairway Strategy

Thirty months of microservices. Stairway to heaven or highway to hell

STAIRWAY TO CLOUD OR HIGHWAY TO HELL? · security “OF” the cloud. Customer data. Platform, applications, identity and access management ... public 01. cloud security. 02. Automated

MARRIAGE & DIVORCE: Stairway To Paradise Or Hell

Consumer-driven contracts: avoid microservices integration hell! (MuCon London - Nov 2016)

STAIRWAY TO SUCCESS

Designing and building a micro-services architecture. Stairway to heaven or a highway to hell?

From Stairway to Heaven onto the Highway to Hell with Xtext

Microservices and Prometheus (Microservices NYC 2016)

TEN-T Corridors – Stairway to Heaven or Highway to Hell?

Thirty months of microservices. Stairway to heaven or highway to hell? - Sander Hoogendoorn - Codemotion Milan 2016

Nature's Stairway

The Stairway - Analysis

What's Better than Microservices? Serverless Microservices.