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