Sebbene le tecnologie serverless stiano rapidamente guadagnando popolarità negli ultimi anni, ci sono ancora molti fraintendimenti e preoccupazioni ad esse associate. La dipendenza dal fornitore, gli strumenti, la gestione dei costi, il cold start, il monitoraggio e il ciclo di vita dello sviluppo: tutti questi argomenti vengono ampiamente discussi quando si parla di tecnologie serverless. In questo articolo, esamineremo alcuni di questi temi e condivideremo consigli e link a fonti utili che aiuteranno i neofiti a creare applicazioni serverless potenti, flessibili ed economicamente vantaggiose.
Fraintendimenti sulle tecnologie serverless
Molti credono che la serverless e l'elaborazione dati senza server (, FaaS) siano quasi la stessa cosa. Quindi, la differenza non è poi così grande e vale la pena implementare la novità. Anche se AWS Lambda è stata una delle "stelle" dell'ascesa delle tecnologie serverless e uno degli elementi più popolari dell'architettura serverless, questa architettura rappresenta qualcosa di più del FaaS.
Il principio fondamentale delle tecnologie serverless è che non devi preoccuparti di gestire e scalare l'infrastruttura; paghi solo per ciò che utilizzi. Molti servizi rientrano in questi criteri: AWS DynamoDB, S3, SNS o SQS, Graphcool, Auth0, Now, Netlify, Firebase e molti altri. In generale, la serverless implica l'utilizzo di tutte le possibilità del cloud computing senza necessità di gestire l'infrastruttura e ottimizzarla per la scalabilità. Ciò significa anche che la sicurezza a livello di infrastruttura non è più un tuo problema, il che è un enorme vantaggio considerando la difficoltà e la complessità nel rispetto degli standard di sicurezza. Infine, non devi acquistare l'infrastruttura che ti viene fornita in uso.
La serverless può essere considerata uno "stato mentale": una certa mentalità nella progettazione delle soluzioni. Evita gli approcci che richiedono la manutenzione di qualsiasi infrastruttura. Con l'approccio serverless, ci concentriamo sulle attività che influiscono direttamente sul progetto e portano benefici ai nostri utenti: creiamo logiche aziendali sostenibili, sviluppiamo interfacce utente e sviluppiamo API adattive e affidabili.
Ad esempio, se possiamo evitare la gestione e il supporto della piattaforma di ricerca a testo libero, è esattamente ciò che faremo. Questo approccio alla creazione delle applicazioni può accelerare notevolmente il lancio del prodotto sul mercato, poiché non è più necessario preoccuparsi di gestire un'infrastruttura complessa. Liberatevi delle responsabilità e dei costi di gestione dell'infrastruttura e concentratevi sulla creazione di applicazioni e servizi necessari ai vostri clienti. Patrick Debois ha definito questo approccio , questo termine è accettato nella comunità serverless. Le funzioni devono essere considerate come un legame per i servizi sotto forma di moduli distribuiti (anziché distribuire un'intera libreria o un'applicazione web). Questo garantisce una straordinaria granularità nella gestione delle distribuzioni e nelle modifiche alle applicazioni. Se non è possibile distribuire le funzioni in questo modo, potrebbe significare che le funzioni stanno svolgendo troppe attività e dovrebbero essere rifattorizzate.
Alcuni sono preoccupati per la dipendenza dal fornitore nella sviluppo di applicazioni cloud. Lo stesso vale per le tecnologie serverless, e difficilmente si tratta di un'illusione. Dalla nostra esperienza, la creazione di applicazioni serverless su AWS, unita alla capacità di AWS Lambda di integrare altri servizi AWS, contribuisce in parte ai vantaggi delle architetture serverless. Questo è un buon esempio di sinergia, in cui il risultato dell'unione è maggiore della semplice somma delle parti. Cercando di evitare la dipendenza da un fornitore, potresti trovarti di fronte a problemi ancora maggiori. Lavorando con i container, è più facile gestire il proprio livello di astrazione tra i fornitori di cloud. Ma quando si tratta di soluzioni serverless, gli sforzi non ripagheranno, specialmente se si considera l'efficacia economica fin dall'inizio. Assicurati di scoprire come i fornitori garantiscano la fornitura dei servizi. Alcuni servizi specializzati dipendono da punti di integrazione con altri fornitori, e possono offrire, out of the box, la possibilità di collegamenti in stile plug-and-play. È più semplice chiamare Lambda da un endpoint dell'API gateway che fare un proxy di una richiesta a un container o a un'istanza EC2. Graphcool offre una semplice configurazione con Auth0, il che è più semplice che utilizzare strumenti di autenticazione di terze parti.
La scelta del fornitore giusto per la tua applicazione serverless è una decisione a livello architettonico. Quando crei un'applicazione, non ti aspetti mai di tornare a gestire server. Scegliere un fornitore cloud non è diverso dal decidere di utilizzare container, database, o persino un linguaggio di programmazione.
Pensa a:
- Quali servizi ti servono e perché.
- Quali servizi offrono i fornitori di cloud e come puoi integrarli con la tua soluzione FaaS scelta.
- Quali linguaggi di programmazione sono supportati (con tipizzazione dinamica o statica, compilati o interpretati, quali benchmarks esistono, quale è la prestazione al primo avvio, qual è l'ecosistema open source, ecc.).
- Quali sono i tuoi requisiti di sicurezza (SLA, 2FA, OAuth, HTTPS, SSL, ecc.).
- Come gestire il tuo CI/CD e i cicli di sviluppo software.
- Quali vantaggi puoi ottenere dalle soluzioni di tipo infrastructure-as-code.
Se stai ampliando un'applicazione esistente e aggiungendo funzioni serverless in modo incrementale, questo potrebbe limitare alcune delle capacità disponibili. Tuttavia, quasi tutte le tecnologie serverless offrono delle API (tramite REST o code di messaggi) che consentono di creare estensioni in modo indipendente dal core dell'applicazione e con un'integrazione semplice. Cerca servizi con API chiare, una buona documentazione e una comunità forte, e non ti sbaglierai. La semplicità dell'integrazione è spesso una metrica chiave, e probabilmente è una delle ragioni principali del successo di AWS da quando nel 2015 è stata lanciata Lambda.
Quando è utile il serverless
Le tecnologie serverless possono essere applicate praticamente ovunque. Tuttavia, i loro vantaggi non si limitano solo ai casi d'uso. La soglia d'ingresso per il cloud computing è così bassa proprio grazie alle tecnologie serverless. Se gli sviluppatori hanno un'idea, ma non sanno come gestire l'infrastruttura cloud e ottimizzare i costi, non devono cercare un ingegnere per farlo. Se una startup vuole creare una piattaforma, ma teme che i costi possano sfuggire al controllo, può facilmente rivolgersi a soluzioni serverless.
Grazie al risparmio sui costi e alla facilità di scalabilità, le soluzioni serverless possono essere applicate sia ai sistemi interni che a quelli esterni, fino a un'applicazione web con milioni di utenti. Le fatture si misurano più in centesimi che in euro. L'affitto della più semplice istanza AWS EC2 (t1.micro) per un mese costerà €15, anche se non fai nulla con essa (chi non ha mai dimenticato di spegnerla?!). Per confronto, per raggiungere lo stesso livello di spesa nello stesso periodo di tempo, dovresti eseguire Lambda con 512 MB per 1 secondo circa 3 milioni di volte. E se non utilizzi questa funzione, non paghi nulla.
Poiché la tecnologia serverless dipende principalmente dagli eventi, è piuttosto semplice aggiungere un'infrastruttura serverless a sistemi vecchi. Ad esempio, con AWS S3, Lambda e Kinesis puoi creare un servizio di analisi per un vecchio sistema di vendita al dettaglio, in grado di ricevere dati tramite API.
La maggior parte delle piattaforme serverless supporta vari linguaggi. I più comuni sono Python, JavaScript, C#, Java e Go. Di solito, non ci sono restrizioni sull'uso delle librerie in nessuno di questi linguaggi, quindi puoi utilizzare le tue librerie open source preferite. Tuttavia, è consigliabile non esagerare con le dipendenze, affinché le tue funzioni vengano eseguite in modo ottimale e non annullino i vantaggi di un'ampia scalabilità delle tue applicazioni serverless. Più pacchetti devono essere caricati nel contenitore, più lungo sarà il tempo di avvio a freddo.
L'avvio a freddo è quando è necessario prima inizializzare il contenitore, l'ambiente di esecuzione e il gestore degli errori, prima di poterli utilizzare. A causa di ciò, il ritardo nell'esecuzione delle funzioni può arrivare fino a 3 secondi, il che non è ideale per gli utenti impazienti. Tuttavia, gli avvii a freddo si verificano al primo accesso dopo alcuni minuti di inattività della funzione. Molti considerano questo un inconveniente minore, che può essere aggirato con il ping regolare della funzione per tenerla in standby. Oppure se ne ignorano del tutto.
Sebbene AWS abbia rilasciato, le basi dati SQL non sono ideali per questo tipo di utilizzo, poiché durante l'esecuzione delle transazioni dipendono dalle connessioni, che possono rapidamente diventare un collo di bottiglia con grande traffico su AWS Lambda. Sì, gli sviluppatori stanno continuamente migliorando Serverless Aurora e dovresti fare delle sperimentazioni con essa, tuttavia oggi le soluzioni NoSQL comesi adattano molto meglio ai sistemi serverless. Tuttavia, è certo che questa situazione cambierà molto presto.
Anche gli strumenti impongono molte limitazioni, soprattutto nel campo del testing locale. Sebbene esistano soluzioni come Docker-Lambda, DynamoDB Local e LocalStack, esse richiedono un lavoro meticoloso e una notevole quantità di configurazione. Tuttavia, tutti questi progetti sono in continua evoluzione, quindi è solo una questione di tempo prima che gli strumenti raggiungano il livello necessario.
L'impatto delle tecnologie serverless sul ciclo di sviluppo
Poiché la tua infrastruttura è semplicemente una configurazione, puoi definire e distribuire codice utilizzando script, come gli script shell. Oppure puoi ricorrere a soluzioni del tipo configuration-as-code come . Anche se questo servizio non offre una configurazione per tutti i settori, consente di definire risorse specifiche da utilizzare come funzioni Lambda. Cioè, dove CloudFormation potrebbe mancarti, puoi scrivere la tua risorsa (funzione Lambda) per colmare questa lacuna. In questo modo, puoi fare qualsiasi cosa, anche configurare dipendenze al di fuori del tuo ambiente AWS.
Poiché tutto ciò è semplicemente una configurazione, puoi parametrizzare i tuoi script di distribuzione per ambienti, regioni e utenti specifici, specialmente se utilizzi soluzioni di tipo infrastructure-as-code come CloudFormation. Ad esempio, puoi distribuire una copia dell'infrastruttura per ogni branch nel repository, per testarle in modo completamente isolato durante lo sviluppo. Questo accelera radicalmente il feedback per gli sviluppatori quando vogliono verificare se il loro codice funziona correttamente in un ambiente reale. I manager non devono preoccuparsi dei costi legati alla distribuzione di numerosi ambienti, poiché si paga solo per l'uso effettivo.
I DevOps hanno meno preoccupazioni, poiché devono solo assicurarsi che gli sviluppatori abbiano la configurazione corretta. Non è più necessario gestire istanze, bilanciatori di carico o gruppi di sicurezza. Ecco perché il termine NoOps viene utilizzato sempre più frequentemente, anche se è comunque importante sapere come configurare l'infrastruttura, specialmente quando si tratta di configurazione IAM e ottimizzazione delle risorse cloud.
Ci sono strumenti molto potenti per il monitoraggio e la visualizzazione come Epsagon, Thundra, Dashbird e IOPipe. Questi consentono di monitorare lo stato attuale delle applicazioni serverless, forniscono registri e tracciamento, registrano metriche di performance e colli di bottiglia architettonici, effettuano analisi e previsioni delle spese, e molto altro. Non solo offrono agli ingegneri DevOps, agli sviluppatori e agli architetti una visione completa delle operazioni delle applicazioni, ma consentono anche ai manager di monitorare la situazione in tempo reale, con spese per le risorse calcolate al secondo e previsioni dei costi. Organizzare tutto ciò con un'infrastruttura gestita è molto più difficile.
Progettare applicazioni serverless è molto più semplice, poiché non è necessario distribuire server web, gestire macchine virtuali o contenitori, aggiornare server, sistemi operativi, gateway e così via. L'astrazione da tutte queste responsabilità consente all'architettura serverless di concentrarsi su ciò che è veramente importante: soddisfare le esigenze del business e dei clienti.
Sebbene l'insieme di strumenti possa essere migliorato (si evolve ogni giorno), gli sviluppatori possono concentrarsi sull'implementazione della logica aziendale e sulla migliore distribuzione della complessità dell'applicazione sui vari servizi all'interno dell'architettura. La gestione delle applicazioni serverless avviene in base a eventi ed è astratta dal provider cloud (come SQS, eventi S3 o stream DynamoDB). Perciò, gli sviluppatori devono solo scrivere la logica aziendale per reagire a determinati eventi, senza preoccuparsi di come implementare al meglio i database e le code di messaggi o di come ottimizzare il lavoro con i dati nei rispettivi storage hardware.
Il codice può essere eseguito e debugato localmente, così come in qualsiasi processo di sviluppo. Il testing modulare rimane invariato. La possibilità di distribuire un'intera infrastruttura applicativa tramite una configurazione personalizzata dello stack consente agli sviluppatori di ricevere feedback importanti rapidamente, senza preoccuparsi del costo dei test o dell'impatto su costose ambienti gestiti.
Strumenti e metodologie per costruire applicazioni serverless
Non esiste un modo specifico per costruire applicazioni serverless, così come non esiste un set di servizi per questa attività. Oggi, AWS è leader tra le potenti soluzioni serverless, ma presta attenzione anche a , e . Se utilizzi AWS, come approccio per costruire applicazioni puoi considerare il (SAM), specialmente se utilizzi C#, poiché Visual Studio offre strumenti eccellenti. SAM CLI può fare tutto ciò che fa Visual Studio, quindi non perderai nulla se decidi di passare a un altro IDE o editor di testo. Naturalmente, SAM funziona anche con altri linguaggi.
Se scrivi in altre lingue, Serverless Framework è un eccellente strumento open source che consente di configurare qualsiasi cosa utilizzando file di configurazione YAML molto potenti. Inoltre, Serverless Framework supporta diversi servizi cloud, quindi lo raccomandiamo a chi cerca una soluzione multi-cloud. Ha una vasta comunità che ha creato una miriade di plugin per ogni esigenza.
Per il testing locale, gli strumenti open source Docker-Lambda, Serverless Local, DynamoDB Local e LocalStack sono molto adatti. Le tecnologie serverless sono ancora in fase iniziale di sviluppo, così come gli strumenti per esse, quindi configurare scenari di testing complessi richiederà un certo impegno. Tuttavia, è incredibilmente economico semplicemente distribuire un stack in un ambiente e testarlo lì. E non è necessario creare una copia locale esatta degli ambienti cloud.
Per ridurre le dimensioni dei pacchetti distribuiti e accelerare i caricamenti, utilizza AWS Lambda Layers.
Utilizza i linguaggi di programmazione appropriati per compiti specifici. Ogni linguaggio ha i suoi vantaggi e svantaggi. Ci sono molti benchmark, ma JavaScript, Python e C# (.NET Core 2.1+) sono leader in termini di prestazioni su AWS Lambda. Recentemente, AWS Lambda ha introdotto il Runtime API, che consente di specificare il linguaggio desiderato e l'ambiente di esecuzione, quindi sperimenta.
Mantieni piccole le dimensioni dei pacchetti per la distribuzione. Più sono piccoli, più velocemente si caricano. Evita di utilizzare librerie grandi, specialmente se utilizzi solo un paio di funzionalità da esse. Se programmi in JavaScript, utilizza strumenti di build come Webpack per ottimizzare il build e includere solo ciò di cui hai veramente bisogno. In .NET Core 3.0 ci sono QuickJit e Tiered Compilation, che migliorano le prestazioni e aiutano notevolmente con i lean launch.
La dipendenza delle funzioni serverless dagli eventi può inizialmente complicare il coordinamento della logica aziendale. In questo contesto, le code dei messaggi e le macchine a stati finiti possono rivelarsi incredibilmente utili. Le funzioni Lambda possono invocarsi a vicenda, ma è consigliabile farlo solo se non ci si aspetta una risposta ('sparato e dimenticato') — non si desidera ricevere una fattura per l'attesa del completamento di un'altra funzione. Le code dei messaggi sono utili per isolare parti della logica aziendale, gestire i colli di bottiglia delle applicazioni e trattare le transazioni (utilizzando code FIFO). Le funzioni AWS Lambda possono essere collegate a code SQS come code di messaggi 'in attesa', che monitorano i messaggi non riusciti per analisi successive. Le funzioni AWS Step Functions (macchine a stati finiti) sono molto utili per gestire processi complessi che richiedono la creazione di catene di funzioni. Invece di invocare un'altra funzione, le Step Functions possono coordinare le transizioni di stato, trasferire dati tra le funzioni e gestire lo stato globale delle funzioni. Questo consente di definire le condizioni per i tentativi di ripetizione o cosa fare in caso di errori specifici — un potente strumento in determinate situazioni.
Conclusione
Negli ultimi anni, le tecnologie serverless si sono sviluppate a ritmi senza precedenti. Questa transizione di paradigma è associata a determinati fraintendimenti. Grazie all'astrazione dell'infrastruttura e alla gestione della scalabilità, le soluzioni serverless offrono vantaggi significativi: dalla semplificazione dello sviluppo e dei processi DevOps, fino a una notevole riduzione dei costi operativi.
E sebbene l'approccio serverless non sia privo di svantaggi, esistono tecniche affidabili e modelli di progettazione che consentono di creare applicazioni serverless resilienti o integrare elementi serverless in architetture esistenti.
Fonte: habr.com
