Studio Terabyte is een fullstack web development studio die oplossingen vindt en bouwt passend bij uw project
Wat is serverless?
Als we aan web apps denken, denken we meestal aan servers die verantwoordelijk zijn voor het ontvangen van HTTP-request, het verwerken van het verzoek, het uitvoeren van wat logica en uiteindelijk het terugsturen van een resultaat. Je bent niet alleen verantwoordelijk voor de logica, maar ook voor de infrastructuur van de server zelf. Dit brengt een aantal problemen met zich mee:
- Er worden kosten in rekening gebracht voor het draaiend houden van de server, zelfs als er geen HTTP-request binnen komen.
- Je bent verantwoordelijk voor uptime en onderhoud van de server en al zijn resources.
- Je bent ook verantwoordelijk voor de juiste beveiligingsupdates op de server.
- Naarmate het gebruik toeneemt, moeten er meer servers bijkomen om het gebruik op te vangen. En als het gebruik daarna weer afneemt, moeten het aantal servers weer naarbenden worden geschaald.
Al dit DevOps-werk leidt af van de belangrijkere zaken zoals van het bouwen en onderhouden van de daadwerkelijke app waarvoor de gebruikers betalen. Zelfs als je een groot bedrijf bent en een DevOps-team hebt, kan het niet snel implementeren en testen van code als ontwikkelaar werk vertragen. Dit is waar serverless kan helpen.
Serverless Computing
Serverless computing (of kortweg serverless), is een architectuur waarbij een cloudprovider (AWS, Azure of Google Cloud) verantwoordelijk is voor het uitvoeren van een stukje code door servers toe te wijzen (dus zijn zij in beheer van alle bovengenoemde taken) op basis van realtime gebruik. Er worden alleen kosten in rekening gebracht voor de tijd dat de code draait. Daarnaast wordt de code doorgaands uitgevoerd in stateless containers die worden geactiveerd aan de hand van verscheidenheid events, waaronder http-request, database events, queuing services, monitoring alerts, bestandsuploads, geplande events (cron-jobs), enz. Er zijn een aantal Serverless aanbieders zoals:
- AWS: AWS Lambda
- Microsoft Azure: Azure Functions
- Google Cloud: Cloud Functions
Ondanks dat serverless de onderliggende infrastructuur overneemt van de ontwikkelaar, zijn servers nog steeds betrokken bij het uitvoeren van de code.
Aangezien de code als afzonderlijke functies wordt uitgevoerd, zijn er een aantal dingen waar we rekening mee moeten houden.
Microservices
De grootste verandering waar we op moeten letten bij de overgang naar een serverloze architectuur, is dat de app uit meerder losstaande functies moet worden opgebouwd. Je bent misschien gewend om je ideeën als één grote app te implementeren, maar in een serverloze architectuur moet je doorgaans een meer op microservices gebaseerde architectuur gebruiken. Dit houdt in dat er een functie, of set aan functies, apart wordt gebruikt om een onderdeel van de app te draaien zoals het inloggen van gebruikers. Deze staat helemaal los van alle andere onderdelen.
Stateless Functions
De functies worden doorgaans uitgevoerd in beveiligde (bijna) stateless containers. Dit betekent dat zodra de code is uitgevoerd, de container wordt afgesloten en een nieuwe wordt aangemaakt voor het volgende event. U kunt er niet vanuit gaan dat de output van de functie er nog steeds is wanneer het volgende event binnenkomt, dus zorg ervoor dat elk event afzonderlijk kan worden afgehandeld. Dit heeft ook betrekking op het volgende onderwerp.
Cold Starts
Aangezien uw functies worden uitgevoerd in een container die op event basis wordt aangemaakt, is er enige vertraging aan verbonden. Dit wordt een cold start genoemd. De container kan enige tijd blijven bestaan nadat de functie is uitgevoerd. Als gedurende deze tijd een ander event binnenkomt, reageert de code veel sneller, dit wordt een warm start genoemd.
De duur van cold starts is afhankelijk van de implementatie van de specifieke cloudprovider en hoe uw code is geschreven.
Afgezien van het optimaliseren van uw code, kunt u eenvoudige trucs gebruiken zoals een aparte geplande functie om uw code elke paar minuten aan te roepen om ervoor te zorgen dat de container niet afsluit en elke start een warm start is. Serverless Stack Framework (SST) heeft kant-en-klare tools voor.
Serverless Stack Framework (SST)
Een van de meest populaire opties voor serverloze apps is AWS. AWS biedt een aantal verschillende diensten en tools die samen kunnen worden gebruikt, zoals DynamoDB, Lambda Functions, S3 en Cognito.
Aangezien deze services op AWS draaien, kan het lastig zijn om ze lokaal te testen en te debuggen. En een groot deel van het bouwen van serverless apps is het kunnen definiëren van de infrastructuur in de vorm van code. Dit houdt in dat we onze infrastructuur programmatisch willen kunnen opbouwen. We willen niet elke keer door de AWS-console klikken om onze infrastructuur te selecteren en in te stellen.
Om dit mogelijk te maken kunnen wij gebruik maken van Serverless Stack Framework (SST).
SST maakt het eenvoudig om serverless applicaties te bouwen door ontwikkelaars in staat te stellen:
- Definieer infrastructuur met AWS CDK
- Test applicaties live met Live Lambda Development
- Breekpunten instellen en fouten opsporen in Visual Studio Code
- Deploy in meerdere environments en regio's
- Gebruik abstracties die speciaal zijn ontworpen voor serverloze apps
- Configureer Lambda-functies met JS en TS (met esbuild), Go, Python, C# en F#
Dit is mogelijke doordat SST gebruik maakt van AWS CDK.
AWS CDK Infrastructure
Met AWS CDK (Cloud Development Kit) kun je TypeScript, JavaScript, Java, .NET en Python gebruiken om AWS-infrastructuur te selecteren en configureren.
Dus een CDK template die een DynamoDB tabel maakt, ziet er bijvoorbeeld zo uit.
Zonder code:
COPY- Resources:
- NotesTable:
- Type: AWS::DynamoDB::Table
- Properties:
- TableName: ${self:custom.tableName}
- AttributeDefinitions:
- - AttributeName: userId
- AttributeType: S
- - AttributeName: noteId
- AttributeType: S
- KeySchema:
- - AttributeName: userId
- KeyType: HASH
- - AttributeName: noteId
- KeyType: RANGE
- BillingMode: PAY_PER_REQUEST
En gedefinieerd als code:
+ const table = new dynamodb.Table(this, "notes", {
+ partitionKey: { name: 'userId', type: dynamodb.AttributeType.STRING },
+ sortKey: { name: 'noteId', type: dynamodb.AttributeType.STRING },
+ billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
+ });
Het eerste dat opvalt, is dat de services (dynamoDB) in JavaScript zijn gedefinieerd als classes. Dat is mooi, want we zijn gewend om in programmeertalen in termen van objecten te denken. En nu kunnen we hetzelfde doen voor onze infrastructuur. Ten tweede kunnen we deze objecten hergebruiken. We kunnen ze combineren en combineren. Dus als je merkt dat je altijd dezelfde set bronnen maakt, kun je daar een nieuwe klas van maken en deze opnieuw gebruiken!
CDK is echt infrastructuur als code.
Live Lambda Development
SST biedt een cloud-native lokale ontwikkelomgeving die onmiddellijke feedback geeft over aanpassingen in Lambda-functiecode. Wijzigingen worden automatisch gedetecteerd, ingebouwd en live opnieuw geladen in minder dan 10 milliseconden. En je kunt breekpunten gebruiken om de functies in je favoriete IDE te debuggen.
Live Lambda Development is een SST-functie waarmee u uw Lambda-functies lokaal kunt debuggen en testen, terwijl het op afstand wordt aangeroepen door bronnen in AWS. Het werkt door verzoeken van uw AWS-account naar uw lokale computer te proxyen.
SST Console
De SST-console is een web dashboard om uw SST-apps te beheren.
De SST-console doet een aantal dingen:
- Real-time logs van de Live Lambda Dev-omgeving
- Bekijk alle geïmplementeerde bronnen binnen de app
- Roep functies aan en speel reeds aangeroepen functies opnieuw af
Hiermee kunt u ook bronnen verkennen die u in uw app gebruikt. U kunt meer lezen in de documentatie.
Conclusie
Dus nu je een idee hebt van wat SST kan doen is de vraag: moet je het gaan gebruiken? Ik geloof dat het een hulpmiddel van onschatbare waarde is als je serverless wilt gaan. Zorg er echter voor dat de app die je aan het bouwen bent, daadwerkelijk profiteert van deze architectuur. Over-engineer de app niet alleen omdat het lijkt alsof iedereen het doet!