Hoewel serverless technologieƫn de afgelopen jaren snel aan populariteit hebben gewonnen, zijn er nog steeds veel misverstanden en zorgen. Vendor lock-in, tooling, kostenbeheer, koude starts, monitoring en de ontwikkelingscyclus - al deze onderwerpen worden actief besproken wanneer het gaat om serverless technologieƫn. In dit artikel zullen we enkele van deze onderwerpen behandelen en tips en links naar nuttige informatie delen, zodat nieuwkomers krachtige, flexibele en kosteneffectieve serverless applicaties kunnen bouwen.
Misverstanden over serverless technologieƫn
Veel mensen denken dat serverless en Function-as-a-Service (, FaaS) vrijwel hetzelfde zijn. Dit betekent dat het verschil niet groot is en dat het de moeite waard is om de noviteit te implementeren. Hoewel AWS Lambda een van de 'sterren' was in de bloeiperiode van serverless technologieƫn en een van de meest populaire elementen van serverless architectuur is, stelt deze architectuur meer voor dan alleen FaaS.
Het kernprincipe van serverless technologieƫn is dat je je geen zorgen hoeft te maken over het beheren en opschalen van de infrastructuur; je betaalt alleen voor wat je gebruikt. Veel diensten vallen onder deze criteria - AWS DynamoDB, S3, SNS of SQS, Graphcool, Auth0, Now, Netlify, Firebase en vele anderen. Over het algemeen houdt serverless in dat je alle mogelijkheden van cloud computing kunt benutten zonder de noodzaak om de infrastructuur te beheren en te optimaliseren voor schaalbaarheid. Dit betekent ook dat de veiligheid op het niveau van infrastructuur niet langer jouw probleem is, wat een enorm voordeel is, gezien de moeilijkheidsgraad en complexiteit van het naleven van veiligheidsnormen. Ten slotte hoef je de aangeboden infrastructuur niet aan te schaffen.
Serverless kan worden gezien als een 'gemoedstoestand': een bepaalde mentaliteit bij het ontwerpen van oplossingen. Vermijd benaderingen die onderhoud vereisen van enige infrastructuur. Bij een serverless benadering besteden we tijd aan het oplossen van taken die direct invloed hebben op het project en voordelen opleveren voor onze gebruikers: we creƫren duurzame bedrijfslogica, ontwikkelen gebruikersinterfaces en bouwen flexibele en betrouwbare API's.
Bijvoorbeeld, als het mogelijk is om het beheer en de ondersteuning van een systeem voor vrije tekstzoekopdrachten te vermijden, dan doen we dat ook. Deze benadering van het bouwen van applicaties kan de marktintroductietijd aanzienlijk versnellen, omdat u zich geen zorgen meer hoeft te maken over het beheer van een complexe infrastructuur. Verlaag uw verantwoordelijkheden en kosten voor infrastructuurbeheer en richt u op het ontwikkelen van applicaties en diensten die uw klanten nodig hebben. Patrick Debois noemde deze aanpak , deze term wordt geaccepteerd in de serverless community. Functies moeten worden beschouwd als een schakel tussen diensten in de vorm van uitrolbare modules (in plaats van een hele bibliotheek of webapplicatie uit te rollen). Dit biedt een ongelooflijke granulariteit in het beheer van implementatie en wijzigingen in de applicatie. Als u functies niet op deze manier kunt implementeren, kan dit erop wijzen dat de functies te veel taken uitvoeren en opnieuw moeten worden gefabriceerd.
Sommigen zijn bezorgd over de afhankelijkheid van leveranciers bij de ontwikkeling van cloudapplicaties. hetzelfde geldt voor serverless technologieƫn, en het is waarschijnlijk geen misverstand. Uit onze ervaring blijkt dat het creƫren van serverless applicaties op AWS, in combinatie met de mogelijkheid van AWS Lambda om andere AWS-diensten te integreren, gedeeltelijk de voordelen van serverless architecturen vormt. Dit is een goed voorbeeld van synergie, waarbij de uitkomst van de samenwerking meer is dan alleen de som der delen. Door te proberen afhankelijkheid van de leverancier te vermijden, kunt u tegen nog grotere problemen aanlopen. Bij het werken met containers is het eenvoudiger om je eigen abstractieniveau tussen cloudproviders te beheren. Maar als het gaat om serverless oplossingen, zullen de inspanningen niet opwegen tegen de kosten, vooral als u vanaf het begin rekening houdt met de kosten-effectiviteit. Zorg ervoor dat u begrijpt hoe leveranciers de diensten leveren. Sommige gespecialiseerde diensten zijn afhankelijk van integratiepunten met andere leveranciers en bieden mogelijk out-of-the-box een plug-and-play-connectiviteit aan. Het is eenvoudiger om een Lambda-aanroep te doen vanuit een API Gateway-endpoint dan om een verzoek naar een container of EC2-instantie te proxyen. Graphcool biedt eenvoudige configuratie met Auth0, wat eenvoudiger is dan het gebruik van externe authenticatiemiddelen.
Het kiezen van de juiste leverancier voor uw serverless applicatie is een architectonale beslissing. Wanneer u een applicatie ontwikkelt, rekent u er niet op dat u ooit weer servers gaat beheren. Het kiezen van een cloudleverancier is niet anders dan het kiezen om containers, databases of zelfs programmeertalen te gebruiken.
Denk na over:
- Welke diensten heeft u nodig en waarom.
- Welke diensten bieden cloudproviders en hoe kunt u deze combineren met de gekozen FaaS-oplossing.
- Welke programmeertalen worden ondersteund (met dynamische of statische typing, gecompileerd of geĆÆnterpreteerd, welke benchmarks zijn er, wat is de prestaties bij koude start, hoe is de open source-ecosysteem, enz.).
- Wat zijn uw beveiligingseisen (SLA, 2FA, OAuth, HTTPS, SSL, enz.).
- Hoe beheert u uw CI/CD en software ontwikkelingscycli.
- Van welke infrastructure-as-code oplossingen kunt u profiteren.
Als je een bestaande applicatie uitbreidt en geleidelijk serverloze functies toevoegt, kan dit de beschikbare mogelijkheden wat beperkten. Desondanks bieden bijna alle serverloze technologieƫn enige API's (via REST of berichtqueues), die het mogelijk maken om uitbreidingen onafhankelijk van de kern van de applicatie te creƫren en eenvoudig te integreren. Zoek naar services met duidelijke API's, goede documentatie en een sterke gemeenschap, en je zult niet verkeerd zitten. Eenvoud van integratie kan vaak een cruciale metric zijn, en waarschijnlijk is dit een van de belangrijkste redenen voor het succes van AWS sinds de release van Lambda in 2015.
Wanneer is serverloos nuttig
Serverloze technologieƫn kunnen vrijwel overal worden toegepast. Echter, hun voordelen zijn niet beperkt tot alleen de manieren van toepassing. De instapdrempel voor cloud computing is vandaag de dag zo laag, juist dankzij serverloze technologieƫn. Als ontwikkelaars een idee hebben, maar niet weten hoe ze met cloudinfrastructuur moeten omgaan en kosten moeten optimaliseren, hoeven ze geen ingenieur te zoeken. Als een startup een platform wil creƫren, maar bang is dat de kosten uit de hand lopen, kan deze eenvoudig gebruikmaken van serverloze oplossingen.
Dankzij kostenbesparingen en de eenvoud van opschaling, zijn serverloze oplossingen even toepasbaar voor interne systemen als voor externe, tot aan een webtoepassing met miljoenen gebruikers. Facturen worden eerder in centen dan in euro's gemeten. De huur van de simpelste AWS EC2-exemplaar (t1.micro) kost ā¬15 per maand, zelfs als je er niets mee doet (wie vergeet er niet eens uit te schakelen?!). Ter vergelijking, om hetzelfde kostenniveau over dezelfde periode te bereiken, moet je een Lambda van 512 MB ongeveer 3 miljoen keer gedurende 1 seconde draaien. En als je deze functie niet gebruikt, betaal je niets.
Aangezien serverloze technologie voornamelijk afhankelijk is van gebeurtenissen, is het relatief eenvoudig om serverloze infrastructuur toe te voegen aan oudere systemen. Bijvoorbeeld, met AWS S3, Lambda en Kinesis kun je een analytische service creƫren voor een oud retail systeem dat data kan ontvangen via API.
De meeste serverloze platforms ondersteunen verschillende talen. Het vaakst zijn dit Python, JavaScript, C#, Java en Go. Gewoonlijk zijn er geen beperkingen op het gebruik van bibliotheken in al deze talen, dus je kunt je favoriete open source-bibliotheken toepassen. Het is echter raadzaam om afhankelijkheden niet te overdrijven, zodat je functies optimaal kunnen functioneren en de voordelen van de enorme schaalbaarheid van je serverloze applicaties niet verloren gaan. Hoe meer pakketten er in de container geladen moeten worden, hoe langer de koude start zal duren.
Een koude start is wanneer de container, de runtime-omgeving en de foutverwerker eerst moeten worden geĆÆnitialiseerd voordat ze kunnen worden gebruikt. Hierdoor kan de vertraging van de uitvoering van functies oplopen tot 3 seconden, wat niet ideaal is voor ongeduldige gebruikers. Koude starts komen echter voor bij de eerste aanroep na enkele minuten inactiviteit van de functie. Veel mensen beschouwen dit dus als een klein ongemak dat kan worden omzeild door regelmatig de functie te pingen om deze inactief te houden. Of ze negeren deze kwestie helemaal.
Hoewel AWS heeft uitgebracht, zijn SQL-databases echter niet ideaal voor dit soort toepassingen, omdat ze bij het uitvoeren van transacties afhankelijk zijn van verbindingen, die snel een knelpunt kunnen worden bij grote verkeersstromen op AWS Lambda. Ja, ontwikkelaars verbeteren Serverless Aurora voortdurend, en het is de moeite waard om ermee te experimenteren, maar vandaag de dag zijn NoSQL-oplossingen zoalsveel geschikter voor serverloze systemen. Zou dit echter ook zeker snel kunnen veranderen.
De toolkit legt ook verschillende beperkingen op, vooral op het gebied van lokale tests. Hoewel er oplossingen zijn zoals Docker-Lambda, DynamoDB Local en LocalStack, vereisen deze echter zorgvuldige configuratie en veel instellingen. Alle deze projecten zijn echter actief aan het ontwikkelen, dus het is slechts een kwestie van tijd voordat de toolkit het noodzakelijke niveau bereikt.
De impact van serverloze technologieƫn op de ontwikkelingscyclus
Aangezien je infrastructuur eenvoudigweg een configuratie is, kun je code definiƫren en implementeren met behulp van scripts, zoals shell-scripts. Of je kunt gebruikmaken van oplossingen zoals configuration-as-code, zoals . Hoewel deze service geen configuratie voor alle gebieden biedt, stelt het je in staat om specifieke middelen te definiƫren voor gebruik als Lambda-functies. Dat wil zeggen, waar CloudFormation je in de steek laat, kun je je eigen bron (Lambda-functie) schrijven die deze kloof sluit. Op deze manier kun je alles doen, zelfs afhankelijkheden configureren buiten je AWS-omgeving.
Aangezien dit allemaal gewoon configuratie is, kun je je implementatiescripts parametriseren voor specifieke omgevingen, regio's en gebruikers, vooral als je infrastructure-as-code oplossingen zoals CloudFormation gebruikt. Bijvoorbeeld, je kunt een kopie van de infrastructuur voor elke branch in de repository implementeren om ze volledig geĆÆsoleerd te testen tijdens de ontwikkeling. Dit versnelt aanzienlijk de feedback die ontwikkelaars ontvangen wanneer ze willen begrijpen of hun code correct functioneert in een live omgeving. Leidinggevenden hoeven zich geen zorgen te maken over de kosten van het implementeren van meerdere omgevingen, aangezien alleen het feitelijke gebruik in rekening wordt gebracht.
DevOps heeft minder zorgen, omdat ze alleen hoeven te zorgen dat de ontwikkelaars de juiste configuratie hebben. Er is geen noodzaak meer om instanties, load balancers of beveiligingsgroepen te beheren. Daarom wordt de term NoOps steeds vaker gebruikt, hoewel het nog steeds belangrijk is om de infrastructuur te kunnen configureren, vooral als het gaat om IAM-configuratie en optimalisatie van cloudbronnen.
Er zijn zeer krachtige monitoring- en visualisatietools zoals Epsagon, Thundra, Dashbird en IOPipe. Ze stellen je in staat om de huidige staat van serverless applicaties te volgen, bieden logs en tracing, registreren prestaties en architectonische knelpunten, analyseren en voorspellen kosten, en nog veel meer. Ze bieden niet alleen DevOps-engineers, ontwikkelaars en architecten een uitgebreid inzicht in de werking van applicaties, maar stellen leidinggevenden ook in staat om de situatie in real-time te volgen, met seconde-tot-seconde kosten voor middelen en kostenvoorspellingen. Het organiseren van dit met beheerde infrastructuur is veel moeilijker.
Het ontwerpen van serverless applicaties is aanzienlijk eenvoudiger, omdat je geen webservers hoeft te implementeren, geen virtuele machines of containers hoeft te beheren, en geen servers, besturingssystemen of internet gateways hoeft te patchen, enzovoort. De abstractie van al deze verantwoordelijkheden stelt serverless architectuur in staat om zich te concentreren op het belangrijkste ā het vervullen van de behoeften van bedrijven en klanten.
Hoewel de toolkit beter kon zijn (het verbetert elke dag), kunnen ontwikkelaars zich concentreren op de implementatie van businesslogica en de beste verdeling van de complexiteit van de applicatie over verschillende services binnen de architectuur. Het beheer van serverless applicaties is gebeurtenisgestuurd en is geabstraheerd door de cloudprovider (bijvoorbeeld SQS, S3-evenementen of DynamoDB-stromen). Daarom hoeven ontwikkelaars alleen de businesslogica te schrijven om op bepaalde gebeurtenissen te reageren en hoeven ze zich geen zorgen te maken over hoe ze databases en berichtenqueues het beste kunnen implementeren, of hoe ze optimaal met gegevens in specifieke hardwareopslag kunnen omgaan.
Code kan lokaal worden uitgevoerd en gedebugd, net als bij elk ontwikkelingsproces. Modulaire testing blijft hetzelfde. De mogelijkheid om een volledige infrastructuur voor een applicatie te implementeren met behulp van een configureerbare stackconfiguratie stelt ontwikkelaars in staat om snel belangrijke feedback te ontvangen, zonder zich zorgen te hoeven maken over de kosten van testen of de impact op dure beheerde omgevingen.
Tools en methoden voor de bouw van serverless applicaties
Er is geen specifieke manier om serverless applicaties te bouwen. Evenmin is er een set van services voor deze taak. Vandaag de dag is AWS de leider onder krachtige serverless oplossingen, maar let ook op , en . Als je AWS gebruikt, kan ik de 'Serverless Application Model' aanraden voor het bouwen van applicaties, (SAM), vooral bij het gebruik van C#, aangezien Visual Studio geweldige tooling biedt. SAM CLI kan alles doen wat Visual Studio ook kan, dus je verliest niets als je overschakelt naar een andere IDE of teksteditor. Natuurlijk werkt SAM ook met andere talen.
Als je in andere talen schrijft, is het Serverless Framework een uitstekende open source-tool die je in staat stelt om alles te configureren met behulp van zeer krachtige configuratie YAML-bestanden. Het Serverless Framework ondersteunt ook verschillende cloudservices, dus we raden het aan aan degenen die op zoek zijn naar een multi-cloudoplossing. Het heeft een enorme community die een hoop plugins heeft gemaakt voor allerlei doeleinden.
Voor lokale tests zijn open source-tools zoals Docker-Lambda, Serverless Local, DynamoDB Local en LocalStack zeer geschikt. Serverless-technologieƫn bevinden zich nog in een vroeg stadium van ontwikkeling, net als de tools ervoor, dus het kan een uitdaging zijn om ze in te stellen voor complexe testscenario's. Het opzetten van een stack in een omgeving en daar te testen is echter ongelooflijk goedkoop. En je hoeft geen exacte lokale kopie van cloudomgevingen te maken.
Gebruik AWS Lambda Layers om de grootte van de uitgerolde pakketten te verkleinen en de laadtijd te versnellen.
Gebruik de juiste programmeertalen voor specifieke taken. Verschillende talen hebben hun eigen voor- en nadelen. Er zijn veel benchmarks, maar JavaScript, Python en C# (.NET Core 2.1+) zijn de leiders op het gebied van prestaties in AWS Lambda. Onlangs is de Runtime API in AWS Lambda geĆÆntroduceerd, waarmee je de gewenste taal en runtime-omgeving kunt specificeren, dus experimenteer.
Houd de pakketgrootte voor uitrol klein. Hoe kleiner ze zijn, hoe sneller ze laden. Vermijd het gebruik van grote bibliotheken, vooral als je er maar een paar functies uit gebruikt. Als je in JavaScript programmeert, gebruik dan bouwtools zoals Webpack om de build te optimaliseren en alleen datgene op te nemen wat je echt nodig hebt. In .NET Core 3.0 zijn er QuickJit en Tiered Compilation, die de prestaties verbeteren en enorm helpen bij koude starts.
De afhankelijkheid van serverloze functies van gebeurtenissen kan in het begin de coƶrdinatie van bedrijfslogica bemoeilijken. In dit verband kunnen berichtenqueues en eindige automaten ongelooflijk nuttig zijn. Lambda-functies kunnen elkaar aanroepen, maar doe dit alleen als je geen antwoord verwacht (āschiet en vergeetā) ā je wilt immers geen rekening krijgen voor het wachten op de voltooiing van een andere functie. Berichtenqueues zijn nuttig voor het isoleren van delen van bedrijfslogica, het beheren van knelpunten in applicaties en het verwerken van transacties (met behulp van FIFO-queues). AWS Lambda-functies kunnen aan SQS-queues worden gekoppeld als
Conclusie
In de afgelopen jaren hebben serverloze technologieƫn zich in een ongekend tempo ontwikkeld. Deze paradigmawisseling wordt met bepaalde misvattingen geassocieerd. Dankzij de abstractie van infrastructuur en het beheer van schaling bieden serverloze oplossingen aanzienlijke voordelen: van het vereenvoudigen van ontwikkelings- en DevOps-processen tot een grote vermindering van operationele kosten.
En hoewel de serverloze benadering niet zonder nadelen is, zijn er betrouwbare methoden en ontwerppatronen waarmee je robuuste serverloze applicaties kunt bouwen of serverloze elementen kunt integreren in bestaande architecturen.
Bron: habr.com
