Ohjelmointi

PaaS, CaaS tai FaaS? Kuinka valita

Kuvittele kävelevä hampurilaisiin erikoistuneeseen ruokakauppaan - kaikenlaisiin, mutta vain hampurilaisiin. Hampurilaisista kaupan vaihtoehdot ovat kuitenkin rajattomat.

Jos olet hampurilaiskokki, siirry käytävälle löytääksesi naudanliha, kana ja muut proteiinivaihtoehdot sekä kaikki juustot, leipätyypit, vihannekset, mausteet ja muut ainesosat, jotka haluat ehkä rakentaa oman hampurilaisen ja sivuilla. Aterian pakkaamiseen on jopa valikoima levyjä ja astioita.

Jos sinulla ei ole aikaa, taitoja tai kiinnostusta koota hampurilainen itse, siirry käytävään kaksi, josta voit ostaa yhden hampurilaisista paketissa. Klassisten vaihtoehtojen ohella on sarja luomuhampurilaiselle, vegaanivaihtoehdolle ja jopa keto-ruokavalioon. Seuraa vain pakkauksen ohjeita, ja sinulla pitäisi olla yksi namia hampurilainen.

Esillä myös tässä sarjassa:

  • Kontit marssivat valtavirtaan ()
  • Kontit ja Kubernetes: 3 muutosmenestystarinaa (CIO)
  • Kubernetes tapaa todellisen maailman ()
  • Tärkeimmät tiedot konttiverkostosta (Network World)
  • Kuinka Visa rakensi oman konttien suojausratkaisun (CSO)
  • Säiliöt työpöydällä? Panostat - Windows 10X: ssä (Computerworld)

Vasta sitten, kun seisot kassalinjalla, pomosi soittaa. Hän sanoo, että sinun on tehtävä 300 erilaista hampurilaista kahdessa tunnissa ennen lounasta. Lisäksi hampurilaisten valmistamisen lisäksi sinun on operoitava prosessi palvelemaan niitä ja maksamaan. Sinun on oltava varovainen, koska jotkut asiakkaat haluavat erikoistilauksia ja toiset yrittävät katkaista linjan ja varastaa lounaansa.

Lopuksi, terveyden ja turvallisuuden tarkastus tehdään lounaan aikana, joten mitä teet paremmin, noudata sääntöjä. Anteeksi, mutta sinulla on vain pari ihmistä, jotka työskentelevät kanssasi, ja heillä on myös vähän kokemusta tämän tyyppisestä toiminnasta.

Pilvihampurilaisen tekeminen

Valinta pilviarkkitehtuurien joukosta on paljon samanlaista kuin tämä välitön hampurilaisoperaatio, ja monin tavoin paljon monimutkaisempi. Kehittäjillä, insinööreillä, arkkitehdeillä ja IT-johtajilla on monia alustan, suorituskyvyn, sääntelyn ja muita näkökohtia harkittaessa, mitkä pilviarkkitehtuurit otetaan käyttöön.

Mikä arkkitehtuuri tarjoaa paremman kokemuksen asiakkaille ja tuottaa korkealaatuisemman tuotteen? Kumpi on helpompi ottaa käyttöön ja saavuttaa määräaika? Mikä polku hoitaa tuki-, vaatimustenmukaisuus- ja turvallisuuskysymykset paremmin? Lopuksi, minkä lähestymistavan voit toteuttaa pienimmillä kustannuksilla?

Insinöörit voivat valita kontti palveluna (CaaS) -vaihtoehdon ja konteinoida sovellukset, mikä vastaa kokin luomaa ja operoimaa ateriansa käytävän läpi. Jos heillä ei ole tätä asiantuntemusta, niin alustana palveluna (PaaS) -vaihtoehdot vastaavat sarjan valitsemista käytävällä kaksi ja sen käytön ohjeiden ja rajoitusten noudattamista.

Kumpikaan CaaS ja PaaS eivät vastaa tarpeitasi? Voisit rakentaa kaiken alusta asti (infrastruktuuri palveluna tai IaaS) tai ottaa käyttöön toimintoja palvelimettomiin ympäristöihin (toimia palveluna tai FaaS).

FaaS on tietyntyyppinen palvelimeton tietojenkäsittely, joka on suunniteltu vastaamaan yhteen tehtävään. Esimerkiksi FaaS: ää voidaan käyttää käyttäjän todentamiseen, tekstin oikeinkirjoituksen tarkistukseen tai matemaattisen laskennan suorittamiseen.

On selvää, että on monia arkkitehtonisia vaihtoehtoja isännöidä, määrittää, hallita ja ottaa käyttöön koodia pilvipalveluun. Asiat entistä monimutkaisempia, kun otetaan huomioon erilaiset tuotetarjonta. PaaS-vaihtoehtoja ovat Azure App Service, AWS Elastic Beanstalk, Google App Engine, Red Hat OpenShift ja Salesforcen Heroku, vain muutamia mainitakseni. Jos etsit CaaS-ratkaisuja, Amazonilla, Googlella ja Amazonilla on kullakin oma hallittu Kubernetes-palvelu omalla lyhenteellään (EKS, GKE ja AKS, vastaavasti). Lisäksi on muita vaihtoehtoja, kuten VMware, IBM, Oracle, Rackspace ja muut.

Tietysti on vielä enemmän palvelimettomia vaihtoehtoja. Azure Serverless -palvelimessa on palvelimettomat toiminnot, Kubernetes-podit ja sovellusympäristöt. AWS: llä on tällä hetkellä laajemmat palvelimettomat vaihtoehdot ja se jakaa palvelimettoman toiminnallisiin luokkiin tietojenkäsittelyä, tallennusta, tietovarastoja, API-välityspalvelimia ja muuta varten. Google Cloud omistaa laajimman määritelmän palvelimettomaksi ja sisältää palveluja, kuten BigQuery ja AutoML.

Key CaaS, PaaS, FaaS ja palvelimettomat näkökohdat

Näitä eri pilviarkkitehtuureja tarkasteltaessa on useita näkökohtia.

  • Kohdeyleisö - PaaS- ja FaaS-vaihtoehdot kohdistetaan ensin kehittäjille tekemällä ratkaisusta helppo konfiguroida ja integroida CI / CD-putkilinjoihin käyttöönottoa varten. Säiliöt parametroivat käyttöympäristön ja alustan kokoonpanon, joten nämä työkalut ovat yleensä suunnattu käyttäjille ja järjestelmänvalvojille.
  • Konfiguroitavuus versus ketteryys - Yleensä CaaS on konfiguroitavin vaihtoehto, joka antaa operaattoreille eniten joustavuutta alustojen ja kokoonpanojen valitsemiseen kontteja varten. PaaS- ja FaaS-vaihtoehdot keskittyvät ketteryyteen ja auttavat kehittäjiä asentamaan ja testaamaan koodia nopeammin.
  • Jotkut PaaS-ratkaisut ovat mielipiteellinen - Suunnittelulla olevat PaaS- ja FaaS-ratkaisut valitaan ennalta, mikä tarkoittaa, että olet jo lukittu heidän alustanvalinta- ja määritysvaihtoehtoihinsa. Nämä ratkaisut suunnitellaan suunnittelijan mielipiteiden perusteella siitä, mitä kehittäjät haluavat, parhaita käytäntöjä ja tavoitteen suorituskykyominaisuuksia. Operaattoreille, jotka haluavat enemmän joustavuutta tai enemmän valvontaa, mielipidetty PaaS tai FaaS voi olla liian rajoittava.
  • Taidot ja oppimiskäyrä - Hyvä yleistys on, että CaaS-ratkaisuilla on jyrkempi oppimiskäyrä ja ne vaativat enemmän taitoja kuin PaaS- ja FaaS-ratkaisut.
  • Toimittajan lukitus - CaaS-ratkaisut on yleensä kehitetty Kubernetes-järjestelmässä, ja ne ovat kannettavia eri pilvipalveluvaihtoehdoissa. Vaikka PaaS- ja FaaS-ratkaisut voidaan suunnitella Kubernetesin perustana, ne eivät yleensä altista Kubernetes-kerrosta loppukäyttäjille ja esittävät yksinkertaistettuja kokoonpanoja. Nämä kokoonpanot ovat PaaS- ja FaaS-ratkaisujen omistamia, ja ne on usein suunniteltu toimimaan vain yhdessä pilvessä. Jotkut IT-johtajat pitävät tätä ongelmallisena ja ovat oikeutetusti huolissaan siitä, että heidät lukitaan pilvipalveluun.

Kysymyksiä ohjaamaan tutkimusta ja prototyyppien tekemistä

Kun kohtaavat niin monia vaihtoehtoja, jotkut organisaatiot tekevät vain vähän tutkimusta ja prototyyppejä ja valitsevat reitin, joka etenee nopeimmin. Toiset investoivat huomattavasti aikaa, energiaa ja rahaa tutkimusvaihtoehtoihin, asiantuntijoiden kuulemiseen ja vaihtoehtojen vankkaan toteutukseen.

Molemmat lähestymistavat ovat parempia kuin organisaatiosi halvaantuu monien vaihtoehtojen joukosta, ei valita yhtään eikä mennä minnekään. Nopeassa maailmassa, jossa jokainen yritys yrittää saada teknistä etua, liian konservatiivinen oleminen ja vallitsevan tilanteen säilyttäminen estävät vain yrityksen mahdollisuuksia.

Joten kuulin asiantuntijoita tunnistamaan joitain keskeisiä kysymyksiä, joiden pitäisi auttaa kaventamaan vaihtoehtoja ja toimintaedellytyksiä:

  1. Oletko pieni tiimi, jolla on vain muutama hakemus? Näissä tapauksissa kannattaa harkita yksinkertaisempia PaaS- ja palvelimettomia vaihtoehtoja, joissa saat suurimman osan vaaditusta alustasta valmiiksi konfiguroituna investoimatta paljon aikaa ja asiantuntemusta. AvidXchangen alustaarkkitehtuurin johtaja DJ Navarrete ehdottaa: "Pienille ja keskisuurille yrityksille, jotka saattavat tarvita enemmän muutoksenhallintatukea menestykseen, ja niille, jotka haluavat lisätä kypsyyttä, vakautta ja nopeutta nopeasti, PaaS on houkutteleva, koska nopeampi tie toteutukseen ja tehokkuuden kasvuun. "
  2. Onko sinulla jaksollisia hyötykuormia, mutta sinun on silti lisättävä niitä tarvittaessa? Laajuus voi olla mikropalvelu tai toiminto, mutta se voi myös kasvaa täydellisiin sovelluksiin ja tietokantoihin. Nämä käyttötapaukset sopivat ihanteellisesti palvelimettomaan tietojenkäsittelyyn, jossa maksat vain vaaditusta käytöstä.
  3. Onko sinulla vaatimustenmukaisuusvelvollisuus tai sääntelystandardi, joka pakottaa sinut raportoimaan tietyistä taustalla olevista vaihtoehdoista tai asetuksista suoritussäiliössä, sovelluksessa, tietokannassa, käyttöjärjestelmässä tai infrastruktuurissa? Wayne Anderson, Microsoftin modernin työpaikan huippuyksikön tietoturva- ja vaatimustenmukaisuusarkkitehti, sanoo, että tämä on kriittinen syy siihen, että palvelimettomat vaihtoehdot suljetaan pois. Oikeudelliset yksiköt tai tilintarkastajat tulkitsevat PCI- ja muut vaatimustenmukaisuusvaatimukset yleensä vaativiksi todisteiksi laskentaympäristön asetuksista.
  4. Hyödynnätkö monia erikoistuneita alustoja tai vanhoja sovelluksia? Näissä tapauksissa voi olla vaikea löytää yhteensopivia kaupallisia PaaS-vaihtoehtoja. Samalla säilöjen kehittäminen voi yksinkertaistaa käyttöönottoa ja riippuvuuksien hallintaa.
  5. Oletko suuri organisaatio tai yritys, joka toimii useissa pilvissä ja jolla on tuotannossa erilaisia ​​sovellus- ja tietoalustoja? Nämä organisaatiot voivat päättää standardoida kontit, koska se tarjoaa eniten joustavuutta useiden alustojen ja kokoonpanovaihtoehtojen tukemisessa. Palvelimeton voi silti olla huomio, jos vaatimustenmukaisuus ei ole tekijä. Yritykset voivat ohjata pois PaaS-vaihtoehdoista, jos niillä on riittävästi taitoa ja kykyä kehittää Kubernetes-vaihtoehtojen laajuutta. Organisaatiot, joilla on riittävät mittakaavat ja tekniset taidot, kuten Shopify, saattavat päättää suunnitella oman PaaS-järjestelmänsä Kubernetesin ja konttien avulla.
  6. Kehitätkö mikropalveluja ja standardisoit pilvipohjaisiin mikropalveluarkkitehtuureihin? Mark Heath ehdottaa, että kontit tai FaaS ovat hyviä vaihtoehtoja, samoin kuin isännöintitoiminnot kontteissa. Heath sanoo, että palvelimettomat toiminnot saattavat olla helpommin määritettävissä ja tuettavia halvemmalla, kun taas säilöt voivat yksinkertaistaa paikallista kehitystä ja tarjota enemmän vaihtoehtoja päätepisteiden suojaamiseksi.
  7. Pilvikonsultti Sarbjeet Johal haluaa tietää, oletko rakentamassa alustoja, sovelluksia tai palveluja ja onko yleisö yrityksen sisäinen, ulkoinen vai asiakaskohtainen vai kuluva kone. Sovellustyypin ja loppukäyttäjän tyypin tuntemus auttaa ennakoimaan tulevat tarpeet ja vaatimukset. Esimerkiksi Johal sanoo: "Ulkoisten sovellusten kohdalla haluat kirjata paljon paremman kulunvalvonnan, datamäärät voivat kasvaa arvaamattomasti ja sovelluksella voi olla pidempi käyttöikä verrattuna sisäisiin sovelluksiin. Jos palvelu tai alusta on konekäyttöinen, saatat tarvita jonkin verran mittausta. " Etenemissuunnitelman ja tulevien tarpeiden ennustamisen pitäisi auttaa edistämään joitain vaihtoehtoja ja sulkemaan pois muita.

Kun vaihtoehdot ovat supistuneet, paras käytäntö on tehdä todiste konseptista. Et kypsennä hampurilaisia ​​300: lle testaamatta reseptiä.

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