De software goeroes rollen op blogs en Twitter op dit moment virtueel over elkaar heen: Is het fenomeen Microservices nu gewoon een nieuwe incarnatie van service oriënted architecture (soa)? Of is het echt iets nieuws.
Een op services gebaseerde software architectuur (soa) houdt in dat je geen monolieten meer ontwikkelt. Oplossingen worden modulair opgebouwd uit afzonderlijke componenten. Door aandacht voor hergebruik worden ontwikkeltijd en -kosten minder en de onderhoudbaarheid beter. Daarnaast biedt de modulaire opzet voordelen voor het parallel plannen van werkzaamheden om zodoende dus in kortere tijd met meerdere teams grotere ict-projecten uit te kunnen voeren. Daarnaast kunnen de componenten op meerdere manieren worden gecombineerd (als een soort Legoblokken), waardoor veel flexibeler oplossingen zijn te realiseren.
Op zich heeft service oriëntatie niets met integratie te maken. In een ideale wereld communiceren services met elkaar, zonder dat er (te configureren) integratie middleware als bijvoorbeeld een service bus aan te pas komt. Dit is waarschijnlijk alleen haalbaar als kunstmatige intelligentie echt op dit niveau doorbreekt en ‘no proces’s mogelijk wordt. De services weten elkaar dan automatisch te vinden en op die manier zal het proces dynamisch tot stand komen. Hierdoor zal proces optimalisatie altijd automatisch plaatsvinden, zonder dat er een vooraf gedefinieerd proces vast is gelegd en zonder dat dit ook telkens (handmatig) bijgestuurd moet worden. Bpm, maar dan zonder configuratie. Dit is vandaag de dag echter nog ver van de werkelijkheid. Maar dat we daar naar toe gaan is zeker.
Tot die tijd zijn we afhankelijk van integratie middleware. Service bussen die in je eigen datacentrum of in de cloud draaien, en ook hybride (door middel van federatie) elkaars services kunnen gebruiken. Deze technologie maakt het mogelijk dat services van verschillende pluimage goed met elkaar kunnen communiceren, en dat dit ook beheersbaar en monitorbaar is.
Architectuur- en ontwerprichtlijnen
De principes die ten grondslag liggen aan soa, zijn gelijk aan die voor Microservices gelden. Laten we ze nog even in gewoon Nederlands een keer op een rijtje zetten. Services worden gebouwd aan de hand van de volgende algemeen geldende architectuur- en ontwerprichtlijnen:
-
Alle services communiceren via een vergelijkbare manier met elkaar en zijn hiermee met elkaar compatibel.
-
De logica binnen de services is niet rechtstreeks gekoppeld aan onderliggende componenten en achterliggende systemen. Hiermee is er een zekere flexibiliteit bij uitbreidingen of veranderingen.
-
Een service wordt ontworpen voor een functioneel doel en verbergt specifieke technische zaken van onderliggende werking of systemen.
-
De te bouwen logica wordt in losse op zichzelf staande delen onderverdeeld zodat deze losse services kunnen vormen en hergebruikt kunnen worden.
-
Een service is zelfstandig in staat om te functioneren (autonoom) en heeft geen referenties naar onderdelen buiten de service.
-
Een service heeft geen wetenschap van eerdere aanroepen. Elke aanroep wordt behandeld alsof deze voor het eerst wordt gedaan met het oog op schaalbaarheid en betrouwbaarheid.
-
Een service bevat metadata die beschrijft hoe deze te gebruiken is.
Deze principes gelden voor soa en Microservices. Punt.
Wat is nu dan wel het verschil? Wat maakt Microservices zo bijzonder? Ik heb eerlijk gezegd nog geen goede definitie van de ‘Micro’ in Microservices gezien. Is het alleen het feit dat het zeer fijnmazige services zijn? Fine grained soa? Is het verschil dat soa om enterprise architectuur draait en Microservices om applicatie architectuur? Wat mij betreft is dat niet heel erg relevant.
Waar het bij zowel soa als Microservices om draait, is dat het een onderdeel vormt van een groter geheel, gedreven vanuit de business. Als er op business niveau niet in services wordt gedacht bij het ontwikkelen van oplossingen, zal soa of Microservices nooit een succes worden. Het is aan ons it-mensen om de business duidelijk te maken wat soa en Microservices nu precies betekent voor niet it-mensen en de bedrijfsoplossingen waar het allemaal om draait. Het fenomeen Microservices gaat dat niet voor ons oplossen.
Belangrijk hierbij is dat we kunnen aantonen dat het voordelen oplevert. Een business case voor hergebruik van componenten, die al of niet door de gebruikende organisaties zelf zijn ontwikkeld. Dat ‘opvoeden’ proberen we al jaren, maar dat lukt ons nog steeds niet erg goed. Laten we ons daar eens druk om gaan maken! Dan komt die architectuur vanzelf wel goed.
“Het is aan ons it-mensen om de business duidelijk te maken wat soa en Microservices nu precies betekent voor niet it-mensen en de bedrijfsoplossingen waar het allemaal om draait.”
Dat is volgens mij maar zeer de vraag. De reden dat SOA zo’n beladen term is geworden komt voor een groot deel omdat het door de IT zo belangrijk werd gevonden om de business te overtuigen. Het was verzonnen door de IT maar zou koste wat koste als een business wens ingezet moeten worden. Maar daar wil de business natuurlijk niet voor betalen. Zie ook het beroemde stuk van Anne Thomas Manes dat SOA dood zou zijn. Dat gaat erover dat een organisatie geen grote SOA projecten meer willen doen met een ESB, maar zonder zichtbare korte-termijn functionele voordelen.
Het verschil met micro services zit hem er m.i. in dat deze meer bottom-up geinitieerd worden. Het is een technisch feestje waar de business mee mag doen, maar ook als die niet mee doet, “doen we het toch”. Je ziet het dan ook vooral bij zeer technische organisaties als e-bay of netflix. Zonder devops is het vrijwel onmogelijk.
De term micro heeft inderdaad slechts zeer beperkt met de grootte van een service te maken. Ik denk dat het meer te maken heeft met het ‘lightweight’ karakter, dwz. zonder ESB en de bijbehorende SOA ceremonie. Het is daarbij ook een beweging die zich afzet tegen andere zaken als WS-* standaards, applicatie servers, en alles dat riekt naar legacy en stroperigheid.
“Dat ‘opvoeden’ proberen we al jaren, maar dat lukt ons nog steeds niet erg goed. Laten we ons daar eens druk om gaan maken!”
Friso legt in zijn reactie mooi uit waarom dit een hopeloze zaak is. Korte-termijn functionele voordelen. Die willen ze zien. Op dat gebied verschilt de business niet van een puber, wat de term “opvoeden” dan ook opmerkelijk goed gekozen maakt. De ouders hebben de ervaring en proberen hun kennis en inzicht over te dragen. Helaas, wat de vriendjes doen, zeggen en dragen is belangrijker ongeacht de inhoud van de boodschap.
Zeker als de papas en mamas zelf zo’n moeite hebben met de moderne begrippen als orientatie/architectuur en microservices, wat is het en is het goed ..? Nee, dan lekker apps installen en meteen spelen. Als het thuis kan, waarom moet het dan zo moeilijk op het werk.
Dus blijf vasthouden aan je strategie met bijbehorende processen (= gewoon laten kleppen en toch doen waar je zelf zin in heb 🙂
Business en pubers, zoek de verschillen.
@Felix briljante vergelijking!
De principes zoals de auteur die geeft kloppen misschien vanuit een architecturele “helicopter-view”, maar ze kloppen net zo goed voor gestructureerd programmeren (jaren ’70 van de vorige eeuw) en object-orientatie (jaren ’90 van de vorige eeuw), domain-driven design (jaren ’00 van deze eeuw), en voor nog veel meer. In die zin is er in de informatica niet zo heel veel gebeurd de afgelopen 40 jaar. Er is wel degelijk een groot verschil met SOA, namelijk zoals Martin Fowler beschrijft: “…small services, each running in its own process and communicating with lightweight mechanisms…”. Omdat SOA aanvankelijk een vereenvoudiging van software-architectuur was gaf het grote IT-handelaren en “dienstverleners” minder te doen. Daarom is verzonnen dat de “business” erbij gesleurd moest worden, zodat architecten en consultants weer iets te doen hadden. Daarmee is de betekenis van “SOA” nogal vaag geworden, en microservices is daarop een reactie. Volgens sommigen zijn microservices “service orientation done right”. Er komt nu een tegenreactie van enterprise architecten, die hun powerpoints weer naar de achtergrond verdrongen zien worden omdat microservices ‘gewoon’ werken, en nu moeten we de “business” gaan “opvoeden”. Laten we dat vooral SOA blijven noemen, zodat microservices kan blijven staan voor gedistribueerde software die ‘gewoon’ werkt, zonder gedoe met architecten en enterprise service bussen.
@Nico ik detecteer veel onbegrip rond SOA (en misbruik van de term). Dar microservices gewoon werken (net als dat ontwikkelaars gewoon goede code schrijven, LOL) is een onbezonnen uitspraak lijkt me. Martin Fowler worstelt ook met de definitie. Dat microservices in hun eigen proces (?) draaien en lichtgewicht communiceren kan ook voor “gewone” services gelden. Zonder architecten (met of zonder PowerPoints) en architectuur zal de Cloud langzaam tot een onbeheersbare anarchie van services verworden. Feit is dat als je je aan de 8 principes van service design houdt, de kans van slagen een stuk groter wordt. De puberende business is gebaat bij servicegericht denken op alle vlakken. Ze kan niet eeuwig puber blijven. Architectuur is verandering mogelijk maken. Meer niet.
De business een puber en ICT de ouder? Ik denk dat je de kern van de meeste ICT-problemen al te pakken hebt. Gebrek aan vertrouwen en inzicht van beide kanten.
Voorbeelden van dit gebrek zijn er prima: Maar dit is toch geen rocket-science (business over project dat uitloopt), dit project zou beter lopen zonder gebruikers, de business wil een ESB en wat dacht je van “Het is aan ons it-mensen om de business duidelijk te maken wat soa en Microservices nu precies betekent voor niet it-mensen en de bedrijfsoplossingen waar het allemaal om draait.”
De business is niet geïnteresseerd in SOA/Microservices etc. Het is aan ons om ervoor te zorgen dat we de spullenboel goed inzetten en gebruiken. En als er iets is wat we de business duidelijk moeten maken is dat we zonder goed inzicht van de wensen en mogelijkheden geen goede oplossingen kunnen maken.
Iets directer en nog iets meer on topic zoals ik het verschil tussen SOA en micro-services zie: SOA voor het aan elkaar koppelen van grotere functionele eenheden (applicaties zo je wil). Micro-services om die coole javascripts front-ends aan je back-end te hangen.
Misschien zijn ‘Microservices’ inderdaad SOA 2.0, dat maakt toch niks uit? Het idee om complexe systemen op te knippen in beter beheersbare delen is een blijvertje.
Waar iedereen mee worstelt, zo ook Fowler in zijn artikel over Microservices, is de granulariteit van een service. Hoe groot moet deze zijn? Ik ga mee met de twee pizza´s regel: een enkel team moet instaat zijn een service te maken en te onderhouden.
Dit geeft meteen aan waarom SOA vaak mislukt: het wordt te groot aangepakt. If you give them too much rope, they hang themselves.
Het succes van IT-projecten houdt sterk verband met motivatie en eigenaarschap.
Wat is de maximale span of control van een groep mensen?
Over hoeveel lagen kan er effectief gecommuniceerd worden?
Wat is de maximale doorlooptijd van een goed lopend project?
Microservices is SOA opzoek naar de menselijke maat 🙂