Microservices randvoorwaarden / keuzes die genomen moeten worden

1. Crowd Designing µ-Services
Architecture
Bas van Oudenaarde, 12 oct 2016

2. Petje op Petje af
Stelling/vraag,
vooraf stukje theorie/praktijk,
of achteraf
eerste
Microservices
in gebruik
Geen
Vraag: Zijn microservices een onderdeel in de huidige stack?

3. 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 )

4. Trends…

5. Petje op Petje af
Agile werken?
?

6. Petje op Petje af
Architectuur-vorm?

7. “DevOps triangle of succes”
Infra as Codeµ Services architecture

8. 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

9. Conways Law…
Trends, Agile Teams -> microservices architectuur
Omgekeerd geldt dit niet! Architectuur -> Teams

10. Petje op Petje af
Polyglot Stacks; Agile Teams
Company-wide
Development stack
Team keuze

11. Petje op Petje af
Domain (ownership):
Object shared tussen
applicatie/componenten
no-shared object

12. DDD of MDD: Bounded Context
Belangrijke stap: Full-Stack Teams en ownership business domain

13. Petje op Petje af
µServices met SOA platform?

14. • 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 )

15. 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

16. Application - messaging distributed
configuration mngt distributed
µServices
Schalen van messaging & config tussen verschillende nodes

17. Application-layer
distributed
key-value store
OS
infra-layer
Voorbeeld: Java-Stack, gehele stack orchestrating:
µServices
Interfacing
Proces
Domain
Services
Backend / Integration
Agent / Swarm based: verantwoordelijk
voor eigen Lifecycle (decentraal)
CoreOS
AWS / on Prem
docker

18. Agent / Swarm based:
• Service discovery ( Consul / NGinx)
• Bootstrapping -> Reactive !
• Life cycle mngt -> scaling, health
Interfa
ProcesDomai
ServicBacke
Interfa
ProcesDomai
ServicBacke
Interfa
ProcesDomai
ServicBacke
Application - messaging distributed

19. CDM een must in ESB
Wat moeten we met CDM ?
One for All

20. CDM niet nodig met Bounded Context?

21. Macro-Micro:
In discussie marco-micro verwarring
macro-level: Integratie context, hoe
beweging in te zetten naar µ Services

22. 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

23. Petje op Petje af
Source Repo’s

24. Petje op Petje af
Network as a Service?( SDx)
infra provisionbaar
testbaar
“De

26. Petje op Petje af
Infra as Code?
Handmatig?
semi-automatisch
wel scripts
geen version control
Geen testen
“De

27. Petje op Petje af
Services Versioning policies?
no versioning
versioning
concept
(auto numbering)

28. 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

29. Petje op Petje af
Versioning-context?
versioning, strak in
relaties
geen expliciete versies
in services
Kijk meer in geheel
(stofwolk)

30. 6
Stel UPK bestaat uit 4 services: A, B, C, D
A
C D
B15 6
7 50
Label: upk 1
A
C D
B15 5
7 49
A
C D
B15 6
7 302
Label: upk 2
Time
Regression
Test failed
Regression
Test passed
Target Label
upk 1

31. 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

32. Continuous Delivery Context

33. 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

34. • Nightly build fix alle nieuwe libs in alle µ componenten
• Geen versioning
• n-1 beleid
• Fout in Software Architectuur
Libraries gebruik…

35. Wrapping up…

36. “DevOps triangle of succes”
Infra as Codeµ Services architecture

37. http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
On Prem vs Cloud

39. Op naar µ Biertje?