Hoewel serverloze technologieën de afgelopen jaren snel aan populariteit hebben gewonnen, zijn er nog steeds veel misvattingen en angsten mee verbonden. Leveranciersafhankelijkheid, tooling, kostenbeheer, koude start, monitoring en ontwikkelingslevenscyclus zijn allemaal hot topics als het gaat om serverloze technologieën. In dit artikel zullen we enkele van de genoemde onderwerpen onderzoeken, en tips en links naar nuttige informatiebronnen delen om beginners te helpen krachtige, flexibele en kosteneffectieve serverloze applicaties te maken.
Misvattingen over serverloze technologieën
Veel mensen denken dat serverloze en serverloze verwerking (, FaaS) zijn bijna hetzelfde. Dit betekent dat het verschil niet te groot is en het de moeite waard is om een nieuwigheid te introduceren. Hoewel AWS Lambda een van de sterren was van de serverloze hoogtijdagen en een van de meest populaire elementen van de serverloze architectuur, is deze architectuur echter veel meer dan FaaS.
Het basisprincipe achter serverloze technologieën is dat u zich geen zorgen hoeft te maken over het beheren en schalen van uw infrastructuur, u betaalt alleen voor wat u gebruikt. Veel services voldoen aan deze criteria: AWS DynamoDB, S3, SNS of SQS, Graphcool, Auth0, Now, Netlify, Firebase en vele andere. Over het algemeen betekent serverloos dat u de volledige kracht van cloud computing gebruikt zonder de infrastructuur te hoeven beheren en te optimaliseren voor schaalbaarheid. Het betekent ook dat beveiliging op infrastructuurniveau niet langer uw zorg is, wat een enorm voordeel is gezien de moeilijkheid en complexiteit van het voldoen aan beveiligingsnormen. Ten slotte hoeft u de infrastructuur die u ter beschikking wordt gesteld niet te kopen.
Serverless kan worden beschouwd als een “state of mind”: een bepaalde mentaliteit bij het ontwerpen van oplossingen. Vermijd benaderingen die onderhoud van enige infrastructuur vereisen. Met een serverloze aanpak besteden we tijd aan het oplossen van taken die rechtstreeks van invloed zijn op het project en voordelen opleveren voor onze gebruikers: we creëren duurzame bedrijfslogica, ontwikkelen gebruikersinterfaces en ontwikkelen adaptieve en betrouwbare API's.
Als het bijvoorbeeld mogelijk is om het beheer en onderhoud van een zoekplatform met vrije tekst te omzeilen, dan zullen we dat doen. Deze benadering van het bouwen van applicaties kan de time-to-market aanzienlijk versnellen, omdat u niet langer hoeft na te denken over het beheer van complexe infrastructuur. Elimineer de verantwoordelijkheden en kosten van infrastructuurbeheer en concentreer u op het bouwen van de applicaties en services die uw klanten nodig hebben. Patrick Debois noemde deze aanpak , wordt de term overgenomen in de serverloze gemeenschap. Functies moeten worden gezien als een koppeling naar services als inzetbare modules (in plaats van een volledige bibliotheek of webtoepassing in te zetten). Dit biedt ongelooflijke granulariteit voor het beheer van de implementatie en wijzigingen in de applicatie. Als u functies op deze manier niet kunt implementeren, kan dit erop wijzen dat de functies te veel taken uitvoeren en opnieuw moeten worden ingericht.
Sommigen zijn in de war door de afhankelijkheid van de leverancier bij het ontwikkelen van cloudapplicaties. Hetzelfde geldt voor serverloze technologieën, en dit is nauwelijks een misvatting. Het is onze ervaring dat het bouwen van serverloze applicaties op AWS, in combinatie met het vermogen van AWS Lambda om andere AWS-services samen te bundelen, deel uitmaakt van de kracht van serverloze architecturen. Dit is een goed voorbeeld van synergie, waarbij het resultaat van de combinatie meer is dan alleen de som van de termen. Proberen leveranciersafhankelijkheid te vermijden kan nog meer problemen opleveren. Wanneer u met containers werkt, is het eenvoudiger om uw eigen abstractielaag tussen cloudproviders te beheren. Maar als het gaat om serverloze oplossingen, loont de inspanning niet, vooral als vanaf het begin rekening wordt gehouden met kosteneffectiviteit. Zorg ervoor dat u erachter komt hoe leveranciers diensten verlenen. Sommige gespecialiseerde services zijn afhankelijk van integratiepunten met andere leveranciers en bieden mogelijk kant-en-klare plug-and-play-connectiviteit. Het is gemakkelijker om een Lambda-aanroep te doen vanaf een gateway-API-eindpunt dan om het verzoek via een proxy naar een container of EC2-instantie te sturen. Graphcool biedt eenvoudige configuratie met Auth0, wat eenvoudiger is dan het gebruik van authenticatietools van derden.
Het kiezen van de juiste leverancier voor uw serverloze applicatie is een architectonische beslissing. Wanneer u een toepassing maakt, verwacht u niet dat u op een dag terugkeert naar het beheren van servers. Het kiezen van een cloudleverancier is niet anders dan kiezen voor het gebruik van containers of een database, of zelfs een programmeertaal.
Overwegen:
- Welke diensten heb je nodig en waarom.
- Welke diensten cloudproviders bieden en hoe u deze kunt combineren met de door u gekozen FaaS-oplossing.
- Welke programmeertalen worden ondersteund (met dynamisch of statisch typen, gecompileerd of geïnterpreteerd, wat zijn de benchmarks, wat zijn de prestaties bij koude start, wat is het open source ecosysteem, enz.).
- Wat zijn uw beveiligingsvereisten (SLA, 2FA, OAuth, HTTPS, SSL, enz.).
- Hoe u uw CI/CD- en softwareontwikkelingscycli beheert.
- Van welke infrastructuur-als-code-oplossingen kunt u profiteren.
Als u een bestaande applicatie uitbreidt en stapsgewijs serverloze functionaliteit toevoegt, kan dit de beschikbare mogelijkheden enigszins beperken. Bijna alle serverloze technologieën bieden echter een soort API (via REST of berichtenwachtrijen) waarmee u onafhankelijk van de applicatiekern en met eenvoudige integratie extensies kunt maken. Zoek naar services met duidelijke API's, goede documentatie en een sterke community, en je kunt niet fout gaan. Gemak van integratie kan vaak een belangrijke maatstaf zijn en is waarschijnlijk een van de belangrijkste redenen waarom AWS zo succesvol is sinds de release van Lambda in 2015.
Wanneer serverloos goed is
Serverloze technologieën kunnen bijna overal worden toegepast. Hun voordelen zijn echter niet beperkt tot slechts één manier van aanbrengen. De toetredingsdrempel voor cloud computing is tegenwoordig zo laag dankzij serverloze technologieën. Als ontwikkelaars een idee hebben, maar niet weten hoe ze de cloudinfrastructuur moeten beheren en de kosten moeten optimaliseren, hoeven ze niet op zoek te gaan naar een of andere ingenieur om het uit te voeren. Als een startup een platform wil bouwen, maar vreest dat de kosten uit de hand lopen, kunnen ze gemakkelijk overstappen op serverloze oplossingen.
Vanwege kostenbesparingen en eenvoudige schaalbaarheid zijn serverloze oplossingen even toepasbaar voor zowel interne als externe systemen, tot een webapplicatie met een miljoenenpubliek. Rekeningen worden gemeten in plaats van in euro's, maar in centen. De simpelste instance van AWS EC2 (t1.micro) voor een maand huren kost €15,-, ook als je er niets mee doet (wie vergeet hem nou niet uit te zetten?!). Ter vergelijking: om dit uitgavenniveau in dezelfde periode te bereiken, zou u ongeveer 512 miljoen keer een Lambda van 1 MB gedurende 3 seconde moeten laten draaien. En maakt u geen gebruik van deze functie, dan betaalt u ook niets.
Omdat serverloos voornamelijk gebeurtenisgestuurd is, is het vrij eenvoudig om een serverloze infrastructuur toe te voegen aan oudere systemen. Met AWS S3, Lambda en Kinesis kunt u bijvoorbeeld een analyseservice maken voor een oud retailsysteem dat gegevens kan ontvangen via een API.
De meeste serverloze platforms ondersteunen meerdere talen. Meestal is dit Python, JavaScript, C#, Java en Go. Meestal zijn er geen beperkingen op het gebruik van bibliotheken in alle talen, dus u kunt uw favoriete open source-bibliotheken gebruiken. Het is echter aan te raden om geen misbruik te maken van afhankelijkheden zodat uw functies optimaal presteren en de voordelen van de enorme schaalbaarheid van uw serverloze applicaties niet teniet doen. Hoe meer pakketten er in de container geladen moeten worden, hoe langer de koude start zal duren.
Bij een koude start moet u eerst de container, runtime en fouthandler initialiseren voordat u ze gebruikt. Hierdoor kan de vertraging bij het uitvoeren van functies oplopen tot 3 seconden, en dit is niet de beste optie voor ongeduldige gebruikers. Koude starts gebeuren echter bij de eerste oproep na een paar minuten inactiviteit. Velen beschouwen dit als een kleine ergernis die kan worden omzeild door de functie regelmatig te pingen om hem inactief te houden. Of ze negeren dit aspect helemaal.
Hoewel AWS is uitgebrachtSQL-databases zijn echter niet ideaal voor deze toepassing, omdat ze afhankelijk zijn van verbindingen om transacties uit te voeren, wat snel een knelpunt kan worden met druk verkeer op AWS Lambda. Ja, de ontwikkelaars zijn voortdurend bezig met het verbeteren van Serverless Aurora, en je zou ermee moeten experimenteren, maar tegenwoordig houden NoSQL-oplossingen ervan. Het lijdt echter geen twijfel dat deze situatie zeer binnenkort zal veranderen.
De toolkit legt ook veel beperkingen op, vooral op het gebied van lokaal testen. Hoewel er oplossingen zijn zoals Docker-Lambda, DynamoDB Local en LocalStack, vereisen ze hard werken en een aanzienlijke hoeveelheid configuratie. Al deze projecten worden echter actief ontwikkeld, dus het is slechts een kwestie van tijd voordat de toolkit het niveau bereikt dat we nodig hebben.
De impact van serverloze technologieën op de ontwikkelingscyclus
Omdat uw infrastructuur slechts een configuratie is, kunt u code definiëren en implementeren met behulp van scripts, zoals shellscripts. Of u kunt een beroep doen op configuratie-als-codeklasse-oplossingen zoals . Hoewel deze service niet voor alle gebieden configuratie biedt, kunt u wel specifieke bronnen definiëren om als Lambda-functies te gebruiken. Dat wil zeggen, waar CloudFormation u in de steek laat, kunt u uw eigen bron (Lambda-functie) schrijven die deze kloof zal dichten. Op deze manier kunt u alles doen, zelfs afhankelijkheden configureren buiten uw AWS-omgeving.
Omdat het allemaal slechts configuratie is, kunt u uw implementatiescripts aanpassen voor specifieke omgevingen, regio's en gebruikers, vooral als u infrastructuur-als-code-oplossingen zoals CloudFormation gebruikt. U kunt bijvoorbeeld voor elke branch in de repository een kopie van de infrastructuur inzetten, zodat u deze tijdens de ontwikkeling volledig geïsoleerd kunt testen. Dit versnelt de feedback voor ontwikkelaars drastisch wanneer ze willen begrijpen of hun code adequaat werkt in een live omgeving. Managers hoeven zich geen zorgen te maken over de kosten van het implementeren van meerdere omgevingen, aangezien ze alleen betalen voor daadwerkelijk gebruik.
DevOps hebben minder zorgen omdat ze er alleen voor hoeven te zorgen dat ontwikkelaars de juiste configuratie hebben. U hoeft geen instanties, balancers of beveiligingsgroepen meer 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 cloudresource-optimalisatie.
Er zijn zeer krachtige monitoring- en visualisatietools zoals Epsagon, Thundra, Dashbird en IOPipe. Ze stellen u in staat om de huidige status van uw serverloze applicaties te bewaken, logging en tracering te bieden, prestatiestatistieken en architectuurknelpunten vast te leggen, kostenanalyses en prognoses uit te voeren, en meer. Ze geven DevOps-engineers, -ontwikkelaars en -architecten niet alleen een uitgebreid beeld van de applicatieprestaties, maar stellen managers ook in staat om de situatie in realtime te volgen, met resourcekosten per seconde en kostenprognoses. Met een beheerde infrastructuur is dat veel moeilijker te organiseren.
Het ontwerpen van serverloze applicaties is veel eenvoudiger omdat u geen webservers hoeft te implementeren, virtuele machines of containers, patchservers, besturingssystemen, internetgateways, enz. hoeft te beheren. Door al deze verantwoordelijkheden weg te nemen, kan een serverloze architectuur zich concentreren op de kern: de oplossing zakelijke en klantbehoeften.
Hoewel de toolkit beter kan (het wordt elke dag beter), kunnen ontwikkelaars zich richten op het implementeren van de bedrijfslogica en het zo goed mogelijk verdelen van de complexiteit van de applicatie over verschillende services binnen de architectuur. Serverloos applicatiebeheer is gebaseerd op gebeurtenissen en geabstraheerd door de cloudprovider (bijv. SQS, S3-gebeurtenissen of DynamoDB-streams). Daarom hoeven ontwikkelaars alleen bedrijfslogica te schrijven om op bepaalde gebeurtenissen te reageren, en hoeven ze zich geen zorgen te maken over hoe ze databases en berichtenwachtrijen het beste kunnen implementeren, of hoe ze optimaal kunnen werken met gegevens in specifieke hardwareopslag.
Code kan lokaal worden uitgevoerd en gedebugd, zoals bij elk ontwikkelingsproces. Het testen van eenheden blijft hetzelfde. De mogelijkheid om een volledige applicatie-infrastructuur te implementeren met een aangepaste stackconfiguratie stelt ontwikkelaars in staat om snel belangrijke feedback te krijgen zonder na te denken over de testkosten of de impact op dure beheerde omgevingen.
Tools en technieken voor het bouwen van serverloze applicaties
Er is geen specifieke manier om serverloze applicaties te bouwen. Evenals een reeks services voor deze taak. AWS is tegenwoordig de leider onder krachtige serverloze oplossingen, maar kijk ook eens naar , и . Als u AWS gebruikt, is de aanbevolen aanpak voor het verzamelen van applicaties (SAM), vooral bij gebruik van C#, omdat Visual Studio geweldige tooling heeft. De SAM CLI kan alles wat Visual Studio kan, dus je verliest niets als je overschakelt naar een andere IDE of teksteditor. Natuurlijk werkt SAM ook met andere talen.
Als u in andere talen schrijft, is het Serverless Framework een uitstekende open source-tool waarmee u alles kunt configureren met zeer krachtige YAML-configuratiebestanden. 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 heleboel plug-ins heeft gemaakt voor elke behoefte.
Voor lokaal testen zijn de open source tools Docker-Lambda, Serverless Local, DynamoDB Local en LocalStack zeer geschikt. Serverloze technologieën bevinden zich nog in de beginfase van ontwikkeling, net als de tools ervoor, dus bij het opzetten van complexe testscenario's zult u hard moeten werken. Het simpelweg implementeren van de stack in een omgeving en daar testen is echter ongelooflijk goedkoop. En u hoeft geen exacte lokale kopie van cloudomgevingen te maken.
Gebruik AWS Lambda Layers om de grootte van geïmplementeerde pakketten te verkleinen en downloads 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 AWS Lambda-prestaties. AWS Lambda heeft onlangs de Runtime API geïntroduceerd, waarmee u uw gewenste taal en runtime-omgeving kunt specificeren, dus experimenteer.
Houd pakketgroottes klein voor implementatie. Hoe kleiner ze zijn, hoe sneller ze laden. Vermijd het gebruik van grote bibliotheken, vooral als u er een aantal functies van gebruikt. Als je in JavaScript programmeert, gebruik dan een build-tool zoals Webpack om je build te optimaliseren en alleen op te nemen wat je echt nodig hebt. .NET Core 3.0 heeft QuickJit en Tiered Compilation die de prestaties verbeteren en veel helpen bij koude starts.
De afhankelijkheid van serverloze functies van gebeurtenissen kan het in het begin moeilijk maken om de bedrijfslogica te coördineren. In dit opzicht kunnen berichtenwachtrijen en statusmachines ongelooflijk nuttig zijn. Lambda-functies kunnen elkaar aanroepen, maar doe dit alleen als u geen reactie verwacht ("vuur en vergeet") - u wilt niet worden gefactureerd voor het wachten tot een andere functie is voltooid. Berichtenwachtrijen zijn handig voor het isoleren van delen van de bedrijfslogica, het beheren van applicatieknelpunten en het verwerken van transacties (met behulp van FIFO-wachtrijen). AWS Lambda-functies kunnen worden toegewezen aan SQS-wachtrijen als vastgelopen berichtenwachtrijen die mislukte berichten bijhouden voor latere analyse. AWS Step Functions (state machines) zijn erg handig voor het beheren van complexe processen die het koppelen van functies vereisen. In plaats van dat een Lambda-functie een andere functie aanroept, kunnen stapfuncties toestandsovergangen coördineren, gegevens tussen functies doorgeven en de globale toestand van functies beheren. Hiermee kunt u voorwaarden voor opnieuw proberen definiëren, of wat u moet doen als een bepaalde fout optreedt - een zeer krachtig hulpmiddel in bepaalde omstandigheden.
Conclusie
De afgelopen jaren hebben serverloze technologieën zich in een ongekend tempo ontwikkeld. Er zijn bepaalde misvattingen verbonden aan deze paradigmaverschuiving. Door de infrastructuur te abstraheren en het beheer te schalen, bieden serverloze oplossingen aanzienlijke voordelen, van vereenvoudigde ontwikkeling en DevOps-processen tot enorme verlagingen van de operationele kosten.
Hoewel de serverloze aanpak niet zonder nadelen is, zijn er robuuste ontwerppatronen die kunnen worden gebruikt om robuuste serverloze applicaties te bouwen of serverloze elementen in bestaande architecturen te integreren.
Bron: www.habr.com