Punti chiave
- Da diversi anni ci viene promesso che il calcolo senza server (serverless) aprirà una nuova era senza un sistema operativo specifico per l'esecuzione delle applicazioni. Ci è stato detto che tale struttura risolverà molti problemi di scalabilità. In realtà, non è affatto così.
- Sebbene molti considerino la tecnologia serverless come una nuova idea, le sue radici possono essere rintracciate fino al 2006, con l'arrivo di Zimki PaaS e Google App Engine: in entrambi i casi viene utilizzata un'architettura senza server.
- Ci sono quattro motivi per cui la rivoluzione serverless si è bloccata: dal supporto limitato per i linguaggi di programmazione ai problemi di prestazioni.
- Il calcolo serverless non è così inutile. Per niente. Tuttavia, non dovrebbe essere visto come una sostituzione diretta dei server. Per alcune applicazioni, può essere uno strumento utile.
Il server è morto, lunga vita al server!
Questa è la fama degli adepti della rivoluzione serverless. Basta dare un'occhiata veloce alla stampa di settore degli ultimi anni per arrivare facilmente alla conclusione che il modello server tradizionale è morto e che tra qualche anno tutti noi useremo architetture serverless.
Come sanno tutti nel settore, e come abbiamo anche indicato nel nostro articolo su , non è così. Nonostante i numerosi articoli sui vantaggi , essa non si è ancora realizzata. Infatti, , che questa rivoluzione potrebbe essere andata in stallo.
Alcune delle promesse per i modelli serverless sono state sicuramente realizzate, ma non tutte. Lontano dal poter dire tutte.
In questo articolo voglio esaminare le ragioni di questa situazione. Perché la mancanza di flessibilità dei modelli serverless continua a essere un ostacolo alla loro adozione più ampia, anche se rimangono utili in circostanze specifiche e ben definite.
Cosa promettevano gli adepti del calcolo serverless
Prima di passare ai problemi del calcolo serverless, diamo un'occhiata a cosa avrebbero dovuto fornire. erano numerose e – a volte – molto ambiziose.
Per coloro che non conoscono il termine, ecco una breve definizione. Il calcolo serverless definisce un'architettura in cui le applicazioni (o parti di esse) vengono eseguite su richiesta in ambienti di esecuzione che di solito sono ospitati in remoto. Inoltre, i sistemi serverless possono essere ospitati internamente. Negli ultimi anni, la creazione di sistemi serverless sostenibili è stata la principale preoccupazione degli amministratori di sistema e delle aziende SaaS, poiché (come affermato) questa architettura offre diversi vantaggi chiave rispetto al modello client-server "tradizionale":
- I modelli serverless non richiedono che gli utenti mantengano i propri sistemi operativi o addirittura creino applicazioni compatibili con specifici OS. Invece, gli sviluppatori scrivono codice comune, lo caricano su una piattaforma serverless e ne osservano l'esecuzione.
- Le risorse nei framework serverless sono solitamente addebitate al minuto (o anche al secondo). Ciò significa che i clienti pagano solo per il tempo in cui il codice viene effettivamente eseguito. Questo si distingue vantaggiosamente dal tradizionale VM cloud, dove la macchina rimane inattiva per gran parte del tempo, ma deve essere comunque pagata.
- Anche il problema della scalabilità è stato risolto. Le risorse nei framework serverless vengono allocate dinamicamente, in modo che il sistema gestisca facilmente picchi improvvisi di domanda.
In breve, i modelli serverless offrono soluzioni flessibili, economiche e scalabili. È sorprendente che non abbiamo pensato a quest'idea prima.
È davvero un'idea nuova?
In realtà, l'idea non è nuova. Il concetto che consente agli utenti di pagare solo per il tempo in cui il codice viene effettivamente eseguito esiste fin da quando è stato introdotto con nel 2006, e circa nello stesso periodo Google App Engine ha offerto una soluzione molto simile.
In effetti, ciò che chiamiamo ora modello "serverless" è più vecchio di molte tecnologie che ora vengono definite "cloud native", e che offrono quasi la stessa cosa. Come già osservato, i modelli serverless sono in sostanza solo un'estensione del modello di business SaaS, che esiste già da alcuni decenni.
È importante riconoscere che il modello serverless non è necessariamente architettura FaaS, anche se c'è una connessione tra i due. FaaS è, in sostanza, la parte della architettura serverless orientata al calcolo, ma non rappresenta l'intero sistema.
Quindi, a cosa serve tutto questo rumore? Beh, dato che la velocità di penetrazione di Internet nei paesi in via di sviluppo continua a crescere rapidamente, cresce anche la domanda di risorse computazionali. Ad esempio, in molti paesi con settori di e-commerce in rapida crescita, semplicemente non esiste l'infrastruttura computazionale per le applicazioni su queste piattaforme. Qui entrano in gioco le piattaforme serverless a pagamento.
Problemi dei modelli serverless
Il problema è che i modelli serverless hanno... problemi. Non fraintendetemi: non sto dicendo che siano cattivi di per sé o che non offrano un valore significativo per alcune aziende in determinate circostanze. Ma l'affermazione principale della "rivoluzione" — che l'architettura serverless sostituirà rapidamente quella tradizionale — non si realizzerà mai.
Ecco perché.
Supporto limitato per i linguaggi di programmazione
La maggior parte delle piattaforme serverless consente di eseguire solo quelle applicazioni scritte in determinati linguaggi. Questo limita gravemente la flessibilità e l’adattabilità di questi sistemi.
Si ritiene che le piattaforme serverless supportino la maggior parte dei linguaggi principali. AWS Lambda e Azure Functions offrono anche un wrapper per eseguire applicazioni e funzioni in linguaggi non supportati, sebbene ciò comporti spesso costi in termini di prestazioni. Pertanto, per la maggior parte delle organizzazioni, di solito questa limitazione non è di grande importanza. Ma ecco il punto. Si presume che uno dei vantaggi dei modelli serverless sia che i programmi poco conosciuti e raramente utilizzati possono essere impiegati in modo più economico, poiché paghi solo per il tempo di esecuzione. E i programmi poco conosciuti e raramente utilizzati sono spesso scritti in... linguaggi di programmazione poco conosciuti e raramente utilizzati.
Questo mina uno dei principali vantaggi del modello serverless.
Vincolo al fornitore
Il secondo problema delle piattaforme serverless, o almeno di come vengono implementate attualmente, è che di solito non si assomigliano a livello operativo. Praticamente non esiste standardizzazione nella scrittura delle funzioni, nel deploy e nella gestione. Questo significa che la migrazione delle funzioni da una piattaforma all'altra richiede un tempo estremamente lungo.
La parte più difficile della transizione a un modello serverless non sono le funzioni computazionali, che di solito sono semplici frammenti di codice, ma il modo in cui le applicazioni sono collegate a sistemi connessi, come lo storage degli oggetti, la gestione dell'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 emersi di recente e che non ci sia stato il tempo di standardizzare il loro funzionamento. Ma non sono poi così nuovi, come ho già notato sopra, e molte altre tecnologie cloud, come i container, sono già diventate molto più pratiche grazie allo sviluppo e alla diffusione di buoni standard.
Prestazioni
È difficile misurare le performance computazionali delle piattaforme serverless, in parte perché i fornitori tendono a mantenere le informazioni riservate. La maggior parte sostiene che le funzioni su piattaforme serverless remote funzionano altrettanto velocemente quanto sui server interni, tranne per alcuni inevitabili problemi di latenza.
Tuttavia, alcuni fatti indicano il contrario. Funzioni che non sono state eseguite su una determinata piattaforma o che non sono state eseguite per un certo periodo richiedono del tempo per l'inizializzazione. Probabilmente questo è dovuto al fatto che il loro codice è stato trasferito su un supporto dati meno accessibile, sebbene - come nel caso dei benchmark - la maggior parte dei fornitori non vi dirà nulla sul trasferimento dei dati.
Certo, ci sono diversi modi per aggirare questo. Uno di essi consiste nell'ottimizzare le funzioni per qualsiasi linguaggio cloud su cui opera la vostra piattaforma serverless, ma questo in parte mina l'affermazione che queste piattaforme siano "flessibili".
Un altro approccio consiste nel garantire l'esecuzione regolare di programmi critici per le prestazioni, affinché rimangano "freschi". Questo secondo approccio, ovviamente, contraddice un po' l'affermazione che le piattaforme serverless siano più economiche, poiché si paga solo per il tempo di esecuzione dei propri programmi. I fornitori di cloud hanno implementato nuovi metodi per ridurre i cold start, ma molti di essi richiedono uno "scalare a uno" (scale to one), il che mina il valore iniziale di FaaS.
Il problema del "cold start" può essere in parte risolto avviando sistemi serverless autonomamente, ma ciò comporta costi propri e rimane un'opzione di nicchia per team ben forniti di risorse.
Non puoi eseguire intere applicazioni
Infine, forse la ragione più importante per cui le architetture serverless non sostituiranno i modelli tradizionali nel prossimo futuro: in genere non è possibile eseguire intere applicazioni su di esse.
Più precisamente, non è economicamente vantaggioso. Il tuo monolite di successo probabilmente non vale la pena trasformarlo in un insieme di quattro dozzine di funzioni collegate da otto gateway, quaranta code e una dozzina di istanze di DB. Per questo motivo, il serverless è più adatto per nuove sviluppi. Praticamente nessuna applicazione esistente (architettura) può essere trasferita. Puoi migrare, ma dovrai ricominciare da capo.
Ciò significa che nella stragrande maggioranza dei casi, le piattaforme serverless sono utilizzate come complemento ai server interni per eseguire compiti che richiedono elevate capacità di calcolo. Questo le differenzia nettamente dalle altre due forme di tecnologie cloud — container e macchine virtuali, che offrono un modo completo per eseguire calcoli remoti. Questo illustra una delle difficoltà nel passare dai microservizi ai sistemi serverless.
Certo, non sempre rappresenta un problema. La possibilità di utilizzare occasionalmente enormi risorse di calcolo senza acquistare hardware proprio può portare a reali benefici duraturi per molte organizzazioni. Ma quando alcune applicazioni sono su server interni e altre su architetture cloud senza server, la gestione diventa più complessa.
Viva la rivoluzione?
Nonostante tutte queste lamentele, non sono contro le soluzioni senza server in quanto tali. Parola di onore. Semplicemente, gli sviluppatori devono capire - soprattutto se stanno esplorando i modelli senza server per la prima volta - che questa tecnologia non è un sostituto diretto dei server. Invece, consulta i nostri consigli e risorse su e decidi come applicare al meglio questo modello.
Fonte: habr.com
