Programiranje

PaaS, CaaS ali FaaS? Kako izbrati

Predstavljajte si, kako vstopite v trgovino, specializirano za hamburgerje - vse vrste hamburgerjev, vendar le hamburgerje. Kar zadeva hamburgerje, pa je možnosti trgovine nešteto.

Če ste kuhar v hamburgerjih, pojdite na eno stran, da poiščete govedino, piščanca in druge beljakovinske možnosti, skupaj z vsemi siri, vrstami kruha, zelenjavo, začimbami in drugimi sestavinami, ki bi si jih morda želeli sestaviti sami. strani. Obstaja celo izbor krožnikov in posod za pakiranje obroka.

Če vam primanjkuje časa, spretnosti ali zanimanja, da sami sestavite hamburger, se odpravite do prehoda dva, kjer lahko kupite enega od hamburgerjev v kompletu. Skupaj s klasičnimi možnostmi obstaja komplet za ekološki burger, veganska možnost in celo keto dieta. Samo sledite navodilom v kompletu in dobili bi en čudovit hamburger.

V tej seriji tudi:

  • Kontejnerji pohod v mainstream ()
  • Zabojniki in Kubernetes: 3 zgodbe o uspehu s preobrazbo (CIO)
  • Kubernetes se sreča z resničnim svetom ()
  • Bistvene stvari, ki jih morate vedeti o mreženju zabojnikov (Network World)
  • Kako je Visa ustvarila lastno varnostno rešitev za zabojnike (CSO)
  • Zabojniki na namizju? Stavite - na Windows 10X (Computerworld)

Šele potem, ko stojiš v blagajni, pokliče šef. Pravi, da morate v dveh urah pred kosilom narediti 300 burgerjev različnih vrst. Poleg tega morate poleg izdelave hamburgerjev tudi operacionalizirati postopek, s katerim jim boste postregli in dobili plačilo. Previdni boste morali biti, ker nekatere stranke želijo posebna naročila, druge pa bodo poskušale prekiniti linijo in jim ukrasti kosilo.

Nazadnje bo med kosilom zdravstveni in varnostni inšpekcijski pregled, zato, kar koli naredite, bolje upoštevajte predpise. Žal, toda z vami bo sodelovalo le nekaj ljudi, ki imajo tudi malo izkušenj s tovrstnimi operacijami.

Izdelava hamburgerja v oblaku

Izbiranje med arhitekturami v oblaku je podobno temu začasnemu hamburgerju in v mnogih pogledih veliko bolj zapleteno. Razvijalci, inženirji, arhitekti in vodje informacijske tehnologije imajo pri premisleku, katere arhitekture v oblaku uporabiti, veliko premislekov glede platforme, zmogljivosti, predpisov in drugih.

Katera arhitektura bo strankam ponudila boljšo izkušnjo in prinesla kakovostnejši izdelek? Katerega bo lažje operacionalizirati in doseči rok? Katera pot bo bolje obravnavala vprašanja podpore, skladnosti in varnosti? Nazadnje, kateri pristop lahko uporabite z najnižjimi stroški?

Inženirji lahko izberejo možnost zabojnika kot storitve (CaaS) in vsebujejo programe, kar je enakovredno kuharju, ki ustvari in operira svoj obrok prek prehoda. Če tega znanja nimajo, so možnosti platforme kot storitve (PaaS) enakovredne izbiri kompleta v drugem prehodu in upoštevanju navodil in omejitev glede njegove uporabe.

Niti CaaS niti PaaS ne ustrezata vašim potrebam? No, lahko zgradite vse od začetka (infrastruktura kot storitev ali IaaS) ali uvedete funkcije v okolja brez strežnikov (funkcija kot storitev ali FaaS).

FaaS je vrsta računalništva brez strežnika, zasnovana za odziv na eno samo nalogo. Na primer, FaaS se lahko uporablja za preverjanje pristnosti uporabnika, izvajanje črkovanja na telesu besedila ali matematični izračun.

Jasno je, da obstaja veliko arhitekturnih možnosti za gostovanje, konfiguriranje, upravljanje in uvajanje kode v oblak. Stvari se še bolj zapletejo, če upoštevamo različne ponudbe izdelkov. Med možnostmi PaaS so Azure App Service, AWS Elastic Beanstalk, Google App Engine, Red Hat OpenShift in Salesforce's Heroku, če omenimo le nekatere. Če raziskujete rešitve CaaS, imajo Amazon, Google in Amazon vsak svojo lastno upravljano storitev Kubernetes s svojo kratico (EKS, GKE in AKS). Poleg tega obstajajo še druge možnosti, kot so VMware, IBM, Oracle, Rackspace in druge.

Seveda obstaja še več možnosti brez strežnika. Azure Serverless ima funkcije brez strežnika, Kubernetes pods in aplikacijska okolja. Trenutno ima AWS širše možnosti brez strežnika in jih razdeli na funkcionalne kategorije za računalništvo, shranjevanje, shranjevanje podatkov, API-jeve proxyje in še več. Google Cloud ima najbolj obsežno definicijo brez strežnika in vključuje storitve, kot sta BigQuery in AutoML.

Ključni CaaS, PaaS, FaaS in premisleki brez strežnika

Pri pregledu teh različnih arhitektur v oblaku je več premislekov.

  • Ciljna publika - možnosti PaaS in FaaS najprej ciljajo na razvijalce, tako da je rešitev enostavna za konfiguracijo in integracijo s cevovodi CI / CD za uvajanje. Zabojniki parametrizirajo operacijsko okolje in konfiguracijo platforme, zato so ta orodja na splošno usmerjena na operaterje in sistemske skrbnike.
  • Konfigurabilnost v primerjavi z okretnostjo - na splošno je CaaS najbolj nastavljiva možnost, ki operaterjem daje največ prilagodljivosti pri izbiri platform in konfiguracij, ki jih je treba shraniti. Možnosti PaaS in FaaS se osredotočajo na okretnost in pomagajo razvijalcem hitreje uvesti in preizkusiti kodo.
  • Nekatere rešitve PaaS so samozavestni - Načrtovane rešitve PaaS in FaaS so predhodno izbrane, kar pomeni, da ste že zaklenjeni v njihovo izbiro platforme in možnosti konfiguracije. Te rešitve so zasnovane na podlagi mnenj oblikovalca o tem, kaj želijo razvijalci, najboljših praks in ciljnih lastnosti delovanja. Za operaterje, ki imajo raje več prilagodljivosti ali več kontrol, je samozavestni PaaS ali FaaS preveč omejujoč.
  • Krivulja spretnosti in učenja - poštena posplošitev je, da imajo rešitve CaaS bolj strmo učno krivuljo in zahtevajo več spretnosti kot rešitve PaaS in FaaS.
  • Zaklepanje prodajalcev - rešitve CaaS so na splošno razvite na Kubernetesu in so prenosljive v različnih možnostih gostovanja v oblaku. Čeprav je mogoče rešitve PaaS in FaaS izdelati s Kubernetesom kot temeljem, plasti Kubernetes običajno ne izpostavijo končnim uporabnikom in namesto tega predstavljajo bolj poenostavljene konfiguracije. Te konfiguracije so lastniške rešitve PaaS in FaaS in so pogosto zasnovane tako, da delujejo samo v enem oblaku. Nekaterim voditeljem IT se zdi to problematično in jih upravičeno skrbi, da bi bili zaprti v prodajalca oblakov.

Vprašanja za usmerjanje raziskav in izdelave prototipov

Nekatere organizacije bodo pri tako številnih možnostih opravile minimalno količino raziskav in izdelave prototipov ter izbrale najhitrejšo pot. Drugi bodo veliko časa, energije in denarja vložili v raziskave, se posvetovali s strokovnjaki in izbrali možnosti za zanesljive izvedbe.

Oba pristopa sta boljša od tega, da vas organizacija ohromi zaradi številnih možnosti, če ne izberete nobene in ne greste nikamor. V hitrem svetu, kjer si vsako podjetje skuša pridobiti tehnično prednost, bo pretirano konzervativno in ohranjanje obstoječega stanja podjetju le oviralo priložnosti.

Tako sem se posvetoval s strokovnjaki, da bi ugotovil nekaj ključnih vprašanj, ki bi morala pomagati zožiti možnosti in pogoje:

  1. Ste majhna ekipa z le nekaj prijavami? V teh primerih bi morali razmisliti o enostavnejših možnostih PaaS in brez strežnika, kjer lahko dobite večino zahtevane platforme vnaprej konfigurirane in ne da bi vložili veliko časa in strokovnega znanja. DJ Navarrete, direktor arhitekture platforme pri AvidXchange, predlaga: "Za uspeh malih in srednje velikih podjetij, ki bodo morda potrebovala več podpore za upravljanje sprememb, in tistih, ki želijo hitro povečati zrelost, stabilnost in hitrost, je PaaS privlačen, ker ponuja hitrejša pot do izvajanja in povečanja učinkovitosti. "
  2. Ali imate epizodne tovore, vendar jih je treba po potrebi še povečati? Obseg je lahko mikrostoritev ali funkcija, lahko pa se razširi tudi na polne aplikacije in zbirke podatkov. Ti primeri uporabe so idealni za računalništvo brez strežnika, kjer plačate samo potrebno uporabo.
  3. Ali imate obveznost skladnosti ali regulativni standard, ki vas prisili, da poročate o določenih osnovnih možnostih ali nastavitvah v izvedbenem vsebniku, aplikaciji, bazi podatkov, operacijskem sistemu ali infrastrukturi? Wayne Anderson, arhitekt za varnost in skladnost Microsoftovega Centra odličnosti za sodobno delovno mesto, pravi, da je to ključni razlog, da so možnosti brez strežnika izključene. Pravne službe ali revizorji pravilo PCI in druge zahteve glede skladnosti praviloma razlagajo kot zahtevajo dokazila o nastavitvah računalniškega okolja.
  4. Ali uporabljate številne specializirane platforme ali stare programe? V teh primerih je težko najti komercialne možnosti PaaS, ki so združljive. Hkrati lahko razvoj vsebnikov poenostavi uvajanje in upravljanje odvisnosti.
  5. Ste velika organizacija ali podjetje, ki deluje v več oblakih in z različnimi aplikacijskimi in podatkovnimi platformami v proizvodnji? Te organizacije se lahko odločijo za standardizacijo zabojnikov, ker zagotavlja največjo prilagodljivost pri podpori več platform in možnosti konfiguracije. Brez strežnika je morda še vedno treba upoštevati, če skladnost ni pomemben dejavnik. Podjetja se lahko odmaknejo od možnosti PaaS, če imajo dovolj spretnosti in zmogljivosti, da razvijejo širino možnosti na Kubernetesu. Organizacije z zadostnim obsegom in tehničnimi znanji, kot je Shopify, se lahko odločijo, da bodo oblikovale lastne PaaS s Kubernetesom in zabojniki kot temeljem.
  6. Ali razvijate mikro storitve in standardizirate arhitekturo mikro storitev v oblaku? Mark Heath predlaga, da so vsebniki ali FaaS dobre možnosti, prav tako pa tudi gostovanje funkcij v vsebnikih. Heath pravi, da je lahko brezstrežniške funkcije lažje konfigurirati in cenejše za podporo, medtem ko lahko vsebniki poenostavijo lokalni razvoj in nudijo več možnosti za zaščito končnih točk.
  7. Svetovalec za oblak Sarbjeet Johal rad ve, ali gradite platforme, aplikacije ali storitve in ali je občinstvo notranje v podjetju, zunanje, obrnjeno na stranke ali potrošni material. Poznavanje vrste aplikacije in vrste končnega uporabnika vam pomaga predvideti prihodnje potrebe in zahteve. Johal na primer pravi: »Pri zunanjih aplikacijah želite prijaviti veliko več nadzora dostopa, obseg podatkov se lahko nepredvidljivo poveča in aplikacija ima lahko daljšo življenjsko dobo v primerjavi z notranjimi aplikacijami. Če je storitev ali platforma strojno potrošna, boste morda potrebovali nekaj merjenja. " Napovedovanje časovnega načrta in prihodnjih potreb bi moralo pomagati pri spodbujanju nekaterih možnosti in izključitvi drugih.

Ko se vam možnosti zožijo, je najboljša praksa izvedba dokaza o konceptu. Burgerjev ne kuhate za 300, ne da bi preizkusili recept.

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