Sebbene le tecnologie serverless abbiano rapidamente guadagnato popolarità negli ultimi anni, ci sono ancora molte idee sbagliate e timori ad esse associate. La dipendenza dal fornitore, gli strumenti, la gestione dei costi, l'avvio a freddo, il monitoraggio e il ciclo di vita dello sviluppo sono tutti argomenti caldi quando si tratta di tecnologie serverless. In questo articolo, esploreremo alcuni degli argomenti menzionati, oltre a condividere suggerimenti e collegamenti a utili fonti di informazioni per aiutare i principianti a creare applicazioni serverless potenti, flessibili e convenienti.
Idee sbagliate sulle tecnologie serverless
Molte persone pensano che l'elaborazione senza server e senza server (, FaaS) sono quasi la stessa cosa. Ciò significa che la differenza non è eccessiva e vale la pena introdurre una novità. Sebbene AWS Lambda sia stata una delle stelle del periodo di massimo splendore del serverless e uno degli elementi più popolari dell'architettura serverless, tuttavia, questa architettura è molto più di FaaS.
Il principio alla base delle tecnologie serverless è che non devi preoccuparti di gestire e ridimensionare la tua infrastruttura, paghi solo per ciò che usi. Molti servizi soddisfano questi criteri: AWS DynamoDB, S3, SNS o SQS, Graphcool, Auth0, Now, Netlify, Firebase e molti altri. In generale, serverless significa utilizzare tutta la potenza del cloud computing senza la necessità di gestire l'infrastruttura e ottimizzarla per la scalabilità. Significa anche che la sicurezza a livello di infrastruttura non è più una tua preoccupazione, il che è un enorme vantaggio data la difficoltà e la complessità di soddisfare gli standard di sicurezza. Infine, non è necessario acquistare l'infrastruttura fornita.
Il serverless può essere considerato uno “state of mind”: una certa mentalità quando si progettano soluzioni. Evitare approcci che richiedono la manutenzione di qualsiasi infrastruttura. Con un approccio serverless, dedichiamo tempo alla risoluzione di attività che influiscono direttamente sul progetto e apportano vantaggi ai nostri utenti: creiamo logiche di business sostenibili, sviluppiamo interfacce utente e sviluppiamo API adattive e affidabili.
Ad esempio, se è possibile evitare di gestire e mantenere una piattaforma di ricerca testuale gratuita, allora è quello che faremo. Questo approccio alla creazione di applicazioni può accelerare notevolmente il time-to-market, poiché non è più necessario pensare alla gestione di infrastrutture complesse. Elimina le responsabilità e i costi della gestione dell'infrastruttura e concentrati sulla creazione delle applicazioni e dei servizi di cui i tuoi clienti hanno bisogno. Patrick Debois ha chiamato questo approccio , il termine è adottato nella comunità serverless. Le funzioni dovrebbero essere pensate come un collegamento ai servizi come moduli distribuibili (invece di distribuire un'intera libreria o applicazione web). Ciò fornisce un'incredibile granularità per la gestione della distribuzione e delle modifiche all'applicazione. Se non riesci a distribuire le funzioni in questo modo, potrebbe indicare che le funzioni eseguono troppe attività e devono essere rifattorizzate.
Alcuni sono confusi dalla dipendenza dal fornitore durante lo sviluppo di applicazioni cloud. Lo stesso vale per le tecnologie serverless, e questo non è certo un malinteso. Nella nostra esperienza, la creazione di applicazioni serverless su AWS, combinata con la capacità di AWS Lambda di raggruppare insieme altri servizi AWS, fa parte della forza delle architetture serverless. Questo è un buon esempio di sinergia, quando il risultato della combinazione è più della semplice somma dei termini. Cercare di evitare la dipendenza dal fornitore può incorrere in ulteriori problemi. Quando si lavora con i contenitori, è più facile gestire il proprio livello di astrazione tra i fornitori di servizi cloud. Ma quando si tratta di soluzioni serverless, lo sforzo non sarà ripagato, soprattutto se si tiene conto del rapporto costo-efficacia fin dall'inizio. Assicurati di scoprire come i fornitori forniscono servizi. Alcuni servizi specializzati si basano su punti di integrazione con altri fornitori e possono fornire connettività plug-and-play pronta all'uso. È più semplice fornire una chiamata Lambda da un endpoint API del gateway piuttosto che inoltrare la richiesta a un contenitore o a un'istanza EC2. Graphcool offre una facile configurazione con Auth0, che è più semplice rispetto all'utilizzo di 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 un giorno a gestire i server. La scelta di un fornitore di servizi cloud non è diversa dalla scelta di utilizzare contenitori o un database o persino un linguaggio di programmazione.
Prendere in considerazione:
- Di quali servizi hai bisogno e perché.
- Quali servizi forniscono i fornitori di servizi cloud e come combinarli con la soluzione FaaS scelta.
- Quali linguaggi di programmazione sono supportati (con tipizzazione dinamica o statica, compilati o interpretati, quali sono i benchmark, quali sono le prestazioni al cold start, qual è l'ecosistema open source, ecc.).
- Quali sono i tuoi requisiti di sicurezza (SLA, 2FA, OAuth, HTTPS, SSL, ecc.).
- Come gestire i tuoi CI/CD e i cicli di sviluppo del software.
- Quali soluzioni di infrastruttura come codice puoi sfruttare.
Se estendi un'applicazione esistente e aggiungi in modo incrementale funzionalità senza server, ciò potrebbe limitare in qualche modo le capacità disponibili. Tuttavia, quasi tutte le tecnologie serverless forniscono un qualche tipo di API (tramite REST o code di messaggi) che consente di creare estensioni indipendenti dal core dell'applicazione e con una facile integrazione. Cerca servizi con API chiare, buona documentazione e una community forte e non puoi sbagliare. La facilità di integrazione può spesso essere un parametro chiave ed è probabilmente uno dei motivi principali per cui AWS ha avuto così tanto successo da quando Lambda è stato rilasciato nel 2015.
Quando Serverless è buono
Le tecnologie serverless possono essere applicate quasi ovunque. Tuttavia, i loro vantaggi non si limitano a un solo modo di applicazione. La barriera all'ingresso per il cloud computing oggi è così bassa grazie alle tecnologie serverless. Se gli sviluppatori hanno un'idea, ma non sanno come gestire l'infrastruttura cloud e ottimizzare i costi, allora non hanno bisogno di cercare un qualche tipo di ingegnere per farlo. Se una startup vuole costruire una piattaforma ma teme che i costi possano andare fuori controllo, può facilmente rivolgersi a soluzioni serverless.
Grazie al risparmio sui costi e alla facilità di scalabilità, le soluzioni serverless sono ugualmente applicabili sia per sistemi interni che esterni, fino a un'applicazione Web con un pubblico multimilionario. I conti non sono misurati in euro, ma in centesimi. Noleggiare l'istanza più semplice di AWS EC2 (t1.micro) per un mese costerà € 15, anche se non ci fai nulla (chi non ha mai dimenticato di spegnerlo?!). In confronto, per raggiungere questo livello di spesa nello stesso periodo di tempo, sarebbe necessario eseguire un Lambda da 512 MB per 1 secondo circa 3 milioni di volte. E se non utilizzi questa funzione, non paghi nulla.
Poiché il serverless è principalmente basato sugli eventi, è abbastanza facile aggiungere un'infrastruttura serverless ai sistemi meno recenti. Ad esempio, utilizzando AWS S3, Lambda e Kinesis, puoi creare un servizio di analisi per un vecchio sistema di vendita al dettaglio che può ricevere dati tramite un'API.
La maggior parte delle piattaforme serverless supporta più lingue. Molto spesso è Python, JavaScript, C#, Java e Go. Di solito non ci sono restrizioni sull'uso delle librerie in tutte le lingue, quindi puoi usare le tue librerie open source preferite. Tuttavia, è consigliabile non abusare delle dipendenze in modo che le tue funzioni funzionino in modo ottimale e non annullino i vantaggi dell'enorme scalabilità delle tue applicazioni serverless. Maggiore è il numero di pacchi da caricare nel container, maggiore sarà il tempo necessario per l'avvio a freddo.
Un avvio a freddo si verifica quando è necessario inizializzare il contenitore, il runtime e il gestore degli errori prima di utilizzarli. Per questo motivo, il ritardo nell'esecuzione delle funzioni può arrivare fino a 3 secondi e questa non è l'opzione migliore per gli utenti impazienti. Tuttavia, gli avviamenti a freddo si verificano alla prima chiamata dopo alcuni minuti di funzionamento inattivo. Così tanti lo considerano un piccolo fastidio che può essere risolto eseguendo regolarmente il ping della funzione per mantenerlo inattivo. Oppure ignorano del tutto questo aspetto.
Sebbene AWS abbia rilasciatoTuttavia, i database SQL non sono l'ideale per questa applicazione, in quanto dipendono dalle connessioni per eseguire transazioni, che possono diventare rapidamente un collo di bottiglia con un traffico intenso su AWS Lambda. Sì, gli sviluppatori migliorano costantemente Serverless Aurora e dovresti sperimentarlo, ma oggi le soluzioni NoSQL come. Tuttavia, non c'è dubbio che questa situazione cambierà molto presto.
Il toolkit impone anche molte restrizioni, soprattutto nel campo dei test locali. Sebbene esistano soluzioni come Docker-Lambda, DynamoDB Local e LocalStack, richiedono un duro lavoro e una notevole quantità di configurazione. Tuttavia, tutti questi progetti vengono sviluppati attivamente, quindi è solo una questione di tempo prima che il toolkit raggiunga il livello di cui abbiamo bisogno.
L'impatto delle tecnologie serverless sul ciclo di sviluppo
Poiché la tua infrastruttura è solo una configurazione, puoi definire e distribuire il codice utilizzando script, ad esempio script di shell. Oppure puoi ricorrere a soluzioni di classe di configurazione come codice come . Sebbene questo servizio non fornisca la configurazione per tutte le aree, consente di definire risorse specifiche da utilizzare come funzioni Lambda. Cioè, dove CloudFormation ti delude, puoi scrivere la tua risorsa (funzione Lambda) che colmerà questo divario. In questo modo puoi fare qualsiasi cosa, anche configurare le dipendenze al di fuori del tuo ambiente AWS.
Poiché si tratta solo di configurazione, puoi personalizzare gli script di distribuzione per ambienti, regioni e utenti specifici, soprattutto se utilizzi soluzioni di infrastruttura come codice come CloudFormation. Ad esempio, puoi distribuire una copia dell'infrastruttura per ogni ramo nel repository in modo da poterli testare completamente in isolamento durante lo sviluppo. Ciò accelera drasticamente il feedback per gli sviluppatori quando vogliono capire se il loro codice funziona adeguatamente in un ambiente live. I manager non devono preoccuparsi del costo dell'implementazione di più ambienti, poiché pagano solo per l'utilizzo effettivo.
I DevOps hanno meno preoccupazioni in quanto devono solo assicurarsi che gli sviluppatori dispongano della configurazione corretta. Non è più necessario gestire istanze, sistemi di bilanciamento o gruppi di sicurezza. Pertanto, il termine NoOps è sempre più utilizzato, sebbene sia ancora importante essere in grado di configurare l'infrastruttura, soprattutto quando si tratta di configurazione IAM e ottimizzazione delle risorse cloud.
Esistono strumenti di monitoraggio e visualizzazione molto potenti come Epsagon, Thundra, Dashbird e IOPipe. Ti consentono di monitorare lo stato corrente delle tue applicazioni serverless, fornire registrazione e traccia, acquisire metriche delle prestazioni e colli di bottiglia dell'architettura, eseguire analisi e previsioni dei costi e altro ancora. Non solo offrono a ingegneri, sviluppatori e architetti DevOps una visione completa delle prestazioni delle applicazioni, ma consentono anche ai manager di monitorare la situazione in tempo reale, con costi delle risorse al secondo e previsione dei costi. È molto più difficile organizzarlo con un'infrastruttura gestita.
La progettazione di applicazioni serverless è molto più semplice perché non è necessario distribuire server Web, gestire macchine virtuali o container, patch server, sistemi operativi, gateway Internet e così via. Eliminando tutte queste responsabilità, un'architettura serverless può concentrarsi sul core: la soluzione, le esigenze aziendali e dei clienti.
Anche se il toolkit potrebbe essere migliore (migliora di giorno in giorno), gli sviluppatori possono concentrarsi sull'implementazione della logica aziendale e sulla distribuzione ottimale della complessità dell'applicazione tra diversi servizi all'interno dell'architettura. La gestione delle applicazioni serverless è basata sugli eventi e astratta dal provider cloud (ad es. SQS, eventi S3 o flussi DynamoDB). Pertanto, gli sviluppatori devono solo scrivere la logica aziendale per rispondere a determinati eventi e non devono preoccuparsi di come implementare al meglio database e code di messaggi o di come organizzare un lavoro ottimale con i dati in archivi hardware specifici.
Il codice può essere eseguito e sottoposto a debug localmente, come con qualsiasi processo di sviluppo. Il test unitario rimane lo stesso. La possibilità di implementare un'intera infrastruttura applicativa con una configurazione dello stack personalizzata consente agli sviluppatori di ottenere rapidamente feedback importanti senza pensare al costo dei test o all'impatto sui costosi ambienti gestiti.
Strumenti e tecniche per la creazione di applicazioni serverless
Non esiste un modo specifico per creare applicazioni serverless. Oltre a una serie di servizi per questo compito. AWS è oggi il leader tra le potenti soluzioni serverless, ma guarda anche , и . Se utilizzi AWS, l'approccio consigliato per la raccolta delle applicazioni è (SAM), specialmente quando si usa C#, perché Visual Studio dispone di ottimi strumenti. L'interfaccia della riga di comando di SAM può eseguire tutte le operazioni di Visual Studio, quindi non perderai nulla se passi a un altro IDE o editor di testo. Ovviamente SAM funziona anche con altre lingue.
Se stai scrivendo in altre lingue, Serverless Framework è un eccellente strumento open source che ti consente di configurare qualsiasi cosa con file di configurazione YAML molto potenti. Il Serverless Framework supporta anche vari servizi cloud, quindi lo consigliamo a chi è alla ricerca di una soluzione multi-cloud. Ha una vasta comunità che ha creato un sacco di plugin per qualsiasi esigenza.
Per i test locali, gli strumenti open source Docker-Lambda, Serverless Local, DynamoDB Local e LocalStack sono adatti. Le tecnologie serverless sono ancora nelle prime fasi di sviluppo, così come i loro strumenti, quindi quando si impostano scenari di test complessi, dovrai lavorare sodo. Tuttavia, semplicemente distribuire lo stack in un ambiente e testarlo è incredibilmente economico. E non è necessario creare una copia locale esatta degli ambienti cloud.
Utilizza AWS Lambda Layers per ridurre le dimensioni dei pacchetti distribuiti e velocizzare i download.
Usa i linguaggi di programmazione giusti per attività specifiche. Lingue diverse hanno i loro vantaggi e svantaggi. Esistono molti benchmark, ma JavaScript, Python e C# (.NET Core 2.1+) sono i leader in termini di prestazioni di AWS Lambda. AWS Lambda ha recentemente introdotto l'API Runtime, che ti consente di specificare il linguaggio e l'ambiente di runtime desiderati, quindi sperimenta.
Mantieni le dimensioni dei pacchetti ridotte per la distribuzione. Più sono piccoli, più velocemente si caricano. Evita di utilizzare librerie di grandi dimensioni, soprattutto se utilizzi un paio di funzionalità da esse. Se stai programmando in JavaScript, usa uno strumento di compilazione come Webpack per ottimizzare la tua compilazione e includere solo ciò di cui hai veramente bisogno. .NET Core 3.0 ha QuickJit e Tiered Compilation che migliorano le prestazioni e aiutano molto nelle partenze a freddo.
L'affidamento delle funzioni serverless sugli eventi può rendere inizialmente difficile il coordinamento della logica di business. A questo proposito, le code di messaggi e le macchine a stati possono essere incredibilmente utili. Le funzioni Lambda possono chiamarsi a vicenda, ma fallo solo se non ti aspetti una risposta ("licenzia e dimentica"): non vuoi essere fatturato 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 ed elaborare le transazioni (utilizzando le code FIFO). Le funzioni AWS Lambda possono essere assegnate alle code SQS come code di messaggi bloccate che tengono traccia dei messaggi non riusciti per un'analisi successiva. Le AWS Step Functions (macchine a stati) sono molto utili per gestire processi complessi che richiedono il concatenamento di funzioni. Invece di una funzione Lambda che chiama un'altra funzione, le funzioni Step possono coordinare le transizioni di stato, passare i dati tra le funzioni e gestire lo stato globale delle funzioni. Ciò consente di definire le condizioni di ripetizione o cosa fare quando si verifica un errore particolare: uno strumento molto potente in determinate condizioni.
conclusione
Negli ultimi anni, le tecnologie serverless si sono sviluppate a un ritmo senza precedenti. Ci sono alcune idee sbagliate associate a questo cambio di paradigma. Astraendo l'infrastruttura e ridimensionando la gestione, le soluzioni serverless offrono vantaggi significativi, dallo sviluppo semplificato e dai processi DevOps alle massicce riduzioni dei costi operativi.
Sebbene l'approccio serverless non sia privo di inconvenienti, esistono robusti modelli di progettazione che possono essere utilizzati per creare solide applicazioni serverless o integrare elementi serverless nelle architetture esistenti.
Fonte: habr.com