{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Microservices: wat zijn ze, waarom zijn ze nodig en wanneer moeten ze worden ge\u00efmplementeerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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.
\n<\/a><\/noindex><\/p>\n

De wet van Conway en de relatie tussen business, organisatie en informatiesysteem<\/h2>\n

\nIk zal mezelf nogmaals toestaan te citeren:<\/p>\n

\u201eElke organisatie die een systeem ontwerpt (in brede zin) zal een ontwerp krijgen dat de structuur kopieert van de teams binnen die organisatie.\u201d
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

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.<\/p>\n

Businessgerichtheid van informatiesystemen<\/h2>\n

\n\"Microservices:
\n
\nLaat 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 \u2014 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 \u2014 de zogenaamde monolithische architectuur past niet bij het domeinmodel van het bedrijf.<\/b>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\u00ebnteerde architectuur versie 3 als de microservices-architectuur versie N even goed zullen functioneren. Wat is de valkuil?<\/p>\n

Alles stroomt, alles verandert, of zijn microservices een middel om de complexiteit te bestrijden?<\/h2>\n

\n Voordat we verder gaan, laten we enkele misverstanden over microservices-architectuur bekijken.<\/p>\n

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! <\/p>\n

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).<\/p>\n

Levenscyclus van een product en levenscyclus van een service.<\/h2>\n

\nKijk 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.<\/b>. En hier ligt naar mijn mening het sleutelvoordeel van microservices-architectuur. Maar laten we het stap voor stap bekijken. <\/p>\n

Laten we de volgende stap in de evolutie van informatiesystemen zetten \u2014 naar een service-geori\u00ebnteerde architectuur (SOA). Op een bepaald moment hebben we een deel van ons product ge\u00efsoleerd. langdurige services<\/b> \u2014 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 \u2014 voor ons is vooral de snelheid van overstappen naar de volgende versie belangrijk.<\/b>. Maar helaas zijn we genoodzaakt om voortdurend veranderingen in de services aan te brengen \u2014 en hier is alles mogelijk, zowel DevOps-praktijken, containerisatie en meer \u2014 alles wat in je opkomt. Maar dit zijn nog steeds geen microservices! <\/p>\n

Microservices als een middel om de complexiteit te beheersen\u2026 configuratiebeheer<\/h2>\n

\n En hier kunnen we eindelijk overgaan tot de bepalende rol van microservices \u2014 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 \u2014 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 \u2014 je wijzigt\/voegt \u00e9\u00e9n 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 \u2014 het is gewoon een kwestie van een diagram tekenen, bijvoorbeeld. Gefeliciteerd \u2014 je hebt een platform \u2014 en nu kun je je eigen bedrijf vormen. Dromen, dromen. <\/p>\n

Conclusies<\/h2>\n

<\/p>\n