Programmēšana

PaaS, CaaS vai FaaS? Kā izvēlēties

Iedomājieties, kā ieiet pārtikas preču veikalā, kura specializācija ir hamburgeri - visa veida hamburgeri, bet tikai hamburgeri. Tomēr attiecībā uz hamburgeriem veikala iespējas ir bezgalīgas.

Ja esat hamburgeru šefpavārs, dodieties uz eju, lai atrastu liellopa, vistas un citas olbaltumvielu iespējas, kā arī visus sierus, maizes veidus, dārzeņus, garšvielas un citas sastāvdaļas, kuras, iespējams, vēlēsities izveidot pats. sāniem. Maltītes iesaiņošanai ir pieejams pat šķīvju un trauku izvēle.

Ja jums trūkst laika, prasmju vai intereses pašiem salikt hamburgeru, dodieties uz divām ejām, kur varat iegādāties vienu no komplektā esošajiem hamburgeriem. Līdztekus klasiskajām iespējām ir pieejams bioloģiskā burgera, vegānu un pat keto diētas komplekts. Vienkārši izpildiet komplektā sniegtos norādījumus, un jums vajadzētu būt vienam yummy burger.

Piedāvāti arī šajā sērijā:

  • Konteineri dodas uz galveno plūsmu ()
  • Konteineri un Kubernetes: 3 veiksmes veiksmes stāsti (CIO)
  • Kubernetes satiekas ar reālo pasauli ()
  • Būtiskākās lietas, kas jāzina par konteineru tīklu (Network World)
  • Kā Visa izveidoja savu konteineru drošības risinājumu (CSO)
  • Konteineri uz darbvirsmas? Jūs derējat - operētājsistēmā Windows 10X (Computerworld)

Tikai tad, kad jūs stāvat kases rindā, jūsu boss zvana. Viņa saka, ka divās stundās pirms pusdienām jāsagatavo 300 dažādu veidu burgeri. Papildus hamburgeru pagatavošanai jums ir jāaktivizē process, lai tos pasniegtu un saņemtu samaksu. Jums būs jābūt piesardzīgam, jo ​​daži klienti vēlas īpašus pasūtījumus, bet citi mēģinās samazināt līniju un nozagt pusdienas.

Visbeidzot, pusdienu laikā notiks veselības un drošības pārbaude, tāpēc, lai ko jūs darītu, labāk ievērojiet noteikumus. Atvainojiet, bet ar jums strādās tikai pāris cilvēki, un viņiem ir arī maza pieredze šāda veida operācijās.

Mākoņu burgera pagatavošana

Izvēle starp mākoņu arhitektūrām ir daudz līdzīga šim hamburgera darbības gadījumam un daudzējādā ziņā ir daudz sarežģītāka. Izstrādātājiem, inženieriem, arhitektiem un IT vadītājiem, apsverot, kuras mākoņa arhitektūras ir jārealizē, ir daudz platformu, veiktspējas, regulēšanas un citu apsvērumu.

Kura arhitektūra piedāvās labāku pieredzi klientiem un sniegs augstākas kvalitātes produktu? Kuru būs vieglāk ieviest un izpildīt savu termiņu? Kurš ceļš labāk risinās atbalsta, atbilstības un drošības jautājumus? Visbeidzot, kuru pieeju jūs varat īstenot ar viszemākajām izmaksām?

Inženieri var izvēlēties konteinera kā pakalpojuma (CaaS) opciju un konteinerizēt lietojumprogrammas, kas ir līdzvērtīga šefpavāra ēdienreizes izveidei un darbības nodrošināšanai caur eju. Ja viņiem nav šīs zināšanas, platformas kā pakalpojums (PaaS) iespējas ir līdzvērtīgas komplekta izvēlei otrajā ejā un tā lietošanas norādījumu un ierobežojumu ievērošanai.

Ne CaaS, ne PaaS neatbilst jūsu vajadzībām? Nu, jūs varētu izveidot visu, sākot no pamatiem (infrastruktūru kā pakalpojumu vai IaaS) vai izvietojot funkcijas līdz vidēm bez servera (funkcionēt kā pakalpojums vai FaaS).

FaaS ir bezserveru skaitļošanas veids, kas paredzēts, lai atbildētu uz vienu uzdevumu. Piemēram, FaaS var izmantot, lai autentificētu lietotāju, veiktu pareizrakstības pārbaudi tekstā vai veiktu matemātisku aprēķinu.

Skaidrs, ka ir daudz arhitektūras iespēju, kā mitināt, konfigurēt, pārvaldīt un izvietot kodu mākonī. Lietas kļūst vēl sarežģītākas, ņemot vērā dažādos produktu piedāvājumus. PaaS iespējas ietver Azure App Service, AWS Elastic Beanstalk, Google App Engine, Red Hat OpenShift un Salesforce’s Heroku, tikai dažus no tiem. Ja jūs pētāt CaaS risinājumus, tad Amazon, Google un Amazon katram ir savs pārvaldītais Kubernetes pakalpojums ar savu akronīmu (attiecīgi EKS, GKE un AKS). Turklāt ir arī citas iespējas, piemēram, VMware, IBM, Oracle, Rackspace un citi.

Protams, ir vēl vairāk iespēju bez serveriem. Azure Serverless ir bez servera funkcijas, Kubernetes pākstis un lietojumprogrammu vide. Pašlaik AWS ir plašākas iespējas bez serveriem, un tā bez serveriem tiek sadalīta funkcionālās kategorijās skaitļošanai, glabāšanai, datu krātuvēm, API starpniekserverēm un daudz ko citu. Google Cloud izmanto visplašāko bezserveru definīciju un ietver tādus pakalpojumus kā BigQuery un AutoML.

Galvenie CaaS, PaaS, FaaS un bez servera apsvērumi

Pārskatot šīs dažādās mākoņu arhitektūras, ir vairāki apsvērumi.

  • Mērķauditorija - PaaS un FaaS opcijas vispirms ir vērstas uz izstrādātājiem, padarot risinājumu viegli konfigurējamu un integrējamu ar CI / CD cauruļvadiem izvietošanai. Konteineri parametro darbības vidi un platformas konfigurāciju, tāpēc šie rīki parasti ir paredzēti operatoriem un sistēmas administratoriem.
  • Konfigurējamība pret veiklību - kopumā CaaS ir viskonfigurējamākā opcija, dodot operatoriem vislielāko elastību, lai izvēlētos platformas un konfigurācijas konteineriem. PaaS un FaaS opcijas koncentrējas uz veiklību un palīdz izstrādātājiem ātrāk izvietot un pārbaudīt kodu.
  • Daži PaaS risinājumi ir viedoklis - PaaS un FaaS risinājumi pēc konstrukcijas ir iepriekšēji atlasīti, tas nozīmē, ka jūs jau esat iekļuvis viņu platformas izvēles un konfigurācijas opcijās. Šie risinājumi tiek izstrādāti, pamatojoties uz dizainera viedokli par izstrādātāju vēlmēm, labāko praksi un mērķa veiktspējas īpašībām. Operatoriem, kuri dod priekšroku lielākai elastībai vai lielākai kontrolei, domāts PaaS vai FaaS var būt pārāk ierobežojošs.
  • Prasmes un mācīšanās līkne - taisnīgs vispārinājums ir tāds, ka CaaS risinājumiem ir stāvāka mācīšanās līkne un tiem nepieciešamas vairāk prasmju nekā PaaS un FaaS risinājumiem.
  • Piegādātāja bloķēšana - CaaS risinājumi parasti tiek izstrādāti Kubernetes un ir pārnēsājami dažādās mākoņu mitināšanas opcijās. Lai gan PaaS un FaaS risinājumus var izstrādāt, pamatojoties uz Kubernetes, tie parasti nepakļauj Kubernetes slāni galalietotājiem un tā vietā piedāvā vienkāršotas konfigurācijas. Šīs konfigurācijas ir PaaS un FaaS risinājumu īpašumtiesības, un tās bieži ir paredzētas darbam tikai ar vienu mākoni. Daži IT vadītāji uzskata, ka tas ir problemātiski, un ir pamatoti noraizējušies par ieslēgšanos mākoņa pārdevējā.

Jautājumi, lai vadītu jūsu pētījumu un prototipu veidošanu

Saskaroties ar tik daudzām iespējām, dažas organizācijas veiks minimālu pētījumu un prototipu veidošanu un izvēlēsies ceļu, kas vistālāk iet. Citi ieguldīs ievērojamu laiku, enerģiju un naudu, lai izpētītu iespējas, konsultētos ar ekspertiem un izvēlētos iespējas stabilai ieviešanai.

Abas šīs pieejas ir labākas nekā tas, ka jūsu organizācija kļūst paralizēta, pateicoties daudzām iespējām, nevienu neizvēloties un nekur nedodoties. Ātrā tempā, kur katrs uzņēmums cenšas iegūt tehniskas priekšrocības, pārāk konservatīva attieksme un status quo saglabāšana tikai kavēs biznesa iespējas.

Tāpēc es konsultējos ar ekspertiem, lai noteiktu dažus galvenos jautājumus, kuriem vajadzētu palīdzēt sašaurināt iespējas un spēles iespējas:

  1. Vai esat maza komanda, kurā ir tikai daži pieteikumi? Šādos gadījumos jums vajadzētu apsvērt vienkāršākas PaaS un bez servera iespējas, kur jūs varat iegūt lielāko daļu nepieciešamās platformas jau iepriekš konfigurētu un neieguldot daudz laika un pieredzes. DJ Navarrete, AvidXchange platformas arhitektūras direktors, ierosina: “Maziem un vidējiem uzņēmumiem, kuriem veiksmīgai darbībai var būt nepieciešams lielāks pārmaiņu vadības atbalsts, un tiem, kas vēlas ātri palielināt briedumu, stabilitāti un ātrumu, PaaS ir pievilcīgs, jo piedāvā ātrāks ceļš uz ieviešanu un efektivitātes pieaugums. ”
  2. Vai jums ir epizodiskas kravas, bet jums tomēr ir jāpaaugstina, kad nepieciešams? Darbības joma varētu būt mikropakalpojums vai funkcija, bet tā varētu arī paplašināties līdz pilnām lietojumprogrammām un datu bāzēm. Šie lietošanas gadījumi ir ideāli piemēroti skaitļošanai bez servera, kur maksājat tikai par nepieciešamo lietojumu.
  3. Vai jums ir atbilstības pienākums vai normatīvs standarts, kas liek jums ziņot par konkrētām pamatā esošajām opcijām vai iestatījumiem izpildes konteinerā, lietojumprogrammā, datu bāzē, operētājsistēmā vai infrastruktūrā? Veins Andersons, Microsoft Mūsdienu darba vietas izcilības centra drošības un atbilstības arhitekts, saka, ka tas ir kritisks iemesls tam, ka tiek izslēgtas iespējas bez servera. PCI un citas atbilstības prasības juridiskie departamenti vai auditori parasti interpretē kā prasību pēc skaitļošanas vides iestatījumu pierādīšanas.
  4. Vai izmantojat daudzas specializētas platformas vai mantotas lietojumprogrammas? Šādos gadījumos var būt grūti atrast saderīgas komerciālās PaaS opcijas. Tajā pašā laikā konteineru izstrāde var vienkāršot izvietošanu un atkarības pārvaldību.
  5. Vai esat liela organizācija vai uzņēmums, kas darbojas vairākos mākoņos un ražošanā ir dažādas lietojumprogrammu un datu platformas? Šīs organizācijas var izvēlēties standartizēt konteinerus, jo tas nodrošina vislielāko elastību, atbalstot vairākas platformas un konfigurācijas opcijas. Bez servera joprojām var būt apsvērums, ja atbilstība nav faktors. Uzņēmumi var novērsties no PaaS iespējām, ja viņiem ir pietiekami daudz prasmju un spēju attīstīt Kubernetes iespēju iespējas. Organizācijas ar pietiekamu apjomu un tehniskām iemaņām, piemēram, Shopify, var izvēlēties izveidot savu PaaS ar Kubernetes un konteineriem kā pamatu.
  6. Vai jūs izstrādājat mikropakalpojumus un standartizējat uz mākoņa balstītu mikropakalpojumu arhitektūru? Marks Hīts iesaka, ka konteineri vai FaaS ir labas iespējas, tāpat kā funkciju mitināšana konteineros. Hīts saka, ka bez servera funkcijas var būt vieglāk konfigurējamas un to izmaksas ir zemākas, savukārt konteineri var vienkāršot vietējo attīstību un nodrošināt vairāk iespēju galapunktu drošībai.
  7. Mākoņdatošanas konsultantam Sarbjeetam Johalam patīk zināt, vai jūs veidojat platformas, lietojumprogrammas vai pakalpojumus un vai auditorija ir uzņēmuma iekšējā, ārējā vai klienta uzmanība, vai mašīna ir patērējama. Lietotnes veida un galalietotāja veida zināšana palīdz paredzēt nākotnes vajadzības un prasības. Piemēram, Johals saka: “Ārējām lietojumprogrammām vēlaties reģistrēt daudz lielāku piekļuves kontroli, datu apjoms var neparedzami palielināties, un lietojumprogrammai var būt ilgāks kalpošanas laiks, salīdzinot ar iekšējām lietojumprogrammām. Ja pakalpojums vai platforma ir mašīnā patērējama, jums var būt nepieciešama mērīšana. ” Ceļveža un nākotnes vajadzību prognozēšanai vajadzētu palīdzēt reklamēt dažas iespējas un izslēgt citas.

Kad esat sašaurinājis iespējas, vislabākā prakse ir koncepcijas pierādīšana. Jūs nepagatavojat burgerus par 300, nepārbaudot recepti.