Phenquestions
Fysieke computers
We zijn ver verwijderd van de enorme servers van het dotcom-tijdperk. In die tijd was de serverinfrastructuur grotendeels on-premise. Een bedrijf draaide zijn oplossingen op een fysieke server. Mensen gebruikten hele aparte servers voor verschillende doeleinden (back-ups, mailserver, webserver, enz.). Toen een bepaalde server niet kon voldoen aan de groeiende behoeften van het bedrijf, werd deze vervangen door een nieuwere, snellere server. Je schaalt op door betere hardware te krijgen. Je hebt verticaal geschaald.
Hypervisors
Toen kwam het tijdperk van hypervisors. Het kwam in een stroomversnelling met de opkomst van VMWare en mensen realiseerden zich dat ze één rack kunnen krijgen om ze allemaal te regeren. Eén rack om alle verschillende use-cases uit te voeren en elk van hen hun eigen afzonderlijke virtuele machine in te richten. Dit leidde ook tot cloudcomputing en bedrijven stopten direct met investeren in serverhardware en kozen ervoor om virtuele servers te 'huren'.
Enorme en dure datacenters werden beheerd door cloudproviders over de hele wereld. Bedrijven profiteerden hiervan door hun diensten wereldwijd aan te bieden, met behulp van een zo breed mogelijk scala aan datacenters. Dit werd voornamelijk gedaan om latenties te verminderen, de klantervaring te verbeteren en om een grotere markt te bereiken.
Dit zette softwareauteurs ook aan het denken in termen van gedistribueerde systemen. Ze schreven software om niet op een enkele gigantische computer te draaien, maar op veel middelmatige computers op een consistente en betrouwbare manier. Je hebt horizontaal geschaald.
U kunt nog steeds verticaal schalen. Door virtualisatie werd het inrichten van meer resources zelfs eenvoudiger. Je hebt de VM uitgeschakeld, de resources aangepast en je cloudprovider een beetje extra betaald. Fluitje van een cent.
De onderliggende fysieke servers zijn niet verdwenen. Cloudproviders zijn nu verantwoordelijk voor het beheer van de complexiteit van netwerkinterfaces, OS-compatibiliteit en andere angstaanjagende pathologieën.
containers
Toen kwamen de containers. Containers waren deze verbazingwekkende lichtgewicht abstractie. Een virtuele omgeving met een besturingssysteem waarmee software als een enkele eenheid kon worden verpakt en ingezet. Net als virtuele machines draaide elke container zich niet bewust van andere containers, maar ze deelden dezelfde kernel van het besturingssysteem.
Hierdoor konden mensen software implementeren op servers (fysiek of virtueel, het maakt niet uit) op een nog hoger abstractieniveau. Je gaf niet om het productiebesturingssysteem. Zolang het uw containerisatietechnologie ondersteunt, zou het uw software uitvoeren. Ook zijn containers gemakkelijker te draaien, waardoor de services schaalbaarder dan ooit zijn.
Dit heeft de flexibiliteit van gedistribueerde systemen verder vergroot. Met technologieën zoals Kubernetes kun je legio containers laten draaien met een complexe reeks services. Gedistribueerde systemen bieden veel voordelen hoge beschikbaarheid, robuustheid en de mogelijkheid om zichzelf te herstellen van een knooppuntstoring.
Tegelijkertijd zijn ze, omdat ze zo complex zijn, ook moeilijker te ontwerpen, implementeren, onderhouden, bewaken en debuggen. Dit druist in tegen de oorspronkelijke trend om de complexiteit uit uw software te abstraheren en die verantwoordelijkheid te delegeren aan uw cloudprovider. Dit is waar serverloze architectuur om de hoek komt kijken.
Serverloos of Function-as-a-Service (FaaS)
Het idee van serverloos heeft vooral grip gekregen dankzij AWS Lambda, en hier zal ik dat als model gebruiken om over serverloos te praten. De principes waarop FaaS is gebaseerd zijn:
- Je betaalt voor wat je gebruikt
- U hoeft zich geen zorgen te maken over schalen
- U concentreert zich op uw code, laat het infrastructuurbeheer over aan AWS A
Wanneer niemand toegang heeft tot uw services, zijn de services niet actief. Dit was niet het geval in de traditionele hostingoplossingen waar je betaalt voor een VPS die altijd up-and-running is, zelfs als deze inactief was en niets nuttigs deed dan luisteren naar een nieuw verzoek.
In serverloze architectuur is uw service niet actief tenzij iemand deze daadwerkelijk wil gebruiken. Wanneer een verzoek binnenkomt, wordt er direct een service gemaakt om het af te handelen.
Hoe werkt het?
Uw functie (bijvoorbeeld een Python-, Go- of Java-programma) staat als een bestand op AWS Lambda. Met deze functie associeer je bepaalde triggergebeurtenissen, zoals een API-gateway, of een nieuw object dat in je S3-bucket komt. En bepaalde bronnen zoals een database of een ander objectarchief of een EC2-instantie.
Als reactie op een van de bijbehorende triggergebeurtenissen, maakt AWS Lambda een container met uw functie erin. De functie wordt uitgevoerd en geeft een antwoord. Als er bijvoorbeeld een nieuwe afbeelding in uw S3-bucket komt, kan AWS Lambda een machine learning-code bevatten, die deze afbeelding zou analyseren en de uitvoer naar een DynamoDB (een van de datastore-services van AWS) zou schrijven.
U betaalt niet voor een hele server, maar alleen voor de hoeveelheid geheugen die u aan uw functie hebt toegewezen, het aantal verzoeken dat u krijgt en hoe lang uw functie draait.
Bovendien hoeft u zich geen zorgen te maken over het schalen van containers als reactie op een zware inkomende werklast. Als er veel triggergebeurtenissen tegelijkertijd plaatsvinden, zorgt AWS voor het opstarten van nieuwe containers en het plannen van workloads daartussen en alle andere complexiteiten.
Geen complete oplossing
Toen virtuele machines kwamen, hielden de fysieke servers niet op te bestaan. Toen containers arriveerden, gebruikten we nog steeds VM's. De FaaS is een abstractie van een hoger niveau en past heel goed bij het moderne ontwerp van RESTful API's, stateless services en lichtgewicht talen zoals Node.js of Python.
Het draait echter nog steeds op een fysieke server (beheerd door bijvoorbeeld AWS), het luistert nog steeds naar inkomende verzoeken (daar betaal je gewoon niet rechtstreeks voor) en je moet nog steeds gegevens op een permanente manier opslaan, daarom heeft het integraties voor S3, EC2 en andere services. Toch is het een nuttige abstractie.
