Che cos'è l'architettura serverless?

Per serverless computing si intende un cambiamento di paradigma nell'ambito dello sviluppo delle applicazioni che consente agli sviluppatori di concentrarsi sulla scrittura del codice senza preoccuparsi dell'infrastruttura. Offre un'ampia gamma di vantaggi rispetto al computing tradizionale, tra cui nessuna gestione dei server, nessun provisioning anticipato, scalabilità automatica e pagamento solo per le risorse utilizzate. Questi vantaggi rendono l'architettura serverless ideale per casi d'uso come applicazioni HTTP stateless, backend web, per dispositivi mobili e IoT, elaborazione dei dati in modalità flusso e batch, chatbot e altro ancora.


Portafoglio di piattaforme di serverless computing GCP

Cloud Functions

Funzioni ed eventi serverless

Cloud Functions

Una piattaforma di computing basata su eventi per connettere ed estendere facilmente i servizi cloud di Google e di terze parti e per creare applicazioni che garantiscono la scalabilità da zero fino a un livello globale.

Ulteriori informazioni  
Ambiente standard App Engine

Applicazioni HTTP serverless

Ambiente standard di App Engine

Una piattaforma serverless completamente gestita per i backend basati sul Web e sulle API. Utilizza i linguaggi di sviluppo più diffusi senza preoccuparti della gestione dell'infrastruttura.

Ulteriori informazioni  
Cloud Run

Container serverless

Cloud Run

Una piattaforma di calcolo serverless che consente di eseguire container stateless richiamabili tramite richieste HTTP. Cloud Run è disponibile come piattaforma completamente gestita, con pagamento a consumo, e anche come parte di Anthos.

Ulteriori informazioni  

Qual è la piattaforma di serverless computing più adatta a te?

Opzioni serverless

* L'ambiente standard di App Engine supporta Node.js, Python, Java, Go, PHP

* Cloud Functions supporta Node.js, Python, Go

Casi d'uso

Applicazione web

Applicazioni web

L'ambiente standard di App Engine è ideale per app web con operazioni minime eseguite in Node.js, Python, PHP, Java e Go. Scrivi le tue applicazioni in modo standard e idiomatico utilizzando librerie di qualsiasi linguaggio. I rapidi tempi di deployment e la reattività della scalabilità rendono l'ambiente standard di App Engine particolarmente adatto a carichi di lavoro complessi.

Elaborazione backend asincrona

Elaborazione backend asincrona

Cloud Functions consente di rispondere agli eventi di dati nell'ambito dell'elaborazione leggera e cloud, come il ridimensionamento di un'immagine caricata su Cloud Storage o la convalida dei dati quando un valore viene modificato nel database Firestore.

Backend per dispositivi mobili

Backend per dispositivi mobili

Per i backend basati su API REST tradizionali per le app per dispositivi mobili, l'ambiente standard di App Engine è una piattaforma applicativa che monitora, aggiorna e scala l'ambiente di hosting. Tutto ciò che devi fare è scrivere il codice per i servizi di backend mobili. Firebase fornisce una suite di servizi di backend avanzati che si integrano direttamente nella tua app per dispositivi mobili: database NoSQL in tempo reale, autenticazione, hosting, archiviazione di file e altro ancora. Firebase si integra con Cloud Functions in modo che tu possa collegarti facilmente con il resto dei servizi di Google Cloud Platform.

API

API

Se stai creando un'API semplice (un piccolo insieme di funzioni a cui accedere tramite HTTP o Cloud Pub/Sub), ti raccomandiamo l'uso di Cloud Functions. Questa piattaforma è stata progettata per grandi carichi di lavoro e il suo paradigma di programmazione (funzioni) aiuta a mantenere ben organizzato il codice backend di dimensioni ridotte. Per un'API più complessa (come un'API REST con molte route) raccomandiamo l'uso dell'ambiente standard App Engine, in modo che sia più semplice organizzare le tue numerose funzioni. Se dipendi da Cloud Endpoints per la gestione delle API, raccomandiamo l'uso dell'ambiente standard App Engine con Python 2.7 e Java 8, poiché supporta Cloud Endpoints.

Operazioni periodiche

Operazioni periodiche

Cloud Scheduler può inviare richieste HTTP programmate per attivare operazioni in base a una pianificazione definita. Può anche scegliere come target App Engine o endpoint HTTP come Cloud Functions e Cloud Run.

Prototipazione rapida e stitching delle API

Prototipazione rapida e stitching delle API

Per progetti piccoli o di "hackathon" che comportano una prototipazione rapida e lo stitching di più API e servizi, raccomandiamo l'uso di Cloud Functions. Il suo paradigma di programmazione ti permette di sviluppare velocemente sia app ridotte sia il "glue code" che integra le API e i servizi esistenti.

Esecuzione di container indipendenti dal provider

Esecuzione di container indipendenti dal provider

I container Docker sono uno standard di settore e possono essere eseguiti nel cloud oppure on-premise. Cloud Run può eseguire i container in base a un meccanismo richiesta-risposta serverless. Raccomandiamo l'uso di Cloud Run a meno che non ti serva un hardware personalizzato come GPU o sia necessario un cluster Kubernetes; in tal caso puoi eseguire Cloud Run su GKE nel tuo cluster Google Kubernetes Engine.

Combinazione di carichi di lavoro serverless e stateful

Combinazione di carichi di lavoro serverless e stateful

Cloud Run for Anthos ti consente di eseguire facilmente i tuoi carichi di lavoro serverless e stateful in contemporanea. Ad esempio puoi eseguire il deployment di MongoDB dal Marketplace nel tuo cluster Anthos GKE per utilizzarlo come un archivio di documenti per i tuoi carichi di lavoro serverless. Anthos ti offre la flessibilità per eseguire qualsiasi cosa nel tuo cluster Kubernetes e, contemporaneamente, puoi usare Cloud Run for Anthos per eseguire il deployment dei carichi di lavoro serverless.

Confronto tra prodotti

Ambiente standard di App Engine Cloud Functions Cloud Run Cloud Run for Anthos
Artefatto di deployment App Funzione Container Container
Scalabilità fino a zero Segno di spunta Segno di spunta Segno di spunta Pod2
Livello gratuito Segno di spunta Segno di spunta Segno di spunta
Websocket Segno di spunta
Linguaggi Java, Node.js, Python, Go, PHP Node.js, Python, Go Qualsiasi Qualsiasi
Controlli di accesso Oauth 2.0, CICP, Firebase Authentication, Accedi con Google, API Users Autorizzazione IAM invoker Autorizzazione IAM invoker, CICP, Accedi con Google, Firebase Authentication Solo cluster, solo VPC
HTTP/2 e gRPC Segno di spunta
Dominio personalizzato Segno di spunta Segno di spunta Segno di spunta
Timeout richiesta 1 minuto3 9 minuti 15 minuti 15 minuti
GPU e TPU Segno di spunta
Connettività VPC Segno di spunta Segno di spuntabeta1 Sulla roadmap Segno di spunta

1. Il software beta non dispone di SLA.

2. Cloud Run su GKE scala il numero di pod fino a zero. Il numero di nodi per cluster non può scalare fino a zero, questi nodi sono fatturati in assenza di richieste.

3. Scalabilità automatica: scadenza di 60 secondi per le richieste HTTP.

Suggerimenti avanzati e best practice

Qui trovi alcuni fattori aggiuntivi che è opportuno considerare.