Microservices. The good the bad and the ugly

@aahoogendoorn

MICROSERVICESTHE GOOD, THE BAD AND THE UGLYSander Hoogendoornditisagile.nlMentoring ▪ Consulting ▪ Training ▪ Agile ▪ Software architecture ▪ Code

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?©2015 ditisagile.nl. All Rights Reserved 2@aahoogendoorn

www.ditisagile.nl

Sander Hoogendoorn

Me Dad Mentor, trainer, software architect, programmer Books, articles, conferences

Work Owner, ditisagile.nl CTO Klaverblad Verzekeringen [PTO Capgemini] [Global design authority agile Capgemini]

Web www.sanderhoogendoorn.com www.smartusecase.com www.speedbird9.com @aahoogendoorn [email protected]


www.ditisagile.nl


www.ditisagile.nl

On being a developer...

@aahoogendoorn

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


www.ditisagile.nl

Monoliths

Advantages A single (layered) architecture

A single technology stack

A single code base maintained by multiple teams

Disadvantages All parts are interconnected

Many other systems are connected to your system

Hard to change, hard to maintain

Long time between releases, thereby increasing risks

Slow innovation

Hard to move to newer technologies

Doesn’t scale very well

Product Account

Order Customer

Products Accounts

Orders Customers


www.ditisagile.nl

Dependencies will kill you

@aahoogendoorn

A BRIEF HISTORY OF COMPONENTS AND SERVICES


www.ditisagile.nl

Client server


www.ditisagile.nl

Component based development


www.ditisagile.nl

Service oriented architecture


www.ditisagile.nl

Microservices

@aahoogendoorn

MICROSERVICESBeyond the hype?


www.ditisagile.nl

Microservices. Beyond the hype?


www.ditisagile.nl

Gartner hype cycle

@aahoogendoorn

MICROSERVICESThe clear benefits


www.ditisagile.nl

BUT FIRST… A DEFINITION


www.ditisagile.nl

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


www.ditisagile.nl

Monoliths. Scalability

Product Account

Order Customer

Product Account

Order Customer

Product Account

Order Customer


www.ditisagile.nl

Microservices. Scalability

Product Account

OrderCustomer


www.ditisagile.nl


Product Account

OrderCustomer

Product

CustomerCustomer Customer

Account Account


www.ditisagile.nl


Product Account

Order

Product

Customer

Account Account

CustomerCustomer


www.ditisagile.nl

Monoliths. Persistence

Product Account

Order Customer

Products Accounts

Orders Customers


www.ditisagile.nl

Microservices. Polyglot persistence

Product Account OrderCustomer

MongoDB

Customers

MongoDB

Orders

Active Directory

Accounts

Oracle

Products


www.ditisagile.nl

Microservices. Promises

Products not projects

Scalable

Decentralized governance

Replaceable parts

High performance

Technology independent

Polyglot persistence

Easy to build

Easy to test

Easier deployment than monoliths

ProductAccount

Order

Customer


www.ditisagile.nl

Microservices. But…

What is a microservice exactly?

How small is a microservice?

Requirements in a microservice world

Components or services

Who owns a microservice?

What technologies do you use?

What protocols do you apply?

How to define messages

How to test microservices

How to coordinate when business services run across components?

How to build deployment pipelines?

ProductAccount

Order

Customer


www.ditisagile.nl

Opinions, opinions, opinions

@aahoogendoorn

ARE MICROSERVICESA STAIRWAY TO HEAVEN?

@aahoogendoorn

OR A HIGHWAY TO HELL?

@aahoogendoorn

MICROSERVICESIN THE REAL WORLD


www.ditisagile.nl

A major Dutch insurance company

We have Most functionality on an expensive mainframe

A wide variety of large systems written in Java that are hard to maintain and to test, and that are very hard to replace

Individual systems that cover large areas of functionality, usually coupled to departments

Aging technology

No mobile strategy, allowing for new business or new services to clients, and intermediaries

We need to Get rid of the mainframe

Shorten time-to-market

Lower TCO

Uphold a fully secure systems landscape


www.ditisagile.nl

FOR THE THINGS WE HAVE TO LEARN BEFORE WE CAN DO THEM, WE LEARN BY DOING THEM

Aristotle

@aahoogendoorn

SO WHAT DID WE LEARN?


www.ditisagile.nl

MICROSERVICES REQUIRE AN EVOLUTIONARY ARCHITECTURE


www.ditisagile.nl

Questions, questions, questions

Communication architecture. The glueHow do we define interfaces between apps and component? How do we arrange messaging?

How do we glue together rapidly changing apps and component?

Application architectureEnd user facing Different users, different fast evolving needs

Which technology is the best for which purpose?

Component architectureComponents and services are evolving rapidly. How do we decide which components we need? How do we deal with versioning? How do we deal with distributed processes and transactions?


www.ditisagile.nl

Our guiding principles

We decided to go from here Client thinks in business processes, so we implement

business processes We move away from the mainframe, to a new systems

landscape, consisting of micro-applications and micro-components

Requirements and documentation are modeled rather than written

Applications implement a single (elementary) business process

Components serve a single purpose and offer services Applications and components all have their own bounded

context – a domain model Applications and components will have an similar internal

software architecture to facilitate ease of maintenance and allow for harvesting re-use

Communication between applications and components will use a simple open protocol - REST

@aahoogendoorn

APPLICATION ARCHITECTURE


www.ditisagile.nl

Presentation

Process

Domain

Services

Outside world

PagesGrids / Panels, Controls

Use casesFlow

Domain objects, Factories / RepositoriesEnums / Value objects / Tupels / Reference objects

Service gateways, Service clientsInfo objects / Search objects

ComponentsRelations Dossiers Intermediaries Accounts Rates

@aahoogendoorn

COMPONENT ARCHITECTURE


www.ditisagile.nl

Service interface

Process

Domain

Data / Services

Outside world

ResourcesRepresentations

Use casesFlow

Domain objects, Factories / RepositoriesEnums / Value objects / Tupels / Reference objects

Storage gateways, Storage clientsInfo objects / Search objects

StorageRelations Dossiers Intermediaries DB2 MongoDB

@aahoogendoorn

DESIGNING MICROSERVICES


www.ditisagile.nl

DOING BIG UP-FRONT DESIGN IS DUMBDOING NO DESIGN IS EVEN DUMBER

Dave Thomas


www.ditisagile.nl

The single unified domain model

Product

Vendor

StockOrder

Client

Delivery

Payment


www.ditisagile.nl

Bounded contexts

Product

Vendor

StockOrder

Client

Delivery

Payment

Product

@aahoogendoorn

MODELING APPLICATIONS


www.ditisagile.nl

Smart use cases


www.ditisagile.nl

52Applicationbounded context

@aahoogendoorn

MODELING COMPONENTS


www.ditisagile.nl

55Resource model

@aahoogendoorn

AND THE REST ISCOMMUNICATION (OVER HTTP)


www.ditisagile.nl

HTTP RETURN CODES CHEAT SHEET1**. Hold on

2**. Here you go 3**. Go away

4**. You fucked up 5**. I fucked up


www.ditisagile.nl

HTTP GET

GET

Retrieve whatever information is identified by the request URI in the form of an entity

The entity is usually a single or a list of objects (of the type provided by the service, often JSON, or XML)

GET is safe (retrieval only) and idempotent

Unfortunately there are many ways of creating GET requests (see examples below)

Returns 200 (found), possibly 400 (bad request) or 404 (not found)

Examples

Get an entire collectionlocalhost:8080/countries

Find objects in the collectionlocalhost:8080/countries?name=“stan”

Find an object in the collection by IDlocalhost:8080/countries/38

Find a sub-object in the collection by IDlocalhost:8080/countries/38/capital

Find object in the collection by ISOlocalhost:8080/countries?isocode=“GRC”

Find object in the collection by ISOlocalhost:8080/countries/isocode/GRC

Find object in the collection by ISOlocalhost:8080/countries/GRC


www.ditisagile.nl

BE CONSERVATIVE IN WHAT YOU SEND, BE LIBERAL IN WHAT YOU ACCEPT

Postel’s Law

@aahoogendoorn

TESTING MICROSERVICES


www.ditisagile.nl

A service development lifecycle

Code Developer Test Test Integration Test Acceptance Test LivePrepare & Design


www.ditisagile.nl

What to test


DevelopersUnit tests

DevelopersQ & A

TestersScenario’s & API’s


Product ownerProduct


www.ditisagile.nl

What to test automated


DevelopersUnit tests

DevelopersQ & A



Product ownerProduct

@aahoogendoorn

DEPLOYING MICROSERVICESContinuous integration, build pipelines and continuous delivery


www.ditisagile.nl

A typical build pipeline



www.ditisagile.nl

ProductionAcceptanceIntegrationTestDevelopment

A typical build pipeline



www.ditisagile.nl

Build pipelines in Jenkins


www.ditisagile.nl

Microservices. Building a deployment pipeline

Code Developer Test Test Acceptance Test Acceptance Live





www.ditisagile.nl

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

@aahoogendoorn

DO WE REALLY NEED PROJECTS?From projects to releases to continuous delivery


www.ditisagile.nl

Do we really need projects?


www.ditisagile.nl

Or roadmap?


www.ditisagile.nl

Minimal viable product


www.ditisagile.nl

And go with the flow


www.ditisagile.nl

Maintenance

From projects to continuous delivery?

Project

MaintenanceMVP

MaintenanceContinuous delivery

@aahoogendoorn

@aahoogendoorn

ALLOW YOUR TEAMS TO LEARN CONTINUOUSLY…


www.ditisagile.nl

The hockey stick model

@aahoogendoorn

… AND HAVE FUN


www.ditisagile.nl

ONE LAST THOUGHT…


www.ditisagile.nl

WHAT WILL YOU DO IN 2020?


www.ditisagile.nl

You can be anything you want…


www.ditisagile.nl

Because…


www.ditisagile.nl

With passion you can achieve amazing things…


www.ditisagile.nl

WRITING CODE IS THE BEST JOB IN THE WORLD

@aahoogendoorn

THIS IS AGILE

www.createspace.com/4747266

Password: agilescrum

Discount code: KGNWKKWG

@aahoogendoorn

www.sanderhoogendoorn.comwww.smartusecase.comwww.speedbird9.com

[email protected]

@aahoogendoorn

REFERENCES AND QUESTIONS

Microservices. The good the bad and the ugly

Software

Transcript of Microservices. The good the bad and the ugly