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
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.
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”