Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Microservices is stap in software-ontwikkeling

Channelweb Expert

Ruud Pieterse
Master Information Systems Architect, DXC Technology. Expert van Channelweb voor de topics Cloud Computing, Infrastructuur en Datacenters.

Softwaredevelopment is in de loop der jaren aan grote veranderingen onderhevig geweest. In vroegere tijden was een monolithische aanpak vanzelfsprekend. Er werd een allesomvattend product opgeleverd dat alle functies bevatte. In de huidige tijd van devops, containers, cloud en ci/cd is de wereld radicaal aan het veranderen.

Een ontwikkelmethode die steeds meer momentum krijgt is microservices. Microservices is de opvolger van service oriented architecture. Feitelijk komt het bij microservices erop neer dat software in kleinere modules wordt ontwikkeld. Dit kan bijvoorbeeld een e-mailfunctie zijn, een payment module of een product catalogus. Eigenschap van een module is dat deze eenduidige functionaliteit bevat, en onafhankelijk kan schalen en getest kan worden. Het gebruik maken van nieuwe technieken zoals containerization geven een additionele impuls aan deze nieuwe manier van werken.

Deze techniek kan een hogere beschikbaarheid van de applicatie bewerkstelligen. De ontwikkeltechniek leent zich uitstekend om in een devops-straat te worden ontwikkeld. Immers het minimal viable product staat als zodanig vast, en kan zelfs uit meerdere andere kleinere producten bestaan.

Er zijn ook nadelen. Het te ontwikkelen product kan te klein zijn voor ontwikkeling in een microservice-structuur. Verder vereist het veel nieuwe tooling en zijn er afhankelijkheden.

Mandaat

"De watervalmethode gaf doorgaans een goed overzicht over het totaalbeeld, maar nu kan dat opeens heel anders zijn"

Er is een groot belang om de organisatie klaar te maken voor deze ontwikkelingen. Er moet een mandaat zijn vanuit het management om de teams op deze manier te laten werken. Er zullen processen moeten worden ontwikkeld die duidelijkheid gaan geven. Iedereen zal ook moeten wennen aan de iteraties die bij deze nieuwe manier van ontwikkelen nodig zijn. Immers, de watervalmethode gaf doorgaans een goed overzicht over het totaalbeeld. Nu kan dat opeens heel anders zijn.

Het gebruik van microservices leent zich beter voor bestaande applicaties dan voor applicaties die van scratch worden ontwikkeld. Modules uit een applicatie kunnen eruit worden genomen (neem als voorbeeld de e-mailfunctionaliteit) en opnieuw ontwikkeld worden.

De businesswaarde van microservices ligt in het feit dat ze de mogelijkheid bieden om sneller in te kunnen springen op ontwikkelingen wanneer de markt om deze veranderingen vraagt. Er is geen lang traject nodig om de hele applicatie door te spitten en de verandering door te voeren. Kleinere modules zijn sneller aan te passen als ze goed geordend zijn. Er zijn nog meer goede redenen om microservices te gebruiken. Het herschrijven van modules omdat ze gebruikmaken van oude technieken is zo’n reden.  Of het feit dat applicaties wellicht gebruik kunnen maken van features die nu al in de cloud beschikbaar zijn. Hierdoor kunnen de modules minder complex worden. Als laatste kunnen de mogelijkheden van het gebruik van api’s een acceleratie leveren op het gebied van kostenreductie. Immers, veel functionaliteit is te verkrijgen via een api en is vaak nog actueler dan code van de applicatie waar data voor moet worden aangeleverd.

Microservices als methodiek is conceptueel al ver. Invoering ervan vereist nog tijd. De tijd is nu, want dat deze richting wordt ingeslagen in een wereld waarin steeds meer wordt samengewerkt vanuit de cloud is onvermijdelijk.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Microservices passen geheel binnen het idee van top-down stepwise refinement van… processen.
Het zijn dus eigenlijk microprocessen of microfuncties.

En dat is een beproefde methode voor complexiteitsreductie en hergebruik van software, die al werd toegepast bij de ontwikkeling van oude, in Cobol geprogrammeerde legacy-systemen.

Leuke theorie om een monoliet te decomposeren in onafhankelijke modules. Al eens gedaan ?
Als het product niet complex is levert het geen winst omdat het niet complex is.
Is het wel complex dan lukt het niet omdat het wel complex is.

Wat al modulair is, dat haal je eruit en ga je nogmaals implementeren. Toevallig als dat nu net een schaalbaarheidsvoordeel oplevert.
De spaghetti laat je zitten.
Wat over blijft is een monoliet + microservices met de nadelen van beide en de nadelen van het geheel.

Hoera.

"Er zijn nog meer goede redenen om microservices te gebruiken. Het herschrijven van modules omdat ze gebruikmaken van oude technieken is zo’n reden".
Bezigheidstherapie :-)

Jack,
Een microservice architectuur is vooral een variant op de service georiënteerde architectuur (SOA) waar één van de problemen de 'disconnected processes' zijn. Veel processen blijken de som der delen te zijn waarin een goede afstemming bepalend is voor de juiste uitkomsten. Het is opmerkelijk dat Master Information Systems Architect het verschil niet ziet tussen coderingsparadigma's master data management wat in de governance processen op macro niveau bepalend is.

Voor de discussie, het zinnetje onder e-mails die ontvanger vraagt om informatie te negeren en te verwijderen geeft aan waar het probleem zit. Wat betreft samenwerken in de cloud is het goed om vooraf afspraken te maken aangaande het delen, bewaren en uiteindelijk verwijderen van gegevens. De stappen in software ontwikkeling zijn leuk maar data blijft het residu van digitale processen waar nog altijd niet genoeg aandacht voor is.

Oudlid,

Er zijn tegenwoordig drie prominente applicatie-architecturen, gebaseerd op de relaties tussen de
diensten: monoliths (tightly coupled), SOA (loosely coupled), en microservices (decoupled).

Naast SOA (done right) is er nog een ander mooi voorbeeld van loose coupling en dat is natuurlijke taal.

Merk op dat in “afstemming” naast “stemming” ook “stem” zit.


Jack,
Taal is een lastige, zeker voor computers omdat stemming om een gemoedstoestand kan gaan of een besluitvorming en het is het werkwoord die de uitleg bepaalt. Het doen of zijn gaat vast een filosofische kip & ei discussie opleveren maar waar het mij omgaat is dat bepaalde koppelingen onlosmakkelijk zijn, zeker in processen. In de besluitvorming gaat het bijvoorbeeld vaak om een onweerlegbaarheid waar vaak de onlosmakkelijke koppeling van data aan vast zit.

In monolitische systemen wordt data gestructureerd opgeslagen, ingeblikt in databases. SOA architecturen kennen veelal een andere output, data en metadata zijn applicatie afhankelijk gekoppeld en daardoor veelal veel minder gestructureerd. Idee van een open huwelijk met Seksueel Overdraagbare Aandoening (SOA) is een taaldingetje maar zoeken naar de e-mail met daaraan gekoppeld het bonnetje van Teeven geeft een idee van problematiek. Prominente applicatie-architecturen zijn leuk maar als je het raam open doet om te luisteren naar wat barbaren roepen dan is de stemming nogal grimmig.

Zo benieuwd wat het resultaat geweeest zou zijn als Ruud, Jack en Ewout samen de opdracht hadden gekregen om een monoliet om te zetten in microservices.
Waarschijnlijk een op hoop geklep en de opdracht die uiteindelijk naar Henri gaat met zijn hippe graphsql oplossingen ;-)

Dino,
Een monoliet is een rots die door competentie verschillen van gesteente uitsteekt boven de omgeving. Een monolitisch systeem is een geïntegreerde eenheid van een in elkaar opgegane omgeving welke op competenties uitsteekt boven de andere systemen, denk aan in steen gebeitelde beheerprocessen. De 'full service stack' van legacy is voor veel organisaties nog altijd de rots van Gibraltar met daarop de API's van SOA architecturen. En de verandering om van een monolitisch systeem met als loopgraven ingesleten olifantenpaadjes processen naar een (M)SOA architectuur te gaan vraagt inderdaad heel veel geklep met de lange adem van Enterprise architectuur.

Oudlid,
de afsluitende opmerking in mijn vorige reactie is voor eigen rekening, maar je kunt er 2 filosofen in terugvinden: Heidegger en Gerard Visser.

Van deze tweede filosoof heb ik een mooie tekst voor je; uitgeprint amper 7 A4-tjes:
https://wapenveldonline.nl/artikel/1361/de-leemte-van-het-darwinisme/

En dan mijn favoriete quote:
“Een woord is in wezen geen teken, dat ons scheidt van de werkelijkheid, maar een ontvangstruimte, die ons ermee verbindt. “

Deze gedachte wordt verder uitgewerkt in zijn, in 2018 verschenen, meesterwerk:
Gelatenheid in de kunst. Nijhoff, Braque, Kawabata
— Van gesloten naar open vormen.


Dino, mogelijk heeft mijn eerste reactie je op het verkeerde been gezet, aangezien ik hier maar een halve waarheid neerzette. Binnen monolieten leidt stapsgewijze verfijning inderdaad tot complexiteitsreductie; het opsplitsen van een proces in een hierarchie van behapbare deelprocessen, die dus wel in één procesgang worden uitgevoerd.

Bij het toepassen van microprocessen wordt een proces echter opgesplitst in opeenvolgende deelprocessen, wat juist een flinke toename van complexiteit oplevert (processpaghetti).

“De kleine, onafhankelijk van elkaar bewegende deeltjes zijn per stuk misschien makkelijker te beheren, ze zorgen tegelijkertijd ook voor complexiteit omdat het zo veel systemen zijn die weer onderling verbonden zijn. “

“And then what they end up doing is creating 50 deployables, but it’s really a distributed monolith. So it’s actually the same thing, but instead of function calls and class instantiation, they’re initiating things and throwing it over a network and hoping that it comes back. “
https://changelog.com/posts/monoliths-are-the-future

“Many companies move to microservices but end up with distributed monoliths which is why they experience more issues.”

Een terugkeer naar monolieten - ander woord voor legacy - is niet aan de orde; het zijn de molenstenen die nu om de nek hangen van organisaties als de belastingdienst en het uwv.

En dan blijft dus over: SOA (done right).

Er bestaan behoorlijk wat kanttekeningen voor het gebruik van microservices: zie bijvoorbeeld het hoofdstukje Criticism and Concerns in de microservices wiki-pagina: https://en.wikipedia.org/wiki/Microservices of: https://www.infoq.com/news/2014/08/failing-microservices/

Daarnaast heb je ook te maken met data consistency problemen (als data decentraal wordt opgeslagen in een varieteit van database architecturen), de 2 phase commit, network latencies, service overschrijdende processen als audit logging, etc. etc.

Maar op een hoger niveau heb je ook de volgende problemen:
- wie is de eigenaar van een proces dat bestaat uit x microservices
- wie is er aansprakelijk voor het niet optimaal functioneren / falen van een microservice en de daaruit resulterende schade
- hoe kan je wijzigingen coordineren in een keten van microservices
- hoe krijg je een common code base voor gedeelde functies van microservices
- hoe garandeer je de software kwaliteit van microservices
...
..

welkom KJ, leuk dat je er schepjes bovenop doet.
Begon Oudlid met (ja, wat eigenlijk ?) en Jack al technisch en filosofisch (why eigenlijk ?) met zijn microservices als "distributed monoliths", ga jij er nog eens overheen met governance en beheer.

Goethes tovenaarsleerling die dat complexe probleem wou reduceren door het doormidden te breken, maar toen had die er juist meer van :-)

Wie vertrouwt men het meest en wordt de opdracht gegund ?
Doet me aan vroeger denken, die discussie wie het weer het allerslechtste kon voorspellen
op 1 : KNMI met de mooie modellen en praatjes
op 2 : de boer die vindt dat het "wel net zoiets zal zijn as gister"
op 3 : Pelleboer (in ieder geval de enige die echt met zijn tools in de cloudklei staat) Ik denk ineens aan Henri :-)

Jack,
Zoals verwacht krijg ik filosofisch 'leesvoer' voorgeschoteld terwijl niemand meer de handleiding leest. Over de leemte in het Darwinisme aangaande het eten of gegeten stelde ik ooit dat je niet kunt filosoferen met een lege maag. Quote over woorden die betekenis krijgen in zinsverband gaan vooral om interactie in de menselijke communicatie, één woord kan in de communicatie met computers genoeg zijn: GOTO

Evolutionaire ontwikkeling volgens voortschrijdende verandering van Darwin waarbij spronginstructies aangepast worden aan de wet of revolutionaire aanpassingen van de wet om deze passend te maken op de spronginstructies van microservice gaat niet om de molensteen maar het graan.

De term 'monoliet' is ook wat misleidend denk ik. Het verwijst naar een groot stuk steen uit de oudheid zoals een hunebed of een obelisk waardoor elke grote applicatie al meteen in de legacy-hoek wordt geschoven.

Echter, de organisatie van de code van een grotere applicatie is in de meeste gevallen vrij efficient en code-redundancy wordt vermeden door het toepassen van functies, subroutines, classes, methoden etc. De organisatie van software hier vindt plaats op basis van efficientie en code optimalisatie door het vermijden van redundatie.

In de microservices wereld is de organisatie van software primair afhankelijk van de per service aangeboden functionaliteit. De monoliet wordt dus opgedeeld in stukjes functionaliteit. Dat is een compleet andere organisatie van code.

Als ik in de monoliet de lengte van een veld aanpas door middel van 1 enkele wijziging in een dictionary, dan is dat uiteraard veel makkelijker te realiseren dan het aanpassen van datzelfde veld in verschillende microservices, iets waarvoro ik verschillende programmeurs moet gaan bellen. Dat zit hem dus in de code die alle microservices in gemeen (moeten) hebben.

Paradigma van KJ: bij gelijke geleverde functionaliteit, programmertaal, en programmeur is de som van de regels code in een monoliet kleiner is dan de som van de regels code in alle microservices.

Monoliet als lekker efficiente software oplossing, zoals de hyperconverged dat voor Infra zou zijn. Soort monoliet done right?
Of monoliet als vieze koude spaghetti?

Code die alle microservices gemeen hebben kun je inderdaad ook in elke microservice apart implementeren, ipv iets te verzinnen waarbij ze juist geen code gemeen moeten hebben. Een mooi design principe ;-)
Als je Jacks "distributed monoliths" omgeving wilt hebben, goto KJ.

@Dino
Mooi design principe inderdaad!

En de stukjes code die ze stiekum toch in gemeen hebben, maken we een aparte "hidden" micro service voor die de andere services kunnen aanroepen.

Een goede monoliet is als een bal gehakt gemaakt door Heston Blumenthal.

Dino,
De tovenaarsleerling van Goethe kent vele verschillende versies waaronder de kinderserie Tita Tovenaar, Tika had een trucje om fouten te herstellen. De 'sprong instructie' van de pas op de plaats aangaande je betoog kent een design principe waar ik volgens mij al in de eerste reactie op wees. De filosofische gelatenheid van Jack gaat om de farizeeërs van het evangelie van Google die met opportunistische datasynthese leiden tot discussies over de betrouwbaarheid van de algoritmen.

hahaha, ik lees met vermaak het artikel en de reacties.

Het is allemaal niet zo moeilijk en in dat opzicht zitten best al wat duidelijke voorbeelden in het artikel zelf. Uiteraard is er niet 1 antwoord wat compleet en helemaal goed is. Zodoende kun je ook blijven discussiëren. Maar aangezien Dino mij al twee keer mijn naam schrijft, hier mijn visie op het onderwerp.

Is AWS onderhand een monoliet? Een monoliet met allemaal microservices? Of is AWS een framework van diensten?
En tot welke grootte is een service een "micro" service?

Ruud geeft een aantal voorbeelden van Microservices:
"Dit kan bijvoorbeeld een e-mailfunctie zijn, een payment module of een product catalogus. Eigenschap van een module is dat deze eenduidige functionaliteit bevat, en onafhankelijk kan schalen en getest kan worden."

Precies dat. Een onderdeel van een monoliet is bijvoorbeeld het versturen van e-mails. Vaak zit daar dan ook nog een stuk "templating" in. Dus vooropgemaakte e-mails die makkelijk met data uit de monoliet gemerged worden en daarna verstuurd. Dit terwijl het versturen van e-mails iets heel generieks is. Daarnaast zijn er naast de monoliet wellicht nog meerdere systemen in gebruik die eigenlijk ook wel mails zouden willen versturen. Door een microservice te ontwikkelen en de monoliet en andere systemen daarop aan te sluiten maakt het mogelijk de service te verbeteren zonder verweven te zijn in de compliciteit van de monoliet.

Een productcatalogus is natuurlijk al een stuk complexer. Juist omdat iedere monoliet hier anders mee om gaat. Grote kans als je dat als microservice naast de monoliet wil neerzetten je in feite de technische schuld van de monoliet vergroot omdat er teveel onderlinge afhankelijkheden ontstaan. Wat je dan mogelijk wil doen is de facade van een product catalogus leggen over de monoliet. Platgeslagen API's om met de product catalogus in de monoliet te kunnen communiceren.

Microservices is geen doel op zich. Het doel is verminderen van technische schuld en "separation of concerns" en als het even mogelijk is iets adaptiever worden al is dat laatste iets wat je makkelijk verkeerd kan doen waardoor het verschuif van "onderdeel van de oplossing" naar "onderdeel van het probleem".

Wel of geen microservices is geen binaire vraag.

Soms is monolithisch bouwen best te verdedigen. Of in ieder geval een mengvorm. Leg de knip op de juiste plek.. wat is specialistisch en wat is generiek. Als je helemaal opnieuw mag bouwen is het inderdaad een idee om de focus wat meer te leggen op microservices. Je bent dan minder snel in de hoek geverfd.

Dat zijn mijn twee centen en moet je het mee doen :-)

En nee. Ik zou niet snel een GraphQL laag over de microservices heen leggen.....

Henri,
De intermenselijke menselijke communicatie kun je invullen met de functionaliteit van e-mail, een functie die monolitische EDI systemen al met het X.400 protocol hadden. Het nadeel van huidige Systems of Engagement ligt in het feit dat de focus op de interactie tussen mensen ligt en niet op de governance principes van data. De technische schuld is gewoon onzin als we kijken naar de organisatorische beperkingen. Filosofische gelatenheid van Jack aangaande de realiteit in bedrijfsvoeringen is gebaseerd op een geloof.

Nieuwe realiteit is een interacties tussen apparaten, de wet van de remmende voorsprong in zelfsturende auto's zit niet in de techniek maar de juridische aansprakelijkheid. Zoals er ook aansprakelijkheid is aangaande alle data die (micro)services verzamelen, bewerken en opslaan. Het verbintenissenrecht is taaie stof maar aangaande afspraken hierin blijken SOA klutsers nogal opportunistisch. De onderhoudbaarheid van oplossingen is vaak een contractuele verplichting, paradigma van DevOps blijkt spreekwoordelijke scheet in het netje te zijn want het lange traject van support wordt niet door de leverancier bepaalt.

Modulaire software ontwikkeling en microservices zijn dan ook twee heel verschillende principes, Ruud Pieterse heeft hierin de klok wel horen luiden maar hij weet nog altijd niet waar de klepel hangt.

Oudlid,
wat betreft monolithische systemen heb ik in mijn eerste reactie ook al een halve waarheid neergezet, zoals de rake aanvullingen van KJ en Dino laten zien. In theorie leidt een stapsgewijze verfijning van processen tot complexiteitsreductie; in de praktijk wordt legacy echter gekenmerkt door een sterke verwevenheid en redundantie van data, bedrijfslogica en afhandeling van bedrijfsprocessen. De enige remedie is een herbouw onder architectuur, maar dan heb je geen monoliet meer; een monoliet done right bestaat dus niet.

Als je dus ten aanzien van de Cobol-systemen van de UWV spreekt van “een goed werkend geweer” ben je het contact met de werkelijkheid wel een beetje kwijt. Inderdaad is gelatenheid, een loslaten van maakbaarheid en controle, dan precies wat je weer bij zinnen kan brengen.

Gelatenheid is niet gebaseerd op geloof, maar op ervaring.

Hopelijk begrijp je wel dat taal meer is dan enkel een communicatiemiddel, een uitwendig instrument voor de overdracht van betekenis tussen mensen.

Jack,
Aangaande de problematiek van SVB/UWV kan ik me alleen maar een oordeel vormen op basis van de verhalen van René Veldwijk naar aanleiding van organisatorisch gelijkenis van instanties waar ik zelf onderzoek gedaan heb. Mijn conclusie is dat de gemiddelde ambtenaar zonder duidelijke beslisprocessen en -modellen geen besluiten zal nemen, taaltechnische zoekterm voor dit bestuurlijke euvel is: "Paarse krokodil"

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2020-03-13T14:03:00.000Z Ruud Pieterse
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.