PaaS, CaaS eller FaaS? Hvordan velge

Tenk deg å gå inn i en matbutikk som spesialiserer seg på hamburgere - alle slags hamburgere, men bare hamburgere. Når det gjelder hamburgere, er butikkens muligheter uendelige.

Hvis du er en hamburgerkokk, kan du gå til midtgangen for å finne biff, kylling og andre proteinalternativer, sammen med alle oster, brødtyper, grønnsaker, krydder og andre ingredienser du kanskje vil lage din egen hamburger og sider. Det er til og med et utvalg av tallerkener og beholdere for å pakke måltidet.

Hvis du mangler tid, ferdigheter eller interesse for å montere hamburgeren selv, så gå over til midtgangen to hvor du kan kjøpe en av hamburgere i et sett. Sammen med de klassiske alternativene, er det et sett for en økologisk burger, et vegansk alternativ og til og med en keto-diett. Bare følg instruksjonene i settet, så bør du ha en deilig burger.

Også omtalt i denne serien:

• Beholdere marsjerer inn i mainstream ()
• Containere og Kubernetes: 3 transformerende suksesshistorier (CIO)
• Kubernetes møter den virkelige verden ()
• Viktige ting å vite om container nettverk (Network World)
• Hvordan Visa bygget sin egen containersikkerhetsløsning (CSO)
• Beholdere på skrivebordet? Du satser - på Windows 10X (Computerworld)

Først da, mens du står i kassen, ringer sjefen din. Hun sier at du må lage 300 burgere av forskjellige typer de to timene før lunsj. I tillegg til å lage burgere, må du operasjonalisere en prosess for å tjene dem og få betalt. Du må være forsiktig fordi noen kunder ønsker spesialbestillinger, og andre vil prøve å kutte linjen og stjele lunsj.

Til slutt vil det være helse- og sikkerhetsinspeksjon under lunsj, så det du gjør bedre, overholder regelverket. Og beklager, men du vil bare ha et par mennesker som jobber med deg, og de har også liten erfaring med denne typen operasjoner.

Å lage skyburgeren

Å velge blant skyarkitekturer er mye som denne midlertidige hamburgeroperasjonen, og på mange måter langt mer komplisert. Utviklere, ingeniører, arkitekter og IT-ledere har mange hensyn til plattform, ytelse, regulering og andre når de vurderer hvilke skyarkitekturer som skal operasjonaliseres.

Hvilken arkitektur vil gi en bedre opplevelse for kundene og gi et produkt av høyere kvalitet? Hvilket vil være enklere å operasjonalisere og nå fristen? Hvilken vei vil håndtere støtte, samsvar og sikkerhetsproblemer bedre? Til slutt, hvilken tilnærming kan du implementere til lavest mulig pris?

Ingeniører kan velge et container-as-a-service (CaaS) -alternativ og containerisere applikasjoner, noe som tilsvarer at kokken lager og operasjonaliserer måltidet sitt gjennom midtgangen. Hvis de ikke har den kompetansen, tilsvarer plattform-som-en-tjeneste (PaaS) -alternativene å velge et sett i midtgangen to og følge instruksjonene og begrensningene for å bruke det.

Verken CaaS eller PaaS tilfredsstiller dine behov? Vel, du kan bygge alt fra grunnen av (infrastruktur som en tjeneste, eller IaaS) eller distribuere funksjoner til serverløse miljøer (fungere som en tjeneste eller FaaS).

FaaS er en type serverløs databehandling designet for å svare på en enkelt oppgave. For eksempel kan en FaaS brukes til å autentisere en bruker, utføre en stavekontroll på en teksttekst eller utføre en matematisk beregning.

Det er klart at det er mange arkitektoniske alternativer for å være vert, konfigurere, administrere og distribuere kode til skyen. Ting blir enda mer kompliserte når man vurderer de forskjellige produkttilbudene. PaaS-alternativene inkluderer Azure App Service, AWS Elastic Beanstalk, Google App Engine, Red Hat OpenShift og Salesforce's Heroku, for bare å nevne noen. Hvis du utforsker CaaS-løsninger, har Amazon, Google og Amazon hver sin administrerte Kubernetes-tjeneste med hvert sitt akronym (henholdsvis EKS, GKE og AKS). I tillegg er det andre alternativer fra slike som VMware, IBM, Oracle, Rackspace og andre.

Selvfølgelig er det enda flere serverløse alternativer. Azure Serverless har serverløse funksjoner, Kubernetes pods og applikasjonsmiljøer. AWS har for tiden bredere serverløse alternativer og deler serverløs inn i funksjonelle kategorier for databehandling, lagring, datalagre, API-proxyer og mer. Google Cloud tar den mest omfattende definisjonen av serverløs og inkluderer tjenester som BigQuery og AutoML.

Nøkkel CaaS, PaaS, FaaS og serverløse hensyn

Det er flere hensyn når du vurderer disse forskjellige skyarkitekturene.

• Målgruppe - PaaS og FaaS-alternativene retter seg først mot utviklerne ved å gjøre løsningen enkel å konfigurere og integrere med CI / CD-rørledninger for distribusjon. Containere parameteriserer driftsmiljøet og plattformkonfigurasjonen, slik at disse verktøyene generelt er rettet mot operatører og systemadministratorer.
• Konfigurerbarhet kontra smidighet - Generelt er CaaS det mest konfigurerbare alternativet, noe som gir operatører størst fleksibilitet til å velge plattformer og konfigurasjoner for containerisering. PaaS og FaaS-alternativene fokuserer på smidighet og hjelper utviklere med å distribuere og teste kode raskere.
• Noen PaaS-løsninger er meningsfull - PaaS- og FaaS-løsninger etter design er forhåndsvalg, noe som betyr at du allerede er låst inn i deres valg av plattform og konfigurasjonsalternativer. Disse løsningene er konstruert basert på designernes meninger om hva utviklere ønsker, beste praksis og målytelsesegenskaper. For operatører som foretrekker mer fleksibilitet eller flere kontroller, kan en meningsfull PaaS eller FaaS være for begrensende.
• Ferdigheter og læringskurve - En rettferdig generalisering er at CaaS-løsninger har en brattere læringskurve og krever flere ferdigheter enn PaaS- og FaaS-løsninger.
• Leverandørinnlåsing - CaaS-løsninger er generelt utviklet på Kubernetes og er bærbare på tvers av forskjellige skyhostingsalternativer. Selv om PaaS- og FaaS-løsninger kan konstrueres med Kubernetes som grunnlag, utsetter de vanligvis ikke Kubernetes-laget for sluttbrukere og presenterer i stedet mer forenklede konfigurasjoner. Disse konfigurasjonene er proprietære for PaaS- og FaaS-løsningen, og ofte designet for å kjøre på bare en sky. Noen IT-ledere synes dette er problematisk og er med rette bekymret for å bli låst inn i skyleverandøren.

Spørsmål for å veilede din forskning og prototyping

Når man står overfor så mange alternativer, vil noen organisasjoner utføre en minimal mengde forskning og prototyping og velge banen som går lengst raskest. Andre vil investere betydelig tid, energi og penger på å undersøke alternativer, konsultere eksperter og velge alternativer for robuste implementeringer.

Begge disse tilnærmingene er bedre enn at organisasjonen din blir lammet av mange muligheter, velger ingen og ikke går noen vei. I den fartsfylte verdenen der hvert selskap prøver å få en teknisk fordel, vil det å være altfor konservativt og opprettholde status quo bare hemme forretningens muligheter.

Så jeg konsulterte eksperter for å identifisere noen viktige spørsmål som kan bidra til å begrense alternativene og spillereglene:

1. Er du et lite team med bare noen få applikasjoner? I disse tilfellene bør du vurdere de enklere PaaS og serverløse alternativene der du kan få mest mulig av den nødvendige plattformen forhåndskonfigurert og uten å investere mye tid og ekspertise. DJ Navarrete, direktør for plattformarkitektur i AvidXchange, foreslår: "For små og mellomstore selskaper som kanskje trenger mer støtte for endringsledelse for å lykkes, og de som ønsker å øke modenhet, stabilitet og hastighet raskt, er PaaS tiltalende fordi det tilbyr en raskere vei til implementering og effektivitetsgevinster. ”
2. Har du episodiske nyttelaster, men trenger fortsatt å øke når det er nødvendig? Omfanget kan være en mikrotjeneste eller funksjon, men kan også vokse til fulle applikasjoner og databaser. Disse brukssakene er ideell for serverløs databehandling, der du kun betaler for den nødvendige bruken.
3. Har du en overholdelsesplikt eller en forskriftsstandard som tvinger deg til å rapportere om spesifikke underliggende alternativer eller innstillinger i kjøringsbeholderen, applikasjonen, databasen, operativsystemet eller infrastrukturen? Wayne Anderson, sikkerhets- og compliance-arkitekt for Microsofts Modern Workplace Center of Excellence, sier dette er en kritisk grunn til at serverløse alternativer blir utelukket. PCI og andre samsvarskrav tolkes vanligvis av juridiske avdelinger eller revisorer som at de krever bevis på innstillingene for databehandlingen.
4. Benytter du mange spesialiserte plattformer eller eldre applikasjoner? I disse tilfellene kan det være vanskelig å finne kommersielle PaaS-alternativer som er kompatible. Samtidig kan utvikling av containere forenkle administrering av distribusjon og avhengighet.
5. Er du en stor organisasjon eller bedrift som opererer i flere skyer og med forskjellige applikasjons- og dataplattformer i produksjon? Disse organisasjonene kan velge å standardisere på containere fordi det gir størst fleksibilitet i å støtte flere plattformer og konfigurasjonsalternativer. Serverfri kan fremdeles være en vurdering hvis samsvar ikke er en faktor. Bedrifter kan styre unna PaaS-alternativene hvis de har nok dyktighet og kapasitet til å utvikle bredden av opsjoner på Kubernetes. Organisasjoner med tilstrekkelig skala og tekniske ferdigheter, som Shopify, kan velge å konstruere sin egen PaaS med Kubernetes og containere som grunnlag.
6. Utvikler du mikrotjenester og standardiserer på en skybasert mikrotjenestearkitektur? Mark Heath antyder at containere eller FaaS er gode alternativer, i likhet med hostingfunksjoner i containere. Heath sier at serverløse funksjoner kan være enklere å konfigurere og billigere å støtte, mens containere kan forenkle lokal utvikling og gi flere alternativer for å sikre sluttpunkter.
7. Skykonsulent Sarbjeet Johal liker å vite om du bygger plattformer, applikasjoner eller tjenester, og om publikum er internt i bedriften, eksternt eller kundevendt, eller maskinforbruk. Å vite typen applikasjon og typen sluttbruker hjelper deg å forutse fremtidige behov og krav. For eksempel sier Johal: “For eksterne applikasjoner vil du logge mye mer tilgangskontroll, datavolumene kan øke uforutsigbart, og applikasjonen kan ha lengre levetid sammenlignet med interne applikasjoner. Hvis en tjeneste eller plattform kan brukes i maskinen, kan det hende du trenger litt måling. ” Prognoser for veikart og fremtidige behov bør bidra til å fremme noen alternativer og utelukke andre.

Når du har innsnevret alternativene, er en best praksis å utføre et bevis på konseptet. Du lager ikke burgere for 300 uten å teste oppskriften.