Serverless gaat niet over de fysieke afwezigheid van servers. Dit is geen containermoordenaar of een voorbijgaande trend. Dit is een nieuwe benadering voor het bouwen van systemen in de cloud. In het artikel van vandaag zullen we ingaan op de architectuur van serverloze applicaties, laten we eens kijken welke rol de serverloze serviceprovider en open-sourceprojecten spelen. Laten we het tot slot hebben over de problemen bij het gebruik van Serverless.
Ik wil een servergedeelte van een applicatie (of zelfs een online winkel) schrijven. Dit kan een chat, een contentpublicatieservice of een load balancer zijn. In ieder geval zullen er veel kopzorgen zijn: je zult de infrastructuur moeten voorbereiden, de applicatie-afhankelijkheden moeten bepalen en moeten nadenken over het hostbesturingssysteem. Dan moet u kleine componenten bijwerken die de werking van de rest van de monoliet niet beïnvloeden. Laten we het schalen onder belasting niet vergeten.
Wat als we kortstondige containers nemen, waarin de vereiste afhankelijkheden al vooraf zijn geïnstalleerd, en de containers zelf geïsoleerd zijn van elkaar en van het host-besturingssysteem? We zullen de monoliet opdelen in microservices, die elk onafhankelijk van de andere kunnen worden bijgewerkt en geschaald. Door de code in zo’n container te plaatsen, kan ik deze op elke infrastructuur draaien. Al beter.
Wat moet u doen als u geen containers wilt configureren? Ik wil niet nadenken over het schalen van de applicatie. Ik wil niet betalen voor inactief draaiende containers als de belasting van de service minimaal is. Ik wil code schrijven. Concentreer u op bedrijfslogica en breng producten met de snelheid van het licht op de markt.
Dergelijke gedachten brachten mij naar serverloos computergebruik. Serverloos betekent in dit geval niet de fysieke afwezigheid van servers, maar de afwezigheid van kopzorgen op het gebied van infrastructuurbeheer.
Het idee is dat applicatielogica wordt opgesplitst in onafhankelijke functies. Ze hebben een evenementenstructuur. Elke functie voert één ‘microtaak’ uit. Het enige dat de ontwikkelaar hoeft te doen, is de functies in de console van de cloudprovider te laden en deze te correleren met gebeurtenisbronnen. De code wordt op verzoek uitgevoerd in een automatisch voorbereide container en ik betaal alleen voor de uitvoeringstijd.
Laten we eens kijken hoe het applicatieontwikkelingsproces er nu uit zal zien.
Van de kant van de ontwikkelaar
Eerder begonnen we te praten over een applicatie voor een online winkel. In de traditionele benadering wordt de hoofdlogica van het systeem uitgevoerd door een monolithische toepassing. En de server met de applicatie draait constant, ook als er geen belasting is.
Om naar serverloos te gaan, splitsen we de applicatie op in microtaken. Voor elk van hen schrijven we onze eigen functie. De functies zijn onafhankelijk van elkaar en slaan geen statusinformatie op (staatloos). Ze kunnen zelfs in verschillende talen zijn geschreven. Als een van hen “valt”, stopt de hele applicatie niet. De applicatiearchitectuur zal er als volgt uitzien:
De indeling in functies in Serverless is vergelijkbaar met het werken met microservices. Maar een microservice kan verschillende taken uitvoeren, en idealiter zou een functie er één moeten uitvoeren. Laten we ons voorstellen dat het de taak is om statistieken te verzamelen en deze op verzoek van de gebruiker weer te geven. Bij de microservice-aanpak wordt een taak uitgevoerd door één dienst met twee ingangspunten: schrijven en lezen. Bij serverloos computergebruik zijn dit twee verschillende functies die geen verband met elkaar hebben. De ontwikkelaar bespaart computerbronnen als statistieken bijvoorbeeld vaker worden bijgewerkt dan gedownload.
Serverloze functies moeten binnen een korte tijd (time-out) worden uitgevoerd, die wordt bepaald door de serviceprovider. Voor AWS is de time-out bijvoorbeeld 15 minuten. Dit betekent dat functies met een lange levensduur moeten worden aangepast om aan de vereisten te voldoen - dit is wat Serverless onderscheidt van andere populaire technologieën van vandaag (containers en Platform as a Service).
Aan elke functie wijzen we een gebeurtenis toe. Een gebeurtenis is een trigger voor een actie:
Evenement
De actie die de functie uitvoert
Er is een productafbeelding geüpload naar de repository.
Comprimeer de afbeelding en upload deze naar een map
Het fysieke winkeladres is bijgewerkt in de database
Laad een nieuwe locatie in kaarten
De klant betaalt voor de goederen
Betalingsverwerking starten
Gebeurtenissen kunnen HTTP-verzoeken, streaminggegevens, berichtenwachtrijen, enzovoort zijn. Gebeurtenisbronnen zijn wijzigingen of voorkomens van gegevens. Bovendien kunnen functies worden geactiveerd door een timer.
De architectuur was uitgewerkt en de applicatie werd bijna serverloos. Vervolgens gaan we naar de dienstverlener.
Van de kant van de aanbieder
Serverloos computergebruik wordt doorgaans aangeboden door cloudserviceproviders. Ze heten anders: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
We zullen de dienst gebruiken via de console of het persoonlijke account van de aanbieder. Functiecode kan op een van de volgende manieren worden gedownload:
- code schrijven in ingebouwde editors via de webconsole,
- download het archief met de code,
- werk met publieke of private git-repository's.
Hier stellen we de gebeurtenissen in die de functie aanroepen. De evenementensets kunnen per provider verschillen.
De provider heeft het Function as a Service (FaaS)-systeem op zijn infrastructuur gebouwd en geautomatiseerd:
- De functiecode komt terecht in de opslag aan de providerzijde.
- Wanneer er een gebeurtenis plaatsvindt, worden containers met een voorbereide omgeving automatisch op de server ingezet. Elke functie-instantie heeft zijn eigen geïsoleerde container.
- Vanuit de opslag wordt de functie naar de container gestuurd, berekend en het resultaat geretourneerd.
- Het aantal parallelle evenementen groeit - het aantal containers groeit. Het systeem schaalt automatisch. Als gebruikers geen toegang hebben tot de functie, is deze inactief.
- De aanbieder stelt de inactieve tijd voor containers in. Als er gedurende deze tijd geen functies in de container verschijnen, wordt deze vernietigd.
Op deze manier krijgen we Serverless uit de doos. We betalen voor de dienst via het ‘pay-as-you-go’-model en alleen voor de functies die worden gebruikt, en alleen voor de tijd dat ze zijn gebruikt.
Om ontwikkelaars kennis te laten maken met de service, bieden providers tot 12 maanden gratis testen aan, maar beperken ze de totale rekentijd, het aantal verzoeken per maand, het geld of het energieverbruik.
Het belangrijkste voordeel van het werken met een provider is dat u zich geen zorgen hoeft te maken over de infrastructuur (servers, virtuele machines, containers). De aanbieder kan FaaS op zijn beurt implementeren, zowel met behulp van eigen ontwikkelingen als met behulp van open source-tools. Laten we er verder over praten.
Van de open source-kant
De open-sourcegemeenschap heeft de afgelopen jaren actief gewerkt aan serverloze tools. Ook de grootste marktspelers dragen bij aan de ontwikkeling van serverloze platforms:
- Kopen Google Reviews biedt ontwikkelaars zijn open-source tool - . IBM, RedHat, Pivotal en SAP namen deel aan de ontwikkeling ervan;
- IBM gewerkt op een serverloos platform , dat toen een project werd van de Apache Foundation;
- Microsoft heeft de platformcode gedeeltelijk geopend .
Ook zijn er ontwikkelingen gaande in de richting van serverless frameworks. и geïmplementeerd in vooraf voorbereide Kubernetes-clusters, werkt met zowel Kubernetes als Docker Swarm. Het raamwerk fungeert als een soort controller: op verzoek bereidt het een runtime-omgeving binnen het cluster voor en lanceert daar vervolgens een functie.
Frameworks laten ruimte voor het configureren van de tool om aan uw behoeften te voldoen. In Kubeless kan een ontwikkelaar dus de time-out voor het uitvoeren van de functie configureren (de standaardwaarde is 180 seconden). In een poging om het koudestartprobleem op te lossen, stelt Fission voor om sommige containers de hele tijd te laten draaien (hoewel dit kosten voor downtime van hulpbronnen met zich meebrengt). En OpenFaaS biedt een reeks triggers voor elke smaak en kleur: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT's en andere.
Instructies om aan de slag te gaan zijn te vinden in de officiële documentatie van de frameworks. Het werken met hen vereist iets meer vaardigheden dan wanneer je met een provider werkt - dit is in ieder geval de mogelijkheid om via de CLI een Kubernetes-cluster te lanceren. Voeg hoogstens andere open-sourcetools toe (bijvoorbeeld de Kafka-wachtrijmanager).
Ongeacht hoe we met Serverless werken – via een provider of via open-source, we zullen een aantal voor- en nadelen ondervinden van de Serverless-aanpak.
Vanuit het oogpunt van voor- en nadelen
Serverless ontwikkelt de ideeën van een containerinfrastructuur en een microservice-aanpak, waarin teams in een meertalige modus kunnen werken zonder gebonden te zijn aan één platform. Het bouwen van een systeem wordt vereenvoudigd en fouten zijn gemakkelijker te corrigeren. Dankzij de microservice-architectuur kunt u veel sneller nieuwe functionaliteit aan het systeem toevoegen dan bij een monolithische applicatie.
Serverless verkort de ontwikkeltijd nog verder, waardoor de ontwikkelaar zich uitsluitend kan concentreren op de bedrijfslogica en codering van de applicatie. Als gevolg hiervan wordt de time-to-market voor ontwikkelingen verkort.
Als bonus krijgen we automatisch schalen voor belasting, en we betalen alleen voor de gebruikte middelen en alleen op het moment dat ze worden gebruikt.
Zoals elke technologie heeft Serverless nadelen.
Een dergelijk nadeel kan bijvoorbeeld de koude starttijd zijn (gemiddeld maximaal 1 seconde voor talen als JavaScript, Python, Go, Java, Ruby).
Enerzijds hangt de koude starttijd in werkelijkheid af van veel variabelen: de taal waarin de functie is geschreven, het aantal bibliotheken, de hoeveelheid code, communicatie met extra bronnen (dezelfde databases of authenticatieservers). Omdat de ontwikkelaar deze variabelen beheert, kan hij de opstarttijd verkorten. Maar aan de andere kant heeft de ontwikkelaar geen controle over de opstarttijd van de container - het hangt allemaal af van de provider.
Een koude start kan veranderen in een warme start wanneer een functie een container hergebruikt die door een eerdere gebeurtenis is gelanceerd. Deze situatie doet zich in drie gevallen voor:
- als klanten veelvuldig gebruik maken van de dienst en het aantal oproepen naar de functie toeneemt;
- als de provider, het platform of het raamwerk u toestaat sommige containers de hele tijd draaiende te houden;
- als de ontwikkelaar functies op een timer uitvoert (bijvoorbeeld elke 3 minuten).
Voor veel toepassingen is een koude start geen probleem. Hier moet u voortbouwen op het type en de taken van de dienst. Een startvertraging van een seconde is niet altijd van cruciaal belang voor een bedrijfstoepassing, maar kan wel van cruciaal belang zijn voor medische diensten. In dit geval zal de serverloze aanpak waarschijnlijk niet langer geschikt zijn.
Het volgende nadeel van Serverless is de korte levensduur van een functie (time-out waarin de functie moet worden uitgevoerd).
Maar als u met taken met een lange levensduur moet werken, kunt u een hybride architectuur gebruiken: combineer Serverless met een andere technologie.
Niet alle systemen kunnen werken met het Serverless-schema.
Sommige applicaties slaan tijdens de uitvoering nog steeds gegevens en status op. Sommige architecturen zullen monolithisch blijven en sommige kenmerken zullen een lange levensduur hebben. Maar (net als cloudtechnologieën en vervolgens containers) is Serverless een technologie met een grote toekomst.
In deze geest zou ik graag verder willen gaan met de kwestie van het gebruik van de serverloze aanpak.
Van de applicatiekant
Voor 2018 het percentage serverloos gebruik . Onder de bedrijven die de technologie al in hun diensten hebben geïmplementeerd, bevinden zich marktgiganten als Twitter, PayPal, Netflix, T-Mobile en Coca-Cola. Tegelijkertijd moet u begrijpen dat Serverless geen wondermiddel is, maar een hulpmiddel voor het oplossen van een bepaald scala aan problemen:
- Verminder de uitvaltijd van hulpbronnen. Het is niet nodig om voortdurend een virtuele machine aan te houden voor diensten met weinig oproepen.
- Verwerk gegevens in een handomdraai. Comprimeer afbeeldingen, knip achtergronden uit, wijzig de videocodering, werk met IoT-sensoren, voer wiskundige bewerkingen uit.
- “Lijm” andere diensten aan elkaar. Git-repository met interne programma's, chatbot in Slack met Jira en agenda.
- Breng de lading in evenwicht. Laten we het hier eens nader bekijken.
Laten we zeggen dat er een dienst is die 50 mensen trekt. Daaronder bevindt zich een virtuele machine met zwakke hardware. Van tijd tot tijd neemt de belasting van de dienst aanzienlijk toe. Dan kan zwakke hardware het niet aan.
U kunt een balancer in het systeem opnemen die de belasting over bijvoorbeeld drie virtuele machines verdeelt. In dit stadium kunnen we de belasting niet nauwkeurig voorspellen, dus houden we een bepaalde hoeveelheid hulpbronnen ‘in reserve’. En we betalen te veel voor downtime.
In zo’n situatie kunnen we het systeem optimaliseren via een hybride aanpak: we laten één virtuele machine achter de load balancer en leggen een koppeling naar het Serverless Endpoint met functies. Als de belasting de drempel overschrijdt, start de balancer functie-instanties die een deel van de aanvraagverwerking overnemen.
Serverless kan dus worden gebruikt waar het nodig is om een groot aantal verzoeken niet te vaak, maar intensief te verwerken. In dit geval is het winstgevender om meerdere functies gedurende 15 minuten uit te voeren dan de hele tijd een virtuele machine of server te onderhouden.
Met alle voordelen van serverless computing moet u vóór de implementatie eerst de applicatielogica evalueren en begrijpen welke problemen Serverless in een bepaald geval kan oplossen.
Serverloos en Selectel
Bij Selectel zijn we dat al via ons controlepaneel. Nu bouwen we ons eigen FaaS-platform. We willen dat ontwikkelaars hun problemen kunnen oplossen met behulp van Serverless via een handige, flexibele interface.
Als u ideeën heeft over wat het ideale FaaS-platform zou moeten zijn en hoe u Serverless in uw projecten wilt gebruiken, deel deze dan in de reacties. Bij de ontwikkeling van het platform houden wij rekening met uw wensen.
Materialen gebruikt in het artikel:
Bron: www.habr.com