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.

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!

De cloud is (nog steeds) één van de allergrootste hypes in de geschiedenis van computertechnologie en vraagt om een evolutie waar geen enkele instelling, publiek of privé, aan kan ontkomen. Op business niveau biedt ze tal van nieuwe mogelijkheden, maar ook risico’s. Het is dus van belang goed voorbereid te zijn om op een optimale manier te kunnen instappen in het cloudverhaal.

Een spanningsveld dat momenteel sterk speelt bij vele organisaties, is dat van public versus private. Meer bepaald: zal men gaan gebruik maken van diensten in de public cloud, aangeboden door externe, veelal Amerikaanse, leveranciers, of probeert men eerder een eigen cloud uit te bouwen, in het eigen datacenter, waarop men dan zelf de nodige diensten kan aanbieden en uitbaten? De eerste optie zal vaak de goedkoopste zijn, aangezien de public cloud-spelers kunnen profiteren van een enorm schaalvoordeel. Het alternatief wordt vooral aantrekkelijker doordat het als veiliger en betrouwbaarder wordt beschouwd, omdat men de volledige controle behoudt over de eigen infrastructuur en – vooral – data. Zeker in perspectief van recente spionageschandalen lijkt het geen overbodige luxe om de data binnen de eigen landsgrenzen te houden.

In deze blog zullen we dus de tweede visie aanhangen: die van het belang van controle over de eigen data, zeker wanneer het gevoelige, persoonsgebonden of zelfs medische data kan betreffen. We gaan dan ook kijken naar mogelijkheden om een private cloud zo functioneel mogelijk te maken, en dit liefst aan een zo klein mogelijke kost.

Specifiek in deze tekst zullen we onderzoeken wat de mogelijkheden zijn om software, die reeds werd ontwikkeld voor stand-alone gebruik, aan te bieden als cloud-dienst. We gaan dus kijken wat we kunnen doen om deze bruikbaar te maken als Software as a Service (SaaS). Concreet zullen we zien hoe we voor onze klanten of tenants een instantie van een bepaald software-pakket op aanvraag kunnen lanceren; Instance as a Service dus!

Om dit te doen hebben we eerst en vooral een aantal mogelijkheden die reeds voor ons worden voorzien in de IT-wereld. Zo bestaan er al langer oplossingen voor het snel gereedmaken van virtuele servers, en we zoomen ook nog in op Containers, een technologie die reeds op korte termijn de Cloud op haar grondvesten heeft doen daveren. Ten slotte doen we een zelf ontwikkelde methode uit de doeken.

1. Kant-en-Klare Servers

Indien men een bestaand IaaS aanbod heeft, en dus virtuele machines aanbiedt via de Cloud, kan men opteren voor het aanbieden van een hele resem aan virtuele machines waar reeds nuttige software is op voorgeïnstalleerd. Verschillende voorbeelden hiervan zijn te vinden in de publieke Cloud.

Bitnami stelt images van virtuele machines gratis ter beschikking op zijn website, met ondersteuning voor meer dan 100 populaire webtoepassingen, zoals WordPress en Drupal. Daarnaast bieden ze ook installatiebestanden (“stacks”) aan om deze op een reeds bestaande machine te installeren, met inbegrip van alle onderliggende middleware, zowel voor Windows, Linux, als Mac. In de public cloud (Amazon, Google en Microsoft) biedt Bitnami tevens aan om de images naar iemand’s cloud account te sturen en de machine rechtstreeks aan te maken en op te starten. Dit heet dan Bitnami Cloud.

Een concurrent van Bitnami is Turnkey. Ook dit bedrijf biedt images van virtuele machines aan voor een groot aantal populaire toepassingen. Er zijn een aantal verschillen met Bitnami: Turnkey biedt b.v. enkel zijn pakketten aan voor Linux servers. Daarbij is het wel zo, dat Turnkey de standaard mechanismes van software installatie op deze machines volgt, terwijl Bitnami een aangepaste manier gebruikt. Hierdoor zijn de virtuele machines van Turnkey achteraf gemakkelijker op de standaard manier van Linux te onderhouden (via de package managers). Om een major update te doen van een Bitnami pakket (met inbegrip van de middleware), raadt men daarentegen meestal aan om een nieuwe machine op te zetten en de data van de oude naar de nieuwe te migreren (kleinere updates kan men typisch uitvoeren via de webinterface van de desbetreffende toepassing).
Bij Turnkey is er ook een iets grotere focus op modulariteit. Zo zou men b.v. bij een WordPress installatie kunnen opteren om de achterliggende MySql database op een aparte Turnkey machine te plaatsen. Bij Bitnami heeft men deze mogelijkheid niet. Uiteraard zorgt dit voor een grotere complexiteit, waardoor Bitnami een groter gebruiksgemak heeft.

Samengevat zou men dus aan Cloud klanten eveneens zo’n groot aanbod aan verschillende virtuele machines kunnen aanbieden, waarbij ze dus bij hun gebruik van IaaS konden gebruikmaken. Zolang de applicaties niet te intensief gebruikt worden, passen deze netjes binnen één virtuele machine. Wanneer er echter moet worden geschaald, zijn ze hier niet meer goed voor aangepast.

Containers

Container technologie is één van die dingen die al een hele tijd bestaan zonder dat er een haan naar kraait, en dan plots fenomenaal doorbreken als hype. Eerder stond de technologie vooral bekend als virtualisatie op het niveau van het besturingssysteem (Operating-System-Level Virtualization). Containers kan men beschouwen als een soort ‘light-weight’ virtuele machines: het zijn eigenlijk “stukjes computer” die men binnen een machine inneemt en die men via (Linux) beveiligingstechnologie perfect geïsoleerd houdt van de rest van de machine en van andere containers. In een container kan men dan alle programmatuur en configuratie stoppen voor een applicatie.

Men kan dan twee richtingen uit: zoals bij de virtuele machines kan men in principe een hele software stack in zo’n container stoppen en aldus een werkend en netjes geïsoleerd pakket bekomen, dat men op eender welke machine die de technologie ondersteunt, kan laten uitvoeren (‘build once, run anywhere’). Maar waar containers echt in uitblinken, is in modulariteit: elk deel (‘component‘) van een systeem kan men in een andere container stoppen en dan met elkaar laten communiceren (e.g. het web gedeelte en de database apart).

Over deze technologie kan nog heel veel gezegd worden, maar om applicaties aan te bieden aan klanten, is het voldoende te weten dat men ook van deze containers een heel aantal prototypes kan verzamelen met allerlei nuttige applicaties erin, net zoals men met de virtuele machines kan. Docker biedt zelfs al zo’n plaats aan waar vele mensen vrijwillig toe bijdragen (de Docker Hub). Het volstaat dan om daarnaast op de private Cloud een Container ondersteunend platform aan te bieden en eventueel een GUI om het opstarten van een standaard container nog wat te vergemakkelijken.

3. Instance as a Service

Bij Onderzoek hebben we een studie aan dit onderwerp gewijd, waarvan binnenkort een research nota zal verschijnen. Onze methode om instanties van applicaties aan te bieden, maakt sterk gebruik van een aPaaS platform. Een aPaaS platform ondersteunt namelijk de schaalbaarheid van de erop ontwikkelde toepassingen, en zal zelf ook erg elastisch kunnen schalen, gezien erop uitgerolde applicaties kunnen komen en gaan. aPaaS platformen nemen dus al een groot deel van de effort om efficiënt gebruik te maken van de onderliggende machines, voor hun rekening. Op die manier krijgen we dus de schaalbaarheid en elasticiteit op het niveau van het platform cadeau!

Onze methode werkt als volgt: We kijken eerst of er reeds een “instant app” beschikbaar is voor het aPaaS platform dat we gebruiken. Dit zijn voorverpakte applicaties die er reeds op gemaakt zijn op ons platform te werken. Indien zo’n instant app bestaat, is het gemakkelijk: we kunnen deze dan eenvoudigweg gebruiken en enkel het lanceren van nieuwe instanties moeten we dan nog automatiseren tot er voldoende self-service is. Dit laatste doen we door een catalogus-applicatie te voorzien waar we snel de instant apps aan kunnen toevoegen.

Wanneer er nog geen instant app bestaat, moeten we deze zelf ontwikkelen op  basis van de broncode van de bestaande applicatie die we wensen aan te bieden. Dit is een iteratieve procedure die uitgewerkt is in bovenstaande figuur, maar waar we in deze blog niet in detail op in zullen gaan. We kunnen wel zeggen dat het slechts een kleine tot matige hoeveelheid werk is, zeker voor iemand die bekend is met de broncode-taal van de betreffende toepassing.

Wat we ten slotte niet mogen vergeten, is onderhoud: Er zullen namelijk geregeld updates komen van de toepassing die we hebben aangepast, en we willen deze natuurlijk graag incorporeren in ons SaaS aanbod. Ook deze 4e fase is te zien in de figuur, maar gaan we niet verder detailleren in deze blog.

4. Een vergelijking

Het grote voordeel van onze methode is dat we schaalbaarheid cadeau krijgen, dankzij het onderliggende aPaaS platform. Bovendien zorgt ze voor een efficiënter gebruik van resources, zeker tegenover de oplossing gebruik makende van virtuele machines. Daarnaast kan de aanwezigheid van een aPaaS platform ook nog zorgen voor een gemakkelijker beheer van ondersteunende diensten, zoals logging en monitoring van de applicaties.

Het nadeel van een eigen methode te hebben is dat we zelf het werk moeten doen, terwijl dit bij gebruik van b.v. de bestaande vm’s of Docker containers veel minder het geval is. Op die manier wordt het gevaarlijk om zomaar allerlei software te gaan aanpassen, wanneer we niet op voorhand weten of er voldoende afname zal zijn.

SaaS betekent Software as a Service. Dit wil zeggen dat men een gebruiksklaar product, zoals b.v. een webmail-applicatie, aflevert als een Cloud-dienst (en dus niet b.v. een server in de cloud, waarop men nog software moet plaatsen). Van SaaS kunnen we ook verschillende eigenschappen opnoemen, maar wat maakt nu écht het verschil tussen deze technologie en tussen de andere XaaS? M.a.w. waaraan, buiten dat het “Software” is en niet “Platform” of “Infrastructure”, kunnen we nu échte SaaS onderscheiden van de wannabe’s? Waar zit hem de Saus in de SaaS?

1. Multi-Tenancy as a Service, maar dan echt!

Een SaaS toepassing kenmerkt zich door het feit dat het één internettoepassing is die door meerdere klanten, of ‘tenants’ kan worden gebruikt, en dit via zelfservice. Uiteraard is er daarbij nog een verschil met de typische Cloud-diensten die we als particulier kunnen gebruiken, zoals Dropbox, Gmail, Twitter, etc. Bij een echte SaaS is het zo dat de tenants ook grote klanten kunnen zijn, die het product als het ware ‘huren’ om het te laten gebruiken door hun eigen (eind-)gebruikers. Typisch dus b.v. een instelling die zijn eigen interne e-mailsysteem via Gmail wil laten werken, of een bedrijf dat Dropbox gebruikt om een intern File sync & share systeem op te zetten. Kortom: er zijn typisch 3 partijen aan het werk: de aanbieder van de dienst, de klant of ‘tenant’ en de eindgebruiker.

Enerzijds is het dus belangrijk dat deze multi-tenancy via zelfservice kan worden opgezet om van SaaS te kunnen spreken: typisch zal een tenant via een webportaal een speciale account kunnen aanmaken, waarmee hij zijn afgehuurd deel van het software-systeem kan beheren. Dit houdt o.a. user management in, en het beheer van de kosten.

Anderzijds is ook van doorslaggevend belang op welke manier er aan multi-tenancy wordt gedaan. Doorgaans is er nood aan een zekere vorm van isolatie tussen de verschillende tenants, die ervoor zorgt dat ze a.h.w. “geen last hebben” van elkaar. Concreet betekent dit o.a. dat gebruik van een grote hoeveelheid bandbreedte, cpu-tijd, of schijfruimte door één tenant geen nadelig gevolg mag hebben op die van andere tenants. Iedereen zal dus een bepaald quota krijgen. Ook wanneer eventueel fouten in het programma optreden bij één tenant, moet worden vermeden dat deze zich uitbreiden naar de andere. Kortom, voor elke tenant moet aan een bepaalde Service Level Agreement (SLA) kunnen worden voldaan, los van de andere tenants.

Ook functioneel kunnen er trouwens zaken zijn die tenants graag geïsoleerd zien. Zo is het uiteraard vanzelfsprekend dat tenants geen toegang hebben tot elkaars data (tenzij ze dit expliciet willen als extra functionaliteit).

2. Aardappelen, SLA? Alles apart betalen!

Nog typisch aan een SaaS product is dat de service betaald wordt op basis van verbruikscriteria, en niet op basis van vaste contracten. Wie meer verbruikt – of wil verbruiken – of wie een betere service wil, kan daarvoor dus bijbetalen. Dit soort van facturatie kent verder nog twee varianten:

• Het “McDonald’s” model. Dit is het zuivere “pay-per-use” model: Net zoals men bij een hamburgerrestaurant elke burger, elk pak friet en de saus allemaal apart betaalt, doet men dit ook voor sommige Cloud diensten. B.v. het maximum aantal GB dat gedurende een bepaalde maand werd ingenomen aan opslag, of het aantal gebruikers dat gedurende een bepaalde maand lid was. Normaal gezien zijn er geen kosten indien niets wordt verbruikt, al komt dit model ook vaak gecombineerd voor met het tweede model.
• Het “All you can eat” model. Bij dit model, dat werkt via de zogenaamde “monthly subscription”, betaalt men een vast maandelijks bedrag om binnen een bepaald quota te verbruiken wat men wil, net zoals men – per persoon – kan eten wat men wil in de gelijknamige restaurants. B.v. 9,99 dollar per gebruiker per maand voor 100 GB opslag (huidige prijs bij Dropbox Pro), of je ze nu leeg laat staan of opvult. Zoals gezegd kan men dit model soms ook aanvullen met het eerste: men betaalt dan extra voor wat men verbruikt boven het vaste quota.

De gehele prijszetting en facturatie is typisch ook goed online op te volgen door de klant, in een apart administratief scherm van de toepassing, en kan, via de typische zelfservice, ook gemakkelijk worden aangepast aan de specifieke behoeften van de klant.

Ten slotte, zoals de titel van dit puntje al aangaf, is een goede SLA niet gratis: ook extra support zal men vaak, typisch via subscriptie, moeten bijbetalen. Dit kan dan typisch onder de vorm van “silver” of “gold” plannen, die men ook in andere branches van computing graag gebruikt.

3. De klant in controle, “Softwarematisch”

Zoals gezegd dient een SaaS gebruik te maken van zelfservice technieken. Deze zelfservice kan in een goed SaaS-product ook gebruikt worden om een aantal zaken per tenant te configureren en adapteren. Zo kan het bijvoorbeeld mogelijk zijn om een logo en kleuren aan te passen, maar b.v. ook om bepaalde beveiligingsregels in te stellen waaraan alle gebruikers van de tenant zich aan moeten houden.

Dit alles moet “softwarematisch” kunnen gebeuren in een goed SaaS-product. Dat wil zeggen, het mag niet de bedoeling zijn om manueel in configuratiebestanden zaken te gaan aanpassen en daarna het product te moeten herstarten. Eerder moet het mogelijk zijn om allerlei instellingen via panelen en wizards in de web-interface van de tenant te doen, en die – liefst onmiddellijk – in werking te laten treden.

Momenteel onderzoeken we hoe bestaande toepassingen “SaaS-Enabled” kunnen worden, d.w.z. dat we ze kunnen aanbieden als SaaS. Zoals je ziet komt daar dus heel wat bij kijken aan extra benodigde functionaliteit, en dit is dan uiteraard nog bovenop het typische Cloud-verhaal (het moet schaalbaar zijn, het moet op gedeelde infrastructuur draaien, …) Hierover meer in een volgende blogpost.

Le cloud est en train de révolutionner le monde de l’informatique. En effet, si l’Infrastructure as a Service et le Software as a Service (IaaS et SaaS) sont déjà profondément ancrés, la couche centrale de la pile du cloud – Platform as a Service (PaaS) – est à son tour en pleine progression. Cette fois, l’impact du cloud se fait sentir sur le développement de logiciels même. Dans cette étude, nous avons passé sous la loupe le plus grand groupe de produits PaaS, l’Application PaaS (aPaaS). Les plateformes aPaaS sont clairement axées sur la standardisation et l’automatisation d’une multitude d’aspects du développement, permettant une réduction du time-to-market, une baisse des coûts et une augmentation du service.

Presentation

De moderne “stack” voor applicaties in de Cloud, van IaaS (Infrastructure as a Service) over PaaS (Platform as a Service) tot SaaS (Software as a Service), is stilaan een gekend plaatje. Maar de strikte scheiding tussen het virtualiseren van infrastructuur, het automatiseren van middleware en het aanbieden van applicaties, en dit alles “als een dienst”, hoeft soms helemaal niet zo strikt te zijn.

In de Application Platform as a Service (aPaaS) branche, die reeds in een vorige blogpost uit de doeken werd gedaan, kan men bijvoorbeeld verschillende soorten aPaaS onderkennen, die variëren van een dunne schil boven IaaS, tot een soort van “Applicatie-Ontwerp-SaaS” oplossingen. In deze blogpost een korte verkenning van deze wondere wereld.

1. Vlak boven de infrastructuur

Sommige PaaS platformen bieden geen ingebouwde applicatieserver of database aan, maar vormen een laag bovenop de infrastructuur die het gebruikers makkelijker maakt om de nodige technologie geïnstalleerd en geconfigureeerd te krijgen op (niet noodzakelijk) virtuele servers.

Een voorbeeld is Cloudify. Bij deze aPaaS kan men als gebruiker een applicatie definiëren aan de hand van een recept. Dit recept stuurt men dan naar een Cloud met Cloudify ondersteuning, waardoor het platform de nodige “ingrediënten” van het recept in gebruik zal nemen. Het grote voordeel, zo stelt Cloudify, is dat recepten niet Cloud-specifiek zijn, en dat ze dus op de meeste Cloud systemen kunnen werken. Dit is b.v. nuttig voor het migreren van applicaties van de ene Cloud naar de andere.

2. Middleware als dienst

De bekendste aPaaS platformen bieden doorgaans een sterke integratie met web- en applicatieservers, en met diensten voor gegevensopslag. Sommige focussen zich op ondersteuning van een welbepaalde technologie, andere op het werken met zoveel mogelijk van de populairdere frameworks van het moment.

Een belangrijk kenmerk van platforms op dit niveau, en voor mij één van doorslaggevend belang, is dat er abstractie wordt gemaakt van de onderliggende infrastructuur. Niet langer moet je rekening houden met op welke server wat komt te staan: je deployt naar een platform, en dit platform kiest transparant welke delen van jouw applicatie op welke resources terecht komen. Welke en hoeveel infrastructuur onderliggend zijn aan het platform, daar hoef je als ontwikkelaar dan minder wakker van te liggen. Bovendien is er bij platformen met deze eigenschap doorgaans enige ondersteuning voor failover, elastisch schalen en multi-tenancy (voor ontwikkelaars).

Architectuur in een Openshift Node

Dit keer kiezen we Red Hat OpenShift als voorbeeld. Dit aPaaS platform bestaat zowel in de publieke cloud, als in een “on premise” installeerbare versie, waardoor je het dus kan gebruiken voor een private Cloud. De basis van het platform is open source.

Wanneer we op deze PaaS inloggen, krijgen we een web console te zien met behulp van dewelke we applicaties kunnen deployen in de Cloud. We moeten daarbij kiezen uit welke “cartridges” een app bestaat. Cartridges kan men beschouwen als een technologisch afgezonderde module, e.g. een MySQL cartridge. daarnaast kiezen we ook hoeveel “gears” de applicatie krijgt, en of ze schaalbaar zal zijn. Gears (letterlijk vertaald: tandwielen of radartjes) zijn eenheden van computatie, ze stellen een bepaalde hoeveelheid processorkracht, geheugen en opslag voor, los van de onderliggende infrastructuur. De cartridges van de applicatie komen dan terecht op de gears en die laatste worden transparant gedeployed op het platform.

3. (Semi-)Grafisch Applicaties ontwikkelen

Dichter bij de SaaS-laag van Cloud platformen, vinden we producten terug die doorgaans gespecialiseerd zijn in slechts enkele onderliggende implementatie-, server- en database-technologieën. Deze specialisatie laat echter wel verregaande automatisatie toe, waardoor het mogelijk wordt om eenvoudige tot matig complexe applicaties te ontwikkelen zonder code te schrijven, of dit slechts in beperkte mate te doen.

Zoho Creator is bijvoorbeeld zo’n platform. Het richt zich vooral op applicaties die sterk gericht zijn op online databases. Zo kan men via drag and drop webformulieren aanmaken, waarvan de data dan in zo’n database zal terechtkomen en eventueel in een complexe workflow. Voorts kan men acties en triggers voorzien rond data-access. Verder kan men bepaalde taken automatiseren, zoals het versturen van emails en genereren van rapporten. Html pagina’s kan men dan verder aanpassen m.b.v. html en het zogenaamd “Deluge Script”, een taal eigen aan het platform.

 Besluit

Deze 3 voorbeelden van een genuanceerdere definiëring van wat aPaaS nu eigenlijk inhoudt, zijn, opnieuw, niet te beschouwen als de enige correcte onderverdeling. In de software-industrie zijn er ondertussen tientallen producten die zichzelf volgens de definitie PaaS mogen noemen, en nog veel meer die zichzelf de noemer geven zonder het strikt genomen te zijn, allemaal met hun eigen specifieke invulling van de term. Al deze producten staan allicht net iets verder of net iets minder ver van IaaS/SaaS dan de voorbeelden hier omschreven.

Dit is voor ontwikkelaars zowel een voordeel als een nadeel: Aan de ene kant biedt het voor elk wat wils, en voor elke applicatie die moet worden geschreven kan men het “ideale platform” vinden. Anderzijds kan dit standaardisatie tegenwerken, en laat dat nu net één van de kenmerken zijn die een aPaaS platform nuttig maken.

Over aPaaS verschenen onlangs een Research Note en Presentatie.