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

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?