Serverless: de ideale link tussen APIs, Events, en je eigen code.

Serverless Computing is een Cloud Computing model waarbij de gebruikers enkel code en een stuk configuratie aanleveren voor een beoogde software, en de cloud provider de volledige verantwoordelijkheid in handen neemt voor het beheer van de onderliggende resources (rekenkracht, geheugen, netwerk, etc.). De gebruikers zijn normaal gezien software ontwikkelaars, en het concept valt dan ook onder de noemer “Platform as a Service” (PaaS). Bij Gartner wordt deze technologie ook Functional Platform as a Service (FPaaS) genoemd. Elders gebruikt men kortweg de term “Function as a Service” (FaaS).

Serverless gaat dus nog een stuk verder dan wat momenteel als “mainstream” PaaS-gebruik kan worden beschouwd: Container platformen en Kubernetes. Bij deze laatste is de developer zelf nog verantwoordelijk voor een deel van de “stack” en bepaalt daarmee zelf voor een groot deel op welke manier de software binnen de container zal werken, en daarmee dus ook over de manier waarop de gecompileerde programmacode wordt geïnstalleerd en uitgerold. Bij Serverless zal men enkel broncode (en een stuk tekstuele configuratie) uploaden naar het platform. De configuratie bepaalt daarbij op welke manier het stuk code kan worden opgeroepen (daarover dadelijk meer). Ook de granulariteit van Serverless is typisch kleiner dan die van Containers: meestal wordt er slechts één specifieke functie per Serverless eenheid geïmplementeerd, tegenover typisch een volledige microservice (of groter…) bij Containers.

Serverless Architecture verwierf bekendheid dankzij het product “AWS Lambda” van Amazon. Dit is momenteel nog steeds het platform waarrond het meest furore wordt gemaakt, mede dankzij een verregaande integratie met de rest van de AWS platformen. Je kan b.v. erg interessante zaken doen rond event-based monitoring. Naast Amazon hebben alle grotere Cloud providers nu wel een Serverless oplossing, en er zijn ook reeds enkele open source initiatieven ontstaan (b.v. Kubeless, een platform dat bovenop een Kubernetes cluster werkt), waarmee je op je eigen infrastructuur een FPaaS kan gaan opzetten.

Serverless = Event Driven

Men kan dus als het ware functies in een Cloud uitrollen, maar hoe worden deze dan uiteindelijk opgeroepen? Daar komt de configuratie bij te pas. Zo’n functie zal men namelijk typisch oproepen als gevolg van één of andere gebeurtenis, en dit zal men dan definiëren in de bijhorende configuratie. Indien het een functie is die een website ondersteunt kan dit b.v. een oproep naar een bepaalde API zijn, waar de functie dan een stukje van implementeert. Maar in principe kan men de functie laten reageren op alle mogelijke soorten gebeurtenissen, zolang men deze gebeurtenissen kan capteren via het gebruikte Cloud platform. Voorbeelden zijn legio:

• Business Events (b.v. een bestelling wordt geplaatst)
• Events gepubliceerd door andere software (mogelijks andere Serverless functies)
• Het binnenkomen van nieuwe data (b.v. door het monitoren van een database of door het volgen van een zogenaamde “stream”, dus eigenlijk een vorm van “Reactive Programming“).
• Het verstrijken van een bepaalde hoeveelheid tijd (dit komt neer op scheduling)
• Het binnenkomen van sensor data (denk aan Internet of Things)

De mogelijkheden zijn in principe eindeloos. Men kan dus eigenlijk stellen dat Serverless Architecture een vorm is van Event Driven Architecture, waarbij van het infrastructuur aspect abstractie wordt gemaakt. Over Event Driven Engineering hebben we reeds uitvoerig geblogd.

Voor- en Nadelen

Serverless is een nuttige technologie aan het worden, met duidelijke voordelen. Er moet echter nog een beetje gezocht worden naar oplossingen voor enkele problemen…

Pay Per Use

In de meeste platformen zal men een Serverless functie enkel uitvoeren en dit aanrekenen, wanneer ze daadwerkelijk wordt opgeroepen. Je betaalt dus enkel voor het daadwerkelijke verbruik ervan, en wanneer ze niet wordt gebruikt, betaal je niets. Dit principe noemt men “Scale to Zero”. Dit kan echter ook een nadeel zijn: als de functie echt enorm veel gebruikt wordt, zal de prijs typisch nogal oplopen en kan het interessanter worden deze op een andere manier aan te bieden (b.v. door een aantal containers die men permanent actief maakt, aan een lagere maandelijkse kost).

Schaalbaarheid en Elasticiteit

Deze aspecten zijn nu heel gemakkelijk. Een functie heeft typisch geen toestand, en vermits de developer enkel rekening moet houden met de code voor één uitvoering, is het de Cloud provider die instaat voor het verzorgen van parallellisatie en alle andere aspecten die bij een verhoogde schaal komen kijken. Men krijgt dus als het ware een zeer flexibele schaalbaarheid cadeau (en in het geval van een publieke Cloud Provider ook een quasi oneindige). Daartegenover staat weliswaar dat de performantie bij een laag gebruik iets slechter kan zijn, vermits een serverless functie normaal gezien pas wordt geïnitialiseerd (en resources krijgt) op het moment dat ze wordt opgeroepen.

Veiligheid

Ook het veiligheidsaspect is een tweesnijdend zwaard: alhoewel men zich minder zorgen moet maken over de veiligheid van onderliggende infrastructuur (de Cloud Provider doet dit normaal gezien volgens de state of the art), vergroot men op een andere manier de zogenaamde “attack surface”. Typisch zal men voor een volledige oplossing heel veel kleine functies nodig hebben, en het aantal toegangswegen tot de applicatiecode is op die manier groter.

Eenvoudige Ontwikkeling, Complex Beheer

De productiviteit van de ontwikkelaars zal waarschijnlijk een stuk hoger zijn, gezien ze enkel rekening moeten houden met functionaliteit en code, en veel minder belang moeten hechten aan onderliggende infrastructuur. Daartegenover staat een verhoogde vendor lock-in: een stuk van de code en de configuratie zal typisch gebruik maken van vendor-specifieke functies, die men bij een andere provider niet zal terugvinden.

Daarnaast is er een groot nadeel verbonden aan het bouwen van een groot web van interopererende functies: de complexiteit van dit gedistribueerde geheel. Er ontstaat als het ware een doos vol kleine “legoblokjes” van allerlei functies, die men dan wel nog met een goed plan tot een mooi geheel in elkaar zal moeten puzzelen. In principe is dit niet nieuw: zelfs binnen monolithische applicaties moet men aandacht besteden aan allerlei componenten en stukken code die onderling afhankelijk zijn, omdat ze elkaar oproepen of dezelfde resources gebruiken. Maar doordat deze complexiteit nu verschuift naar de configuratie en het platform, en ze typisch overheen een netwerk zal reiken, wordt het een probleem van beheersbaarheid en routering, eerder dan van code kwaliteit. Men zal nog goede manieren moeten vinden om dit soort zaken beter te gaan ondersteunen, misschien zelfs door encapsulatie, zoals dit reeds vrij goed op punt staat voor het eigenlijke programmeerwerk.

Conclusie

Serverless Architecture is een snel maturerende technologie met duidelijke voordelen. De FaaS platformen maken zeker deel uit van wat de aantrekkingskracht van de Cloud groter maakt. Ze moeten zich echter nog iets grondiger gaan bewijzen: nu komt het er op aan om de laatste nadelen, zoals de beheersbaarheid, nog op punt te stellen en om de meest nuttige toepassingen voor deze architectuur te vinden en te bouwen.

_________________________

Dit is een ingezonden bijdrage van Koen Vanderkimpen, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

“Digitale Transformatie”

Wanneer men het tegenwoordig heeft over bovenstaand buzzword, zal men steevast een aantal technologische evoluties opsommen die een verregaande impact op onze wereld hebben, en bijgevolg ook op de business, (in het bijzonder de IT business). We denken dan Big Data + Analytics, Sociale Media, Cloud en Mobile; de zogenaamde “Nexus of Forces“.

Het is wel waar dat deze nexus nogal wat furore maakt, maar die kan dat, doordat er, onderliggend, een aantal andere technologische evoluties spelen, die het de software engineering wereld mogelijk maken om al deze krachten voldoende te ondersteunen. Evoluties die, als het ware, ervoor zorgen dat de software die deze nexus draaiende houdt, kan worden gebouwd en ontplooid op een beheersbare manier, zonder dat ontwikkelaars ten onder gaan aan de groeiende complexiteit. Een aantal van die evoluties vatten we hier nu samen onder de noemer “Vortex of Enablers”. (Over vele van deze technologieën hadden we het reeds eerder – volg de links voor meer informatie.)

Enablers 1 en 2: Verregaande Virtualisatie met Cloud & Containers

De Cloud is niet meer weg te denken, maar welke technologie gaat er precies achter schuil? Oorspronkelijk werden er enorme sprongen voorwaarts gemaakt door het virtualiseren van machines, en infrastructuur in het algemeen (IaaS). Maar nu zien we de platformen pas echt ook voor ontwikkelaars tot wasdom komen. PaaS platformen zijn, dankzij de verschroeiend harde introductie van Container technologie, uitgegroeid tot de virtualisatiekeuze bij uitstek. Het worden nu zelfs vaker en vaker in de eerste plaats “Container Platformen“. Momenteel zijn Containers niet meer weg te denken uit Software Engineering, en ze zijn ook een belangrijke enabler voor DevOps. Maar het verhaal zal hier nog niet eindigen. Aan de horizon duikt reeds een nog hoger niveau van virtualisatie op: het zogenaamde Serverless Computing (zie ook onze research radar).

Enabler 3: MicroServices

MicroServices zijn de manier bij uitstek waarmee we complexe IT systemen kunnen opdelen in vele kleinere en makkelijker onderhoudbare componenten. Ze zorgen ervoor dat we een verzameling van toepassingen kunnen bouwen die allemaal potentieel klant zijn van elkaar en elk hun stukje van het geheel uitvoeren. Daarnaast zijn ze typisch klein en onafhankelijk, waardoor ze ideaal zijn om uitgerold te worden via een container platform.

Enabler 4: Event Driven Software Engineering

Over Events hadden we het al uitgebreid in vorige blogs. In het algemeen merken we dat dit mechanisme aan populariteit wint om een dynamisch en snel veranderende wereld, die continu nieuwe data genereert, te kunnen vatten in IT.

Events lenen zich dan ook heel goed voor het capteren van data: alles wat in een computersysteem binnenkomt, kan namelijk worden gezien als een Event, en het gebruik hiervan als primaire databron is soms handiger dan wanneer men de ervan afgeleide data zou gaan bewaren. In een overheidscontext zien we bijvoorbeeld de notie van civic moments aan belang winnen, hetgeen eigenlijk niet minder dan business Events zijn voor overheidstoepassingen.

Enabler 5: Steeds Betere Web Raamwerken

Het venster dat de klant krijgt op een IT-toepassing, is de client. Het is dan ook enorm belangrijk dat deze goed is gebouwd en vooral handig is in gebruik. De meeste client toepassingen zijn momenteel webgebaseerd of mobiel, en ook in deze laatste categorie wint webtechnologie gestaag aan belang. Het trio Html, Css en Javascript blijft dan ook de manier bij uitstek om een eindgebruikerstoepassing te bouwen, en elk jaar zien we wel een nieuw raamwerk populair worden in deze wereld; raamwerken die het makkelijker maken om sneller grotere, complexere en mooiere toepassingen te bouwen. Daarnaast wordt deze technologie ook steeds beter ondersteund door de technologie die er aan server-zijde bij komt: we krijgen haast onbeperkte schaalbaarheid en robuustheid wanneer we toestandsloze webtoepassingen gaan hosten op container platformen, gebruik makende van microservices als backend, op hun beurt ontsloten door (vaak RESTful) API’s (en, waarom niet, werkend via node.js).

Enabler 6: API’s

Het aanbieden van een degelijke API is de ideale manier om de functionaliteiten van een IT systeem beschikbaar te stellen aan andere. API’s hebben reeds een hele evolutie achter de rug: eerst waren er vooral (taal-specifieke) programmatorische API’s, daarna werden componenten steeds beter interoperationeel dankzij eerst SOAP-, en daarna REST-gebaseerde API’s. Momenteel zijn er heuse API Management platformen, die, naast beheer van API’s, ook voor de interoperabiliteit van heel wat communicatieprotocollen kunnen zorgen.

Via API’s kan men een sterk hergebruik van data bekomen: gegevens die reeds verwerkt zijn door één toepassing, worden op die manier beschikbaar voor een hele resem andere; vaak zijn dit dan microservices, maar ook frequent client-toepassingen op het web. De API’s worden bovendien vaak ook aangeboden aan derde partijen en daarbij soms ook gemonetariseerd. Uiteindelijk ontstaat er een hele “API Economy”: meer en meer toepassingen ontstaan eenvoudigweg doordat de data die ze nodig hebben, reeds beschikbaar is, en makkelijk consumeerbaar via zo’n API.

De Vortex

De relaties tussen de verschillende opgesomde technologische evoluties hier beschreven, zijn duidelijk waar te nemen: dit blijkt reeds uit de tekst. Op dit moment hebben we dan ook een unieke smeltkroes: de effecten van deze enablers op software engineering versterken elkaar, en vormen zo het fundament van de vele zaken die er bovenop worden gebouwd: de digitale economie.

Op termijn kan deze architecturale stijl de grenzen tussen verschillende applicaties gaan vervagen, om ze te transformeren tot een applicatie-ecosysteem bestaande uit vele herbruikbare, onafhankelijk uitrolbare en afzonderlijk schaalbare componenten.

De Geschiedenis van “Tiers”

De meest traditionele applicaties zijn monolithisch: één programma dat al zijn functies vervult zonder afhankelijk te zijn van externe hulpmiddelen. Lang geleden werden de meeste applicaties op deze manier gebouwd, en vandaag zijn heel wat desktop applicaties hier nog steeds voorbeelden van. Met de opkomst van netwerken en Database Management Systemen (DBMS), werd echter voor vele applicaties een meer component-gebaseerde uitrol nodig. Voor een gedistribueerde applicatie werd het b.v. nodig om een “client” en een “server” of “backend” te hebben, om op die manier een gebruiker toe te laten de applicatie op een andere plaats (op een andere machine) te gebruiken dan de plaats waar de kern van de applicaties zich bevindt (meestal ook met het doel om meerdere gebruikers gelijktijdig van de applicatie gebruik te kunnen laten maken). Dit wordt de “client-server” of “2-tier” architectuur genoemd. Voor applicaties, die aan geavanceerde I/O doen, werd het daarnaast ook noodzakelijk om de verantwoordelijkheid hiervoor bij een DBMS te leggen. Dit systeem wordt dan de “data tier” van de applicatie.

Uiteraard leidden deze twee architecturen reeds snel tot de zogenaamde “3-tier” architectuur, met een client tier en een backend die werd gesplitst in een tier voor de business logic en een data tier. Tegenwoordig zijn er vaak nog meer opsplitsingen mogelijk. In de context van web-applicaties zal men b.v. de client tier nog in twee delen splitsen: de eigenlijke client in de browser, en een “web tier” om de client via het web te kunnen aanbieden. Men zou deze laatste zelfs nog kunnen opdelen in aparte servers voor het statische en dynamische gedeelte van de applicatie. Ook wordt het mogelijk dat een applicatie meerdere verschillende databronnen gebruikt, of dat haar business logica verdeeld geraakt over meerdere tiers (b.v. application logic vs domain logic). Langzaamaan verdwijnt dan ook de notie van tiers (waarbij men een min of meer hiërarchische en lineaire relatie verwacht tussen de componenten), om plaats te maken voor een flexibeler systeem, waarbij de communicatie flexibeler vormen kan aannemen…

Tiers of Lagen?

De opdeling in tiers klinkt allicht bekend in de oren voor wie reeds met software architectuur bezig is, en doet ook denken aan de opdeling van een applicatie in lagen (“layers”). De beide termen, tiers en layers, worden soms zelfs als synoniemen beschouwd (zuiver taalkundig zijn ze dat ook, en in het Nederlands kunnen we ze beide vertalen als “lagen“). Dit is logisch: er is een grote similariteit tussen deze beide concepten, en bijgevolg is er dus enige verwarring aanwezig.

Lagen voorzien in een logische scheiding binnen de architectuur van een applicatie, waarbij het zaak is om tussen deze lagen, die functioneel gezien zo coherent mogelijk moeten zijn, een zo groot mogelijke onderlinge onafhankelijkheid te creëren (het zogenaamde “loskoppelen“). Ze hebben eerder als doel om functionele belangen (user interface (UI), applicatielogica, business logica, data access, etc.) gescheiden te houden en de applicatie aldus makkelijker onderhoudbaar te maken op lange termijn, doordat deze belangen apart benaderd kunnen worden. Tiers daarentegen, zijn fysiek gescheiden onderdelen van een applicatie, die apart van elkaar worden ontplooid, waardoor ze niet alleen het aparte onderhoud en de aparte ontwikkeling verder doortrekken, maar ook apart hergebruiken en schalen mogelijk maken.

De verwarring tussen de beide concepten ontstaat allicht omdat de logische layers in de praktijk zeer vaak corresponderen met de fysieke tiers: de UI zit in de client tier, de business logica zit in de logic tier, en de database-laag komt overeen met de data tier. De scheiding in losgekoppelde lagen is daarnaast de ideale manier om ervoor te zorgen dat tiers los van elkaar kunnen worden gedeployed. Daarenboven wordt het onderscheid ook vervaagd in de context van de Cloud: Tiers zijn dan wel fysiek gescheiden, maar door het gebruik van Cloud-technologie (IaaS of PaaS) kunnen ze evenwel worden gehost op dezelfde fysieke of zelfs virtuele machine. Ze zouden eenvoudig in verschillende Containers kunnen worden geplaatst (zij het JEE, Docker of andere containers).

Om te besluiten: layers vormen dus de bouwstenen van een applicatie op een logische manier, en beïnvloeden sterk de architectuur en het design ervan. Tiers, op hun beurt, definiëren de opdeling van een applicatie in onafhankelijk uitrolbare componenten. Ze hebben ook een sterke impact op de architectuur, maar eerder op het niveau van de interacties tussen de applicatie en andere systemen binnen een groter geheel, en op het niveau van de infrastructuur. Tiers kunnen moeilijk zonder layers: het loskoppelen van delen van de applicatie is nodig om ze apart te kunnen uitrollen. Beide zijn onontbeerlijk om de complexiteit van een applicatie in beheersbare blokken op te delen.

Richting Microservices

Over de interessante evoluties binnen applicatie-architectuur en lagen, kunnen we in de toekomst nog een blog schrijven. Vandaag ligt de focus op tiers, en hoe het opsplitsen van een applicatie in componenten en diensten verregaande gevolgen kunnen hebben voor applicatie-ecosystemen.

Ik heb het reeds in verscheidene blogs over applicatie-ecosystemen gehad, maar nagelaten het concept eenduidig te definiëren. Bij deze dan een poging tot definitie:

Een ecosysteem van applicaties is een groep applicaties (en gerelateerde IT entiteiten) die werken rond een gelijkaardig business domein, of die toebehoren aan eenzelfde organizatie (of beide). Soms betreft het zelfs groepen van applicaties die rond verschillende maar gerelateerde business domeinen werken. Typisch verwerken ze dezelfde of sterk gerelateerde gegevens, en vrij vaak interageren ze ook met elkaar, en/of worden ze gebruikt door dezelfde groep van eindgebruikers.

Hieruit volgt dat binnen een applicatie-ecosysteem er een groot potentieel (!) bestaat voor hergebruik. Of dit potentieel effectief wordt gehaald, hangt sterk af van gemaakte keuzes betreffende enterprise, applicatie en systeem-architectuur.

Een kritiek die is komen te ontstaan op de N-tier architectuur, is dat een applicatie nog steeds te geïsoleerd en self-contained is: alle business-logica zit vaak in één tier, alle persistentie-logica in een andere, etc. Men zou zelfs kunnen zeggen dat we de monolithische applicatie hebben vervangen door monolithische tiers! En dit terwijl applicaties steeds complexer worden en verregaandere behoeften hebben, zoals de integratie van business rules, taakbeheer en workflows; allemaal zaken die zo complex zijn, dat ze al een toepassing op zichzelf kunnen vormen.

Service Oriented Architecture (SOA) is een stap in de goede richting, maar historisch gezien richt deze methodiek zich op interacties tussen verschillende applicaties, binnen het ruimere opzicht van enterprise architectuur. Microservices nemen de ideeën van N-tier en SOA samen, en drijven ze naar een nieuw summum: elke aparte applicatie wordt nu beschouwd als zijn eigen mini-ecosysteem van onafhankelijk uitrolbare diensten, zich elk focussend op een verschillende business capabiliteit, zo klein gemaakt als maar kan (vandaar “micro”), en met zo min mogelijk gecentraliseerde orchestratie. Meestal heeft elke microservice – indien deze nood heeft aan persistentie – ook zijn eigen database (of een ander soort persistentiesysteem), die enkel en alleen voor deze microservice wordt ingeschakeld.

Deze stijl verhoogt sterk de Agility van SOA: de kleinere services kunnen meer cohesief op zichzelf staan, en intern zijn ze meestal ook eenvoudiger dan volledige applicaties typisch zijn. Daarnaast kunnen onderhoud en evolutie van alle microservices apart van elkaar worden beheerd. Dit alles maakt dat deze aparte microservices makkelijker te bouwen en onderhouden zijn dan de volledige applicatie (uiteraard kruipt er wel enig werk in het op een goede manier opdelen van de applicatie in verschillende microservices). Men kan zelfs zo ver gaan als volledige microservices te vervangen door nieuwere en betere: indien ze klein genoeg zijn, kan de kost gerechtvaardigd zijn om een dergelijk stuk software – huiver – weg te gooien.

Daarnaast wordt het voor ontwikkelteams ook mogelijk om flexibeler te kiezen welke technologie, welke talen en welke raamwerken ze zullen gebruiken om hun specifieke microservice zo optimaal mogelijk te implementeren. Ze zouden Java, Node.js, of eender welke andere technologie kunnen kiezen, zo lang ze maar overeenkomen over een gestandaardiseerd communicatiekanaal. Dit kanaal, op zijn beurt, zien we meer en meer evolueren richting RESTful APIs: een robuuste de facto standaard.

Deze evolutie wordt verder nog versterkt door de opkomst van Container technologie: deze zijn de infrastructuurplatformen van de toekomst (of zelfs al van vandaag), en zijn “lichter” en makkelijker inzetbaar dan virtuele machines, waardoor het kosten-effectief wordt om een groter aantal kleinere services te hosten i.p.v. een klein aantal zwaardere applicatie(s)(-tiers). De beide technologische evoluties werken op die manier hand in hand om de schaalbaarheid van applicaties te verbeteren op een fijnmazig niveau: elke microservice kan onafhankelijk van de andere worden geschaald, en via containers kan er voor worden gezorgd dat de eronder liggende infrastructuur, gebruikt door het geheel aan services, een betere match vormt met het evoluerend verbruikspatroon.

Microservices maken het mogelijk voor een organizatie om meer Agile te werken en cross-functionele teams te bouwen, gefocust op business capabiliteiten, i.p.v. teams gefocusd op specifieke IT functies (UI specialisten, middleware specialisten, DBA’s, …). Wanneer een applicatie monolithisch wordt gebouwd, is er vaak veel heen-en-weer “gedoe'” tussen verschillende teams nodig om cross-functionele zaken te implementeren, met het gevaar dat business logica doorsijpelt op plaatsen waar deze niet hoort te zitten (b.v. in de UI of de data laag). Een meer expliciete scheiding van de applicatie in service componenten maakt de grenzen duidelijker, zowel tussen de microservices als tussen de teams die ze implementeren, waardoor er meer onafhankelijkheid in het implementatieproces kan worden gestopt. Een meer servicegericht model van samenwerking wordt op deze manier mogelijk: teams worden klant van elkaar omdat hun producten klant zijn van elkaar.

Ecosystemen van Services

Binnen een applicatie-ecosysteem van enige omvang, is er altijd al op vele niveau’s de nood geweest aan integraties. Met een beetje geluk waren deze integraties gekend wanneer een applicatie werd gebouwd, maar vaak is het echter zo dat de nood aan integratie achteraf ontstaat, wanneer een applicatie reeds enige tijd in productie is. Integraties komen ook voor op het UI niveau, waar ze leiden tot portaal technologie en integration-at-the-glass. Of ze komen voor op het niveau van de data, wat vaak tot gevolg heeft dat een database wordt gedeeld tussen verschillende applicaties. Er zijn reeds verdienstelijke pogingen gedaan om al deze integraties op te vangen via middleware, maar zelfs de alomtegenwoordige Enterprise Service Bus (ESB) is geen panacee.

We kunnen nooit vrij zijn van de onverwachtheid van sommige integratie-behoeftes, maar microservices kunnen een aantal van de moeilijkheden helpen verminderen. Enerzijds komt dit door de standaardisatie van de communicatie tussen microservices. Anderzijds doordat business capabiliteiten dankzij deze architectuur worden opgedeeld in kleinere stukken, wordt het makkelijker om een component te gaan hergebruiken in een andere applicatie, en deze apart te schalen indien hij daardoor zwaarder belast wordt. Bovendien kunnen we applicaties op zo’n manier opsplitsen, dat hergebruik wordt aangemoedigd: er zullen enerzijds applicatiespecifieke microservices deel uitmaken van een applicatie, maar anderzijds zullen er ook microservices zijn die een bepaalde business problematiek of capabiliteit ondersteunen, die onafhankelijk is van applicatielogica; deze laatste zijn vaak in meerdere toepassingen nuttig. Verder kunnen we ook nog microservices hebben die verantwoordelijk zijn voor een bepaald deel van de persistentie-behoeften van de applicatie. Services zo klein dat ze data betreffen die ook door andere applicaties gebruikt wordt. Deze “data services” zullen de poortwachters zijn van de data: zij encapsuleren de databases (of maken deel uit van een algemenere Data as a Service aanpak) en hebben meerdere applicaties als klant.

Uiteindelijk leidt deze opdeling in services tot een heel ander ecosysteem: niet één van monolithische of tiered applicaties, maar één van intergeconnecteerde microservices. En deze grote groep microservices kan dan “ten dienste” staan van specifieke “client”-componenten die een UI bevatten en dus de gebruikers toelaten dit ecosysteem te gebruiken op verschillende manieren. Dezelfde achterliggende dienst kan bijvoorbeeld een rol spelen binnen een web-toepassing, maar ook in een mobiele toepassing.

Eén probleem is dat deze sterke interconnectiviteit tussen een steeds groter wordende groep microservices kan gaan lijken op een onbeheersbaar kluwen (zogenaamde point-to-point integraties). Er zijn echter een paar zaken die dit effect tegengaan:

• Enerzijds is de point-to-point integratie slechts een integratie op conceptueel niveau. Op technisch vlak zal dit worden opgevangen door middleware-technologie, zoals de ESB. Zolang een dienst een logisch en leesbaar adres heeft, kan deze op die manier worden aangesproken. De werkelijke localisering en verbinding is de verantwoordelijkheid van een onderliggend platform.
• Daarnaast kan men ook twee reeds eerder besproken principes toepassen: die van Data-Centric IT, en die van Event-Driven Architecture. Deze zijn compatibel met elkaar en met Microservices, en zorgen samen voor een beheersbaar “inter-service” communicatiemodel: samen kunnen deze methodieken er namelijk voor zorgen dat een dienst enkel moet weten welke data en events er nodig zijn en hoe deze kunnen worden geadresseerd. Er zijn uiteraard nog externe zaken nodig die geen data of Event zijn, maar dit zijn dan meestal generieke en nuttige diensten, zoals het genereren van pdf’s of het aanroepen van eerder technische capabiliteiten, zoals authenticatie of logging.
• Ten slotte komen er specifiek voor deze problematiek ook oplossingen te voorschijn onder de noemer van API management. De publieke interface van een microservice kan namelijk gezien worden als een API (Application Programming Interface). Naast het beheer van een veelvoud aan APIs, richten deze platformen zich ook vaak op het beheer van de levenscyclus van de erachterliggende diensten.

Besluit

Microservices zijn als deployment architectuur een perfecte match voor Agile software ontwikkeling, en verankeren de goede principes van Service Oriented Architecture. Ze maken het mogelijk software op een flexibeler manier te ontwikkelen, met vele kleine componenten, waardoor er sneller kan worden ingespeeld op veranderende behoeften. Ze laten herbruikbaarheid toe op een fijnmazige manier, en verhogen de efficiëntie in het gebruik van resources. Ook met de huidige ontwikkelingen op vlak van infrastructuur: Containers, gaan ze heel goed samen. Samen daarmee, en met EDA en REST, vormen ze een blauwdruk om een applicatie-ecosysteem future-proof op te bouwen.

Containers, the name you know !

Het woord “Container” klinkt vele mensen, niet alleen in de bouw en scheepvaart, maar ook in de IT, reeds bekend in de oren. Het is dan ook, net zoals “Component“, een erg brede term, die binnen ons vakgebied wijd uiteenlopende implementaties kent. In ruime zin wil het uiteraard precies zeggen wat het woord betekent: “Een ding waar andere dingen in kunnen”.

Een paar voorbeelden:

• Containers als Abstract Data Type: binnen programmeertalen kunnen ze worden gebruikt om verzamelingen van andere waarden of objecten te bevatten en beheren (e.g. een Lijst of een Set).
• Containers zijn ook een andere naam voor Applicatieservers, of een specifiek deel ervan om servlets te hosten (de “Web Container“).
• Waar het in deze blog over gaat: Containers als Virtualizatie-middel op niveau van besturingssystemen (“Operating-system-level Virtualization“).

Containers are the new VM’s !

Wat is dat dan precies, die nieuwe Containers waar iedereen het over heeft? Zoals gezegd is het dus een soort van virtualizatietechniek op niveau van, t.t.z. binnen een besturingssysteem. En hier zit natuurlijk het verschil met Virtuele Machines, waarbij we virtualizatie hebben over besturingssystemen heen. Desondanks zorgt de technologie ervoor dat Containers en de erin aanwezige processen netjes van elkaar geïsoleerd blijven. Zoals op de figuur te zien is, hebben Containers het grote voordeel tegenover VM’s dat ze veel lichter zijn. Binnen een VM zal er altijd nood zijn aan een gast-besturingssysteem (“guest os”), dat, hoe klein ook, een deel van de bruikbare middelen van het systeem zal opslorpen. Containers dragen deze last niet. Voorlopig blijven VM’s koning van het datacenter, maar Containers zouden wel eens een coup kunnen plegen.

Containers zijn mogelijk dankzij de manier waarop de Linux kernel werkt (Microsoft kondigde echter al support aan voor Containers binnen Windows Server). Het isoleren van processen en het beperken van hun resource-gebruik is reeds heel lang mogelijk binnen Linux; er was echter een bedrijf als Docker nodig om een ecosysteem aan ondersteunende tools te creëren, om zo deze technologie van onder de grond te halen en recht naar de Cloud te katapulteren. Ondertussen is er trouwens al wat concurrentie in de Containermarkt.

Containers: build once; ship and run anywhere !

De technologie die de laatste tijd rond Containers is uitgebouwd en vooral door Docker en CoreOS is gepopulariseerd, laat toe om om een applicatie met alle nodige bibliotheken, bestanden en configuratie, in een pakketje te stoppen, en dit pakketje naar een Container ondersteunend platform te sturen om de applicatie te laten werken. Het is perfect mogelijk om in je eigen datacenter, of zelfs op één machine op je zolder, Containers te ondersteunen, net zoals in de public cloud. Het mooie is dat het niet uitmaakt waar de server zich bevindt: indien Containers ondersteund zijn, kan je je pakketje erop zwieren. Bovendien bestaan er al van heel veel applicaties standaard pakketjes (b.v. te vinden in de Docker Hub), en hoef je dus al vaak zelf niet meer veel werk te doen om iets te kunnen lanceren.

Containerpakketjes zijn ook heel flexibel uitbreidbaar: ze kunnen gelaagd worden opgebouwd, een beetje als een ajuin. Indien bijvoorbeeld iemand al een Node.js image heeft voorzien, kan je jouw node.js applicatie daarbovenop bouwen. Je hoeft dus niet telkens van nul te beginnen.

Ten slotte is het ook mogelijk je applicatie in meerdere pakketjes te stoppen: b.v. het applicatieve deel en de database apart. Je kan zo’n pakketje zelfs schalen, door het meermaals uit te rollen. Je kan b.v. het webgedeelte van je applicatie in één Docker Image stoppen, en tien maal uitrollen om alle front-end gebruikers aan te kunnen, terwijl je daarnaast b.v. maar één Docker Image uitrolt voor de database (handig als niet alle gebruikers steeds de database nodig hebben). Zo komt de droom van ultieme Modulariseerbaarheid (remember Components?) weer een stapje dichterbij.

CaaS, CPaaS, ContaaS ?

Via Docker en Containertechnologie kan men dus zeer snel applicaties of hun onderdelen uitrollen. Uiteraard wordt het al snel onoverzichtelijk wanneer men dit zomaar ad hoc gaat doen. Gelukkig zijn er reeds systemen ontwikkeld die het beheer van een Container-ondersteunend datacenter en de erop uitgerolde Containers goed ondersteunen. Google Kubernetes is er zo eentje, maar ook CoreOS is al jaren op deze markt actief. De Google Container Engine is een voorbeeld van Containers as a Service in de public cloud.

Momenteel worden zulke “CaaS” platformen meer naar voren gebracht als alternatief voor IaaS en PaaS. Ze vullen dan ook een unieke niche tussen de twee: IaaS werkt met VM’s en vergt veel meer configuratie en administratie, en PaaS is voor sommige gebruikers misschien te beperkend of gewoon een stap te ver qua niveau van ondersteuning. Dan biedt CaaS een gulden middenweg. De betere PaaS platformen maken ondertussen zelfs al gebruik van Containers!

Spijtig genoeg is CaaS vooralsnog geen officiële afkorting – althans niet voor Containers as a Service. De meest gebruikte betekenis van CaaS is Communication as a Service, maar Compiler, Commerce, Content, Crimeware en ja, zelfs Cloud as a Service (partner managed cloud) zijn kandidaten.  ContaaS bestaat allicht nog niet, maar klinkt wat ongelukkig. Ook Container Platform as a Service kunnen we niet afkorten als cPaaS, dit betekent reeds collaboration Platform-as-a-Service. Gezien echter het stijgende gebruik binnen het IT nieuws, zullen ook wij toch de terminologie CaaS hanteren.

Containers, Conclusie !

Containers zijn een bijzonder handige manier om applicaties uit te rollen en te modulariseren. Ze zijn momenteel sterk gehyped en, ondersteund door CaaS, zouden ze wel eens grote invloed kunnen hebben op de cloud, en op ons vak!