PaaS, CaaS o FaaS? Come scegliere

Immagina di entrare in un negozio di alimentari specializzato in hamburger: tutti i tipi di hamburger, ma solo hamburger. Quando si tratta di hamburger, però, le opzioni del negozio sono infinite. 

Se sei uno chef di hamburger, vai al corridoio uno per trovare il manzo, il pollo e altre opzioni proteiche, insieme a tutti i formaggi, i tipi di pane, le verdure, i condimenti e gli altri ingredienti che potresti desiderare per costruire il tuo hamburger e lati. C'è anche una selezione di piatti e contenitori per il confezionamento del pasto.

Se ti mancano il tempo, le capacità o l'interesse per assemblare l'hamburger da solo, vai al corridoio due dove puoi acquistare uno degli hamburger in kit. Insieme alle opzioni classiche, c'è un kit per un hamburger biologico, un'opzione vegana e persino una dieta cheto. Segui le indicazioni nel kit e dovresti avere un delizioso hamburger.

Presenti anche in questa serie:

  • I container marciano nel mainstream ()
  • Containers e Kubernetes: 3 storie di successo trasformazionali (CIO)
  • Kubernetes incontra il mondo reale ()
  • Cose essenziali da sapere sul networking dei container (Network World)
  • Come Visa ha costruito la propria soluzione per la sicurezza dei container (CSO)
  • Contenitori sul desktop? Puoi scommetterci - su Windows 10X (Computerworld)

Solo allora, mentre sei in fila alla cassa, il tuo capo chiama. Dice che devi preparare 300 hamburger di diversi tipi nelle due ore prima di pranzo. Inoltre, oltre a preparare gli hamburger, devi rendere operativo un processo per servirli ed essere pagato. Dovrai stare attento perché alcuni clienti vogliono ordini speciali e altri cercheranno di tagliare la linea e rubare il loro pranzo.

Infine, durante il pranzo ci sarà un'ispezione sanitaria e di sicurezza, quindi qualunque cosa farai meglio rispettare le normative. E mi dispiace, ma avrai solo un paio di persone che lavorano con te e hanno anche poca esperienza con questo tipo di operazione.

Preparare il cloud burger

La selezione tra le architetture cloud è molto simile a questa operazione improvvisata di hamburger e, per molti versi, molto più complicata. Sviluppatori, ingegneri, architetti e leader IT hanno molte considerazioni su piattaforma, prestazioni, normative e altro quando valutano quali architetture cloud rendere operative.

Quale architettura offrirà una migliore esperienza ai clienti e produrrà un prodotto di qualità superiore? Quale sarà più facile da rendere operativo e rispettare la scadenza? Quale percorso gestirà meglio i problemi di supporto, conformità e sicurezza? Infine, quale approccio puoi implementare al minor costo? 

Gli ingegneri possono selezionare un'opzione container-as-a-service (CaaS) e containerizzare le applicazioni, il che equivale allo chef che crea e rende operativo il suo pasto attraverso il corridoio uno. Se non hanno questa competenza, le opzioni PaaS (platform-as-a-service) sono equivalenti a scegliere un kit nel corridoio due e seguire le indicazioni e i vincoli per utilizzarlo.

Né CaaS né PaaS soddisfano le tue esigenze? Bene, potresti costruire tutto da zero (infrastruttura come servizio o IaaS) o distribuire funzioni in ambienti senza server (funzione come servizio o FaaS).

FaaS è un tipo di elaborazione senza server progettato per rispondere a una singola attività. Ad esempio, un FaaS potrebbe essere utilizzato per autenticare un utente, eseguire un controllo ortografico su un corpo di testo o eseguire un calcolo matematico.

Chiaramente, ci sono molte opzioni architetturali per ospitare, configurare, gestire e distribuire il codice nel cloud. Le cose si complicano ulteriormente se si considerano le diverse offerte di prodotti. Le opzioni PaaS includono il servizio app di Azure, AWS Elastic Beanstalk, Google App Engine, Red Hat OpenShift e Heroku di Salesforce, solo per citarne alcuni. Se stai esplorando le soluzioni CaaS, Amazon, Google e Amazon hanno ciascuno il proprio servizio Kubernetes gestito con il proprio acronimo (rispettivamente EKS, GKE e AKS). Inoltre, ci sono altre opzioni come VMware, IBM, Oracle, Rackspace e altri.

Naturalmente, ci sono ancora più opzioni serverless. Azure Serverless ha funzioni serverless, pod Kubernetes e ambienti applicativi. AWS attualmente dispone di opzioni serverless più ampie e suddivide il serverless in categorie funzionali per elaborazione, archiviazione, archivi dati, proxy API e altro ancora. Google Cloud utilizza la definizione più ampia di serverless e include servizi come BigQuery e AutoML.

Considerazioni chiave CaaS, PaaS, FaaS e serverless

Ci sono diverse considerazioni quando si esaminano queste diverse architetture cloud. 

  • Destinatari: le opzioni PaaS e FaaS si rivolgono innanzitutto agli sviluppatori rendendo la soluzione facile da configurare e integrare con le pipeline CI / CD per la distribuzione. I contenitori parametrizzano l'ambiente operativo e la configurazione della piattaforma, quindi questi strumenti sono generalmente destinati agli operatori e agli amministratori di sistema.
  • Configurabilità contro agilità: in generale CaaS è l'opzione più configurabile, offrendo agli operatori la massima flessibilità per selezionare le piattaforme e le configurazioni da containerizzare. Le opzioni PaaS e FaaS si concentrano sull'agilità e aiutano gli sviluppatori a distribuire e testare il codice più velocemente.
  • Alcune soluzioni PaaS sono  supponenti: le soluzioni PaaS e FaaS in base alla progettazione stanno preselezionando, il che significa che sei già bloccato nella loro scelta della piattaforma e nelle opzioni di configurazione. Queste soluzioni sono progettate in base alle opinioni del progettista su ciò che vogliono gli sviluppatori, best practice e caratteristiche prestazionali target. Per gli operatori che preferiscono una maggiore flessibilità o più controlli, un PaaS o FaaS supponente potrebbe essere troppo vincolante. 
  • Competenze e curva di apprendimento: una generalizzazione equa è che le soluzioni CaaS hanno una curva di apprendimento più ripida e richiedono più competenze rispetto alle soluzioni PaaS e FaaS.
  • Vendor lock-in: le soluzioni CaaS sono generalmente sviluppate su Kubernetes e sono portabili su diverse opzioni di hosting cloud. Anche se le soluzioni PaaS e FaaS possono essere progettate con Kubernetes come base, in genere non espongono il livello Kubernetes agli utenti finali e presentano invece configurazioni più semplificate. Queste configurazioni sono proprietarie delle soluzioni PaaS e FaaS e spesso progettate per essere eseguite su un solo cloud. Alcuni leader IT trovano questo problema e sono giustamente preoccupati di essere bloccati nel fornitore di cloud. 

Domande per guidare la tua ricerca e prototipazione

Di fronte a così tante opzioni, alcune organizzazioni eseguiranno una quantità minima di ricerca e prototipazione e selezioneranno il percorso più veloce. Altri investiranno molto tempo, energia e denaro per ricercare opzioni, consultare esperti e selezionare opzioni per implementazioni robuste.

Entrambi questi approcci sono migliori del fatto che la tua organizzazione resti paralizzata dalla moltitudine di opzioni, non selezionandone nessuna e non andando da nessuna parte. Nel mondo frenetico in cui ogni azienda sta cercando di ottenere un vantaggio tecnico, essere eccessivamente conservatore e mantenere lo status quo inibirà solo le opportunità di un'azienda. 

Quindi, mi sono consultato con esperti per identificare alcune domande chiave che dovrebbero aiutare a restringere le opzioni e il campo di gioco:

  1. Sei un piccolo team con solo poche applicazioni? In questi casi, dovresti considerare le opzioni PaaS e serverless più semplici in cui puoi ottenere la maggior parte della piattaforma richiesta preconfigurata e senza investire molto tempo ed esperienza. DJ Navarrete, direttore dell'architettura della piattaforma presso AvidXchange, suggerisce: "Per le aziende di piccole e medie dimensioni che potrebbero richiedere un maggiore supporto per la gestione del cambiamento per avere successo e per coloro che cercano di aumentare rapidamente la maturità, la stabilità e la velocità, PaaS è interessante perché offre un percorso più rapido per l'implementazione e il miglioramento dell'efficienza. "
  2. Hai payload episodici ma devi comunque aumentare quando richiesto? L'ambito potrebbe essere un microservizio o una funzione, ma potrebbe anche estendersi alle applicazioni e ai database completi. Questi casi d'uso sono ideali per l'elaborazione serverless, dove paghi solo per l'utilizzo richiesto.
  3. Hai un obbligo di conformità o uno standard normativo che ti obbliga a segnalare opzioni o impostazioni sottostanti specifiche nel contenitore di esecuzione, applicazione, database, sistema operativo o infrastruttura? Wayne Anderson, architetto della sicurezza e della conformità per il Modern Workplace Center of Excellence di Microsoft, afferma che questo è un motivo fondamentale per cui le opzioni serverless vengono escluse. I requisiti PCI e altri requisiti di conformità sono generalmente interpretati dagli uffici legali o dai revisori come richiedenti la prova delle impostazioni dell'ambiente di elaborazione.
  4. Stai sfruttando molte piattaforme specializzate o applicazioni legacy? In questi casi, potrebbe essere difficile trovare opzioni PaaS commerciali compatibili. Allo stesso tempo, lo sviluppo di container può semplificare la distribuzione e la gestione delle dipendenze.
  5. Sei una grande organizzazione o impresa che opera in più cloud e con varie piattaforme di dati e applicazioni in produzione? Queste organizzazioni possono scegliere di standardizzare i container perché fornisce la massima flessibilità nel supportare più piattaforme e opzioni di configurazione. Il serverless può ancora essere considerato se la conformità non è un fattore. Le aziende possono allontanarsi dalle opzioni PaaS se dispongono di competenze e capacità sufficienti per sviluppare l'ampia gamma di opzioni su Kubernetes. Le organizzazioni con dimensioni e competenze tecniche sufficienti, come Shopify, potrebbero scegliere di progettare il proprio PaaS con Kubernetes e container come base.
  6. Stai sviluppando microservizi e standardizzando su un'architettura di microservizi basata su cloud? Mark Heath suggerisce che i container o FaaS sono buone opzioni, così come le funzioni di hosting nei container. Heath afferma che le funzioni serverless possono essere più facili da configurare e meno costose da supportare, mentre i container possono semplificare lo sviluppo locale e fornire più opzioni per proteggere gli endpoint. 
  7. Il consulente cloud Sarbjeet Johal ama sapere se stai realizzando piattaforme, applicazioni o servizi e se il pubblico è interno all'azienda, esterno o rivolto al cliente o consumabile. Conoscere il tipo di applicazione e il tipo di utente finale aiuta ad anticipare esigenze e requisiti futuri. Ad esempio, dice Johal: "Per le applicazioni esterne, si desidera registrare molto più controllo degli accessi, i volumi di dati potrebbero aumentare in modo imprevedibile e l'applicazione potrebbe avere una longevità maggiore rispetto alle applicazioni interne. Se un servizio o una piattaforma è consumabile dalla macchina, potresti aver bisogno di una misurazione. " La previsione della tabella di marcia e delle esigenze future dovrebbe aiutare a promuovere alcune opzioni ed escluderne altre.

Una volta ristrette le opzioni, una buona pratica è condurre una prova di concetto. Non cucini hamburger per 300 senza testare la ricetta.