Kernpunten
- Sinds enkele jaren is ons beloofd dat serverloos computergebruik (serverloos) een nieuw tijdperk zal openen zonder een specifiek besturingssysteem om applicaties uit te voeren. Er werd ons verteld dat een dergelijke structuur veel schaalbaarheidsproblemen zou oplossen. Eigenlijk is alles anders.
- Hoewel velen serverloze technologie als een nieuw idee zien, gaan de wortels ervan terug tot 2006 met Zimki PaaS en Google App Engine, die beide een serverloze architectuur gebruiken.
- Er zijn vier redenen waarom de serverloze revolutie tot stilstand is gekomen, van beperkte ondersteuning voor programmeertalen tot prestatieproblemen.
- Serverloos computergebruik is niet zo nutteloos. Verre van dat. Ze mogen echter niet worden gezien als een directe vervanging van servers. Voor sommige toepassingen kunnen ze een handig hulpmiddel zijn.
De server is dood, lang leve de server!
Dit is de strijdkreet van de aanhangers van de serverloze revolutie. Een snelle blik op de vakpers van de afgelopen jaren volstaat om te concluderen dat het traditionele servermodel dood is en dat we over een paar jaar allemaal serverloze architecturen zullen gebruiken.
Zoals iedereen in de branche weet, en zoals we ook hebben opgemerkt in ons artikel over , dit is fout. Ondanks vele artikelen over de verdiensten , het is nooit gebeurd. In werkelijkheid, dat deze revolutie mogelijk op een dood spoor is beland.
Sommige beloften voor serverloze modellen zijn zeker uitgekomen, maar niet allemaal. Niet iedereen.
In dit artikel wil ik de redenen voor deze aandoening bespreken. Waarom het gebrek aan flexibiliteit van serverloze modellen nog steeds een obstakel vormt voor een bredere acceptatie, hoewel ze nuttig blijven in specifieke, goed gedefinieerde omstandigheden.
Wat de adepten van serverless computing beloofden
Laten we, voordat we verder gaan met de problemen van serverloos computergebruik, eens kijken wat ze te bieden hadden. waren talrijk en soms zeer ambitieus.
Voor degenen die niet bekend zijn met de term, hier is een korte definitie. Serverloos computergebruik definieert een architectuur waarin applicaties (of delen van applicaties) op verzoek worden uitgevoerd in runtime-omgevingen die doorgaans op afstand worden gehost. Daarnaast kunnen serverloze systemen worden gehost. Het bouwen van robuuste serverloze systemen is de afgelopen jaren een grote zorg geweest van systeembeheerders en SaaS-bedrijven, aangezien (naar men beweert) deze architectuur verschillende belangrijke voordelen biedt ten opzichte van het "traditionele" client/server-model:
- Serverloze modellen vereisen niet dat gebruikers hun eigen besturingssystemen onderhouden of zelfs applicaties bouwen die compatibel zijn met specifieke besturingssystemen. In plaats daarvan maken ontwikkelaars gedeelde code, uploaden deze naar een serverloos platform en kijken hoe deze wordt uitgevoerd.
- Resources in serverloze frameworks worden meestal per minuut (of zelfs seconden) gefactureerd. Dit betekent dat klanten alleen betalen voor de tijd dat ze de code daadwerkelijk uitvoeren. Dit steekt gunstig af bij de traditionele cloud-VM, waar de machine het grootste deel van de tijd inactief is, maar je moet ervoor betalen.
- Ook het probleem van de schaalbaarheid is opgelost. Resources in serverloze frameworks worden dynamisch toegewezen, zodat het systeem plotselinge pieken in de vraag gemakkelijk kan opvangen.
Kortom, serverloze modellen bieden flexibele, goedkope, schaalbare oplossingen. Het verbaast me dat we niet eerder op dit idee zijn gekomen.
Is dit echt een nieuw idee?
Eigenlijk is het idee niet nieuw. Het concept om gebruikers alleen te laten betalen voor de tijd dat de code daadwerkelijk wordt uitgevoerd, bestaat al sinds het werd geïntroduceerd onder de in 2006, en rond dezelfde tijd, kwam Google App Engine met een zeer vergelijkbare oplossing.
Wat we nu het "serverloze" model noemen, is in feite ouder dan veel van de technologieën die nu "cloud native" worden genoemd en die bijna hetzelfde bieden. Zoals opgemerkt, zijn serverloze modellen in wezen slechts een uitbreiding van het SaaS-bedrijfsmodel dat al tientallen jaren bestaat.
Het is ook de moeite waard om te erkennen dat het serverloze model geen FaaS-architectuur is, hoewel er een verband tussen beide is. FaaS is in wezen het compute-centrische onderdeel van een serverloze architectuur, maar vertegenwoordigt niet het hele systeem.
Dus waarom al deze hype? Welnu, terwijl de snelheid van internetpenetratie in ontwikkelingslanden blijft stijgen, neemt ook de vraag naar computerbronnen toe. Veel landen met snelgroeiende e-commercesectoren beschikken bijvoorbeeld eenvoudigweg niet over de computerinfrastructuur voor toepassingen op deze platforms. Dit is waar betaalde serverloze platforms om de hoek komen kijken.
Problemen met serverloze modellen
Het addertje onder het gras is dat serverloze modellen… problemen hebben. Begrijp me niet verkeerd: ik zeg niet dat ze op zichzelf slecht zijn of in bepaalde omstandigheden geen significante waarde bieden aan sommige bedrijven. Maar de belangrijkste bewering van de "revolutie" - dat de serverloze architectuur snel de traditionele zal vervangen - komt nooit uit.
Dat is waarom.
Beperkte ondersteuning voor programmeertalen
Op de meeste serverloze platforms kunnen alleen applicaties die in bepaalde talen zijn geschreven, worden uitgevoerd. Dit beperkt de flexibiliteit en het aanpassingsvermogen van deze systemen ernstig.
Er wordt aangenomen dat serverloze platforms de meeste grote talen ondersteunen. AWS Lambda en Azure Functions bieden ook een wrapper voor het uitvoeren van applicaties en functies in niet-ondersteunde talen, hoewel dit vaak prestatiekosten met zich meebrengt. Dus voor de meeste organisaties is deze beperking meestal geen probleem. Maar hier gaat het om. Een van de voordelen van serverloze modellen zou zijn dat obscure, weinig gebruikte programma's goedkoper kunnen worden gebruikt omdat u alleen betaalt voor de tijd dat ze draaien. En obscure, zelden gebruikte programma's zijn vaak geschreven in... obscure, zelden gebruikte programmeertalen.
Dit ondermijnt een van de belangrijkste voordelen van het serverloze model.
Bindend aan een verkoper
Het tweede probleem met serverloze platforms, of in ieder geval de manier waarop ze momenteel worden geïmplementeerd, is dat ze op operationeel niveau meestal niet op elkaar lijken. Er is praktisch geen standaardisatie op het gebied van schrijffuncties, implementatie en beheer. Dit betekent dat het migreren van functies van het ene platform naar het andere extreem tijdrovend is.
Het moeilijkste deel van de overstap naar een serverloos model zijn niet de rekenfuncties, die meestal slechts stukjes code zijn, maar hoe applicaties communiceren met verbonden systemen zoals objectopslag, identiteitsbeheer en wachtrijen. Functies kunnen worden verplaatst, maar de rest van de applicatie niet. Dit is precies het tegenovergestelde van de beloofde goedkope en flexibele platformen.
Sommigen beweren dat serverloze modellen nieuw zijn en dat er geen tijd is geweest om te standaardiseren hoe ze werken. Maar ze zijn niet zo nieuw, zoals ik hierboven opmerkte, en veel andere cloudtechnologieën, zoals containers, zijn al veel handiger geworden door de ontwikkeling en brede acceptatie van goede standaarden.
Производительность
De rekenprestaties van serverloze platforms zijn moeilijk te meten, deels omdat leveranciers de neiging hebben om informatie geheim te houden. De meesten beweren dat functies op externe, serverloze platforms net zo snel werken als op interne servers, afgezien van enkele onvermijdelijke latentieproblemen.
Er zijn echter aanwijzingen dat dit anders is. Functies die niet eerder op een bepaald platform hebben gedraaid, of al een tijdje niet hebben gedraaid, hebben enige tijd nodig om te initialiseren. Dit is waarschijnlijk te wijten aan het feit dat hun code is overgezet naar een minder gemakkelijk beschikbaar opslagmedium, hoewel - net als bij benchmarks - de meeste leveranciers u niet zullen vertellen over het overzetten van gegevens.
Natuurlijk zijn er verschillende manieren om dit te omzeilen. Een daarvan is het optimaliseren van functies voor elke cloudtaal waarop uw serverloze platform draait, maar dat ondermijnt enigszins de bewering dat deze platforms "agile" zijn.
Een andere benadering is ervoor te zorgen dat prestatiekritische programma's regelmatig worden uitgevoerd om ze "vers" te houden. Deze tweede benadering druist natuurlijk een beetje in tegen de bewering dat serverloze platforms kosteneffectiever zijn omdat u alleen betaalt voor de tijd dat uw programma's draaien. Cloudproviders hebben nieuwe manieren geïntroduceerd om koude starts te verminderen, maar veel van hen vereisen "schaal naar één" (schaal naar één), wat de oorspronkelijke waarde van FaaS ondermijnt.
Het probleem van de koude start kan gedeeltelijk worden verholpen door serverloze systemen intern te gebruiken, maar dit brengt zijn eigen kosten met zich mee en blijft een niche-optie voor goed uitgeruste teams.
U kunt geen volledige apps uitvoeren
Ten slotte is misschien wel de belangrijkste reden waarom serverloze architecturen traditionele modellen niet snel zullen vervangen, dat ze (over het algemeen) geen volledige applicaties kunnen uitvoeren.
Nauwkeuriger gezegd, het is onpraktisch vanuit kostenoogpunt. Uw succesvolle monoliet moet waarschijnlijk niet worden omgezet in een set van vier dozijn functies die met elkaar zijn verbonden door acht gateways, veertig wachtrijen en een dozijn database-instanties. Om deze reden is serverless beter geschikt voor nieuwe ontwikkelingen. Vrijwel geen bestaande applicatie (architectuur) kan worden geporteerd. U kunt migreren, maar u moet helemaal opnieuw beginnen.
Dit betekent dat in de overgrote meerderheid van de gevallen serverloze platforms worden gebruikt als aanvulling op back-endservers om rekenintensieve taken uit te voeren. Dit is heel anders dan de andere twee vormen van cloud computing, containers en virtuele machines, die een holistische manier bieden om op afstand te werken. Dit illustreert een van de uitdagingen bij het migreren van microservices naar serverloze systemen.
Natuurlijk is dit niet altijd een probleem. De mogelijkheid om periodiek enorme computerresources te gebruiken zonder uw eigen hardware te kopen, kan voor veel organisaties echte en blijvende voordelen opleveren. Maar als sommige applicaties op interne servers staan en andere op serverloze cloud-architecturen, dan betreedt het beheer een nieuw niveau van complexiteit.
Lang leve de revolutie?
Ondanks al deze klachten ben ik niet per se tegen serverloze oplossingen. Eerlijk gezegd. Het is alleen dat ontwikkelaars moeten begrijpen - vooral als ze voor het eerst serverloze modellen verkennen - dat deze technologie geen directe vervanging is voor servers. Bekijk in plaats daarvan onze tips en bronnen op en beslissen hoe dit model het beste kan worden toegepast.
Bron: www.habr.com