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?