How to build microservices
•
0 recomendaciones•1,358 vistas
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.
Recomendados
Recomendados
Más contenido relacionado
Más de Dennis van der Stelt
Más de Dennis van der Stelt (14)
Último
Último (20)
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
- 2. Dennis van der Stelt
- 3. Dennis van der Stelt
- 4. Dennis van der Stelt
- 5. Dennis van der Stelt
- 6. Dennis van der Stelt
- 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 “ ”
- 9. Dennis van der Stelt domain experts
- 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…
- 12. Dennis van der Stelt
- 13. Dennis van der Stelt
- 14. Dennis van der Stelt
- 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 “ ”
- 17. SOA is business agility
- 18. Dennis van der Stelt find me. http://dennis.bloggingabout.net dvdstelt@bloggingabout.net
Notas del editor
- - 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 coupling That’s all Object Orientation is : High cohesion, low coupling That’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