Cloudfuncties versus Kubernetes Engine

Bijgewerkt augustus 2019.

De rekenopstelling van Google biedt veel geweldige keuzes. Twee van de beste technologieën op GCP zijn Kubernetes Engine en Cloud Functions. Beide zijn krachtig en als ontwikkelaar is het eenvoudig om standaard te werken met Cloud Functions omdat het veel administratief werk uit handen neemt. Dit administratieve werk, zij het declaratieve yaml-bestanden, is een belangrijk aspect bij het configureren van Kubernetes Engine.

Het oorspronkelijke uitgangspunt voor dit artikel was een ontwikkelaar die me eenvoudigweg vroeg: "wanneer zou u Kubernetes verkiezen boven cloudfuncties?". Het is een vraag waar ik zelf veel over heb nagedacht sinds ik met beide heb gewerkt, en dus denk ik dat de beste manier om dit aan te pakken standaard is naar Cloud Functions en de voorbeelden uitleggen waar Kubernetes Engine een betere keuze zou zijn. Hoewel ik niet alle redenen catalogiseer, zijn hier de belangrijkste die spelen bij het kiezen van Kubernetes.

3 talen zullen het niet redden

Wanneer u op dit moment cloudfuncties gebruikt, hebt u slechts drie ontwikkelomgevingen om uit te kiezen en dat zijn Node.js, Python en Go. Dit is een ongelooflijke technologie en het is krachtig.

Kubernetes Engine biedt u vrijheid omdat de pods die u maakt, geïsoleerde omgevingen zijn die elke taal en runtime kunnen uitvoeren. U bent misschien een .NET-winkel en moet C # gebruiken. Ik heb het idee opgevat om de Core Foundation-bibliotheken van Apple in een dienst te gebruiken. Die dienst moet in Swift worden geschreven. Dit zijn slechts enkele van de gevallen waarin het gebruik van een andere taal en een aantal kaders kan zijn betrokken. In de toekomst zal Cloud Functions meer van deze technologieën ondersteunen, maar dat duurt een aantal jaren voordat het in productie is.

Snelheid

Snelheid, en ik bedoel nu, niet over 200 ms. Dit is een fundamenteel verschil. Er zijn gevallen waarin u gewoon gegevens wilt ophalen en ergens naartoe wilt duwen. Als een Cloud-functie enige tijd niet wordt gebruikt, worden alle instanties van die functie uitgeschakeld. Dit is een goede zaak, u betaalt niets als u het niet gebruikt. Er kunnen echter gevallen zijn waarin u gewoon niet wilt wachten op die koude starttijd. Als dat geen optie is, staat Kubernetes voor je klaar, ben je al een cluster en kun je een paar pods laten draaien voor die specifieke service, klaar om in actie te komen wanneer dat nodig is.

Zware verwerking en grote werklasten

Functies zijn geweldig om verschillende services met elkaar te verbinden. Ze zijn echter niet bedoeld voor zware of langdurige taken. Ze hebben een tekort aan CPU en geheugen in vergelijking met Compute, Kubernetes en App Engine. Ze hebben een veel snellere time-outtijd van 5 minuten, wat betekent dat het werk snel moet worden gedaan en u snel uit de functie moet terugkeren.

Bovendien kan het zware lasten niet goed aan. Als je veel beeldverwerking of big data-analyse gaat doen op een cloudfunctie, kom je in de problemen. Met Kubernetes Engine kun je pods schalen op basis van verschillende parameters zoals hoge CPU, geheugen, etc. Met cloudfuncties heb je niet de mogelijkheid om CPU te selecteren en is de geheugentoewijzing vrij laag in vergelijking met de andere computerservices.

Aanroep Madness

Hoe vaak gebruik je de functie? Is het honderd of honderdduizend keer per dag? Het is anders als uw cloudfunctie afhankelijk is van een trigger van de firebase-database, op dat moment is het de moeite waard om genoegen te nemen met de Cloud-functie. Als u echter een service probeert te bouwen die e-mails gaat valideren of gewoon een enorme hoeveelheid gegevens opneemt, is het de moeite waard om Kubernetes te overwegen. Ten eerste kunt u altijd een paar pods laten draaien, zodat u de latentie voor de service vermindert. Ten tweede is bij Cloud Functions een deel van de prijs hoe vaak een functie wordt aangeroepen. Met Kubernetes kun je tijdens piekmomenten naar meer instanties opschalen dan terugschalen. Het maakt niet uit of uw service tienduizend keer wordt ingeroepen, op dit moment betaalt u voor het aantal nodes en pods dat u gebruikt, wat uw totale kosten zal verlagen.

Microservice-communicatie

Tot slot hebben we service-to-service communicatie. Cloudfuncties hebben een aantal echt krachtige triggers voor zowel Firebase als GCP. U kunt bijvoorbeeld een Cloud Pub / Sub-trigger instellen of een andere functie activeren door bestanden naar Cloud Storage te uploaden. Daarnaast hebben we HTTP-triggers die handig zijn voor het maken van webhaken.

Maar wat als u verschillende services heeft die niet hoeven te worden geactiveerd, maar u wilt alleen dat ze met elkaar praten? Op dit moment is praten en communiceren tussen services niet echt een effectieve aanpak bij het gebruik van cloudfuncties. Denk alleen aan het implementatieproces. Met Cloud Functions is dit omslachtig als u een aantal services op Google Cloud gaat updaten. Ondertussen uploadt u met Kubernetes eenvoudig uw configuraties en zorgt Kubernetes ervoor dat de omgeving goed voor u werkt. Ja, er is veel meer werk vooraf om de yaml-bestanden te maken, maar dan is het supereenvoudig om die infrastructuur operationeel te houden.

Uiteindelijk hangt het af van wat je aan het bouwen bent en wat je behoeften zijn, maar als je jongleert met het idee om meerdere HTTP-functie-triggers te bellen op basis van één oproep naar je Cloud-functies, moet je een stapje terug doen en jezelf afvragen of Kubernetes een betere optie is voor de 90% intercommunicatie die plaatsvindt.

Deze lijst is niet limitatief en kan absoluut worden geïnterpreteerd. Nogmaals, het is gebaseerd op uw behoeften als bedrijf en organisatie. Kubernetes groeit nog steeds in een snel tempo en niet iedereen heeft een ontwikkelaar / team bij de hand dat een Kubernetes Engine-project voor hen kan beheren. Aan de andere kant heb je misschien veel .NET Core-services die je wilt implementeren en Cloud Functions halen het gewoon niet omdat je Node.js, Python of Go moet gebruiken. Het is altijd de moeite waard om een ​​stapje terug te doen en na te denken over de verschillende technologieën die spelen en hoe we deze kunnen gebruiken om zo productief mogelijk te zijn.

James Wilson is een ontwikkelaar die gedistribueerde systemen bouwt met Go en Google Cloud. Hij is ook een auteur van Pluralsight en je kunt zijn cursussen hier bekijken.