- Workload pattern
-
La comprensione del modello operativo dell'applicazione è il fattore più importante nella scelta dei servizi serverless. Modelli di carico di lavoro diversi richiedono diverse combinazioni di servizi. L'elaborazione dei dati senza server rientra in gran parte nei seguenti schemi:
Elaborazione asincrona: elaborazione di file, manipolazione di immagini, trasformazioni batch e webhook. Questi carichi di lavoro elaborano eventi che non richiedono una risposta immediata e traggono vantaggio dalle code per il buffering e dai fan-out per l'elaborazione parallela.
Sincrono request/response: API Web, backend mobili e microservizi. Questi carichi di lavoro richiedono un calcolo a bassa latenza che risponda alle singole richieste HTTP e sia scalabile con il traffico simultaneo.
Streaming: telemetria IoT, analisi click-stream, analisi in tempo reale ed elaborazione delle transazioni. Questi carichi di lavoro acquisiscono dati continui e ad alta velocità che devono essere elaborati quasi in tempo reale.
Orchestrazione: flussi di Multi-step approvazione, pipeline ETL e modelli di saga. Questi carichi di lavoro coordinano le attività con la logica di ramificazione, la gestione degli errori e la gestione dello stato.
Ogni modello utilizza una combinazione diversa di servizi serverless. Per esempi dettagliati e combinazioni di servizi consigliate per ogni modello, consulta la sezione Scegli.
- Execution duration and concurrency
-
I servizi di elaborazione serverless si differenziano notevolmente per quanto tempo consentono l'esecuzione di una singola esecuzione e per come gestiscono la concorrenza. A differenza dei server tradizionali, le funzioni di evento Lambda non vengono eseguite costantemente. Quando una funzione viene attivata da un evento, si parla di invocazione. Le funzioni di evento Lambda hanno una durata limitata a 15 minuti, ma in media, in tutti i AWS clienti, la maggior parte delle chiamate dura meno di un secondo.
Short-lived, le chiamate basate sugli eventi sono gestite al meglio da Lambda, che supporta durate di esecuzione fino a 15 minuti e si ridimensiona automaticamente per richiesta fino a migliaia di chiamate simultanee. Il servizio Lambda esegue istanze della tua funzione solo quando necessario e scala automaticamente da zero richieste al giorno a migliaia al secondo. Paghi solo per il tempo di calcolo effettivamente utilizzato, quindi non è previsto alcun costo quando il codice non è in esecuzione. La fatturazione al millisecondo di Lambda può ridurre i costi per carichi di lavoro di breve durata.
Esistono molti tipi di eventi di chiamata che possono attivare funzioni di breve durata. Alcuni esempi includono una richiesta HTTP da API Gateway, una pianificazione gestita da una EventBridge regola, un messaggio da un dispositivo IoT o una notifica che un file è stato caricato in un bucket Amazon S3.
Le sessioni interattive con stato, come le sandbox di codifica AI, i notebook interattivi e gli ambienti CI multi-tenant, richiedono ambienti isolati che mantengano lo stato durante le interazioni con gli utenti. Le microVM Lambda hanno un fattore di forma di elaborazione diverso da Event Functions: utilizzano un modello di Dockerfile-based programmazione, allocano un ambiente per sessione (non per richiesta) e fatturano in base a un modello di base più burst anziché a millisecondo. Le MicroVM offrono VM-level isolamento con funzionalità complete del sistema operativo, avvio rapido basato su istantanee, durata fino a 8 ore e riduzione dei costi di inattività. suspend/resume
Long-running oppure i processi steady-state, come i processi batch, le WebSocket connessioni permanenti o i servizi che richiedono più di 15 minuti di elaborazione continua, sono meglio gestiti da Fargate, che può essere eseguito all'infinito. Per dettagli su come Fargate e Lambda si scalano in modo diverso, consulta la scheda Modello di scalabilità e latenza. Fargate fornisce un'allocazione coerente delle risorse per i carichi di lavoro che superano il timeout o i limiti di calcolo di Lambda. Inoltre, le funzioni Lambda durable consentono esecuzioni in più fasi e di lunga durata che mantengono lo stato su più invocazioni. Ogni singola chiamata rispetta comunque il limite di 15 minuti. Le funzioni Durable controllano automaticamente l'avanzamento e riprendono da dove erano state interrotte, quindi la durata totale del flusso di lavoro può superare di gran lunga i 15 minuti senza richiedere Fargate o un'orchestrazione esterna.
Considera il tempo di esecuzione medio e massimo dei tuoi carichi di lavoro. Una funzione Lambda che occasionalmente supera i 15 minuti si guasta in modo imprevedibile e richiede una riprogettazione dell'architettura. L'architettura e le esigenze dell'applicazione determinano come richiamare una funzione. Ad esempio, i modelli di elaborazione in batch hanno requisiti diversi rispetto all'elaborazione dei dati su richiesta. Fargate è adatto a un microservizio che gestisce principalmente l'elaborazione dei dati in batch. Lambda è più semplice da implementare e mantenere per l'elaborazione su richiesta.
- Cost model and predictability
-
Uno dei principali vantaggi dello sviluppo serverless è che si paga solo per le risorse consumate. Le tecnologie serverless sono pay-as-you-go, il che significa che puoi scalare verso l'alto e verso il basso man mano che le tue esigenze applicative cambiano senza pagare per la capacità inattiva. Tuttavia, diversi servizi AWS serverless utilizzano modelli di prezzo diversi che favoriscono modelli di utilizzo diversi.
Pay-per-use i prezzi (Lambda, Step Functions Express, EventBridge) si basano sulle chiamate e sulla durata effettive, senza costi in caso di inattività. Per Lambda, ti vengono addebitati in base al numero di richieste per le tue funzioni e alla durata di esecuzione del codice. Quando il codice non è in esecuzione non viene addebitato alcun costo. Questo modello è adatto a carichi di lavoro imprevedibili o con picchi di traffico in cui il traffico può scendere a zero e per applicazioni in fase iniziale in cui la domanda è incerta.
Capacity-based prezzi (Fargate, Amazon Aurora Serverless, DynamoDB provisioned mode) addebiti per la capacità di elaborazione o di throughput riservata. Sebbene ciò possa comportare costi durante i periodi di traffico ridotto, diventa più conveniente su una scala sostenuta e prevedibile in cui i prezzi per richiesta supererebbero la capacità riservata equivalente. Ad esempio, la modalità provisioning di DynamoDB consente di regolare la capacità di throughput delle tabelle in base alle esigenze, il che può essere più economico per carichi di lavoro con modelli di traffico coerenti.
I prezzi ibridi (DynamoDB on-demand, API Gateway) offrono prezzi per richiesta scalabili linearmente senza impegno iniziale. Ciò garantisce la prevedibilità dei costi senza la necessità di prevedere la capacità, ma può diventare costoso a un throughput molto elevato rispetto alle alternative predisposte.
Baseline plus burst pricing (Lambda MicroVMS) addebita le risorse di base configurate mentre la microVM è in funzione, con la possibilità di aumentare fino a quattro volte la soglia di riferimento durante i picchi di attività. Le microVM sospese riducono i costi preservando al contempo lo stato. Questo modello è adatto a carichi di lavoro interattivi con attività variabili e periodi di inattività.
Modella i modelli di traffico previsti su cicli giornalieri, settimanali e stagionali. I carichi di lavoro con un elevato rapporto tra picco e media favoriscono i prezzi per uso. Steady-state i carichi di lavoro potrebbero trarre vantaggio dai prezzi basati sulla capacità. Puoi anche utilizzare una combinazione: ad esempio, Lambda con pay-per-use per il calcolo variabile insieme alla modalità provisioning di DynamoDB per modelli di accesso ai dati prevedibili.
- Operational complexity
-
I framework per applicazioni web tradizionali raggruppano routing, accesso ai dati, pool di connessioni e integrazioni in un'unica base di codice che puoi distribuire e gestire come un'unica unità. L'impostazione, la configurazione e la manutenzione dei framework, degli ambienti di runtime e dell'infrastruttura rallentano la distribuzione delle funzionalità e le correzioni di bug. Man mano che le applicazioni crescono e si affidano a più sistemi esterni, questa complessità aumenta i tempi di avvio per i nuovi sviluppatori, rende più difficile rintracciare l'origine dei bug e ritarda la distribuzione di nuove funzionalità.
I servizi serverless si basano su una serie di responsabilità operative che riducono o eliminano questo sovraccarico. Invece di gestire tutto in un unico pacchetto, si compongono servizi vagamente connessi in cui ognuno fa bene una cosa con il minor numero possibile di dipendenze.
Gestione minima: Lambda, API Gateway, DynamoDB, Amazon SQS, Amazon SNS e Step Functions non richiedono il provisioning EventBridge, l'applicazione di patch o la pianificazione della capacità del server. Non è necessario configurare pool di connessioni, configurare ambienti di runtime o gestire l'infrastruttura di scalabilità. Puoi concentrarti interamente sulla scrittura o sulla generazione di codice che risolva i problemi aziendali.
Gestione dei container: Fargate richiede la creazione e la manutenzione delle immagini dei container, la configurazione delle definizioni delle attività e la gestione delle pipeline di distribuzione. Non gestisci l'infrastruttura sottostante, ma sei il proprietario del ciclo di vita del container. Questo modello è adatto ai team che necessitano di runtime personalizzati o dispongono di carichi di lavoro containerizzati esistenti da eseguire senza gestire i cluster.
Infrastruttura come complessità del codice: AWS Serverless Application Model
riduce al minimo la complessità IaC per le architetture serverless con sintassi abbreviata e test locali. Kit di sviluppo per il cloud AWS (AWS CDK) e Terraform forniscono più potenza per applicazioni complesse al costo di curve di apprendimento più ripide e più codice da mantenere.
Considerate le competenze esistenti del vostro team, il numero di servizi da gestire e gli standard operativi della vostra organizzazione. Se i tuoi team dedicano più tempo alla manutenzione dell'infrastruttura che alla creazione di funzionalità, passare alla gestione minima può liberare risorse per attività di maggior valore.
- Scaling model and latency
-
La scalabilità di un servizio influisce direttamente sulla reattività dell'applicazione sotto carico. Nelle architetture serverless, la scalabilità avviene automaticamente, ma servizi diversi utilizzano meccanismi diversi che influiscono sulla latenza e sul throughput.
Per-request scaling (Lambda) crea un nuovo ambiente di esecuzione per ogni richiesta concorrente. Lambda richiama la funzione in un ambiente di esecuzione, che fornisce un ambiente di runtime sicuro e isolato che gestisce i processi e le risorse necessari per eseguire la funzione. Ciò fornisce una risposta quasi istantanea ai picchi di traffico, scalabile da zero a migliaia di esecuzioni simultanee in pochi secondi.
Tuttavia, il ridimensionamento per richiesta introduce partenze a freddo, ovvero ritardi di inizializzazione che si verificano quando Lambda crea un nuovo ambiente di esecuzione. Il fattore che contribuisce maggiormente all'avvio a freddo è il tempo impiegato da Lambda per l'inizializzazione della funzione, che include il caricamento del codice della funzione, l'avvio del runtime e l'inizializzazione del codice della funzione. Per i carichi di lavoro Java, Python e .NET, Lambda SnapStart può migliorare le prestazioni di avvio fino a 10 volte senza costi aggiuntivi scattando un'istantanea dell'ambiente di esecuzione inizializzato e memorizzandola nella cache per un accesso a bassa latenza. Per altri runtime, puoi mitigare gli avviamenti a freddo con Provisioned Concurrency a un costo aggiuntivo.
Task-level scaling (Fargate) aggiunge o rimuove istanze di container in base a metriche quali l'utilizzo della CPU, l'utilizzo della memoria o il numero di richieste. La scalabilità aggiunge nuove attività in pochi secondi o minuti ed evita partenze a freddo per le richieste gestite dalle attività esistenti. Una volta che un'attività è in esecuzione, rimane inattiva per tutta la sua durata, garantendo una latenza costante per tutte le richieste gestite.
Throughput-based lo scaling (DynamoDB, Kinesis) regola la read/write capacità o il numero di frammenti in base alla domanda. La modalità on-demand di DynamoDB è scalabile istantaneamente per adattarsi ai modelli di traffico del carico di lavoro. La modalità provisioned richiede una configurazione con scalabilità automatica ma fornisce un throughput prevedibile a costi per richiesta inferiori. Con l'architettura serverless e DynamoDB, i pool di connessioni non sono necessari per connettere e scalare rapidamente il database. Invece, regolate la capacità di throughput delle vostre tabelle in base alle esigenze.
Per requisiti di latenza rigorosi (P99 inferiore a 100 ms), valutate attentamente il comportamento di avvio a freddo. Lambda con Provisioned Concurrency o Fargate con attività preriscaldate fornisce una latenza SnapStart prevedibile per i carichi di lavoro delle API. Per i carichi di lavoro di elaborazione dati in cui la latenza è meno critica, il ridimensionamento Lambda standard è in genere sufficiente.
- Integration and composability
-
Le architetture serverless sono composte da più servizi che comunicano tramite eventi. Un evento rappresenta un cambiamento di stato o un aggiornamento. Ad esempio, un articolo inserito in un carrello, un file caricato su un sistema di storage o un ordine pronto per la spedizione. La profondità dell'integrazione nativa tra i servizi influisce sulla velocità di creazione e sulla quantità di codice personalizzato da scrivere.
Integrazione nativa profonda: Lambda si integra con oltre 200 AWS servizi come sorgenti di eventi. Alcuni servizi possono attivare direttamente le funzioni Lambda. Ad esempio, quando un'immagine viene aggiunta a un bucket Amazon S3, è possibile attivare Lambda per ridimensionarla. Alcuni servizi non possono richiamare direttamente Lambda, ma puoi utilizzare una mappatura dell'origine degli eventi, che è un meccanismo di polling che legge da una fonte di eventi e richiama una funzione Lambda. Puoi utilizzare le mappature delle sorgenti degli eventi per elaborare gli elementi di uno stream o di una coda in: DynamoDB Streams, Amazon Kinesis, Amazon MQ, Amazon MSK, self-managed e Amazon SQS. Apache Kafka
Flessibilità nell'instradamento degli eventi: EventBridge fornisce un routing basato sui contenuti con regole di filtro, che consentono a un singolo bus di eventi di indirizzare gli eventi verso destinazioni diverse in base al contenuto dell'evento. Amazon SNS offre un fan-out basato su argomenti per recapitare messaggi a più abbonati contemporaneamente. Amazon SQS offre un buffering point-to-point in cui i consumatori raccolgono attivamente i messaggi dalla coda. Le combinazioni più comuni includono il routing di eventi Amazon SNS a una coda Amazon SQS come buffer per i consumatori a valle, l'estrazione di eventi da uno stream EventBridge o da una coda con Pipes e l'instradamento degli eventi a Kinesis per l'analisi. EventBridge
Modelli di integrazione delle API: API Gateway offre due approcci di integrazione. Le integrazioni proxy trasmettono direttamente tutte le informazioni sulle richieste a una funzione Lambda per l'elaborazione, che è più semplice da configurare. Non-proxy Le integrazioni (personalizzate) possono trasformare i dati prima che raggiungano la funzione e prima che l'output ritorni ai client, il che è utile per la migrazione del codice precedente o per mantenere il codice funzionale incentrato sulla logica aziendale. L'API REST offre il set di funzionalità più ampio, tra cui caching, convalida delle richieste e WAF. L'API HTTP offre la latenza e il costo più bassi. AWS AppSync fornisce abbonamenti in tempo reale e GraphQL. Gli URL delle funzioni Lambda forniscono l'endpoint HTTPS a funzione singola più semplice senza richiedere API Gateway. Per le comunicazioni bidirezionali in cui il server deve inviare dati ai client, le WebSocket API Gateway forniscono connessioni permanenti adatte per chat, dashboard in tempo reale e giochi multiplayer.
A causa della scarsa connessione tra i componenti di un sistema basato sugli eventi, le funzioni di calcolo non sono a conoscenza di altre attività dell'architettura. È possibile scalare i componenti in modo indipendente, un servizio può fallire senza influire sugli altri servizi e gli eventi possono essere instradati, memorizzati nel buffer in modo flessibile e fornire un registro per il controllo.
- Portability and standards
-
La scelta dei servizi serverless influisce sulla portabilità dell'architettura tra gli ambienti. Le applicazioni serverless di solito comprendono diversi AWS servizi, integrati con codice personalizzato eseguito nelle funzioni Lambda. Sebbene Lambda possa essere integrato con la maggior parte dei AWS servizi, dovresti considerare il compromesso tra una profonda integrazione della piattaforma e la capacità di eseguire carichi di lavoro in altri ambienti.
AWS i servizi nativi (Lambda, Step Functions EventBridge, DynamoDB) forniscono l'integrazione più profonda e il più basso sovraccarico operativo. Puoi utilizzare uno qualsiasi di questi servizi tramite l' AWS SDK senza dover installare applicazioni o configurare server. Acquisire esperienza nell'uso di questi servizi tramite il codice nelle funzioni Lambda è un passo importante per produrre applicazioni serverless ben progettate. Tuttavia, questi servizi creano un abbinamento ad API e formati di eventi AWS specifici, il che significa che la migrazione verso un altro cloud richiede un refactoring significativo.
Standards-based i servizi (Fargate con Docker contenitori, Amazon MQ con, Amazon MSK conApache Kafka) AMQP funzionano su protocolli aperti o tecnologie open source. Se hai bisogno di un runtime personalizzato non fornito da AWS, puoi creare e distribuire un'immagine del contenitore personalizzata su Fargate. Amazon MSK offre Apache Kafka compatibilità per i team con competenze esistenti in Kafka. Queste opzioni rendono più fattibile la portabilità dei carichi di lavoro a scapito di una maggiore complessità operativa e di una minore integrazione con altri servizi. AWS
Framework di distribuzione: AWS Serverless Application Model generano modelli e sono solo. Kit di sviluppo per il cloud AWS (AWS CDK)
CloudFormation AWS AWS Serverless Application Model si estende CloudFormation con una sintassi abbreviata incentrata sull'accelerazione dello sviluppo serverless, offrendo definizioni ottimizzate per le risorse API Gateway, Lambda e Step Functions, oltre a test Lambda locali tramite SAM CLI. Terraformfornisce la definizione di un'infrastruttura multi-cloud utilizzando un unico flusso di lavoro tra i provider, ma con strumenti meno specifici per il serverless e capacità di test Lambda locali limitate.
I contenitori e la messaggistica basata su standard possono migliorare la portabilità per i requisiti multi-cloud. I servizi serverless nativi offrono una stretta integrazione con altri AWS servizi, il che può semplificare lo sviluppo quando il carico di lavoro viene eseguito principalmente su. AWS
