Crowd Designing µ-Services Architecture

Bas van Oudenaarde, 12 oct 2016

Petje op Petje af

Stelling/vraag, vooraf stukje theorie/praktijk,

of achteraf

eerste Microservices

in gebruikGeen

Vraag: Zijn microservices een onderdeel in de huidige stack?

Doel: Samen de randvoorwaarden & architectuur-schets

neerzetten voor een volgende microservice implementatie aan de hand van praktische

praktijk-cases

( Designing van een microservices architectuur is een Team sport )

Trends…

Petje op Petje af

Agile werken?

?

Petje op Petje af

Architectuur-vorm?

“DevOps triangle of succes”

Infra as Codeµ Services architecture

Conways Law"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure." Conway, 1968

Conways Law…

Trends, Agile Teams -> microservices architectuur

Omgekeerd geldt dit niet! Architectuur -> Teams

Petje op Petje af

Polyglot Stacks; Agile Teams

Company-wide Development stack Team keuze

Petje op Petje af

Domain (ownership):

Object shared tussen applicatie/componenten

no-shared object

DDD of MDD: Bounded Context

Belangrijke stap: Full-Stack Teams en ownership business domain

Petje op Petje af

µServices met SOA platform?

• Doel: snelheid behouden / flexibel / schaalbaar • Systeem is de gehele architectuur

µServices met SOA platform?

Hoe schalen met Tibco platform? Multi-stack?

Hoe schaalt (state-fullness) bv database?

Vergeet Canonical Data Models; schaalt niet / slow / lastig in DDD context

( https://www.innoq.com/en/blog/thoughts-on-a-canonical-data-model/ https://www.linkedin.com/pulse/canonical-data-model-world-microservices-robert-zakrzewski )

Application-layer

messaging-layer

‘Middleware’-layer

distributed key-value store

OS

infra-layer

Voorbeeld: Java-Stack, gehele stack orchestrating:

Messaging: bv. mqtt /

µServices µServicesµServices

Application - messaging distributed

configuration mngt distributed

µServices

Schalen van messaging & config tussen verschillende nodes

Application-layer

distributed key-value store

OSinfra-layer

Voorbeeld: Java-Stack, gehele stack orchestrating:

µServicesInterfacing

Proces

Domain

ServicesBackend / Integration

Agent / Swarm based: verantwoordelijk voor eigen Lifecycle (decentraal)

CoreOSAWS / on Prem

docker

Agent / Swarm based:• Service discovery ( Consul / NGinx) • Bootstrapping -> Reactive !

• Life cycle mngt -> scaling, health

InterfaProcesDomaiServicBackeInterfaProcesDomaiServicBacke

InterfaProcesDomaiServicBacke

Application - messaging distributed

CDM een must in ESB

Wat moeten we met CDM ?

One for All

CDM niet nodig met Bounded Context?

Macro-Micro:

In discussie marco-micro verwarring

macro-level: Integratie context, hoe beweging in te zetten naar µ Services

Monoliet: • DDD: Bounded Context / Root aggregates • Modulair opgebouwd, modulair te bouwen • Wel in 1 repo (vaak) • Goed opletten vanwege interne API koppeling; meer ‘regelen’ qua afspraken dus…

Meer onafhankelijk, snelheid en ownership -> µ Services

Petje op Petje af

Source Repo’s

Petje op Petje af

Network as a Service?( SDx)

infra provisionbaar testbaar

“De

Petje op Petje af

Infra as Code?

Handmatig? semi-automatisch

wel scripts geen version control

Geen testen

“De

Petje op Petje af

Services Versioning policies?

no versioning

versioning concept

(auto numbering)

Services Versioning policies?…• Handig voor multi-team communicatie / planning

• Lazy Developers -> automatisch versioning • Lazy Developers -> Geen meta-flags

bv 1.0-SNAPSHOT • Lazy Developers -> Geen feature-branches, lastig branches; feature-toggles ook lastig; forward model

Petje op Petje af

Versioning-context?

versioning, strak in relaties

geen expliciete versies in services

Kijk meer in geheel

(stofwolk)

6

StelUPKbestaatuit4services:A,B,C,D

A

C D

B15 6

7 50

Label:upk1A

C D

B15 5

7 49

A

C D

B15 6

7 302

Label:upk2

Time

RegressionTestfailed

RegressionTestpassed

TargetLabelupk 1

Petje op Petje af

Schieten we te ver door? nano-services

meer services, minder afhankelijkheden

Run-time depedencies?Let op: geen compile time decencies, alle componenten bouwen syntactisch los van elkaar

A

C D

B

A:10,11,12,13,14,15,…

B:3,4,5,6…

C:1,2…

D:300,301,302,…

15 6

2 302

A

C D

B

relatiesomgeving

μService:

Continuous Delivery Context

Petje op Petje af

Libraries gebruik?

DRY,gebruik libs

blijven services compatible indien Libs versies omhoog gaan en niet direct in alle services meegaan

Geen shared libs

• Nightly build fix alle nieuwe libs in alle µ componenten• Geen versioning• n-1 beleid• Fout in Software Architectuur

Libraries gebruik…

Wrapping up…

“DevOps triangle of succes”

Infra as Codeµ Services architecture

http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

On Prem vs Cloud

Op naar µ Biertje?