Pilvefunktsioonid vs Kubernetes'i mootor

Uuendatud august 2019.

Google'i arvutuslik rivistus pakub palju häid valikuid. Kaks parimat GCP-tehnoloogia on Kubernetes Engine ja Cloud Functions. Mõlemad on võimsad ja arendajana on vaikeseade Cloud Functions, kuna see võtab minu käest palju administratiivset tööd. See administratiivne töö, ehkki deklaratiivsed yaml-failid on Kubernetes Engine'i seadistamisel oluline aspekt.

Selle artikli algne eeldus oli, et arendaja lihtsalt küsis minult: “millal valiksite Kubernetes pilvefunktsioonide kohal?”. See on küsimus, mida olen pärast nende mõlemaga töötamist palju kaalunud, ja seetõttu on minu arvates parim viis selle lahendamiseks vaikimisi pilvefunktsioonid sisestada ja selgitada juhtumeid, kus Kubernetes Engine oleks parem valik. Ehkki ma ei loetle kõiki põhjuseid, on siin mitu peamist, mis mängivad Kubernetese valimisel.

3 keelt ei kavatse seda kärpida

Pilvefunktsioonide kasutamisel on teil praegu valida ainult kolme arenduskeskkonna hulgast, milleks on Node.js, Python ja Go. See on uskumatu tehnoloogia ja see on võimas.

Kubernetes Engine pakub teile vabadust, kuna loodavad kaustad on isoleeritud keskkonnad, mis võivad kasutada mis tahes keelt ja tööaega. Võimalik, et olete .NET-pood ja peate kasutama C #-d. Olen lõbustanud idee kasutada Core Foundationi raamatukogusid Apple'ist teenuses. See teenus tuleb kirjutada Swiftis. Need on vaid mõned juhtumid, mis võivad hõlmata mõne muu keele ja raamistike kasutamist. Tulevikus toetab pilvefunktsioon rohkem neid tehnoloogiaid, kuid selle tootmiseks kulub mitu aastat.

Kiirus

Kiirus ja ma mõtlen seda praegu, mitte 200 ms jooksul. See on põhimõtteline erinevus. On juhtumeid, kui soovite lihtsalt andmeid hankida ja kuskile lükata. Kui pilvefunktsiooni mõnda aega ei kasutata, siis kõik selle funktsiooni eksemplarid suletakse. See on hea asi, kui te ei kasuta seda, ei maksa te midagi. Kuid võib esineda juhtumeid, kus te ei soovi lihtsalt seda külma alguse aega oodata. Kui see pole valik, siis on Kubernetesel oma seljataga, olete juba klaster ja teil on selle teenuse jaoks paar tööpakki, mis on vajaduse korral valmis tegutsema.

Suur töötlemine ja suur töökoormus

Funktsioonid on suurepärased erinevate teenuste ühendamiseks. Need pole siiski mõeldud rasketeks ega pikkadeks jooksmise ülesanneteks. Võrreldes Compute, Kubernetes ja App Enginega on neil protsessori ja mälu osas lühike. Neil on 5 minutiga palju kiirem aegumistähtaeg, mis tähendab, et töö tuleb kiiresti ära teha ja peate kiiresti funktsioonist naasma.

Lisaks ei tule see raskete raskustega hästi toime. Kui teete pilvitöötluse jaoks palju pilditöötlust või suurandmete analüüsi, satuvad probleemid. Kubernetes Engine'i abil on teil võimalus mõõtühikuid erinevate parameetrite (nt kõrge CPU, mälu jne) alusel skaneerida. Pilvefunktsioonide abil ei saa te CPU-d valida ja mälu on teiste arvutusteenustega võrreldes üsna madal.

Kutsumise hullus

Mitu korda funktsiooni kutsute? Kas see on päevas sada või sada tuhat korda? See on erinev, kui teie pilvefunktsioon tugineb tulemüüri andmebaasi päästikule, siis tasub sel hetkel pilvefunktsiooni jaoks leppida. Kui proovite luua teenust, mille eesmärk on e-kirjade kinnitamine või lihtsalt tohutu hulga andmete sissevõtmine, tasub kaaluda Kubernetesit. Esiteks võite alati käitada paar taskut, nii et vähendate teenuse viivitust. Teiseks, pilvefunktsioonide puhul on osa hinnast mitu korda funktsioonile kutsutud. Kubernetes'i abil saate tipptundidel skaleerida kuni mitu eksemplari, kui tagasi skaleerida. Pole tähtis, kas teie teenusele helistatakse kümme tuhat korda, maksate sel hetkel teie käitatavate sõlmede ja taskude arvu eest, mis vähendab teie kogukulusid.

Microsofti side

Lõpuks on meil olemas teenustevaheline suhtlus. Pilvefunktsioonidel on mõned tõesti võimsad päästikud nii Firebase'i kui ka GCP jaoks. Näiteks saate häälestada pilve pubi / alampäästiku või käivitada mõne muu funktsiooni, laadides faile pilvsalvestusse. Lisaks on meil HTTP-päästikud, millest on abi veebikonksude loomisel.

Mis aga juhtuks, kui teil on mitu teenust, mida pole vaja käivitada, vaid soovite lihtsalt, et nad omavahel räägiksid? Praegu pole teenuste vaheline rääkimine ja suhtlemine pilvefunktsioonide kasutamisel tegelikult tõhus viis. Mõelge ainult kasutuselevõtuprotsessist. Pilvefunktsioonide puhul on see tülikas, kui hakkate Google Cloudis hunnikut teenust värskendama. Samal ajal laadite Kubernetesiga lihtsalt oma konfiguratsioonid üles ja Kubernetes tagab, et keskkond töötab teie jaoks korralikult. Jah, yaml-failide loomiseks on vaja veel palju tööd teha, kuid siis on selle infrastruktuuri ülalpidamine ja käitamine ülilihtne.

Lõppkokkuvõttes sõltub see sellest, mida te ehitate ja millised on teie vajadused, kuid kui žongleerite mõttega kutsuda pilvefunktsioonidesse mitu kõnet põhinevat mitut HTTP-funktsiooni käivitajat, peaksite tagasi astuma ja endalt küsima, kas Kubernetes on parem valik toimuva 90% -lise ühenduvuse jaoks.

See loetelu ei ole ammendav ja on kindlasti tõlgendamiseks avatud. See põhineb jällegi teie kui ettevõtte ja organisatsiooni vajadustel. Kubernetes kasvab endiselt kiires tempos ja kõigil pole käepärast arendajat / meeskonda, kes suudaks nende jaoks Kubernetes Engine projekti juhtida. Teisest küljest, võib-olla on teil palju .NET Core'i teenuseid, mida soovite juurutada, ja Cloud Functions seda lihtsalt ei lõika, kuna peate kasutama Node.js, Python või Go. Alati tasub astuda samm tagasi ja mõelda erinevate mängitavate tehnoloogiate üle ning sellele, kuidas saaksime neid võimalikult produktiivseks kasutada.

James Wilson on arendaja, kes ehitab hajutatud süsteeme, kasutades Go ja Google Cloud. Ta on ka Pluralsighti autor ja tema kursusi saate vaadata siit.