AWS

AWS: sviluppare più velocemente applicazioni con le architetture serverless

di pubblicato il nel canale Cloud AWS: sviluppare più velocemente applicazioni con le architetture serverless

Il cloud si evolve e per AWS sono sempre più importanti le architetture serverless. Edge9 ha incontrato Danilo Poccia, che ci ha raccontato cosa sono e che ruolo ricoprono nell’offerta di AWS. Con un obiettivo chiaro: rendere più veloce e sicuro lo sviluppo di nuove applicazioni

 

AWS è sinonimo di cloud e da oltre 14 anni propone sul mercato soluzioni innovative che hanno definito il concetto stesso di cloud. Negli ultimi anni si sta sempre più sviluppando l’architettura “serverless” di AWS e per comprendere a fondo quale sia il significato di questa evoluzione, Edge9 ha incontrato Danilo Poccia, Principal Evangelist Serverless in Amazon Web Services. Danilo è uno dei maggiori esperti a livello mondiale delle tecnologie serverless, e non solo, di AWS e quindi il suo è un punto di vista privilegiato sull’evoluzione del cloud.

Serverless, per AWS, significa focalizzarsi sull’utente finale 

Edge9: Cosa significa Serverless per AWS?

Danilo Poccia: Le architetture serverless sono native del cloud, perché i clienti cercano di focalizzarsi sempre di più sulle cose che sono importanti per loro, sulle funzionalità che vogliono implementare e per farlo vogliono demandare ad AWS le responsabilità “operative” di gestione dei server. Attività come il provisioning o la gestione delle patch sono importantissime ma non focalizzate sull’obiettivo che i clienti stanno cercando di raggiungere. L’architettura serveless permette di affidare le attività di gestione dell’infrastruttura ad AWS, che è abituata a farle su scala molto ampia e quindi lo può fare in modo mirato.

AWS Danilo Poccia

Dentro Serverless ci sono una serie di tecnologie, come Lambda, ma non è uno switch on/off; un’architettura è serverless se segue il principio di minimizzare l’impatto di gestione, utilizzando servizi completamente gestiti, come ad esempio Amazon S3, che è stato il primo servizio che abbiamo lanciato quasi 14 anni fa. S3 è uno storage semplice da usare senza doversi mettere a pensare a quali dischi sto usando o ad altre tematiche tecniche che sono normalmente associate all’utilizzo dello storage.

Edge9: La direzione del mercato appare nettamente in direzione di una maggiore "containerizzazione" di ogni tipo di carico di lavoro. L'approccio Serverless è l'evoluzione di concetti come PaaS e container: qual è la futura evoluzione del panorama vista da AWS? Il mondo IT diventerà Serverless?

Danilo Poccia: Io vedo le architetture serverless e dei container lavorare insieme e molto spesso i clienti, come qualche anno fa Pirelli, utilizzano insieme funzioni Lambda e container. Il termine container è un po’ sovraccarico di significati e sono due gli ambiti in cui spesso è utilizzato. Da una parte c’è la componente di isolamento, dall’altra quella di packaging, ossia la creazione di codice che posso utilizzare in vari ambienti, dallo sviluppo al test fino alla produzione. Ci sono molte convergenze e sulla parte di packaging c’è un trend verso quelle che in gergo vengono chiamate micro virtual machine. In questo ambito come AWS abbiamo rilasciato un progetto open source che si chiama Firecracker, un sistema di micro VM molto leggero che può far partire in pochi millisecondi una nuova VM e ne può supportare migliaia su un singolo server fisico. Questa tecnologia viene utilizzata sia da AWS Fargate, per i container che noi definiamo serverless, ma anche per isolare ed eseguire le funzioni Lambda. C’è sicuramente una convergenza tecnologica. 

Un altro aspetto dei container relativo al packaging è che, mentre i container includono una componente di sistema operativo che fa parte delle dipendenze, in ambito Serverless questa componente viene gestita dalla piattaforma. Questo crea delle componenti ancora più isolate e sempre più focalizzate sulle funzionalità che voglio implementare. 

Serveless significa sviluppare più velocemente 

Edge9: Al momento attuale l'approccio serverless porta a far sì che i software sviluppati per i servizi di Amazon non siano compatibili con quelli di altri provider. Un ritorno al vendor lock-in in un'epoca di maggiore apertura o una fase di transizione per via dell'assenza di standard?

Danilo Poccia: Ci sono state delle iniziative di standardizzazione come i Cloud Events, a cui noi come AWS abbiamo partecipato, però in ambito Serverless è necessario fare delle distinzioni perché da una parte ci sono i servizi completamente gestiti, ad esempio di storage, di database, e li chiaramente ogni provider cerca di fornire le funzionalità migliori e noi come AWS sfruttiamo il fatto che negli anni abbiamo lanciato molte funzionalità basate sul feedback dei nostri clienti. Per quanto riguarda le singole funzioni, invece, sono scritte in linguaggi di programmazione assolutamente tradizionali, quindi una funzione Lambda è comunque scritta in Java, Javascript, Python. Abbiamo anche lanciato la possibilità per i clienti di utilizzare un qualsiasi linguaggio di programmazione utilizzando il proprio runtime custom. Dentro queste funzioni c’è la possibilità di essere invocate quando succede qualcosa e soltanto quell’invocazione ha delle dipendenze con gli altri servizi AWS. Già qualche anno fa avevo pubblicato in open source su GitHub lo stesso codice che poteva essere utilizzato come funzione Lambda o container Docker e a seconda di dove veniva incapsulata la funzione veniva eseguito o il metodo che si aspetta il nostro API gateway o un’interfaccia web dentro un container Docker. Quello che conta è dove uno vuole focalizzarsi e fare cambiamenti non dovrebbe essere un problema come in passato, quando c’erano architetture monolitiche.

AWS Lambda

Serverless ti porta invece a utilizzare i microservizi e una loro caratteristica è che possono essere riscritti velocemente. Una delle regole guida è che un microservizio deve poter essere riscritto in due settimane. Ed è il caso peggiore perché contempla la necessità di riscrivere tutto il microservizio, nella media quindi in pochi giorni è possibile riadattare un microservizio da un’architettura a un'altra, minimizzando il rischio, a fronte dei grandi vantaggi derivanti dalla flessibilità di un’architettura serverless. Prima di Natale il responsabile della ricerca e sviluppo di iRobot, un nostro cliente e amico, ha dichiarato che vendono la maggior parte dei Roomba fra il Black Friday e Natale. Quasi tutti i prodotti Roomba vengono attivati in una finestra temporale ridottissima di 4 ore la mattina di Natale, quando vengono scartati i regali. L’attivazione è gestita attraverso un’architettura serverless che deve gestire un carico di lavoro in quelle 4 ore che arriva ad essere 100 volte superiore rispetto a quello che avviene durante il resto dell’anno. Grazie all’utilizzo del Serverless è un giorno come un altro e iRobot non deve attivare procedure particolari.

Quando iRobot ha iniziato ad aggiungere funzionalità avanzate ai Roomba non avevano un dipartimento IT, quindi pensare di creare un dipartimento IT tradizionale avrebbe creato un’enorme complessità e costi. Hanno invece utilizzato il cloud e architetture serverless da zero e quindi possono gestire tutto in modo particolarmente snello e veloce.

La sicurezza è essenziale per AWS

Edge9: Il vantaggio principale del Serverless è l'assenza di gestione del sistema: è la stessa architettura a gestire le risorse necessarie. Questo comporta anche un diverso approccio alla sicurezza dell’intero sistema. Quali strumenti impiega AWS per garantire il massimo controllo possibile?

Danilo Poccia: La sicurezza per noi è la priorità più importante e per AWS sono fondamentali 3 caratteristiche: visibilità su quello che accade, controllo per agire a differenti livelli e automazione dei processi di sicurezza. Uno sviluppo interessante, nato ascoltando il feedback dei clienti, è un servizio lanciato all’ultimo re:invent che si chiama Amazon Detective, disponibile attualmente in preview. AWS offre in generale un’ampia visibilità, ad esempio attraverso AWS CloudTrail posso vedere tutte le modifiche che vengono fatte sia alle componenti serverless, che a quelle non serverless, e posso analizzare il traffico di rete nei VPC (Virtual Private Cloud). La mole di dati generata da CloudTrail può diventare significativa ed è necessario processare queste informazioni in modo efficace. Amazon Detective permette appunto di analizzare in modo automatico tutti questi flussi di dati per trovare delle anomalie, dei comportamenti che possono essere sospetti. Questo è un ulteriore passo avanti che semplifica, soprattutto per aziende medio/piccole che non hanno un centro di sicurezza, la scoperta delle anomalie nei comportamenti, come accessi da un paese diverso dal solito per determinati servizi.

AWS Detective

Una caratteristica fondamentale del Serverless è che permette di costruire architetture estremamente modulari. Questa possibilità di essere granulari permette di applicare l’approccio fondamentale del “risk privilege”, ossia dare i minimi permessi a ogni componente della mia architettura. Quindi con Serverless posso creare delle applicazioni in cui se una funzione deve soltanto leggere una parte di un database, gli viene concesso solo quel permesso specifico. In questo modo anche in caso di problemi di sicurezza l’impatto viene enormemente limitato rispetto a un’architettura tradizionale, dove una falla in una macchina virtuale può permettere all’attaccante di prendere il controllo dell’intera VM.

Edge9: Come vede AWS l’evoluzione della piattaforma ARM per i server?

Danilo Poccia: AWS cerca da sempre di offrire un’ampia gamma di scelte al cliente. Nel mondo ARM abbiamo fatto importanti investimenti negli ultimi 2 anni: nel 2019 abbiamo lanciato il primo processore ARM per i data center progettato da AWS, AWS Graviton, e adesso a re:invent abbiamo lanciato la seconda generazione, Graviton 2, che è estremamente più performante, secondo i nostri test interni è circa il 40% più veloce delle macchine EC2 M5, che sono delle macchine di fascia intermedia, e a queste prestazioni è associato un risparmio di costi di circa il 20%. L’architettura ARM è quindi sicuramente molto interessante. Da parte di chi crea applicazioni e di chi sviluppa c’è stato un altro trend negli ultimi anni, con piattaforme di sviluppo che sono più astratte rispetto all’architettura utilizzata, penso a linguaggi come Javascript, Python, lo stesso Swift. Questo trend si è sviluppato in maniera autonoma rispetto ad AWS e ad oggi si possono utilizzare architetture ARM in modo trasparente con vari servizi di AWS ma non nelle funzioni Lambda. Su questo siamo in ascolto e quindi se i clienti ce lo chiederanno è sicuramente un aspetto che potremo approfondire.

Edge9: Per concludere, quali sono i trend che AWS vede per il prossimo futuro?

Danilo Poccia: Vedo due trend fondamentali, ascoltando quello che mi dicono i clienti: primo sviluppare in modo rapido e veloce e portare in produzione le nuove funzionalità nel più breve tempo possibile. In quest’ottica continuous integration e continuous deployment sono due approcci che raccomando a tutti, perché chiunque voglia approcciare il mondo serverless, per sfruttarne tutti i vantaggi, deve cercare di avere una catena di sviluppo che permette di portare in produzione in modo veloce e controllato le funzionalità senza dover aspettare settimane o mesi.  Su questo il serverless aiuta perché gli ambienti di sviluppo sono più piccoli, lavoro su componenti che è più facile portare in produzione, anche in pochi giorni. Secondo, più banalmente, la capacità di focalizzarsi: i clienti non vogliono perdere tempo su quello che non gli comporta un vantaggio immediato e quindi potersi focalizzare direttamente sulla funzionalità che offrono un vantaggio all’utente finale è quello che ci chiedono veramente tutti. È da qui che siamo partiti oltre 5 anni fa per lanciare le funzioni Lambda e quello è stato il primo passo per creare tutto il mondo delle architetture serverless di AWS.

1 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Vul18 Febbraio 2020, 10:42 #1
Amazon dovrebbe pensare a semplificare i suoi servizi e pricing.

Inoltre nasconde convenientemente dove dietro ad nmila servizi poi si nascondano prezzi stratosferici per api gateway.

Alla fine piu cercano di girare la ruota e venderti il serverless e piu ti rendi conto che il monolite su aws beanstalk era piu semplice da sviluppare e piu economico da mantenere.

Come se il 99% dei servizi che la gente scrive su aws poi soffrano davvero così tanto di scalabilità...ma quando mai..

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
^