Same shit, different decade

De wereld van de IT verandert snel. Wat vandaag helemaal hot is, is morgen alweer achterhaald. Maar is de technologie van morgen wel zo anders dan die van vandaag? Als je goed kijkt naar de geschiedenis van de IT, zie je dat veel patronen en architecturen steeds terugkeren, alleen met een andere naam of een iets andere inslag.

Door verbanden te leggen tussen oud en nieuw voorkom je dat je wordt verblind door de nieuwste glimmende "silver bullets". Daarnaast kan je door op een andere manier naar nieuwe ontwikkelingen te kijken, inzichten krijgen om de technologie van vandaag beter te begrijpen. In dit artikel zal ik een aantal van dit soort verbanden tussen heden en verleden proberen te leggen en zien hoe we daarvan kunnen leren.

 

SOA en Microservices

Een parallel die voor de hand ligt om aan te halen, is die tussen Service Oriented Architecture (SOA) en Microservices. SOA wordt vaak weggezet als een complexe architectuur met veel ballast en overbodig rigide structuren. Microservices aan de andere kant worden vaak geroemd om hun lichtgewicht aanpak en flexibiliteit. Microservices zijn zo'n beetje dé silver bullet van dit moment.

Op het eerste gezicht lijkt er dus een duidelijk verschil. Als we echter in wat meer detail gaan kijken, blijken die verschillen wel mee te vallen. Eén van de redenen van de slechte reputatie van SOA, is dat veel mensen het associëren met SOAP en ESB's. Dat is onterecht. Het zijn technische artefacten uit de tijd waarin SOA is ontstaan (2005) en dit is blijven kleven. Doordat ze zoveel werden gebruikt in SOA oplossingen uit die tijd, zijn ze in de beleving van velen onlosmakelijk aan SOA verbonden. Ze komen beide echter nergens voor in de definitie van SOA.

De definitie die Wikipedia hanteert voor SOA is: "A style of software design where services are provided to the other components by application components, through a communication protocol over a network." Daarnaast is een veel gebruikte definitie die van de acht SOA principes voor service design van Thomas Erl:

• Standardized service contract;
• Service loose coupling;
• Service abstraction;
• Service reusability;
• Service autonomy;
• Service statelessness;
• Service discoverability;
• Service composability.

Zowel de Wikipedia-definitie als de principes van Erl zijn niet uniek voor SOA en gelden net zo goed voor microservices. De vraag is dus wat microservices bieden wat SOA niet had? Op technisch vlak eigenlijk helemaal niets. Microservices zijn vooral populair omdat het een vorm van SOA is die vaak gebruik maakt van REST, cloud oplossingen, decentrale service discovery en meer zaken die het IT landschap versimpeld hebben. Dit zijn echter allemaal zaken die net zo min in de definitie van microservices zijn opgenomen als SOAP en ESB in de definitie van SOA. Toch is het waarschijnlijk die associatie die de adoptie van (de term) microservices helpt en SOA hindert. Het voornaamste verschil is dus dat blijkbaar een nieuwe term nodig was om grote groepen de ware aard van SOA te laten inzien.

De vraag is nu wat je kan met deze informatie. Ten eerste helpt het je om wat kritischer te kijken naar waar je architectuur echt om draait. Daarnaast maakt het de hoeveelheid informatie waaruit je kan putten veel groter. Veel content over microservice gaat over hoe groot ze moeten zijn. Dat is logisch gezien de naam, maar zeker niet het meest relevante punt. Het voordeel van artikelen en blogs over SOA ten opzichte van microservices, is dat ze veel meer gaan over de architecturale principes en minder over de technische details. Dat is niet per definitie beter, maar het helpt wel je horizon te verbreden.

 

NoSQL of PreSQL?

Een paar jaar geleden werd ineens elke developerconferentie beheerst door NoSQL. Het was een tijdje lang hét buzzword in IT. Hoewel de echte hype nu voorbij is, is NoSQL een blijvertje gebleken. Het is inmiddels weer redelijk gebruikelijk om je eerst goed af te vragen wat voor data je hebt en hoe deze gebruikt wordt alvorens een database technologie te kiezen. Er zijn tijden geweest waarin bijna rechtstreeks naar de relationele database werd gegrepen.

De relationele database is zelf echter lang niet altijd de standaard geweest. De eerste relationele databases ontstonden pas midden jaren '70. Voor die tijd waren het vooral navigational databases die de toon zetten. Een navigational database bevatten records of objectverwijzingen naar andere records, waardoor er overheen genavigeerd kan worden. Er zijn twee smaken in te onderscheiden. Het netwerk model is vergelijkbaar aan de opzet van veel Java Collection types, waarin elementen een verwijzing bevatten naar een volgend of vorig element. De CODASYL standaard, die ook ten grondslag lag aan COBOL, was hierin leidend. De andere variant is het hiërarchische model dat meer doet denken aan een filetree. Het was dus eigenlijk NoSQL avant la lettre. Vandaag de dag vinden we vergelijkbare technologie in graph databases, die op hun beurt weer tot NoSQL gerekend worden.

In de jaren '80 en '90 waren ook al ontwikkelingen buiten het relationele paradigma. Object databases werden ontwikkeld om de brug tussen database en (object georiënteerde) code te verkleinen. Toen bestond dus al aandacht voor het feit dat het relationele model niet altijd strookt met een objectmodel. Door de populariteit van relationele databases werd dit toen post-relationeel genoemd. Er leefde blijkbaar de verwachting dat het relationele tijdperk met deze ontwikkeling snel achter de rug zou zijn. Toch zouden relationele databases in de decennia daarna onverminderd populair blijven.

Pas met de opkomst van XML aan het begin van deze eeuw ontstond een categorie databases die we ook vandaag de dag nog onder NoSQL scharen. Het begon in eerste instantie met relationele databases die XML ondersteunden, maar daarna volgden de echte native XML databases. Dit blijft tot op de dag van vandaag echter ook een redelijk niche. Andere soorten document georiënteerde databases (JSON) mogen zich in de warme bestelling van veel developers verheugen.

Eigenlijk is het dus een beetje vreemd dat niet-relationele databases zich samen moeten profileren onder een noemer die zich juist expliciet afzet tegen die relationele wereld (als we SQL in NoSQL tenminste als synoniem voor relationeel beschouwen). Het komt waarschijnlijk doordat relationele databases een enorme stap voorwaarts waren en zo dus synoniem werden voor de term database. Niet-relationele databases zijn van alle tijden en het zou eigenlijk mooi zijn als op een dag de term NoSQL uitsterft, omdat we het allemaal gewoon weer databases gaan noemen.

 

Client-server is terug

Een parallel die niet zo vaak wordt getrokken, is die tussen SPA's (Single Page Applications) met een REST backend en het client-server model. De voornaamste reden waarom dit niet wordt gezien, komt waarschijnlijk door de geleidelijke evolutie van het web.

Het world wide web, zoals het begin jaren ‘90 is ontstaan, bestond initieel enkel uit statische content. De server serveerde via HTTP HTML pagina's uit naar de client: een browser. De basis was dus altijd al client-server. Toen behoefte kwam aan meer dynamische content ontstonden de eerste hypertext preprocessors en server-side MVC frameworks. Denk bijvoorbeeld aan PHP, ASP en natuurlijk JSP. De HTML standaard zelf was niet dynamisch genoeg en door middel van preprocessing kon dit server-side toch gesimuleerd worden. Voor de gebruiker leek het wel enigszins dynamisch (buiten de vele page reloads). Via die weg zijn we langzaam allemaal gaan wennen aan n-tier architecturen voor web applicaties, waarbij het HTTP verkeer tussen frontend en backend zo ver mogelijk werd weg-geabstraheerd door frameworks. In de beginjaren waren dit onder andere action-based frameworks als Struts en Spring MVC. Daarna kwamen de component-based MVC frameworks zoals JSF, GWT en Vaadin, waarin de abstractie zo ver weg ligt van de onderliggende techniek dat veel developers niet meer scherp hebben welke code uitgevoerd wordt op de server en welke op de client.

Met de komst van HTML5 en JavaScript frameworks, zoals Angular en React, is de webapplicatie eindelijk volwassen geworden. Waar voorheen de webapplicatie eigenlijk een illusie was die werd gecreëerd door de combinatie van preprocessing en wat losse JavaScript, is het tegenwoordig echt een op zichzelf staande applicatie. Het MVC framework is verhuisd van de server naar de client. De browser is gepromoveerd van een simpele HTTP client tot een volledig applicatieplatform.

Doordat moderne webapplicaties op zichzelf staande applicaties zijn die (vaak) gebruik maken van REST backends, is eigenlijk opnieuw sprake van klassiek client-server. De client is niet meer de browser, maar de webapplicatie zelf. De connectie tussen client en server is niet meer verstopt achter abstracties, maar is weer expliciet. Met REST wordt vaak gekozen voor het volledig benutten van HTTP, met alle bijbehorende semantiek. De client op het web is van thin client, via rich client weer terug geëvolueerd tot thick client. Waar beheerders van klassieke client-server oplossingen hun nek braken over de distributie van de client software, is dit tegenwoordig een fluitje van een cent. Web technologie zorgt ervoor dat de client over de hele wereld gedistribueerd kan worden en dat de gebruiker altijd kan beschikken over de laatste versie zonder dat deze daarvoor specifieke handelingen moet uitvoeren.

Server side MVC versus Client side MVC

 

In het figuur is te zien hoe deze subtiele verandering effect heeft op de deployment van web applicaties. De webserver is niet langer een doorgeefluik van (preprocessed) HTTP, maar enkel een software distributie mechanisme dat de applicatie ter download aanbiedt aan de browser. Ondanks dat het web in de basis nog steeds is gebouwd op dezelfde technieken als begin jaren '90, heeft het een flinke architecturele verandering doorgemaakt. Het is goed om te beseffen dat de rol van de componenten daardoor drastisch is veranderd.

 

API's

Met de opkomst van REST is steeds meer aandacht voor API's. Deze term is echter aan erosie onderhevig. Op dit moment staat de term API haast synoniem voor REST API, maar dat is ook wel eens anders geweest. Tot niet zo lang geleden werd de term API met name gebruikt om de API van een framework of een library aan te duiden. De design principes zijn echter veelal onveranderd. Ook in de toepassing van REST API's is een interessante parallel naar het verleden te trekken.

Zoals eerder al beschreven, heeft het moderne web een verandering doorgemaakt richting een gedistribueerd client-server model. De REST API is hierin in feite vergelijkbaar met het communicatieprotocol tussen een klassieke terminal en een mainframe. Zeker wanneer je bedenkt dat de achterliggende services vaak gehost worden op een cloudplatform. De public cloud is een fenomeen dat we niet echt terug kunnen vinden in het verleden, maar de private cloud heeft toch ook wel een aantal kenmerken van een mainframe. Het is een gecontroleerde omgeving waarin alle rekenkracht gebundeld zit. De client (een terminal of een webapplicatie) bevat zelf zo weinig mogelijk business logica en laat zoveel mogelijk rekenwerk over aan deze centrale voorziening. Uiteraard is de hedendaagse client wel een stuk rijker aan user experience dan de klassieke terminal. Zo keren we langzaam weer terug naar een model dat allang was afgeschreven. Dit keer alleen met technologie die een stuk krachtiger is.

 

Conclusie

In vrijwel alle hedendaagse technieken zijn parallellen te vinden met het verleden. Dit betekent natuurlijk niet dat we met zijn allen in cirkeltjes aan het rondrennen zijn en maar niet vooruit komen. Het is juist een teken dat we vooruitgang bouwen op fundamenten die er al liggen. Soms is het gewoon interessant om te zien waar de oorsprong ligt, maar vaak helpt het ook om de techniek beter te doorgronden. Er lijkt een soort golfbeweging te zijn van centralisatie naar decentralisatie en weer terug. Ook bestaat een golfbeweging van abstract naar concreet en weer terug. Waarschijnlijk kijken we hier over 5 of 10 jaar weer heel anders tegenaan, maar de kennis van vandaag is morgen zeker ook van toepassing.