We hadden webservices, wcf services en rest services, maar die waren het allemaal net niet. Gelukkig zijn er nu microservices. En iedereen leefde nog lang en gelukkig. Of toch niet? In deze sessie kijken we hoe we kunnen falen en slagen met microservices. Waarom er door verstokte oude mannen wordt gezegd dat microservices zijn hoe ze een service geörienteerde architectuur altijd bedoeld hadden. Waarom het definiëren van je bounded context zo ontzettend belangrijk is. Omdat je dan het verschil kunt maken tussen het opnieuw bouwen van een monolith vol microservices of een goede architectuur.
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
How to build microservices
1. Dennis van der Stelt
monoliths are bad; therefor microservices are good
Dennis van der Stelt
http://dennis.bloggingabout.net/
dennis@bloggingabout.net
Solution Architect at Particular Software
MICROSERVICES
@dvdstelt
7. Dennis van der Stelt
“Failure is simply
the opportunity
to begin again,
this time more
intelligently.”
HENRY FORD
8. Dennis van der Stelt
CONWAY’S LAW (1967)
organizations which design systems ... are constrained to produce designs which
are copies of the communication structures of these organizations
“
”
10. Dennis van der Stelt
Use grammatical inspection technique of highlighting all the nouns in the text.
You will find that :
- Nouns become classes & attributes
- Verbs become methods and relations
NOUN/VERB ANALYSIS
Thought at school when we were young and naïve…
- Nouns become things (objects, services, bounded contexts, etc)
- Verbs are how they talk to each other
11. Dennis van der Stelt
Use grammatical inspection technique of highlighting all the nouns in the text.
You will find that :
- Nouns become things (objects, services, bounded contexts, etc)
- Verbs are how they talk to each other
NOUN/VERB ANALYSIS
Thought at school when we were young and naïve…
15. Dennis van der Stelt
Sales
Lists requests made by
customer
Customer
Displays customer
information such as
name and current
location
Taxi
Shows where taxi drivers
are and at what time they
arrive at your location
Finance
COMPOSITE UI
Micro views
16. Dennis van der Stelt
Handle business events through
Inversion of communication
by supplementing SOA with
EDA
“
”
18. Dennis van der Stelt
find me.
http://dennis.bloggingabout.net
dvdstelt@bloggingabout.net
Editor's Notes
- Veel bedrijven, veelal gezien wat niet werkt. Wat werkt wel?
- Vooral populaire onderwerpen zijn moeilijk. Buzzwords.
- Klanten die zeggen, we gaan dit oplossen met SOA.
- Hoe dan? Webservices die webservices aanroepen, die webservices aanroepen. Maar dat gaat niet werken.
- Nee, maar dit keer zijn het REST server, die REST services aanroepen, etc.
- Dit keer wordt het echt anders, micro services calling micro services
Wie heeft er ooit gewerkt met …
ASP.NET WebServices (asmx) -> SOA
WCF WebServices (svc) -> Don Box met 4 tenets of SOA
WebAPI REST Services
WAAROM IS WCF DOOD? WebAPI draaide origineel op WCF!
Maar WCF was niet cool meer.
WCF moest dood.
SOAP moest dood.
XML moest dood.
JSON!!! Zelfs xml config in Visual Studio moest om!
Microservices op REST & JSON
Serverless??? Applicaties die volledig draaien op 3rd party apps/services _of_ draaien in containers die héél kort leven
HOE KAN DAT? Netflix doet het toch ook!!!
Netflix doet iets met microservices, maar ze leggen niet uit hoe ze dat doen. Kan werken in hun geval, maar onduidelijk is wat & hoe.
Ik zie het nooit werken. Probleem is altijd tightly coupled designs.
Wie heeft dat ook, tightly coupled designs die niet werken?
Hoe je het ook noemt, tightly coupled werkt niet. Webservices, REST services, micro services, etc.
Probleem hier : tightly coupled orchestration
Dat is 90% van wat je moet weten als developer, de rest is marketing. Tight coupling werkt niet.
De overige 10% is wat wel werkt : encapsulation
Bouw software die highly cohesive (samenwerken) & well encapsulated is, en dan heb je vanzelf loose coupling.
Verhaal portemonee
Dit komt terug op zaken die al heel oud zijn. Elke 10 jaar komt er echter iets nieuws wat een hoop buzz creeërt en waar veel mensen aan mee willen doen.
High cohesion, low coupling
That’s all SOA is : High cohesion, low couplingThat’s all Object Orientation is : High cohesion, low couplingThat’s all micro services is : High cohesion, low coupling
De rest is marketing! Maar wie zou er naar een conferentie over OO design gaan?
SOA & Microservices is interessant! Vertel meer! Waarom moeten die services zo klein zijn?!
Allemaal marketing. Hoe je het ook vorm geeft, dit is waar het om gaat : High cohesion, low coupling
Maar dit is MOEILIJK !!! High encapsulation betekent verantwoordelijkheden vinden
Daar hoor je niemand over! Allemaal techniek, allemaal oplossingen, maar wat is het probleem?
Dat we nu een Docker containerized runtime wat-het-ook-is hebben, maakt het niet minder eenvoudig om verantwoordelijkheden te vinden.
Dit doen we jaar na jaar na jaar…
OO, Componetized, SOA, REST, Microservices, Serverless…
Praat met domein experts!!!
noun = zelfstandig naamwoord
verb = werkwoord
The word service is too overloaded
Probeer met Monopoly. En pak dan niet het board, de pionnen, het geld. Maar begin met de spelregels!
Every verb creates coupling between two ‘things’
“Een ding doet een werkwoord met een ander ding”
Vul dit in met webservices, rest services, micro services. Die gaan deze koppeling niet voor je oplossen!
Je eindigt met iets dat tightly coupled is, en dat is het probleem.
Hoe dan wel???
Opnieuw, stel vragen aan de business! Hoe werkt dit allemaal?
Zelfstandig naamwoord zoals klant en naam en locatie en meer data. Allemaal attributen.
Architecten laten attributen over aan developers, dat is te diep techniek in. Maar er zit veel waarde in ze!!!
Vraag jezelf af, zitten deze attributen in dezelfde transactie?
Voorbeeld : klantnaam en korting. Behoren die in dezelfde transactie?
Maak er een requirement van.
Als een klantnaam meer dan 7 karakters is, dan kan hij niet meer dan 7% korting hebben.
Dat is gek. De business zal vragen wat er mis met je is.
Dat is goed! Klantnaam en korting horen niet bij elkaar! Geen consistency requirements.
We maken iets highly consistent waar de business totaal geen waarde aan hecht!!!
Je kunt het ook van andere kant bekijken.
Als er een product in de aanbieding is, mag een klant geen korting op dat product.
Die zijn attributen van verschillende entiteiten, die dus blijkbaar wel heel dicht bij elkaar horen te zijn. Er zijn consistency requirements!
Onderzoek dit soort regels en controleer of er een consistency requirement is. Dan horen ze bij elkaar.
Je krijgt zo een heleboel attributen die bij elkaar horen! Geïndexeerd door één identifier.
Klanten-korting met een klanten id, ergens anders klantnaam met klanten id.
Werkt hetzelfde als foreign keys in relationele database!
Zo krijg je ‘dingen’ waarvan business je vertelt dat ze tightly coupled zijn.
Als we die bij elkaar stoppen in één object, is het encapsulated, en highly cohesive!!!
Als we een project starten, luisteren we naar business, lopen naar whiteboard, tekenen vierkantjes en geven ze een naam.
Naamgeving is een van moeilijkste zaken in development. En we doen het als we nog bijna niets weten van het domein!
Doe het andersom. Begin met wat je weet, maar zet het niet in een vierkantje, totdat je weet wat er echt in moet en bij elkaar hoort.
Eerst de verantwoordelijkheden onderkennen!
Als je dit doet, kunnen ontwikkelaars zeggen : “Dit duurt lang, wanneer gaan we nou eens code schrijven?”
Zie een project als een reis die begint met een enkele stap.
Als je eerste stap de verkeerde kant op is, sla je een flater aan het einde van de reis.
Deze exercitie is je orienteren welke kant je op moet.
Layering is voor separation of concerns. Maar scheidt UI van de rest en dan weet je voldoende en hoef je niet meer layering toe te passen.
We lossen complexe problemen vaak op door meer layers toe te voegen. Niet doen!
En als we iets in UI hebben wat tightly coupled is aan product of prijs, waarom stoppen we dat niet samen?
UI deel & data persistence deel gaan goed samen!
Als het in onze analyse niet samen ging, kan het wel samen op het scherm, maar praten die delen niet met elkaar.
Vertical slicing ipv horizontal layering