Punti chiave
- Da diversi anni ci viene promesso che il calcolo serverless aprirà una nuova era senza un sistema operativo specifico per eseguire applicazioni. Ci è stato detto che tale struttura risolverà molti problemi di scalabilità. In realtà, è tutto diverso.
- Sebbene molti considerino la tecnologia serverless come un'idea nuova, le sue radici risalgono fino al 2006, quando sono emersi Zimki PaaS e Google App Engine — entrambi utilizzano un'architettura senza server.
- Ci sono quattro motivi per cui la rivoluzione serverless è giunta a un punto morto: dal supporto limitato per i linguaggi di programmazione ai problemi di prestazioni.
- Il calcolo serverless non è affatto inutile. Anzi. Tuttavia, non dovrebbe essere considerato come un sostituto diretto dei server. Per alcune applicazioni, può essere uno strumento utile.
Il server è morto, viva il server!
Ecco come suona il grido di battaglia dei proseliti della rivoluzione senza server. È sufficiente dare un'occhiata alla stampa di settore degli ultimi anni per concludere che il modello tradizionale dei server è morto e che tra qualche anno tutti noi utilizzeremo architetture senza server.
Come è noto a chiunque in questo settore, e come abbiamo anche indicato nel nostro articolo su , non è così. Nonostante i numerosi articoli sui vantaggi della , essa non si è mai materializzata. In effetti, , che questa rivoluzione potrebbe essere giunta a un punto morto.
Alcuni dei promesse fatte per i modelli senza server sono state sicuramente realizzate, ma non tutte. Lungi da essere tutte.
In questo articolo voglio esaminare le ragioni di questa situazione. Perché la mancanza di flessibilità dei modelli senza server rimane un ostacolo alla loro adozione più ampia, sebbene essi continuino ad essere utili in circostanze specifiche e ben definite.
Cosa promettevano i sostenitori del cloud senza server
Prima di affrontare le questioni del calcolo serverless, diamo un'occhiata a ciò che avrebbero dovuto offrire. sono state numerose e — a volte — molto ambiziose.
Per coloro che non sono familiari con il termine, ecco una breve definizione. Il calcolo serverless definisce un'architettura in cui le applicazioni (o parti di applicazioni) vengono eseguite su richiesta in ambienti di esecuzione che di solito sono ospitati in remoto. Inoltre, i sistemi serverless possono essere ospitati localmente. Negli ultimi anni, la creazione di sistemi serverless sostenibili è stata una delle principali preoccupazioni per gli amministratori di sistema e le aziende SaaS, poiché (si sostiene) quest'architettura offre diversi vantaggi chiave rispetto al modello “tradizionale” client-server:
- I modelli serverless non richiedono che gli utenti mantengano i propri sistemi operativi o anche che sviluppino applicazioni compatibili con specifici sistemi operativi. Invece, gli sviluppatori creano un codice comune, lo caricano su una piattaforma serverless e ne osservano l'esecuzione.
- Le risorse nei framework serverless sono solitamente addebitate al minuto (o persino al secondo). Ciò significa che i clienti pagano solo per il tempo in cui il loro codice è effettivamente in esecuzione. Questo rappresenta un vantaggio rispetto alla tradizionale VM cloud, dove la macchina rimane inattiva per gran parte del tempo, ma bisogna comunque pagare.
- Anche il problema della scalabilità è stato affrontato. Le risorse nei framework serverless vengono allocate dinamicamente, consentendo al sistema di gestire facilmente improvvisi picchi di domanda.
In breve, i modelli serverless offrono soluzioni flessibili, economiche e scalabili. È sorprendente che non ci sia venuta in mente quest'idea prima.
È davvero un'idea nuova?
In realtà, l'idea non è nuova. Il concetto che permette agli utenti di pagare solo per il tempo durante il quale il codice è effettivamente in esecuzione esiste dal momento in cui è stato introdotto nel contesto di nel 2006, e circa nello stesso periodo Google App Engine ha offerto una soluzione molto simile.
In realtà, ciò che chiamiamo attualmente modello «serverless» è più vecchio di molte tecnologie che oggi vengono definite «cloud native», offrendo risultati quasi simili. Come già accennato, i modelli serverless sono fondamentalmente un'estensione del modello di business SaaS, esistente da decenni.
Va anche detto che il modello serverless non è un'architettura FaaS, anche se c'è una connessione tra i due. FaaS è, sostanzialmente, la parte orientata al calcolo dell'architettura serverless, ma non rappresenta l'intero sistema.
Ma a cosa serve tutta questa confusione? Poiché la velocità di penetrazione di internet nei paesi in via di sviluppo continua ad aumentare rapidamente, cresce anche la domanda di risorse computazionali. Ad esempio, in molti paesi con settori di e-commerce in rapida espansione, non esiste alcuna infrastruttura computazionale per le applicazioni su queste piattaforme. È qui che intervengono le piattaforme serverless a pagamento.
Problemi con i modelli serverless
Il punto è che i modelli serverless presentano… problemi. Non fraintendetemi: non dico che siano intrinsecamente cattivi o che non offrano valore significativo per alcune aziende in certe 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 le applicazioni scritte in determinati linguaggi. Questo limita seriamente 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 forniscono anche un'interfaccia per eseguire applicazioni e funzioni in linguaggi non supportati, sebbene questo comporti spesso un costo in termini di prestazioni. Quindi, per la maggior parte delle organizzazioni, questa limitazione non ha un impatto significativo. Ma ecco il punto. Si presume che uno dei vantaggi dei modelli serverless sia che i programmi poco conosciuti e raramente utilizzati possano essere eseguiti a un costo inferiore, poiché si paga solo per il loro 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.
Lock-in del fornitore
Il secondo problema con le piattaforme serverless, o almeno con il modo in cui vengono implementate attualmente, è che generalmente non si somigliano l'una all'altra a livello operativo. Praticamente non c'è standardizzazione nella scrittura delle funzioni, nel deployment e nella gestione. Questo significa che la migrazione delle funzioni da una piattaforma all'altra richiede un tempo estremamente lungo.
La parte più difficile del passaggio a un modello serverless non sono le funzioni computazionali, che sono generalmente semplici frammenti di codice, ma il modo in cui le applicazioni sono collegate a sistemi esterni, 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'opposto di quanto promesso da piattaforme economiche e flessibili.
Alcuni sostengono che i modelli serverless siano emersi recentemente e che non ci sia stato tempo per standardizzarne il funzionamento. Ma non sono così nuovi come ho già sottolineato prima, e molte altre tecnologie cloud, come i container, sono già diventate molto più pratiche grazie allo sviluppo e all'ampio uso di buoni standard.
Prestazioni
È difficile misurare le prestazioni computazionali delle piattaforme serverless, in parte perché i fornitori tendono a mantenere le informazioni riservate. La maggior parte afferma che le funzioni su piattaforme serverless remote funzionano altrettanto rapidamente quanto sui server interni, tranne per alcuni inevitabili problemi di latenza.
Tuttavia, fatti specifici suggeriscono il contrario. Le funzioni che in precedenza non erano state eseguite su una determinata piattaforma o non venivano eseguite da un po' di tempo necessitano di un certo tempo per l'inizializzazione. Probabilmente ciò è dovuto al fatto che il loro codice è stato trasferito su un supporto dati meno accessibile, anche se, come nel caso dei benchmark, la maggior parte dei fornitori non vi dirà del trasferimento dei dati.
Certo, ci sono diversi modi per aggirare questo problema. Uno di essi consiste nell'ottimizzare le funzioni per qualsiasi linguaggio cloud con cui funziona la vostra piattaforma serverless, ma questo mina un po' l'affermazione che queste piattaforme siano "flessibili".
Un altro approccio consiste nell'assicurare l'esecuzione regolare di programi critici per le prestazioni, affinché rimangano "freschi". Questo secondo approccio, naturalmente, 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 servizi cloud hanno implementato nuovi metodi per ridurre i tempi di avvio a freddo, ma molti di questi richiedono lo "scalare a uno" (scale to one), il che mina il valore iniziale del FaaS.
Il problema del "cold start" può essere parzialmente risolto avviando autonomamente i sistemi serverless, ma questo comporta costi aggiuntivi ed è ancora un'opzione di nicchia per team con risorse ben fornite.
Non puoi avviare intere applicazioni.
Infine, forse la ragione più importante per cui le architetture serverless non sostituiranno i modelli tradizionali nel prossimo futuro: non è (di norma) possibile avviare intere applicazioni.
In realtà, non è conveniente dal punto di vista dei costi. Il tuo monolite di successo probabilmente non vale la pena trasformarlo in un insieme di quarantina di funzioni, collegate da otto gateway, quaranta code e una dozzina di istanze di database. Per questo motivo, la soluzione serverless è più adatta per nuovi sviluppi. Praticamente nessuna applicazione esistente (architettura) può essere migrata. Puoi migrare, ma dovrai ricominciare da zero.
Ciò significa che, nella stragrande maggioranza dei casi, le piattaforme serverless sono utilizzate come integrazione ai server interni per eseguire compiti che richiedono elevate capacità di calcolo. Questo le differenzia notevolmente dalle due altre forme di tecnologie cloud: i contenitori e le macchine virtuali, che offrono un modo integrato per effettuare computazioni remote. Questo illustra una delle difficoltà del passaggio dai microservizi ai sistemi serverless.
Certo, questo non rappresenta sempre un problema. La possibilità di utilizzare periodicamente enormi risorse di calcolo senza dover acquistare hardware proprio può portare vantaggi reali e duraturi per molte organizzazioni. Ma se alcune applicazioni risiedono su server interni e altre su architetture cloud senza server, la gestione diventa notevolmente più complessa.
Viva la rivoluzione?
Nonostante tutte queste lamentele, non sono contrario alle soluzioni senza server in sé. Parola d'onore. Semplicemente, gli sviluppatori devono capire — soprattutto se stanno esplorando per la prima volta i modelli senza server — che questa tecnologia non è un diretto sostituto dei server. Invece, dai un'occhiata ai nostri consigli e risorse per e decidi come applicare al meglio questo modello.
Fonte: habr.com
