Debesų funkcijos vs Kubernetes variklis

Atnaujinta 2019 m. Rugpjūčio mėn.

„Google“ skaičiavimo sistema siūlo daugybę puikių pasirinkimų. Dvi geriausios GCP technologijos yra „Kubernetes Engine“ ir „Cloud Functions“. Jie abu yra galingi, todėl, kaip kūrėją, lengva numatyti „Cloud Functions“ numatytuosius nustatymus, nes iš mano rankų reikia daug administracinio darbo. Šis administracinis darbas, nors ir deklaratyvūs „yaml“ failai, yra svarbus aspektas konfigūruojant „Kubernetes Engine“.

Pradinė šio straipsnio prielaida buvo kūrėjas, tiesiog paklausęs manęs: „kada jūs pasirinktumėte„ Kubernetes “per„ Cloud Functions “?“. Tai klausimas, kurį aš pats daug apsvarsčiau dirbdamas su abiem šiais būdais, todėl manau, kad geriausias būdas tai sutvarkyti yra „Cloud Functions“ numatytasis nustatymas ir paaiškinti atvejus, kai „Kubernetes Engine“ būtų geresnis pasirinkimas. Nors nedetalizuoju kiekvienos priežasties, čia yra keletas svarbiausių variantų, renkantis Kubernetes.

3 kalbos nesiruošia jo sumažinti

Kai šiuo metu naudojate „Cloud Functions“, turite tik tris kūrimo aplinkas, iš kurių galite pasirinkti „Node.js“, „Python“ ir „Go“. Tai yra neįtikėtina technologija ir ji yra galinga.

„Kubernetes Engine“ suteikia jums laisvės, nes jūsų kuriami ankštys yra izoliuotos aplinkos, kuriose galima paleisti bet kokią kalbą ir laiką. Galbūt esate .NET parduotuvė ir turite naudoti C #. Man buvo malonu naudoti „Core Foundation“ bibliotekas iš „Apple“ tarnyboje. Ši paslauga turės būti parašyta „Swift“ kalba. Tai tik keli atvejai, kai gali būti naudojama kita kalba ir sistemos. Ateityje „Cloud Functions“ palaikys daugiau šių technologijų, tačiau prireiks nemažai metų, kol jos bus pradėtos gaminti.

Greitis

Greitis, ir aš turiu omenyje dabar, o ne per 200 ms. Tai yra esminis skirtumas. Yra atvejų, kai norima tiesiog gauti duomenis ir juos kažkur perkelti. Jei debesies funkcija tam tikrą laiką nenaudojama, visi tos funkcijos egzemplioriai išjungiami. Tai yra geras dalykas, jūs nieko nemokite, jei jo nenaudojate. Tačiau gali būti atvejų, kai tiesiog nenorite laukti šalto pradžios laiko. Jei tai nėra išeitis, „Kubernetes“ turės užpakalį, jūs jau esate klasteris ir galite turėti porą ankščių, susijusių su ta konkrečia paslauga, pasiruošę pradėti veikti, kai iškyla poreikis.

Didelis apdirbimas ir didelis darbo krūvis

Funkcijos yra puikios, norint sujungti įvairias paslaugas. Tačiau jie nėra skirti sunkioms ar ilgoms bėgimo užduotims. Jie turi nedaug procesoriaus ir atminties, palyginti su „Compute“, „Kubernetes“ ir „App Engine“. Jie turi daug greičiau 5 minučių pertraukos laiką, tai reiškia, kad darbą reikia atlikti greitai ir greitai grįžti iš funkcijos.

Be to, jis netvarko sunkių krovinių. Jei ketinate atlikti daugybę vaizdų apdorojimo ar didelių duomenų analizės, naudodami debesies funkciją, susidursite su problemomis. Naudodamiesi „Kubernetes Engine“, jūs turite galimybę mastelį didinti pagal įvairius parametrus, pvz., Aukštą procesorių, atmintį ir kt. Su debesies funkcijomis jūs negalite pasirinkti procesoriaus, o atminties paskirstymas yra gana menkas, palyginti su kitomis skaičiavimo paslaugomis.

Raginimo beprotybė

Kiek kartų jūs naudojatės funkcija? Ar tai šimtas ar šimtas tūkstančių kartų per dieną? Skirtinga, jei jūsų debesies funkcija priklauso nuo „firebase“ duomenų bazės suaktyvinimo, tada verta atsiskaityti už debesies funkciją. Tačiau jei bandote sukurti paslaugą, kuri patvirtins el. Laiškus ar tiesiog praras didžiulį kiekį duomenų, verta pagalvoti apie „Kubernetes“. Pirma, visada galite paleisti kelis podiumus, kad sumažintumėte bet kokį paslaugos vėlavimą. Antra, naudojant „Cloud Functions“ dalį kainos yra, kiek kartų iškviečiama funkcija. Naudodamiesi „Kubernetes“ piko metu galite padidinti skaičių iki daugiau, nei sumažinti. Nesvarbu, ar į jūsų paslaugą bus kreipiamasi dešimt tūkstančių kartų, šiuo metu jūs mokate už naudojamą mazgų ir taškų skaičių, o tai sumažins bendras išlaidas.

Mikro paslaugų bendravimas

Galiausiai, mes palaikome ryšį tarp paslaugų. Debesies funkcijos turi keletą išties galingų „Firebase“ ir GCP aktyviklių. Pvz., Galite nustatyti „Cloud Pub / Sub“ trigerį arba suaktyvinti kitą funkciją, įkeldami failus į „Cloud Storage“. Be to, mes turime HTTP aktyviklius, kurie naudingi kuriant internetinius kabliukus.

Tačiau ką daryti, jei turite kelias paslaugas, kurių nereikia suaktyvinti, o jūs tiesiog norite, kad jos kalbėtųsi tarpusavyje? Šiuo metu kalbėjimas ir bendravimas tarp tarnybų nėra efektyvus būdas, kai naudojamos debesų funkcijos. Pagalvokite tik apie diegimo procesą. Su „Cloud Functions“ tai sudėtinga, kai pradedate atnaujinti daugybę paslaugų „Google Cloud“. Tuo tarpu su „Kubernetes“ jūs tiesiog įkeliate savo konfigūraciją, o „Kubernetes“ užtikrina, kad aplinka tinkamai veiktų jums. Taip, kuriant „yaml“ failus, reikia daug daugiau darbų, bet tada palaikyti šią infrastruktūrą ir ją naudoti yra labai paprasta.

Galų gale, tai priklauso nuo to, ką statote ir kokie yra jūsų poreikiai, tačiau jei žongliruojate idėja paskambinti keliais HTTP funkcijos aktyvikliais pagal vieną skambutį į „Cloud Functions“, tuomet turėtumėte atsitraukti ir paklausti savęs, ar „Kubernetes“ yra geresnis pasirinkimas. 90% tariamo ryšio.

Šis sąrašas nėra baigtinis ir jį tikrai galima aiškinti. Vėlgi, tai priklauso nuo jūsų, kaip įmonės ir organizacijos, poreikių. „Kubernetes“ vis dar auga sparčiai ir ne visi turi kūrėją / komandą, kuri galėtų valdyti jiems skirtą „Kubernetes Engine“ projektą. Kita vertus, galbūt jūs turite daug .NET Core paslaugų, kurias norite įdiegti, ir „Cloud Functions“ jos tiesiog neišnaikins, nes reikia naudoti „Node.js“, „Python“ ar „Go“. Visada verta žengti žingsnį atgal ir galvoti apie įvairias žaidžiamas technologijas ir tai, kaip galėtume panaudoti jas kaip įmanoma produktyvesnes.

Jamesas Wilsonas yra kūrėjas, kuriantis paskirstytas sistemas, naudodamas „Go“ ir „Google Cloud“. Jis taip pat yra Pluralsight autorius ir jo kursus galite peržiūrėti čia.