{"id":37937,"date":"2019-10-31T22:20:41","date_gmt":"2019-10-31T19:20:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/detalnyj-razbor-aws-lambda\/"},"modified":"2019-10-31T22:20:41","modified_gmt":"2019-10-31T19:20:41","slug":"detalnyj-razbor-aws-lambda","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/detalnyj-razbor-aws-lambda","title":{"rendered":"Analisi dettagliata di AWS Lambda","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Traduzione dell'articolo preparata appositamente per gli studenti del corso \u00abServizi Cloud\u00bb<\/a><\/noindex>. Ti interessa svilupparti in questa direzione? Guarda il masterclass di Egor Zuev (Team Lead presso InBit) \u00abServizio AWS EC2\u00bb<\/a><\/noindex> e unisciti al prossimo gruppo del corso: inizio il 26 settembre. <\/em><\/p>\n

<\/p>\n

\"Analisi<\/p>\n

<\/p>\n

Sempre pi\u00f9 persone passano a AWS Lambda per la scalabilit\u00e0, le prestazioni, il risparmio e la possibilit\u00e0 di gestire milioni e persino trilioni di richieste al mese. Per questo non \u00e8 necessario gestire l'infrastruttura su cui opera il servizio. Il ridimensionamento automatico consente di gestire migliaia di richieste simultanee al secondo. Credo che AWS Lambda possa essere giustamente considerato uno dei servizi pi\u00f9 richiesti di AWS.<\/a><\/noindex><\/p>\n

<\/p>\n

AWS Lambda<\/h2>\n

<\/p>\n

AWS Lambda \u00e8 un servizio di calcolo serverless orientato agli eventi che consente di eseguire codice senza dover allocare e gestire server e complementare altri servizi AWS basati sulla logica dell'utente. Lambda risponde automaticamente a vari eventi (chiamati trigger), come richieste HTTP tramite Amazon API Gateway, modifiche ai dati nel bucket Amazon S3 o nelle tabelle Amazon DynamoDB; oppure \u00e8 possibile avviare il proprio codice tramite chiamate API, utilizzando l'AWS SDK e i passaggi tra stati in AWS Step Functions.<\/p>\n

<\/p>\n

Lambda esegue codice su un'infrastruttura di calcolo ad alta disponibilit\u00e0 e si occupa completamente della gestione della piattaforma sottostante, inclusi la manutenzione dei server e del sistema operativo, l'allocazione delle risorse, il ridimensionamento automatico, il monitoraggio del codice e la registrazione. Quindi, devi solo caricare il tuo codice e configurare come e quando deve essere eseguito. Il servizio si occuper\u00e0 di avviarlo e garantire l'alta disponibilit\u00e0 della tua applicazione.<\/p>\n

<\/p>\n

Quando passare a Lambda?<\/h2>\n

<\/p>\n

AWS Lambda \u00e8 una piattaforma di calcolo conveniente, adatta a molteplici scenari, ovviamente se il linguaggio e l'ambiente di esecuzione del tuo codice sono supportati dal servizio. Se desideri concentrarti sul codice e sulla logica aziendale, delegando la gestione dei server, l'allocazione delle risorse e il ridimensionamento a un fornitore esterno a un prezzo ragionevole, vale sicuramente la pena passare a AWS Lambda.<\/p>\n

<\/p>\n

Lambda \u00e8 ideale per la creazione di interfacce software e, se utilizzato insieme ad API Gateway, pu\u00f2 ridurre significativamente i costi e accelerare il time-to-market. Ci sono vari modi per utilizzare le funzioni Lambda e diverse opzioni per organizzare un'architettura serverless\u2014ognuno pu\u00f2 scegliere qualcosa di adatto a seconda degli obiettivi prefissati.<\/p>\n

<\/p>\n

Lambda consente di eseguire un'ampia gamma di attivit\u00e0. Ad esempio, grazie al supporto di CloudWatch, \u00e8 possibile creare attivit\u00e0 pianificate e automatizzare singoli processi. Non ci sono limiti sulla natura e sull'intensit\u00e0 dell'utilizzo del servizio (si considerano il consumo di memoria e il tempo), e nulla vi impedisce di lavorare in modo graduale su un microservizio completo basato su Lambda.<\/p>\n

<\/p>\n

Qui \u00e8 possibile creare azioni orientate ai servizi che non vengono eseguite continuamente. Un esempio tipico \u00e8 la ridimensionamento delle immagini. Anche nei sistemi distribuiti, le funzioni Lambda rimangono rilevanti.<\/p>\n

<\/p>\n

Quindi, se non volete occuparvi dell'allocazione e della gestione delle risorse di calcolo\u2014provate AWS Lambda; se non avete bisogno di calcoli gravosi e dispendiosi in termini di risorse\u2014provate anche AWS Lambda; se il vostro codice viene eseguito periodicamente\u2014esatto, dovreste provare AWS Lambda.<\/p>\n

<\/p>\n

Sicurezza<\/h2>\n

<\/p>\n

Finora non ci sono state lamentele riguardo alla sicurezza. D'altra parte, dal momento che molti processi interni e caratteristiche di implementazione di questo modello sono nascosti all'utente dell'ambiente di esecuzione gestito AWS Lambda, alcune regole comuni di sicurezza cloud perdono rilevanza.<\/p>\n

<\/p>\n

Come la maggior parte dei servizi AWS, Lambda \u00e8 fornito secondo il principio di responsabilit\u00e0 condivisa tra AWS e il cliente in materia di sicurezza e conformit\u00e0 normativa. Questo principio riduce il carico operativo per il cliente, poich\u00e9 AWS si occupa delle attivit\u00e0 di manutenzione, amministrazione e controllo dei componenti del servizio\u2014dal sistema operativo dell'host e dal livello di virtualizzazione alla sicurezza fisica delle infrastrutture. <\/p>\n

<\/p>\n

Parlando specificamente di AWS Lambda, AWS \u00e8 responsabile della gestione dell'infrastruttura sottostante, dei servizi di base correlati, del sistema operativo e della piattaforma applicativa. Mentre il cliente \u00e8 responsabile della sicurezza del proprio codice, della conservazione dei dati riservati, del controllo dell'accesso a essi, nonch\u00e9 al servizio e alle risorse Lambda (Identity and Access Management, IAM), anche nell'ambito delle funzioni utilizzate.<\/p>\n

<\/p>\n

Nello schema sottostante \u00e8 mostrato il modello di responsabilit\u00e0 condivisa applicabile ad AWS Lambda. L'area di responsabilit\u00e0 di AWS \u00e8 colorata in arancione, mentre la responsabilit\u00e0 del cliente \u00e8 evidenziata in blu. Come potete vedere, AWS si assume maggiori responsabilit\u00e0 per le applicazioni implementate sul servizio.<\/p>\n

<\/p>\n

\"Analisi<\/p>\n

<\/p>\n

Il modello di responsabilit\u00e0 condivisa applicabile ad AWS Lambda<\/em><\/p>\n

<\/p>\n

Ambiente di esecuzione Lambda<\/h3>\n

<\/p>\n

Il principale vantaggio di Lambda \u00e8 che, eseguendo una funzione per vostro conto, il servizio gestisce autonomamente le risorse necessarie. Non dovete perdere tempo e sforzi nell'amministrazione dei sistemi, potendo cos\u00ec concentrarvi sulla logica aziendale e sulla scrittura del codice.<\/p>\n

<\/p>\n

Il servizio Lambda \u00e8 suddiviso in due piani. Il primo \u00e8 il piano di controllo. Secondo Wikipedia, il piano di controllo (control plane) \u00e8 la parte della rete responsabile del trasporto del traffico di segnalazione e del routing. \u00c8 il principale componente che prende decisioni globali sulla allocazione, manutenzione e distribuzione dei carichi di lavoro. Inoltre, il piano di controllo svolge il ruolo di topologia di rete del fornitore, responsabile per il routing e la gestione del traffico.<\/p>\n

<\/p>\n

Il secondo piano \u00e8 il piano dati. Anch'esso, come il piano di controllo, ha i propri compiti. Il piano di controllo fornisce API per gestire le funzioni (CreateFunction, UpdateFunctionCode) e controlla le interazioni di Lambda con altri servizi AWS. Il piano dati gestisce le API di chiamata (Invoke API), che attivano le funzioni Lambda. Dopo la chiamata della funzione, il piano di controllo assegna o seleziona un ambiente di esecuzione esistente, previamente preparato per quella funzione, e poi esegue il codice al suo interno.<\/p>\n

<\/p>\n

AWS Lambda supporta numerosi linguaggi di programmazione, tra cui Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 e altri, tramite i rispettivi ambienti di runtime. AWS li aggiorna regolarmente, distribuisce patch di sicurezza ed esegue altre operazioni di manutenzione su questi ambienti. Lambda consente di utilizzare anche altri linguaggi a condizione che tu implementi il relativo ambiente di runtime. E in tal caso, sarai tu a doverti occupare della sua manutenzione, compreso il monitoraggio della sicurezza.<\/p>\n

<\/p>\n

Come funziona tutto questo e come il servizio eseguir\u00e0 le tue funzioni?<\/strong><\/p>\n

<\/p>\n

Ogni funzione opera in uno o pi\u00f9 ambienti dedicati, che esistono solo durante il ciclo di vita di quella funzione e poi vengono distrutti. In ciascun ambiente viene eseguita solo una chiamata alla volta, ma viene riutilizzato se ci sono molte chiamate seriali della stessa funzione. Tutti gli ambienti di runtime operano su macchine virtuali con virtualizzazione hardware \u2014 sui cosiddetti microVM. Ogni microVM \u00e8 assegnata a un particolare account AWS e pu\u00f2 essere riutilizzata da ambienti per eseguire diverse funzioni in quell'account. Le microVM sono incapsulate in strutture hardware della piattaforma Lambda Worker, di propriet\u00e0 e gestite da AWS. Lo stesso ambiente di runtime non pu\u00f2 essere utilizzato da funzioni diverse, cos\u00ec come le microVM sono uniche per diversi account AWS.<\/p>\n

<\/p>\n

\"Analisi<\/p>\n

<\/p>\n

Il modello di isolamento in AWS Lambda<\/em><\/p>\n

<\/p>\n

L'isolamento degli ambienti di runtime \u00e8 attuato tramite diversi meccanismi. A livello superiore, ogni ambiente presenta copie separate dei seguenti componenti:<\/p>\n

<\/p>\n