De kracht van een mierenhoop
"Niet erg efficiënt op microschaal, maar enorm efficiënt en robuust op macroschaal."
Inmiddels zijn we allemaal wel bekend met het woord 'bug': een foutje in een computerprogramma, vaak vervelend, soms desastreus. Als je een beetje kunt programmeren, snap je goed hoe dit komt. Als je niet kunt programmeren, snap je het waarschijnlijk niet.
Computers zijn dom. Erg dom. Ze snappen werkelijk helemaal niets. Alles moet je ze vertellen. En alles wat je ze verteld, moet ook nog eens in precies de goede volgorde. Doe je het niet, dan draait het in de soep. En die soep heet dan een bug en als je pech hebt moet alles opnieuw geinitialiseerd worden. Opnieuw opstarten heet dit.
Om iets simpels op het scherm te krijgen, heb je duizenden regels code nodig. En in elke regel code kan potentieel een foutje zitten. Of je loopt net tegen een uitzondering aan of een gebruiker doet niet wat je had verwacht ofzo. Kortom: het pad is smal en er zijn veel afgronden.
Daarbij komt dat veel software 'gestapeld' is: De code die deze tekst bevat heb ik gemaakt (en is slechts vrij simpele HTML). Met deze code vertel ik de browser, die door iemand anders is gemaakt, hoe hij de tekst moet weergeven. Deze browser verteld het OS (voor de meeste mensen nog steeds Windows) hoe het eruit moet zien. En het OS gebruikt o.a. een driver om het beeldscherm aan te sturen. En dan is dit nog maar het topje van de ijsberg, maar we hebben nu al het werk van heel erg veel mensen, gedurende heel veel tijd, samengevoegd om simpel een stukje tekst weer te geven. En mensen maken fouten, dus zit dit proces vol met fouten. Het is eigenlijk nog een wonder dat het zo vaak goed gaat!
Organische systemen zoals planten en dieren (en mensen?) zijn veel robuuster. Als er ergens iets misgaat, gaan ze zelden meteen dood. In vaktermen heet dit 'graceful degradation' of 'geleidelijke achteruitgang'. Het beste voorbeeld is wel iemand die blind wordt of een ledemaat moet missen: Na enig aanpassen kunnen deze mensen meestal weer vrij goed functioneren. Beperkt natuurlijk, maar niet hopeloos. Bij een computer is het meestal alles of niets.
Al tijden kijken mensen naar manieren om dit gedrag te imiteren. Ze gebruiken dan termen als 'distributed computing' of 'agents'. Het idee is dat je meer 'losse' componenten hebt, sommige zelfs redundant, waardoor een systeem niet geheel uitvalt als een onderdeeltje weigert. Hierbij zijn grofweg twee manieren: managed, waarbij een soort scheidsrechter de spil is en taken en opdrachten verdeeld (met natuurlijk als grote probleem dat de scheidsrechter de bottleneck is) en self organized, waarbij systemen (schijnbaar) autonoom werken en zelf op zoek gaan die hen aanvullen bij het uitvoeren van een taak.
Het voordeel is dat alle services (zoals het nu dan heet) kleiner en simpeler kunnen worden uitgevoerd, waarmee de betrouwbaarheid en beschikbaarheid kan worden verhoogd. Bovendien kun je ze redundant uitvoeren en ze makkelijker vervangen, vernieuwen of opschalen. Bovendien kun je een heleboel context gewoon vergeten. Binnen een Service Oriented Approach (met de slechte Nederlandse afkorting SOA), interesseert het je niet hoe en waar een service werkt, je wil alleen iets weten over zaken als betrouwbaarheid, beschikbaarheid, responsetijd etc. etc. Dit doe je op basis van een 'contract', die je kunt uitvragen bij de service en op basis van deze gegevens kunt besluiten om de service al dan niet te gebruiken.
SOA is dus een manier om je betrouwbaarheid, schaalbaarheid, robuustheid en nog veel meer zaken op een goede manier te regelen. Het is echter ook een hele nieuwe manier van denken en organiseren van software. Je zult veel meer in functionele eenheden moeten gaan denken. Eigenlijk is het de logische volgende stap na Object Georiënteerd denken: een object wordt nu een functionele eenheid die je als service kunt afnemen. Hierbij werkt de service min of meer autonoom of weer samen met andere services.
Natuurlijk zijn er vele problemen te overwinnen. Niet in de laatste plaats omdat de service weer heel precies zijn. Je kunt niet om een service vragen die 'even een sommetje uitrekent', maar je zult op zoek moeten naar een service 'die twee natuurlijke getallen bij elkaar op kan tellen en met een betrouwbaarheid van 100% en binnen 10 seconden het resultaat in XML verpakt kan teruggeven'. Een flauw voorbeeld, maar het geeft een indruk van de preciesheid waarmee je computers moet aanspreken. Gelukkig zou je zoiets weer kunnen oplossen met systemen die lijken op een telefoonboek: een service-lookup-service.
Er is een grens aan wat mensen kunnen bevatten en dus programmeren. Er is een grens aan de schaalbaarheid van teams en het is belachelijk dat iedereen telkens het wiel uitvindt. Daarom zijn services (of agents of hoe ze ook gaan heten) een natuurlijke en veel betere ontwikkeling. Het is alsof iedereen alleen dat doet waar hij heel goed in is en de rest laat liggen voor een ander. Eigenlijk net als een mierenhoop: Niet erg efficiënt op microschaal, maar enorm efficiënt en robuust op macroschaal. En dat blijft toch een soort natte droom van iedere software-architect.
