Ik wilde al een tijd een artikel schrijven over microservicesarchitectuur, maar twee dingen hielden me steeds tegen: hoe dieper ik in het onderwerp dook, hoe meer het me leek dat wat ik weet - voor de hand liggend is, en wat ik niet weet - nog verder moet worden bestudeerd. Aan de andere kant vind ik dat er al genoeg is om over na te denken en te bespreken met een breder publiek. Alternatieve meningen zijn welkom.
De wet van Conway en de relatie tussen business, organisatie en informatiesysteem
Ik zal mezelf nogmaals toestaan te citeren:
„Elke organisatie die een systeem ontwerpt (in brede zin) zal een ontwerp krijgen dat de structuur kopieert van de teams binnen die organisatie.”
— Melvyn Conway, 1967
Naar mijn mening heeft deze wet eerder betrekking op de doelmatigheid van de organisatie van het bedrijf dan direct op het informatiesysteem. Laat me dit uitleggen aan de hand van een voorbeeld. Stel, we hebben een vrij stabiele zakelijke kans met een levenscyclus die lang genoeg is om het zinvol te maken een onderneming te organiseren (geen typefout, maar ik hou erg van deze term die ik heb geleend). Uiteraard zal het ondersteunende systeem van dit bedrijf organisatorisch en procesmatig overeenkomen met dit bedrijf.
Businessgerichtheid van informatiesystemen
Laat me dit voorbeeld verder uitleggen. Stel dat er een zakelijke kans is om een bedrijf op te richten voor het verkopen van pizza. In versie V1 (laten we het 'voor-informatief' noemen) bestond het bedrijf uit een pizzeria, een kassa en een bezorgdienst. Deze versie was langlevend onder omstandigheden van lage veranderlijkheid in de omgeving. Vervolgens kwam versie 2 — geavanceerder en in staat om het informatiesysteem als basis te gebruiken voor een bedrijf met een monolithische architectuur. En hier, naar mijn mening, ontstaat een vreselijke ongelijkheid ten opzichte van monolithen — de zogenaamde monolithische architectuur past niet bij het domeinmodel van het bedrijf.Als dat zo was, zou het systeem helemaal niet kunnen functioneren - in strijd met dezelfde wet van Conway en gezond verstand. Nee, de monolithische architectuur sluit volledig aan bij het businessmodel op deze fase van de zakelijke ontwikkeling - ik bedoel natuurlijk de fase waarin het systeem al is gebouwd en in gebruik is genomen. Het is een opmerkelijk feit dat, ongeacht de architecturale aanpak, zowel de service-georiënteerde architectuur versie 3 als de microservices-architectuur versie N even goed zullen functioneren. Wat is de valkuil?
Alles stroomt, alles verandert, of zijn microservices een middel om de complexiteit te bestrijden?
Voordat we verder gaan, laten we enkele misverstanden over microservices-architectuur bekijken.
Voorstanders van de microservices-aanpak zeggen vaak dat het splitsen van een monoliet in microservices de ontwikkeling vereenvoudigt door de codebasis van individuele services te verkleinen. Naar mijn mening is deze bewering totale onzin. Serieus, lijkt de duidelijke interactie binnen een monoliet en homogene code ingewikkeld? Als dat echt zo was, zouden alle projecten vanaf het begin als microservices worden opgebouwd, terwijl de praktijk laat zien dat migratie van monolithen naar microservices veel gebruikelijker is. Complexiteit verdwijnt niet; het verschuift gewoon van afzonderlijke modules naar interfaces (of het nu gaat om databus, RPC, API en andere protocollen) en orkestratiesystemen. En dat is ingewikkeld!
Het voordeel van het gebruik van een heterogene stack is ook twijfelachtig. Ik ga niet beweren dat het mogelijk is, maar in de praktijk komt het zelden voor (Terwijl ik vooruitloop - dit zou er moeten zijn, maar eerder als gevolg dan als voordeel).
Levenscyclus van een product en levenscyclus van een service.
Kijk nog eens goed naar het diagram hierboven. Ik heb niet per ongeluk de verkorte levenscyclus van een afzonderlijke versie van de business gemarkeerd - in de huidige omstandigheden is het versnellen van de overgang tussen versies bepalend voor het succes. Het succes van een product wordt bepaald door de snelheid waarmee zakelijke hypotheses erin worden getest.. En hier ligt naar mijn mening het sleutelvoordeel van microservices-architectuur. Maar laten we het stap voor stap bekijken.
Laten we de volgende stap in de evolutie van informatiesystemen zetten — naar een service-georiënteerde architectuur (SOA). Op een bepaald moment hebben we een deel van ons product geïsoleerd. langdurige services — langdurig in de zin dat bij de overstap tussen productversies de kans bestaat dat de levenscyclus van de service langer is dan de levenscyclus van de volgende productversie. Het zou logisch zijn om ze helemaal niet aan te passen — voor ons is vooral de snelheid van overstappen naar de volgende versie belangrijk.. Maar helaas zijn we genoodzaakt om voortdurend veranderingen in de services aan te brengen — en hier is alles mogelijk, zowel DevOps-praktijken, containerisatie en meer — alles wat in je opkomt. Maar dit zijn nog steeds geen microservices!
Microservices als een middel om de complexiteit te beheersen… configuratiebeheer
En hier kunnen we eindelijk overgaan tot de bepalende rol van microservices — dit is een benadering die het beheer van de productconfiguratie vereenvoudigt. In detail beschrijft de functie van elke microservice precies de zakelijke functie binnen het product volgens het domeinmodel — en dat zijn al zaken die niet in de kortlevende versie leven, maar in de langdurige zakelijke mogelijkheden. En de overstap naar de volgende versie van het product gebeurt letterlijk onopgemerkt — je wijzigt/voegt één microservice toe, of misschien gewoon het schema van hun interactie, en plotseling bevind je je al in de toekomst, terwijl je de huilende concurrenten achterlaat die blijven springen tussen de versies van hun monolieten. Stel je nu voor dat er een behoorlijk aantal microservices is met vooraf gedefinieerde interfaces en zakelijke mogelijkheden. En je komt en bouwt de structuur van je product uit bestaande microservices — het is gewoon een kwestie van een diagram tekenen, bijvoorbeeld. Gefeliciteerd — je hebt een platform — en nu kun je je eigen bedrijf vormen. Dromen, dromen.
Conclusies
- De architectuur van het systeem moet worden bepaald door de levenscyclus van de componenten die erin zijn opgenomen. Als een component binnen de versie van het product leeft, heeft het geen zin om de complexiteit van het systeem te verhogen door een microservice-aanpak toe te passen.
- De microservice-architectuur moet gebaseerd zijn op het domeinmodel — omdat zakelijke mogelijkheden het meest langdurige gebied zijn.
- Leveringspraktijken (DevOps-praktijken) en orchestration hebben een van de belangrijkste betekenissen voor microservicesarchitectuur — omdat de toegenomen snelheid van componentwijzigingen hogere eisen stelt aan de snelheid en kwaliteit van de levering.
Bron: habr.com
