Punti chiave
- Da diversi anni ci viene promesso che il serverless computing inaugurerà una nuova era senza un sistema operativo specifico per eseguire le applicazioni. Ci è stato detto che questa struttura avrebbe risolto molti problemi di scalabilità. In effetti, tutto è diverso.
- Sebbene molti considerino il serverless un'idea nuova, le sue radici possono essere fatte risalire al 2006 con l'avvento di Zimki PaaS e Google App Engine, che utilizzano entrambi l'architettura serverless.
- Ci sono quattro ragioni per cui la rivoluzione serverless si è bloccata, che vanno dal supporto limitato del linguaggio di programmazione ai problemi di prestazioni.
- Il computing serverless non è poi così inutile. Affatto. Tuttavia, non devono essere considerati un sostituto diretto dei server. Per alcune applicazioni possono essere uno strumento utile.
Il server è morto, lunga vita al server!
Questo è il grido di battaglia della rivoluzione serverless. Basta una rapida occhiata alla stampa di settore degli ultimi anni ed è facile concludere che il modello server tradizionale è morto e che entro pochi anni utilizzeremo tutti architetture serverless.
Come tutti gli operatori del settore sanno, e come abbiamo sottolineato anche nel nostro articolo su , questo è sbagliato. Nonostante molti articoli sul merito , non ha mai avuto luogo. Infatti, che questa rivoluzione potrebbe essere giunta a un vicolo cieco.
Alcune delle promesse dei modelli serverless sono state certamente realizzate, ma non tutte. Non tutti.
In questo articolo voglio esaminare le ragioni di questa condizione. Perché la mancanza di flessibilità dei modelli serverless rappresenta ancora un ostacolo alla loro più ampia adozione, anche se rimangono utili in circostanze specifiche e ben definite.
Ciò che hanno promesso gli adepti del serverless computing
Prima di affrontare le sfide del serverless computing, diamo un'occhiata a cosa avrebbe dovuto fornire. erano numerosi e, a volte, molto ambiziosi.
Per chi non conosce il termine, ecco una rapida definizione. L'elaborazione serverless definisce un'architettura in cui le applicazioni (o parti di applicazioni) vengono eseguite su richiesta in ambienti runtime generalmente ospitati in remoto. Inoltre, i sistemi serverless possono essere ospitati a casa. Costruire sistemi serverless resilienti è stata una delle principali preoccupazioni degli amministratori di sistema e delle aziende SaaS negli ultimi anni, poiché (si sostiene) questa architettura offre diversi vantaggi chiave rispetto al modello client-server "tradizionale":
- I modelli serverless non richiedono agli utenti di mantenere i propri sistemi operativi o addirittura di creare applicazioni compatibili con sistemi operativi specifici. Invece, gli sviluppatori creano codice condiviso, lo caricano su una piattaforma serverless e lo guardano funzionare.
- Le risorse nei framework serverless vengono generalmente fatturate al minuto (o anche al secondo). Ciò significa che i clienti pagano solo per il tempo in cui effettivamente eseguono il codice. Ciò si confronta favorevolmente con una VM cloud tradizionale, in cui la macchina è inattiva per la maggior parte del tempo, ma devi pagare per questo.
- Anche il problema della scalabilità è stato risolto. Le risorse nei framework serverless vengono assegnate dinamicamente in modo che il sistema possa facilmente far fronte a improvvisi picchi di domanda.
In breve, i modelli serverless forniscono soluzioni flessibili, scalabili e a basso costo. È sorprendente che non abbiamo pensato prima a questa idea.
È davvero una nuova idea?
In realtà l’idea non è nuova. Il concetto di consentire agli utenti di pagare solo per il tempo in cui il codice è effettivamente in esecuzione esiste da quando è stato introdotto da nel 2006 e più o meno nello stesso periodo Google App Engine offriva una soluzione molto simile.
In effetti, quello che oggi chiamiamo modello “serverless” è più antico di molte tecnologie ora chiamate “cloud native” che forniscono più o meno la stessa cosa. Come notato, i modelli serverless sono essenzialmente solo un’estensione del modello di business SaaS che esiste da decenni.
Vale anche la pena riconoscere che il serverless non è un'architettura FaaS, sebbene esista una connessione tra i due. FaaS è essenzialmente la parte incentrata sul calcolo di un'architettura serverless, ma non rappresenta l'intero sistema.
Allora di cosa si tratta? Ebbene, poiché i tassi di penetrazione di Internet continuano a salire alle stelle nei paesi in via di sviluppo, allo stesso tempo aumenta anche la domanda di risorse informatiche. Ad esempio, molti paesi con settori dell’e-commerce in rapida crescita semplicemente non dispongono dell’infrastruttura informatica per le applicazioni su queste piattaforme. È qui che entrano in gioco le piattaforme serverless a pagamento.
Problemi con i modelli serverless
Il problema è che i modelli serverless hanno... problemi. Non fraintendetemi: non sto dicendo che siano cattivi di per sé o che non forniscano un valore significativo ad alcune aziende in alcune circostanze. Ma l’affermazione principale della “rivoluzione”, ovvero che l’architettura serverless sostituirà rapidamente l’architettura tradizionale, non si materializza mai.
Ecco perchè.
Supporto limitato per i linguaggi di programmazione
La maggior parte delle piattaforme serverless consente solo di eseguire applicazioni scritte in determinati linguaggi. Ciò limita seriamente la flessibilità e l’adattabilità di questi sistemi.
Si ritiene che le piattaforme serverless supportino la maggior parte delle lingue principali. AWS Lambda e Funzioni di Azure forniscono inoltre un wrapper per l'esecuzione di applicazioni e funzioni in linguaggi non supportati, sebbene ciò spesso comporti un costo in termini di prestazioni. Pertanto, per la maggior parte delle organizzazioni questa limitazione non rappresenta un grosso problema. Ma ecco il punto. Uno dei vantaggi dei modelli serverless dovrebbe essere che i programmi poco conosciuti e utilizzati raramente possono essere utilizzati in modo più economico perché si paga solo per il tempo di esecuzione. E i programmi poco conosciuti e usati raramente sono spesso scritti in... linguaggi di programmazione poco conosciuti e usati raramente.
Ciò mina uno dei principali vantaggi del modello serverless.
Vincolo del venditore
Il secondo problema con le piattaforme serverless, o almeno con il modo in cui sono attualmente implementate, è che di solito non sono simili tra loro a livello operativo. Non esiste praticamente alcuna standardizzazione in termini di funzioni di scrittura, distribuzione e gestione. Ciò significa che la migrazione delle funzionalità da una piattaforma all’altra richiede molto tempo.
La parte più difficile del passaggio a un modello serverless non sono le funzioni di calcolo, che di solito sono solo frammenti di codice, ma il modo in cui le applicazioni comunicano con i sistemi connessi come l'archiviazione di oggetti, la gestione delle identità e le code. Le funzioni possono essere spostate, ma il resto dell'applicazione no. Questo è l’esatto opposto delle piattaforme economiche e flessibili promesse.
Alcuni sostengono che i modelli serverless siano nuovi e non c’è stato il tempo per standardizzare il loro funzionamento. Ma non sono così nuove, come ho notato sopra, e molte altre tecnologie cloud, come i contenitori, sono già diventate molto più utilizzabili grazie allo sviluppo e all’adozione diffusa di buoni standard.
Производительность
Le prestazioni informatiche delle piattaforme serverless sono difficili da misurare, in parte perché i fornitori tendono a mantenere private le informazioni. Molti sostengono che le funzioni su piattaforme remote e serverless funzionano altrettanto velocemente di quelle sui server interni, con l’eccezione di alcuni inevitabili problemi di latenza.
Tuttavia, i fatti individuali indicano il contrario. L'inizializzazione delle funzionalità che non sono state eseguite in precedenza su una particolare piattaforma o che non sono state eseguite per un certo periodo richiederà del tempo. Ciò è probabilmente dovuto al fatto che il loro codice è stato portato su un supporto di archiviazione meno accessibile, anche se, come nel caso dei benchmark, la maggior parte dei fornitori non ti parlerà della migrazione dei dati.
Naturalmente, ci sono diversi modi per aggirare questo problema. Il primo è ottimizzare le funzionalità per qualunque linguaggio cloud sia in esecuzione sulla tua piattaforma serverless, ma ciò mina in qualche modo l’affermazione che queste piattaforme siano “agili”.
Un altro approccio consiste nel garantire che i programmi critici per la produttività vengano eseguiti regolarmente per mantenerli aggiornati. Questo secondo approccio, ovviamente, è un po’ in contraddizione con l’affermazione secondo cui le piattaforme serverless sono più convenienti perché si paga solo per il tempo di esecuzione dei programmi. I fornitori di servizi cloud hanno introdotto nuovi modi per ridurre gli avviamenti a freddo, ma molti di essi richiedono la “scala a uno”, il che mina il valore originale del FaaS.
Il problema dell’avvio a freddo può essere parzialmente risolto eseguendo internamente sistemi serverless, ma ciò comporta dei costi e rimane un’opzione di nicchia per i team dotati di risorse adeguate.
Non è possibile eseguire intere applicazioni
Infine, forse il motivo più importante per cui le architetture serverless non sostituiranno presto i modelli tradizionali: (di solito) non possono eseguire intere applicazioni.
Più precisamente, è poco pratico dal punto di vista dei costi. Il tuo monolite di successo probabilmente non dovrebbe essere trasformato in un insieme di quattro dozzine di funzioni collegate da otto gateway, quaranta code e una dozzina di istanze di database. Per questo motivo il serverless è più adatto ai nuovi sviluppi. Quasi nessuna applicazione (architettura) esistente può essere migrata. Puoi migrare, ma devi iniziare da zero.
Ciò significa che nella stragrande maggioranza dei casi, le piattaforme serverless vengono utilizzate come complemento ai server back-end per eseguire attività ad alta intensità di calcolo. Ciò le rende molto diverse dalle altre due forme di tecnologie cloud – contenitori e macchine virtuali – che offrono un modo olistico per eseguire l’elaborazione remota. Ciò illustra una delle sfide legate al passaggio dai microservizi al serverless.
Naturalmente, questo non è sempre un problema. La capacità di sfruttare periodicamente enormi risorse di elaborazione senza dover acquistare il proprio hardware può portare vantaggi reali e duraturi a molte organizzazioni. Ma quando alcune applicazioni risiedono su server interni e altre su architetture cloud serverless, la gestione assume un nuovo livello di complessità.
Lunga vita alla rivoluzione?
Nonostante tutte queste lamentele, non sono contrario alle soluzioni serverless di per sé. Onestamente. Gli sviluppatori devono solo capire, soprattutto se esplorano il serverless per la prima volta, che la tecnologia non sostituisce direttamente i server. Consulta invece i nostri suggerimenti e risorse per e decidere come applicare al meglio il modello.
Fonte: habr.com