Cloud computing heeft de afgelopen jaren al menige (IT-)organisatie aanzienlijke verbeteringen gebracht als het gaat om wendbaarheid, efficiency, innovatie en daarmee concurrentievoordeel voor de organisatie. Applicatieservers die initieel in gehuurde en gemanagede datacenters draaien, worden massaal verschoven naar public platformen als Amazon Web Services, Google Cloud Platform en Microsoft Azure.

Hoewel deze shift vaak nog vooral gericht is op rehosten van servers, zijn de resultaten in zin van efficiency, flexibiliteit en wendbaarheid, alsook innovatie, al enorm. De volgende shift in cloud computing gaat echter niet meer over servers, maar is ‘serverless’.

Als we de afgelopen twee decennia terug in de tijd kijken, zien we eigenlijk een continue run om dezelfde applicatiefunctionaliteit op steeds minder fysieke hardware te kunnen laten draaien. Deze trend ontstond aan het begin van het tweede millennium met de opkomst van virtualisatietechnologie gedreven door VMware.

Door meer servers op één fysieke server te draaien, werd enorm veel efficiency behaald en dat evolueerde zo jaren door. De volgende grote stap was de start van public cloud computing. In 2006 lanceerde Amazon Web Services hun public cloud-computingplatform, in de begin jaren veelal gericht op ‘infra-structure as a service’-diensten.

In plaats van servers die gevirtualiseerd op een eigen infrastructuur draaien, al dan niet in een eigen of gehuurd datacenter, werd ingezet op grotere schaalvoordelen met hogere efficiency en wendbaarheid tot gevolg. Langzamerhand werd de focus breder getrokken: naast infrastructure as a service kwam ook platform as a service.

Softwareontwikkelaars en applicatiearchitecten gingen daarop cloud-native denken, designen en implementeren. Ook de CIO ging serieus nadenken over een cloudstrategie. Het cloud-native denken groeide door naar applicatiearchitectuur op basis van microservices waarbij in plaats van één grote monolithische applicatie, de functionaliteit werd opgeknipt in kleinere applicatieservices die samenhang hebben. Deze kleinere functies kunnen vervolgens zelfstandig draaien, schalen en ontwikkeld worden.

De populariteit van microservices ging hand in hand met containerization (Docker) waarbij deelfunctionaliteiten van een applicatie in containers gingen draaien. De laatste stap in deze evolutie is gezet met de lancering van Amazon Web Services Lambda. AWS Lambda is de grondlegger van de event-based serverless computing, wat we vandaag de dag ‘serverless’ noemen (zie figuur 1).

Figuur 1. De ontwikkeling van fysieke servers naar serverless

Businesslogic

Serverless lijkt een vreemde benaming, want een cloudserviceprovider gebruikt uiteraard nog steeds servers. Voor de afnemer van de serverless dienst is er echter geen zorg meer voor het inrichten en managen van de onderliggende servers. Eigenlijk is dit net zo als bij ‘platform as a service’-diensten, managed databases bijvoorbeeld.

Waar het bij serverless om draait, is het verwerken/draaien van applicatiecode in programeertalen als bijvoorbeeld Node.js, Python of Java. Het verwerken van de applicatiecode gebeurt daarbij op basis van een trigger. Wat een trigger kan zijn, varieert enorm: van het ontvangen van een upload van een file, het ontvangen van een e-mail of een scheduled event tot een api-request of trigger vanaf een andere serverless functie.

Vertaald naar applicatiearchitectuur is het gedachtegoed van serverless om applicaties op te bouwen uit businesslogic – net als bij microservices. De businesslogic definieer je in events en functies. Een event triggert een functie en een functie is simpelweg een stukje applicatiecode dat door het onderliggende cloudplatform wordt uitgevoerd.

Serverlessgeoriënteerde applicaties zijn meestal niet uitsluitend gebouwd uit serverless diensten als bijvoorbeeld AWS Lambda. Naast applicatiecode hebben de meeste applicaties ook behoefte aan bijvoorbeeld storage, wat ingevuld kan worden met object-storage als AWS S3 of NoSQL-databasestorage met AWS DynamoDB, en komen de triggers ook van buiten waardoor de AWS API Gateway een oplossing kan zijn.

Figuur 2. Voorbeeld van de architectuur van een serverless applicatie

Serverless is game-changer in cloud computing

Serverless cloud computing is absoluut de game-changer in softwareontwikkeling en cloud computing. Doordat er geen servers meer nodig zijn voor het uitvoeren van applicatiecode, vervallen veel van de nadelen die nog steeds bij cloud computing gelden. Software-developers zijn hierdoor in staat om nog sneller te kunnen ontwikkelen en vooral ook hun tijd te kunnen besteden aan business-requested features. Op de gebieden pay-per-use, beheer en schaalbaarheid worden de grootste voordelen behaald.

Ultieme pay-per-usebelofte ingelost

Alhoewel infrastructure-as-a-servicediensten worden geleverd met een pay-per-usebelofte, betalen we in de praktijk eigenlijk nog steeds vaak teveel. Dat komt doordat servers veel ‘idle time’ hebben. Zelfs al kan er tot op de seconde worden afgenomen, er blijft altijd idle time. De regie om te schalen ligt namelijk bij de applicatiedeveloper, inframan of in het mooiste geval geautomatiseerd in de applicatie.

Maar het schalen gaat nog steeds in eenheden van een hele server. Daarentegen wordt bij serverless eigenlijk alleen gerekend naar de I die wordt verwerkt, tot op honderden milliseconden nauwkeurig. Je kunt je voorstellen hoeveel efficiënter applicaties kunnen werken dan in een situatie waar dit op één of meerdere servers gebeurt.

Beheer(kosten)

Omdat we geen servers hebben, hoeven we geen medewerkers of derde partij meer te betalen om ze te provisionen, te onderhouden en te monitoren. Geen OS-patching en hardening meer en ook geen gedoe met OS-lifecyclemanagementprojecten. Buiten de besparing in effort, reduceert dit ook nog eens het aanzienlijke risico dat alle changes en upgrades continu met zich meebrengen.

Schaalbaarheid

Serversless computing wordt als hoog beschikbare dienst aangeboden. Er hoeft dus niet nagedacht te worden hoe de uitvoering van de applicatiecode op infrastructureel niveau hoog beschikbaar wordt gemaakt. Ook voor schaalbaarheid geldt dit mechanisme. De cloudprovider draagt continu zorg voor voldoende resources om de applicatiecode uit te kunnen voeren. Capaciteit is er gewoon en geen zorg meer van de developer.

Serverless in de praktijk

Sinds de lancering van serverless met AWS Lambda, en later ook de equivalenten
Azure Functions en Google Cloud Functions, groeit de toepassing enorm hard. Ook bij onze klanten zijn we eigenlijk direct al in 2014 gestart met het toepassen van serverless. We zagen al snel toepassingen voor het bouwen van maatwerkfuncties binnen het AWS-cloudplatform zelf.

Het automatiseren van reguliere beheerscripts, controlefuncties en checks ‘serverless’ oplossen, is inmiddels dan ook een absolute standaard geworden bij onze cloudimplementaties. Zo gebruiken we bijvoorbeeld AWS Lambda-scripts om op basis van een gescheduled event back-ups van de Amazon EC2 IaaS-dienst te maken en om virtuele EC2-servers buiten kantooruren af te sluiten om kosten te besparen.

Een andere recente case is de integratie tussen een HR-systeem en een cloud-identityplatform. Het doel is om HR-data gesynchroniseerd te krijgen naar het cloud-identityplatform. Dit syncproces loopt enkele keren per dag en leent zich daarom prima om serverless met pythonscripts op te lossen. De integratie kost de organisatie nauwelijks geld omdat het runproces qua resources zeer efficiënt is.

Serverless is absoluut interessant, maar kent ook enkele nadelen

Een laatste voorbeeld is een organisatie waarbij grote delen van de webapplicatie wordt vervangen door AWS Lambda-functies. Technisch is het mogelijk de gehele applicatie zonder servers te laten draaien. Dat is ook voor deze applicatie de visie waar naartoe wordt gewerkt.

Niet alleen rozengeur en maneschijn

Het toepassen van serverless in het applicatielandschap is absoluut interessant, maar kent ook enkele nadelen.

Het vereist nieuwe competenties binnen IT en een andere manier van applicatiearchitectuur. Bestaande applicaties moeten effectief omgebouwd worden om ze geschikt te maken voor serverless. Daarnaast is lock-in een belangrijk punt. Hoe meer gebruik wordt gemaakt van de bouwstenen van de cloudprovider, hoe meer lock-in op het platform. Datzelfde geldt voor het securityvraagstuk. Door het runnen van code direct op het cloudplatform wordt een belangrijk deel van de securitymaatregelen bij de cloudprovider gelegd.

Tot slot kan performance, monitoring en debugging beperkter zijn. Serverlessapplicaties reageren anders en hebben een vorm van latency tussen functies. Qua monitoring en debugging zitten we met serverless ver boven het OS-niveau en hebben we daarmee ook geen toegang tot OS-leveltooling en metrics. Ook hier zijn we aangewezen op wat de cloudprovider ons out of the box te bieden heeft.

Toch een serverloze toekomst

Ondanks de nadelen leveren de voordelen veel meer op in termen van efficiency, wendbaarheid en innovatiesnelheid. Serverless is eigenlijk geëvolueerd tot de eerste vraag bij het cloudnative migreren of bouwen van nieuwe cloudapplicaties. Vaak wordt serverless ingezet in een deel van de totale applicatieoplossing, aangevuld met diensten als API Gateways en PaaS-diensten als databases, storage maar ook Docker en eventueel IaaS.

De serverlesstrend en -adoptie ontwikkelen zich naar verwachting de komende jaren snel. Op zichzelf niet zo vreemd, want serverless is eigenlijk een veel betere en logischere manier om cloudresources te consumeren. Trends als cloudnative, DevOps, data-analytics, machine-learning en IoT zullen voor serverless belangrijke drivers zijn en tot nieuwe innovatieve mogelijkheden en hoge efficiency leiden.

Jeroen Jacobs (jeroen@oblcc.com) is cloudconsultant & projectleider en Edwin van Nuil (edwin@oblcc.com) is managing director bij Oblivion Cloud Control, dat zich richt op cloudvraagstukken.