Programmering

PaaS, CaaS eller FaaS? Hvordan man vælger

Forestil dig at gå ind i en købmand, der specialiserer sig i hamburgere - alle slags hamburgere, men kun hamburgere. Når det kommer til hamburgere, er butikkens muligheder dog uendelige.

Hvis du er en hamburger-kok, skal du gå til midtgangen for at finde de muligheder for oksekød, kylling og andre proteiner, sammen med alle oste, brødtyper, grøntsager, krydderier og andre ingredienser, du måske vil bygge din egen hamburger og sider. Der er endda et udvalg af plader og beholdere til emballering af måltidet.

Hvis du mangler tid, færdigheder eller interesse i at samle hamburgeren selv, skal du gå over til midtergang to, hvor du kan købe en af ​​hamburgere-i-et-sæt. Sammen med de klassiske muligheder er der et sæt til en økologisk burger, en vegansk mulighed og endda en keto-diæt. Bare følg anvisningerne i sættet, så skal du have en lækker burger.

Også med i denne serie:

  • Containere marcherer ind i mainstream ()
  • Containere og Kubernetes: 3 transformerende succeshistorier (CIO)
  • Kubernetes møder den virkelige verden ()
  • Vigtige ting at vide om containernetværk (Network World)
  • Hvordan Visa byggede sin egen container sikkerhedsløsning (CSO)
  • Beholdere på skrivebordet? Du satser - på Windows 10X (Computerworld)

Først da, når du står i kassen, ringer din chef. Hun siger, at du skal lave 300 burgere af forskellige typer de to timer før frokost. Plus, udover at lave burgere, skal du også operere en proces for at betjene dem og få betalt. Du bliver nødt til at være forsigtig, fordi nogle kunder ønsker specialordrer, og andre vil prøve at skære linjen og stjæle deres frokost.

Endelig vil der være en sundheds- og sikkerhedsinspektion under frokosten, så uanset hvad du gør bedre i overensstemmelse med reglerne. Og undskyld, men du vil kun have et par mennesker, der arbejder sammen med dig, og de har også ringe erfaring med denne type operationer.

At lave skyburgeren

At vælge blandt skyarkitekturer ligner meget denne midlertidige hamburgeroperation og på mange måder langt mere kompliceret. Udviklere, ingeniører, arkitekter og IT-ledere har mange platform-, ydeevne-, lovgivningsmæssige og andre overvejelser, når de overvejer, hvilke skyarkitekturer der skal operationaliseres.

Hvilken arkitektur giver kunderne en bedre oplevelse og giver et produkt af højere kvalitet? Hvilket er lettere at operationalisere og nå din deadline? Hvilken vej håndterer support, overholdelse og sikkerhedsproblemer bedre? Endelig, hvilken tilgang kan du implementere til de laveste omkostninger?

Ingeniører kan vælge en container-as-a-service (CaaS) -mulighed og containerisere applikationer, hvilket svarer til, at kokken opretter og operationaliserer sit måltid gennem gangen. Hvis de ikke har den ekspertise, svarer platform-as-a-service (PaaS) -mulighederne til at vælge et sæt i midtergang to og følge anvisningerne og begrænsningerne for at bruge det.

Hverken CaaS eller PaaS opfylder dine behov? Nå, du kan bygge alt fra bunden (infrastruktur som en tjeneste eller IaaS) eller implementere funktioner til serverløse miljøer (fungere som en tjeneste eller FaaS).

FaaS er en type serverløs computing designet til at svare på en enkelt opgave. For eksempel kan en FaaS bruges til at godkende en bruger, udføre en stavekontrol på en teksttekst eller udføre en matematisk beregning.

Der er tydeligvis mange arkitektoniske muligheder for at være vært, konfigurere, administrere og distribuere kode til skyen. Ting bliver endnu mere komplicerede, når man overvejer de forskellige produkttilbud. PaaS-muligheder inkluderer Azure App Service, AWS Elastic Beanstalk, Google App Engine, Red Hat OpenShift og Salesforce's Heroku, for bare at nævne nogle få. Hvis du udforsker CaaS-løsninger, har Amazon, Google og Amazon hver deres administrerede Kubernetes-tjeneste med deres eget akronym (henholdsvis EKS, GKE og AKS). Der er desuden andre muligheder fra f.eks. VMware, IBM, Oracle, Rackspace og andre.

Selvfølgelig er der endnu flere serverløse muligheder. Azure Serverless har serverløse funktioner, Kubernetes-bælg og applikationsmiljøer. AWS har i øjeblikket bredere serverløse indstillinger og opdeler sin serverløse i funktionelle kategorier til computing, opbevaring, datalagre, API-proxyer og mere. Google Cloud tager den mest omfattende definition af serverfri og inkluderer tjenester som BigQuery og AutoML.

Nøgle CaaS, PaaS, FaaS og serverløse overvejelser

Der er flere overvejelser, når man gennemgår disse forskellige skyarkitekturer.

  • Målgruppe - PaaS og FaaS-indstillinger målretter først udviklerne ved at gøre løsningen let at konfigurere og integrere med CI / CD-rørledninger til implementering. Containere parametrerer driftsmiljøet og platformskonfigurationen, så disse værktøjer er generelt målrettet mod operatører og systemadministratorer.
  • Konfigurerbarhed versus agility - Generelt er CaaS den mest konfigurerbare mulighed, hvilket giver operatører mest fleksibilitet til at vælge platforme og konfigurationer til containerisering. PaaS og FaaS-mulighederne fokuserer på smidighed og hjælper udviklere med at implementere og teste kode hurtigere.
  • Nogle PaaS-løsninger er meningsfuld - PaaS- og FaaS-løsninger efter design vælges forud, hvilket betyder, at du allerede er låst fast i deres platformvalg og konfigurationsmuligheder. Disse løsninger er konstrueret baseret på designerens meninger om, hvad udviklere ønsker, bedste praksis og målpræstationsegenskaber. For operatører, der foretrækker mere fleksibilitet eller flere kontroller, kan en opfattet PaaS eller FaaS være for begrænsende.
  • Færdigheder og indlæringskurve - En fair generalisering er, at CaaS-løsninger har en stejlere indlæringskurve og kræver flere færdigheder end PaaS- og FaaS-løsninger.
  • Vendor lock-in - CaaS-løsninger er generelt udviklet på Kubernetes og er bærbare på tværs af forskellige cloud hosting-muligheder. Selvom PaaS- og FaaS-løsninger kan konstrueres med Kubernetes som fundament, udsætter de typisk ikke Kubernetes-laget for slutbrugere og præsenterer i stedet mere forenklede konfigurationer. Disse konfigurationer er beskyttet af PaaS- og FaaS-løsningen og er ofte designet til kun at køre på en sky. Nogle it-ledere finder dette problematisk og er med rette bekymrede over at blive låst inde i cloud-leverandøren.

Spørgsmål til vejledning i din forskning og prototyping

Når de står over for så mange muligheder, udfører nogle organisationer en minimal mængde forskning og prototyping og vælger den vej, der går længst hurtigst. Andre vil investere betydelig tid, energi og penge til at undersøge muligheder, konsultere eksperter og vælge muligheder for robuste implementeringer.

Begge disse tilgange er bedre end din organisation bliver lammet af de mange muligheder, vælger ingen og går ingen steder. I den hurtige verden, hvor alle virksomheder forsøger at få en teknisk fordel, vil det være alt for konservativt og opretholde status quo kun hæmme en virksomheds muligheder.

Så jeg konsulterede eksperter for at identificere nogle vigtige spørgsmål, der kunne hjælpe med at indsnævre mulighederne og spillereglerne:

  1. Er du et lille team med kun få ansøgninger? I disse tilfælde skal du overveje de enklere PaaS og serverløse muligheder, hvor du kan få det meste af den krævede platform forudkonfigureret og uden at investere meget tid og ekspertise. DJ Navarrete, direktør for platformarkitektur hos AvidXchange, foreslår: “For små til mellemstore virksomheder, der muligvis har brug for mere support til forandringsledelse for at få succes, og dem der ønsker at øge modenhed, stabilitet og hastighed hurtigt, er PaaS tiltalende, fordi det tilbyder en hurtigere vej til implementering og effektivitetsgevinster. ”
  2. Har du episodiske nyttelast, men har stadig brug for at skalere op, når det kræves? Omfanget kunne være en mikroservice eller funktion, men kunne også vokse til fulde applikationer og databaser. Disse brugssager er ideel til serverløs computing, hvor du kun betaler for den krævede brug.
  3. Har du en overholdelsesforpligtelse eller en lovgivningsmæssig standard, der tvinger dig til at rapportere om specifikke underliggende muligheder eller indstillinger i udførelsesbeholderen, applikationen, databasen, operativsystemet eller infrastrukturen? Wayne Anderson, sikkerheds- og overholdelsesarkitekt for Microsofts Modern Workplace Center of Excellence, siger, at dette er en kritisk grund til, at serverløse muligheder bliver udelukket. PCI og andre overholdelseskrav fortolkes generelt af juridiske afdelinger eller revisorer som krævende bevis for computermiljøindstillinger.
  4. Bruger du mange specialiserede platforme eller ældre applikationer? I disse tilfælde kan det være svært at finde kommercielle PaaS-indstillinger, der er kompatible. Samtidig kan udvikling af containere forenkle implementering og afhængighedsstyring.
  5. Er du en stor organisation eller virksomhed, der opererer i flere skyer og med forskellige applikations- og dataplatforme i produktion? Disse organisationer kan vælge at standardisere på containere, fordi det giver den mest fleksibilitet i understøttelse af flere platforme og konfigurationsmuligheder. Serverfri kan stadig være en overvejelse, hvis overholdelse ikke er en faktor. Virksomheder kan styre sig væk fra PaaS-muligheder, hvis de har tilstrækkelig dygtighed og kapacitet til at udvikle bredden af ​​muligheder på Kubernetes. Organisationer med tilstrækkelig skala og tekniske færdigheder, såsom Shopify, kan vælge at konstruere deres egen PaaS med Kubernetes og containere som fundament.
  6. Udvikler du mikrotjenester og standardiserer på en skybaseret mikrotjenestearkitektur? Mark Heath antyder, at containere eller FaaS er gode muligheder, ligesom hostingfunktioner i containere. Heath siger, at serverløse funktioner kan være lettere at konfigurere og billigere at understøtte, mens containere kan forenkle lokal udvikling og give flere muligheder for at sikre slutpunkter.
  7. Cloud-konsulent Sarbjeet Johal kan godt lide at vide, om du bygger platforme, applikationer eller tjenester, og om publikum er internt i virksomheden, eksternt eller kundeorienteret eller maskinforbrug. At kende typen af ​​applikation og typen slutbruger hjælper dig med at foregribe fremtidige behov og krav. For eksempel siger Johal, ”For eksterne applikationer vil du logge meget mere adgangskontrol, datamængderne kan stige uforudsigeligt, og applikationen kan have en længere forlænget levetid sammenlignet med interne applikationer. Hvis en tjeneste eller platform er maskinforbruget, skal du muligvis måle noget. ” Prognose af køreplanen og fremtidige behov bør hjælpe med at promovere nogle muligheder og udelukke andre.

Når først indstillingerne er indsnævret, er en bedste praksis at udføre et bevis på konceptet. Du tilbereder ikke burgere til 300 uden at teste opskriften.

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