Sebbene le tecnologie serverless stiano guadagnando rapidamente 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 temi sono oggetto di discussione quando si parla di tecnologie serverless. In questo articolo esamineremo alcuni di questi argomenti e condivideremo consigli e collegamenti a risorse utili per aiutare i neofiti a creare applicazioni serverless potenti, flessibili ed economiche.
Fraintendimenti sulle tecnologie serverless
Molti pensano che serverless e elaborazione dati without servers (, FaaS) siano praticamente la stessa cosa. Significa che la differenza non è molto ampia e vale la pena implementare questa novità. Sebbene AWS Lambda sia stata una delle 'stelle' della fioritura delle tecnologie serverless e uno degli elementi più popolari dell'architettura serverless, tuttavia, questa architettura rappresenta qualcosa di più del semplice FaaS.
Il principio fondamentale delle tecnologie serverless è che non devi preoccuparti della gestione e della scalabilità dell'infrastruttura, paghi solo per ciò che usi. Molti servizi rientrano in questi criteri: AWS DynamoDB, S3, SNS o SQS, Graphcool, Auth0, Now, Netlify, Firebase e molti altri. In generale, serverless implica utilizzare tutte le potenzialità del cloud computing senza la necessità di gestire e ottimizzare l'infrastruttura per scalare. Significa anche che la sicurezza a livello di infrastruttura non è più un tuo problema, il che rappresenta un enorme vantaggio, considerando la difficoltà e la complessità di conformarsi agli standard di sicurezza. Infine, non devi acquistare l'infrastruttura messa a tua disposizione.
Il serverless può essere considerato uno 'stato mentale': una certa mentalità nella progettazione delle soluzioni. Evita approcci che richiedono la manutenzione di qualsiasi infrastruttura. Con un approccio serverless, dedichiamo il nostro tempo a risolvere problemi che hanno un impatto diretto sul progetto e portano vantaggi ai nostri utenti: creiamo logiche di business solide, sviluppiamo interfacce utente e sviluppiamo API reattive e affidabili.
Ad esempio, se possiamo evitare la gestione e il supporto di una piattaforma di ricerca testuale, è esattamente quello che faremo. Questo approccio alla costruzione delle applicazioni può accelerare notevolmente il time-to-market, poiché non devi più pensare alla gestione di un'infrastruttura complessa. Liberati delle responsabilità e dei costi di gestione dell'infrastruttura e concentrati sulla creazione di applicazioni e servizi che i tuoi clienti desiderano. Patrick Debois ha definito questo approccio , questo termine è accettato nella comunità serverless. Le funzioni devono essere considerate come un collegamento tra servizi, sotto forma di moduli distribuiti (anziché distribuire un'intera libreria o un'app web). Questo garantisce una incredibile granularità nella gestione delle distribuzioni e delle modifiche all'applicazione. Se non riesci a distribuire funzioni in questo modo, potrebbe significare che le funzioni stanno svolgendo troppi compiti e devono essere rifattorizzate.
Alcuni sono confusi dalla dipendenza dal fornitore nello sviluppo di applicazioni cloud. Lo stesso vale per le tecnologie serverless e difficilmente è il risultato di un fraintendimento. Dalla nostra esperienza, sviluppare applicazioni serverless su AWS, insieme alla capacità di AWS Lambda di integrare altri servizi AWS, contribuisce in parte alle virtù delle architetture serverless. Questo è un buon esempio di sinergia, dove il risultato dell'unione è maggiore della somma dei singoli elementi. Cercare di evitare la dipendenza dal fornitore potrebbe portarti a problemi ancora maggiori. Quando lavori con i container, è più facile gestire il tuo livello di astrazione tra diversi fornitori cloud. Ma quando si tratta di soluzioni serverless, gli sforzi non ripagheranno, soprattutto se consideri fin dall'inizio l'efficienza economica. Assicurati di scoprire come i fornitori garantiscono la fornitura dei servizi. Alcuni servizi specializzati dipendono dai punti di integrazione con altri fornitori e possono fornire funzionalità plug-and-play out of the box. È più semplice invocare Lambda da un punto finale del gateway API che inoltrare una richiesta a un container o a un'istanza EC2. Graphcool offre una semplice configurazione con Auth0, il che è più facile che utilizzare strumenti di autenticazione di terze parti.
La scelta del fornitore giusto per la tua applicazione serverless è una decisione architettonica. Quando crei un'applicazione, non ti aspetti di tornare mai più alla gestione dei server. La scelta del fornitore cloud non è diversa dalla scelta di utilizzare contenitori, un database o persino un linguaggio di programmazione.
Considera:
- Quali servizi ti servono e perché.
- Quali servizi offrono i fornitori cloud e come puoi combinarli utilizzando la tua soluzione FaaS scelta.
- Quali linguaggi di programmazione sono supportati (con tipizzazione dinamica o statica, compilati o interpretati, quali sono i benchmark, che prestazioni ha al primo avvio, quale è 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 del software.
- Quali vantaggi delle soluzioni di tipo infrastructure-as-code puoi sfruttare.
Se stai espandendo un'applicazione esistente e aggiungendo funzionalità serverless in modo incrementale, questo potrebbe limitare alcune opzioni disponibili. Tuttavia, praticamente tutte le tecnologie serverless offrono API (tramite REST o code di messaggi) che consentono di creare estensioni in modo indipendente dal core dell'applicazione e con una facile integrazione. Cerca servizi con API chiare, una buona documentazione e una comunità forte, e non sbaglierai. La semplicità di integrazione può spesso essere una metrica chiave ed è probabilmente una delle principali ragioni del successo di AWS da quando Lambda è stato lanciato nel 2015.
Quando è utile il serverless
Le tecnologie serverless possono essere applicate praticamente ovunque. Tuttavia, i loro vantaggi non si limitano solo a casi d'uso. La barriera di ingresso per l'informatica cloud è così bassa 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 desidera creare una piattaforma ma ha paura che i costi possano sfuggire al controllo, può tranquillamente optare per soluzioni serverless.
Grazie al risparmio sui costi e alla facilità di scalabilità, le soluzioni serverless sono applicabili sia per sistemi interni che esterni, fino a web application con milioni di utenti. Le fatture sono più spesso misurate in centesimi piuttosto che in euro. L'affitto dell'istanza più semplice di AWS EC2 (t1.micro) per un mese costerà €15, anche se non fai nulla (chi non ha mai dimenticato di spegnerla?!). Per fare un paragone, per raggiungere lo stesso livello di spesa nello stesso periodo di tempo, dovresti eseguire Lambda di 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 facile aggiungere un'infrastruttura serverless nei sistemi esistenti. Ad esempio, utilizzando AWS S3, Lambda e Kinesis, puoi creare un servizio di analisi per un antico sistema di vendita al dettaglio che può ricevere dati tramite API.
La maggior parte delle piattaforme serverless supportano diversi linguaggi. Spesso si tratta di Python, JavaScript, C#, Java e Go. Di solito, non ci sono limitazioni nell'uso delle librerie in nessun linguaggio, quindi puoi utilizzare le tue librerie open source preferite. Tuttavia, è preferibile non abusare delle dipendenze affinché le tue funzioni vengano eseguite in modo ottimale e non annullino i vantaggi dell'enorme scalabilità delle tue applicazioni serverless. Più pacchetti devi caricare nel contenitore, più a lungo richiederà l'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 è l'ideale per gli utenti impazienti. Tuttavia, gli avvii a freddo si verificano alla prima chiamata dopo alcuni minuti di inattività della funzione. Pertanto, molti considerano questo un inconveniente marginale che può essere eluso mantenendo regolarmente la funzione in esecuzione a vuoto. Oppure lo ignorano del tutto.
Sebbene AWS abbia rilasciato, tuttavia, i database SQL non sono ideali per questo tipo di applicazione, poiché, durante l'esecuzione delle transazioni, dipendono dalle connessioni, che possono rapidamente diventare un collo di bottiglia in caso di un alto traffico su AWS Lambda. Sì, gli sviluppatori stanno costantemente migliorando Serverless Aurora, e dovreste sperimentare con essa, ma oggi le soluzioni NoSQL comesono sicuramente molto più adatte per sistemi serverless. Comunque, è indubbio che questa situazione cambierà presto.
Gli strumenti impongono anche molte limitazioni, specialmente per quanto riguarda il testing locale. Anche se ci sono soluzioni come Docker-Lambda, DynamoDB Local e LocalStack, richiedono un lavoro meticoloso e una configurazione significativa. Tuttavia, tutti questi progetti stanno evolvendo attivamente, quindi è solo una questione di tempo prima che gli strumenti raggiungano il livello di cui abbiamo bisogno.
L'impatto delle tecnologie serverless sul ciclo di sviluppo
Poiché la vostra infrastruttura è semplicemente una configurazione, è possibile definire e distribuire il codice utilizzando script, come gli script shell. Oppure si possono utilizzare soluzioni di tipo configuration-as-code come . Sebbene questo servizio non fornisca una configurazione per tutte le aree, consente di definire risorse specifiche da utilizzare come funzioni Lambda. Quindi, dove CloudFormation potrebbe deludervi, potete scrivere la vostra risorsa (funzione Lambda) per colmare questa lacuna. In questo modo, potete fare qualsiasi cosa, persino configurare dipendenze al di fuori del vostro ambiente AWS.
Poiché tutto ciò è semplicemente una configurazione, potete parametricizzare i vostri script di distribuzione per ambienti, regioni e utenti specifici, specialmente se utilizzate soluzioni di tipo infrastructure-as-code come CloudFormation. Ad esempio, potete distribuire una copia dell'infrastruttura per ogni ramo del repository, per testarle completamente isolate durante lo sviluppo. Questo accelera radicalmente il feedback per gli sviluppatori, quando vogliono capire se il loro codice funziona correttamente nell'ambiente reale. I responsabili non devono preoccuparsi dei costi di 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 una configurazione corretta. Non è più necessario gestire istanze, bilanciatori o gruppi di sicurezza. Perciò, è sempre più frequente l'uso del termine NoOps, anche se è ancora importante sapere come configurare l'infrastruttura, soprattutto per quanto riguarda la configurazione IAM e l'ottimizzazione delle risorse cloud.
Ci sono strumenti molto potenti per il monitoraggio e la visualizzazione, come Epsagon, Thundra, Dashbird e IOPipe. Questi strumenti consentono di monitorare lo stato attuale delle applicazioni serverless, forniscono log e tracciamento, registrano metriche di performance e colli di bottiglia architetturali, eseguono analisi e previsioni di costi, e molto altro. Non solo offre ai ingegneri DevOps, sviluppatori e architetti una panoramica completa del funzionamento delle applicazioni, ma consente anche ai responsabili di monitorare la situazione in tempo reale, con spese per risorse calcolate al secondo e previsioni sui costi. Organizzare qualcosa di simile con un'infrastruttura gestita è molto più difficile.
Progettare applicazioni serverless è molto più semplice, perché non è necessario distribuire server web, gestire macchine virtuali o container, applicare patch a server, sistemi operativi, gateway Internet, ecc. L'astrazione da tutte queste responsabilità permette all'architettura serverless di concentrarsi su ciò che è veramente importante: soddisfare le esigenze di business e dei clienti.
Sebbene gli strumenti potessero essere migliori (stanno migliorando ogni giorno), gli sviluppatori possono concentrarsi sull'implementazione della logica di business e sulla migliore distribuzione della complessità dell'applicazione attraverso i vari servizi nell'architettura. La gestione delle applicazioni serverless avviene in base agli eventi ed è astratta dal fornitore cloud (ad esempio, SQS, eventi S3 o flussi DynamoDB). Pertanto, agli sviluppatori basta scrivere la logica di business per rispondere a determinati eventi, senza doversi preoccupare di come implementare al meglio i database e le code di messaggi, o come organizzare il funzionamento ottimale con i dati in specifici archivi hardware.
Il codice può essere eseguito e debugato localmente, esattamente come in qualsiasi processo di sviluppo. Il test modulare rimane invariato. La possibilità di distribuire un'intera infrastruttura applicativa tramite una configurazione personalizzabile dello stack consente agli sviluppatori di ricevere rapidamente feedback importante, senza preoccuparsi del costo dei test o dell'impatto su ambienti gestiti costosi.
Strumenti e metodologie per la creazione di applicazioni serverless
Non esiste un modo specifico per costruire applicazioni serverless. Né un insieme di servizi designati per questo compito. Attualmente, il leader tra le potenti soluzioni serverless è AWS, ma vale la pena prestare attenzione anche a , e . Se usi AWS, ti consiglio di considerare l'approccio di raccolta delle applicazioni tramite (SAM), specialmente se utilizzi C#, poiché Visual Studio offre strumenti eccellenti. SAM CLI può fare esattamente le stesse cose di Visual Studio, quindi non perderai nulla passando a un altro IDE o editor di testo. Naturalmente, SAM funziona anche con altri linguaggi.
Se stai scrivendo in altri linguaggi, il Serverless Framework è un eccellente strumento open source che consente di configurare qualsiasi cosa tramite file YAML di configurazione molto potenti. Inoltre, il Serverless Framework supporta vari servizi cloud, quindi lo raccomandiamo a chi cerca una soluzione multi-cloud. Ha una grande comunità che ha creato numerosi plugin per ogni necessità.
Per il test locale, strumenti open source come Docker-Lambda, Serverless Local, DynamoDB Local e LocalStack sono molto utili. Le tecnologie serverless sono ancora in fase di sviluppo, così come gli strumenti associati, quindi la configurazione per scenari di test complessi può richiedere un po' di lavoro. Tuttavia, distribuire semplicemente uno stack in un ambiente e testarlo è incredibilmente economico. E non è necessario creare una copia locale esatta degli ambienti cloud.
Per ridurre le dimensioni dei pacchetti distribuiti e accelerare i tempi di caricamento, utilizza AWS Lambda Layers.
Utilizza i linguaggi di programmazione giusti per compiti specifici. Ogni linguaggio ha i propri vantaggi e svantaggi. Ci sono molti benchmark, ma JavaScript, Python e C# (.NET Core 2.1+) sono i leader in termini di prestazioni su AWS Lambda. Recentemente, AWS Lambda ha introdotto l'Runtime API, che consente di specificare il linguaggio e l'ambiente di esecuzione desiderati, quindi sperimenta.
Mantieni le dimensioni dei pacchetti per il deployment ridotte. Più sono piccoli, più velocemente si caricano. Evita di utilizzare librerie enormi, specialmente se hai bisogno solo di alcune funzionalità. Se programmi in JavaScript, utilizza strumenti di build come Webpack per ottimizzare la build includendo solo ciò di cui hai realmente bisogno. In .NET Core 3.0 ci sono QuickJit e Tiered Compilation, che migliorano le prestazioni e aiutano notevolmente nei cold start.
La dipendenza delle funzioni serverless dagli eventi può inizialmente complicare il coordinamento della logica di business. Per questo motivo, le code di messaggi e gli automi a stati finiti possono risultare estremamente utili. Le funzioni Lambda possono invocarsi a vicenda, ma fallo solo se non ti aspetti una risposta ('sparato e dimenticato') — non desideri ricevere una fattura per l'attesa di completamento di un'altra funzione. Le code di messaggi sono utili per isolare le parti della logica di business, gestire i colli di bottiglia e trattare le transazioni (utilizzando le code FIFO). Le funzioni AWS Lambda possono essere associate a code SQS come code di messaggi 'in sospeso', che monitorano i messaggi falliti per ulteriori analisi. Le funzioni AWS Step Functions (automi a stati finiti) sono molto utili per gestire processi complessi che richiedono la creazione di catene di funzioni. Invece di far invocare una funzione Lambda da un'altra, le Step Functions possono coordinare le transizioni di stato, trasferire dati tra funzioni e gestire lo stato globale delle funzioni. Questo consente di specificare le condizioni per i tentativi di ripetizione o cosa fare in caso di errori specifici — uno strumento molto potente in determinate situazioni.
Conclusione
Negli ultimi anni, le tecnologie serverless si sono sviluppate a ritmi senza precedenti. Questa cambiamento di paradigma è associata a certi fraintendimenti. Grazie all'astrazione dell'infrastruttura e della gestione della scalabilità, le soluzioni serverless offrono notevoli vantaggi: dalla semplificazione dello sviluppo e dei processi DevOps, a una significativa riduzione dei costi operativi.
Sebbene l'approccio serverless abbia i suoi svantaggi, esistono metodologie affidabili e schemi di design che permettono di creare applicazioni serverless robuste o di integrare elementi serverless nelle architetture esistenti.
Fonte: habr.com
