Eén van de belangrijkste opgemerkte trends op Devoxx 2017 is het gebeuren omtrent ‘Serverless computing’. Heel wat sessies gingen dan ook over deze evolutie.
There will always be servers.
Ondanks de betekenis van het woord zelf, wil dit niet zeggen dat er geen servers meer zijn. Natuurlijk zijn er nog servers, want zonder servers hebben we geen applicaties.
De doorbraak van deze Serverless architectuur is vooral te danken aan de opkomst van de vele mobile en IoT applicaties. De groei lijkt dus niet meer te stuiten. Een Serverless architectuur is een voortzetting van de microservices architectuur. Hierbij worden microservices nog verder opgesplitst in kleinere functionele 'nano services'. Ieder van deze ‘functies’ kunnen op zijn geheel iets betekenen (unit of work) voor het business process en staat op zichzelf.
De impact van het gebruik van Serverless architectuur is vooral te zien bij development en deployment. Indirect heeft dit ook invloed op de operationele kost.
- Development: Developers focussen zich op een kleine stuk onafhankelijk functionaliteit (code) die men in de cloud kan deployen. Men denkt dus enkel in termen van services of functies die met elkaar communiceren.
- Deployment: Net zoals microservices worden deze Functions gedeployed in de cloud als onafhankelijke units of deployment. Scaling, resources allocation, etc. is voor de rekening van de Serverless framework providers.
- Kosten: Men betaalt wat er gebruikt wordt. Externe events triggeren de functies op de Serverless frameworks. Resources worden gealloceerd, zodat die Functions uitgevoerd kunnen worden en daarna worden de resources terug vrijgegeven. Er zijn geen resources meer die niks staan te doen, wat de daaraan verbonden operationele kosten zullen doen verminderen.
In de cloud worden ‘PaaS’ (Platform As A Service) en ‘BaaS’ (Backend As A Service) initieel gezien als Serverless architectuur frameworks. Deze laten de klanten toe om applicaties in de cloud o.a. te deployen, starten en stoppen, zonder daarbij de complexiteit van een ops architectuur te moeten opzetten. Minimale configuratie is voldoende om up-and-running te zijn.
Met ‘FaaS’ gaan we nog een stap verder. Waar we bij een PaaS architectuur nog zelf instonden voor de configuratie ivm resource-scaling is het bij FaaS zo dat de scaling automatisch en dynamisch gebeurt. De verantwoordelijkheid van de scaling is de verantwoordelijkheid van de provider. Wanneer er bijvoorbeeld meer gebruik gemaakt wordt van bepaalde Functions, dan zal daarvoor een hogere kost voor aangerekend worden. Dus geen nutteloze operationele kosten meer voor resources die niks staan te doen. Deze benadering van omgaan met resources stuurt ons ook verder naar een 'Greener' computing economie.
Typical servers in business and enterprise data centers deliver between five and 15 percent of their maximum computing output on average over the course of the year.
Naast de besproken voordelen zijn er natuurlijk ook mogelijke nadelen aan verbonden.
- Een Serverless architecture is niet efficiënt voor langdurende operaties, waarbij je wel een dedicated server nodig voor zal blijven hebben.
- Vendor lock-in, omdat er op dit ogenblik geen uniformiteit is voor FaaS aanbieders en ben je dus afhankelijk van de keuze van de aanbieder. Veranderen van de een naar de andere FaaS is dus niet evident.
- Een Serverless architectuur introduceert een extra overhead voor wat betreft extra function/microservices calls.
- De initiële call (geactiveerd door de events) is bij Serverless architectuur niet performant. De functie die moet uitgevoerd worden, moet eerst gevonden worden, waarna de execution environment opgestart wordt om deze functie effectief ook zijn werk te laten uitvoeren. Dus ook hier zit je met overhead.
Op dit ogenblik zijn de bekendste Serverless Architecture Framework aanbieders de volgende.
- Amazon AWS Lambda
- Google Cloud Functions
- Red Hat OpenShift EcoSystem met Iron.io integratie
- Microsoft Azure Web Jobs
- IBM's Bluemix Cloud Functions (gebaseerd of Apache OpenWhisk)