Programavimas

PaaS, CaaS ar FaaS? Kaip pasirinkti

Įsivaizduokite, einate į maisto prekių parduotuvę, kurios specializacija yra mėsainiai - visokie, bet tik mėsainiai. Vis dėlto kalbant apie mėsainius, parduotuvės pasirinkimų yra begalė.

Jei esate mėsainių virėjas, eikite į vieną praėjimą ir raskite jautienos, vištienos ir kitų baltymų variantų, taip pat visus sūrius, duonos rūšis, daržoves, pagardus ir kitus ingredientus, kuriuos galbūt norėsite pasistatyti patys. šonus. Maistui pakuoti yra net lėkštės ir indai.

Jei jums trūksta laiko, įgūdžių ar noro patiems surinkti mėsainį, pereikite prie dviejų praėjimų, kur galėsite nusipirkti vieną iš mėsainių rinkinyje. Kartu su klasikinėmis galimybėmis yra ekologiško mėsainio, veganiško ir net keto dietos rinkinys. Tiesiog sekite instrukcijas rinkinyje ir turėtumėte turėti vieną mielą mėsainį.

Taip pat rodoma šioje serijoje:

  • Konteineriai žygiuoja į pagrindinę srovę ()
  • Konteineriai ir „Kubernetes“: 3 transformacinės sėkmės istorijos (CIO)
  • Kubernetes susitinka su realiu pasauliu ()
  • Pagrindiniai dalykai, kuriuos reikia žinoti apie konteinerių tinklą (tinklo pasaulis)
  • Kaip „Visa“ sukūrė savo konteinerių saugumo sprendimą (CSO)
  • Konteineriai darbalaukyje? Statote - „Windows 10X“ („Computerworld“)

Tik tada, kai jūs stovite kasos eilėje, jūsų viršininkas skambina. Ji sako, kad per dvi valandas iki pietų reikia pagaminti 300 skirtingų rūšių mėsainių. Be to, be mėsainių gaminimo, jūs turite įdiegti procesą, kad juos patiektumėte ir gautumėte atlyginimą. Turėsite būti atsargūs, nes vieni klientai nori specialių užsakymų, o kiti bandys nukirsti liniją ir pavogti savo pietus.

Galiausiai per pietus bus atliktas sveikatos ir saugos patikrinimas, todėl, kad ir ką darytumėte, geriau laikykitės taisyklių. Atsiprašau, bet su jumis dirbs tik pora žmonių, taip pat jie turi mažai patirties tokio tipo operacijose.

Padaryti debesies mėsainį

Pasirinkimas tarp debesų architektūros yra labai panašus į šią laikiną hamburgerio operaciją ir daugeliu atžvilgių yra daug sudėtingesnis. Kurdami kūrėjai, inžinieriai, architektai ir IT lyderiai turi daug platformos, našumo, reguliavimo ir kitų aspektų, svarstydami, kurias debesų architektūras naudoti.

Kuri architektūra pasiūlys geresnę patirtį klientams ir suteiks aukštesnės kokybės produktą? Kuris bus lengviau pritaikomas ir įvykdys jūsų terminą? Kuris kelias padės geriau išspręsti palaikymo, atitikties ir saugumo problemas? Galiausiai, kurį požiūrį galite įgyvendinti už mažiausią kainą?

Inžinieriai gali pasirinkti konteinerio kaip paslaugos (CaaS) parinktį ir supakuoti programas į konteinerius, o tai prilygsta virėjui, kuriančiam ir valdančiam savo patiekalą per praėjimą. Jei jie neturi tokios patirties, „platforma kaip paslaugos“ („PaaS“) parinktys yra lygiavertės rinkinio rinkimui antrame praėjime ir jo naudojimo nurodymų bei apribojimų laikymuisi.

Nei „CaaS“, nei „PaaS“ neatitinka jūsų poreikių? Na, jūs galite sukurti viską nuo pat pradžių (infrastruktūra kaip paslauga arba IaaS) arba įdiegti funkcijas iki serverių neturinčių aplinkų (veikti kaip paslauga arba „FaaS“).

„FaaS“ yra kompiuterių be serverių tipas, skirtas atsakyti į vieną užduotį. Pavyzdžiui, „FaaS“ gali būti naudojamas vartotojo autentifikavimui, teksto rašybos tikrinimui arba matematiniam skaičiavimui atlikti.

Aišku, yra daugybė architektūrinių galimybių, kaip priglobti, konfigūruoti, valdyti ir įdiegti kodą debesyje. Viskas pasidaro dar sudėtingesnė, atsižvelgiant į skirtingų produktų pasiūlą. „PaaS“ parinktys apima „Azure App Service“, „AWS Elastic Beanstalk“, „Google App Engine“, „Red Hat OpenShift“ ir „Salesforce's Heroku“. Jei tyrinėjate „CaaS“ sprendimus, tada „Amazon“, „Google“ ir „Amazon“ turi savo valdomą „Kubernetes“ paslaugą su savo akronimu (atitinkamai EKS, GKE ir AKS). Be to, yra ir kitų variantų, tokių kaip „VMware“, „IBM“, „Oracle“, „Rackspace“ ir kt.

Be abejo, yra dar daugiau galimybių be serverio. „Azure Serverless“ yra be serverio funkcijų, „Kubernetes“ ankštys ir programų aplinka. Šiuo metu AWS turi platesnes be serverio parinktis ir skirsto savo serverius į funkcines kategorijas skaičiavimui, saugojimui, duomenų saugykloms, API tarpiniams serveriams ir kt. „Google Cloud“ naudoja plačiausią be serverio apibrėžimą ir apima tokias paslaugas kaip „BigQuery“ ir „AutoML“.

Pagrindiniai „CaaS“, „PaaS“, „FaaS“ ir serverio aspektai

Peržiūrint šias skirtingas debesų architektūras yra keli aspektai.

  • Tikslinė auditorija - „PaaS“ ir „FaaS“ parinktys pirmiausia nukreiptos į kūrėjus, todėl sprendimą lengva sukonfigūruoti ir integruoti su CI / CD vamzdynais, skirtais diegti. Konteineriai parametruoja operacinę aplinką ir platformos konfigūraciją, todėl šie įrankiai paprastai yra skirti operatoriams ir sistemos administratoriams.
  • Konfigūruotumas, palyginti su judrumu - Apskritai „CaaS“ yra labiausiai sukonfigūruojama parinktis, suteikianti operatoriams didžiausią lankstumą renkantis platformas ir konfigūracijas konteinerių kaupimui. „PaaS“ ir „FaaS“ parinktys daugiausia dėmesio skiria judrumui ir padeda kūrėjams greičiau įdiegti ir išbandyti kodą.
  • Kai kurie „PaaS“ sprendimai yra nuomoningas - „PaaS“ ir „FaaS“ sprendimai pagal dizainą yra iš anksto pasirinkti, o tai reiškia, kad jūs jau esate užrakinti jų platformos pasirinkimo ir konfigūravimo parinktis. Šie sprendimai sukurti remiantis dizainerio nuomone, ko nori kūrėjai, geriausia praktika ir tikslinėmis našumo charakteristikomis. Operatoriams, kurie nori didesnio lankstumo ar daugiau kontrolės priemonių, nuomonėmis paremtas „PaaS“ arba „FaaS“ gali būti per daug varžantis.
  • Įgūdžiai ir mokymosi kreivė - teisingas apibendrinimas yra tas, kad CaaS sprendimų mokymosi kreivė yra stipresnė ir reikalauja daugiau įgūdžių nei PaaS ir FaaS sprendimai.
  • Tiekėjo užraktas - „CaaS“ sprendimai paprastai yra sukurti „Kubernetes“ ir yra nešiojami įvairiose debesų prieglobos parinktyse. Nors „PaaS“ ir „FaaS“ sprendimus galima sukurti naudojant „Kubernetes“ kaip pagrindą, jie paprastai neatskleidžia „Kubernetes“ sluoksnio galutiniams vartotojams ir pateikia supaprastintas konfigūracijas. Šios konfigūracijos priklauso „PaaS“ ir „FaaS“ sprendimams ir dažnai sukurtos veikti tik viename debesyje. Kai kuriems IT lyderiams tai atrodo problemiška ir jie yra pagrįstai susirūpinę dėl to, kad bus užrakinti debesų tiekėjoje.

Klausimai, skirti vadovautis tyrimais ir prototipų kūrimu

Kai susiduriama su tiek daug galimybių, kai kurios organizacijos atliks minimalų tyrimą ir prototipų sudarymą ir pasirinks kelią, kuris eina greičiausiai. Kiti investuos daug laiko, energijos ir pinigų tyrimų galimybėms konsultuotis, konsultuotis su ekspertais ir pasirinkti patikimo įgyvendinimo variantus.

Abu šie metodai yra geresni, nei jūsų organizacija tampa paralyžiuota dėl daugybės variantų, nepasirenkant nė vieno ir niekur nedingstant. Sparčiai besikeičiančiame pasaulyje, kuriame kiekviena įmonė bando įgyti techninį pranašumą, pernelyg konservatyvi ir status quo išlaikymas tik slopins verslo galimybes.

Taigi, konsultavausi su ekspertais, norėdamas nustatyti keletą pagrindinių klausimų, kurie turėtų padėti susiaurinti galimybes ir sąlygas:

  1. Ar esate maža komanda, turinti tik keletą paraiškų? Tokiais atvejais turėtumėte apsvarstyti paprastesnes „PaaS“ ir „serverless“ parinktis, kur galite gauti daugumą reikalingos platformos iš anksto sukonfigūravę ir neinvestuodami daug laiko bei patirties. DJ Navarrete, „AvidXchange“ platformos architektūros direktorius, siūlo: „Mažoms ir vidutinėms įmonėms, kurioms gali prireikti daugiau pokyčių valdymo palaikymo, ir tiems, kurie nori greitai padidinti brandą, stabilumą ir greitį,„ PaaS “yra patrauklus, nes siūlo greitesnis kelias į įgyvendinimą ir efektyvumo padidėjimas “.
  2. Ar turite epizodinių naudingųjų apkrovų, bet vis tiek turite padidinti, kai to reikia? Taikymo sritis gali būti mikroservisa ar funkcija, tačiau ji taip pat gali išplėsti iki pilnų programų ir duomenų bazių. Šie naudojimo atvejai idealiai tinka kompiuteriui be serverio, kur mokate tik už reikiamą naudojimą.
  3. Ar turite atitikties įsipareigojimą ar reguliavimo standartą, kuris verčia jus pranešti apie konkrečias pagrindines vykdymo konteinerio, programos, duomenų bazės, operacinės sistemos ar infrastruktūros parinktis ar parametrus? Wayne'as Andersonas, „Microsoft“ šiuolaikinės darbo vietos kompetencijos centro saugumo ir atitikties architektas, sako, kad tai yra kritinė priežastis, dėl kurios galimybės be serverio atmetamos. Teisės departamentai ar auditoriai paprastai aiškina PCI ir kitus atitikties reikalavimus kaip reikalaujančius įrodymų, kad reikia skaičiavimo aplinkos parametrų.
  4. Ar naudojatės daugybe specializuotų platformų ar senų programų? Tokiais atvejais gali būti sunku rasti suderinamų komercinių „PaaS“ parinkčių. Kartu kuriant sudėtinius rodinius gali būti paprasčiau diegti ir valdyti priklausomybę.
  5. Ar esate didelė organizacija ar įmonė, veikianti keliuose debesyse ir turinti įvairias taikomąsias bei duomenų platformas? Šios organizacijos gali nuspręsti standartizuoti konteinerius, nes tai suteikia didžiausią lankstumą palaikant kelias platformas ir konfigūravimo parinktis. Be serverio vis tiek gali būti svarstoma, jei atitikimas nėra veiksnys. Įmonės gali atsisakyti „PaaS“ pasirinkimo galimybių, jei jos turi pakankamai įgūdžių ir galimybių išplėsti „Kubernetes“ pasirinkimo galimybes. Organizacijos, turinčios pakankamai masto ir techninių įgūdžių, pvz., „Shopify“, gali pasirinkti kurti savo „PaaS“, kurios pagrindas yra „Kubernetes“ ir konteineriai.
  6. Ar kuriate mikropaslaugas ir standartizuojate debesų pagrindu veikiančių mikropaslaugų architektūrą? Markas Heathas siūlo, kad konteineriai ar „FaaS“ yra geros galimybės, kaip ir talpinimo funkcijos konteineriuose. Heathas sako, kad be serverio funkcijas gali būti lengviau sukonfigūruoti ir pigiau palaikyti, o konteineriai gali supaprastinti vietos plėtrą ir suteikti daugiau galimybių apsaugoti galinius taškus.
  7. Debesų tinklo konsultantas Sarbjeet Johal mėgsta žinoti, ar kuriate platformas, programas ar paslaugas ir ar auditorija yra įmonės vidinė, ar išorinė, ar nukreipta į klientą, ar mašina. Žinodami programos tipą ir galutinio vartotojo tipą, galite numatyti būsimus poreikius ir reikalavimus. Pavyzdžiui, Johalas sako: „Norint prisijungti prie išorinių programų, reikia prisijungti kur kas daugiau prieigos kontrolės, duomenų kiekis gali nenuspėjamai padidėti, o programos ilgaamžiškumas gali būti ilgesnis, palyginti su vidinėmis programomis. Jei paslaugą ar platformą galima naudoti mašinoje, jums gali prireikti šiek tiek matavimo. “ Gairių ir ateities poreikių prognozavimas turėtų padėti reklamuoti kai kurias galimybes ir atmesti kitas.

Kai susiaurinsite galimybes, geriausia praktika yra atlikti koncepcijos įrodymą. Jūs neišvirsite mėsainių už 300, neišbandę recepto.

$config[zx-auto] not found$config[zx-overlay] not found