Applicazione Web senza server

Questa architettura di riferimento illustra un'applicazione Web senza server. L'applicazione rende disponibile il contenuto statico di Archiviazione BLOB di Azure e implementa un'API che usa Funzioni di Azure. L'API legge i dati da Azure Cosmos DB e restituisce i risultati all'app Web.

Due implementazioni di riferimento per questa architettura sono disponibili in GitHub: Drone Delivery App (ARM & Azure Pipelines) e To Do App (Bicep & GitHub Actions).

Architettura

Scaricare un file di Visio di questa architettura.

Il termine senza server ha due significati distinti ma correlati:

• Back-end come servizio (BaaS). I servizi cloud back-end, ad esempio database e archiviazione, forniscono API che consentono alle applicazioni client di connettersi direttamente a questi servizi.
• Funzioni come servizio (FaaS). In questo modello una "funzione" è un frammento di codice che viene distribuito nel cloud ed eseguito all'interno di un ambiente di hosting che elimina completamente i server che eseguono il codice.

Entrambe le definizioni hanno in comune l'idea che gli sviluppatori e il personale DevOps non dovranno distribuire, configurare o gestire i server. Questa architettura di riferimento è incentrata sull'uso di Funzioni di Azure faaS, anche se la gestione di contenuto Web da Archiviazione BLOB di Azure potrebbe essere un esempio di BaaS. Alcune caratteristiche importanti di FaaS sono:

1. Le risorse di calcolo vengono allocate in modo dinamico dalla piattaforma in base alle esigenze.
2. Prezzi basati sul consumo: vengono addebitati solo i costi per le risorse di calcolo usate per eseguire il codice.
3. Scalabilità delle risorse di calcolo su richiesta in base al traffico, senza che lo sviluppatore debba eseguire una qualsiasi configurazione.

Le funzioni vengono eseguite quando si verifica un trigger esterno, ad esempio una richiesta HTTP o un messaggio che arriva su una coda. In questo modo, lo stile di architettura basata su eventi diventa naturale per le architetture senza server. Per coordinare il lavoro tra i componenti dell'architettura, è consigliabile usare i broker di messaggi o i modelli di pubblicazione/sottoscrizione. Per informazioni sulla scelta tra tecnologie di messaggistica in Azure, vedere Scegliere tra i servizi di Azure che recapitano messaggi.

Componenti

Questa architettura è costituita dai componenti seguenti:

Archiviazione BLOB. Il contenuto Web statico, ad esempio i file HTML, CSS e JavaScript, viene archiviato in Archiviazione BLOB di Azure e servito ai client usando l'hosting di siti Web statici. Tutte le interazioni dinamiche avvengono tramite il codice JavaScript che effettua chiamate alle API back-end. Non è disponibile alcun codice sul lato server per il rendering della pagina Web. L'hosting di siti Web statici supporta l'indicizzazione dei documenti e le pagine di errore 404 personalizzate.

Rete CDN. Usare la rete per la distribuzione di contenuti di Azure, ovvero la rete CDN, per memorizzare nella cache il contenuto in modo da ridurre la latenza e accelerare la distribuzione del contenuto, nonché offrire un endpoint HTTPS.

App per le funzioni. Funzioni di Azure è un'opzione di calcolo senza server. Usa un modello basato su eventi, in cui un frammento di codice, vale a dire una "funzione", viene richiamato da un trigger. In questa architettura la funzione viene richiamata quando un client effettua una richiesta HTTP. La richiesta viene sempre instradata attraverso un gateway API, descritto di seguito.

Gestione API. Azure Gestione API fornisce un gateway API che si trova davanti alla funzione HTTP. È possibile usare Gestione API per pubblicare e gestire le API usate dalle applicazioni client. L'uso di un gateway consente di separare l'applicazione front-end dalle API back-end. Ad esempio, Gestione API può riscrivere gli URL, trasformare le richieste prima di raggiungere il back-end, impostare intestazioni di richiesta o risposta e così via.

Gestione API può essere usato anche per implementare le problematiche trasversali quali:

• applicazione delle quote di uso e dei limiti di frequenza
• convalida dei token OAuth per l'autenticazione
• abilitazione di richieste multiorigine (CORS)
• memorizzazione nella cache delle risposte
• monitoraggio e registrazione delle richieste

Se l'utente non ha bisogno di tutte le funzionalità offerte da Gestione API, un'altra opzione consiste nell'usare Proxy di Funzioni. Questa funzionalità di Funzioni di Azure consente di definire un'unica superficie API per più app per le funzioni, tramite la creazione di route per le funzioni di back-end. Proxy di Funzioni può eseguire anche trasformazioni limitate sulla richiesta e la risposta HTTP. Tuttavia, non offre lo stesso numero di funzionalità basate su criteri di Gestione API.

Azure Cosmos DB. Azure Cosmos DB è un servizio di database multimodelli. Per questo scenario, l'applicazione per le funzioni recupera i documenti da Azure Cosmos DB in risposta alle richieste HTTP GET dal client.

MICROSOFT Entra ID (Microsoft Entra ID). Gli utenti accedono all'applicazione Web usando le credenziali dell'ID Microsoft Entra. Microsoft Entra ID restituisce un token di accesso per l'API, che l'applicazione Web usa per autenticare le richieste API (vedere Autenticazione).

Monitoraggio di Azure. Monitoraggio di Azure raccoglie le metriche relative alla prestazioni dei servizi di Azure distribuiti nella soluzione. La visualizzazione delle metriche in una dashboard consente di ottenere visibilità sull'integrità della soluzione. Vengono raccolti anche i log applicazioni.

Azure Pipelines. Azure Pipelines è un servizio di integrazione continua (CI) e recapito continuo (CD) che compila, testa e distribuisce l'applicazione.

GitHub Actions. Il flusso di lavoro è un processo automatizzato (CI/CD) configurato nel repository GitHub. Con un flusso di lavoro è possibile compilare, testare, assemblare o distribuire qualsiasi progetto in GitHub.

Dettagli dello scenario

Potenziali casi d'uso

Questa soluzione di consegna tramite drone è ideale per gli aeromobili, l'aviazione, il settore aerospaziale e la robotica.

Consigli

Piani dell'app per le funzioni

Funzioni di Azure supporta due modelli di hosting. Il piano a consumo consente di allocare automaticamente le funzionalità di calcolo durante l'esecuzione del codice. Il piano di servizio app consente di allocare un set di macchine virtuali per il codice. Definisce anche il numero di macchine virtuali e le relative dimensioni.

Si noti che il piano di servizio app non è strettamente serverless, in base alla definizione specificata in precedenza. Il modello di programmazione è lo stesso, ma lo stesso codice di funzione può essere eseguito sia in un piano a consumo che in un piano di servizio app.

Ecco alcuni fattori da considerare quando si sceglie il tipo di piano da usare:

• Avvio a freddo. Con il piano a consumo, una funzione che non è stata richiamata di recente riscontrerà una maggiore latenza alla successiva esecuzione. Questa maggiore latenza è dovuta all'allocazione e alla preparazione dell'ambiente di runtime. Si tratta in genere dell'ordine di secondi, ma dipende da diversi fattori, tra cui il numero di dipendenze che devono essere caricate. Per altre informazioni, vedere Understanding Serverless Cold Start (Informazioni sull'avvio a freddo senza server). L'avvio a freddo riguarda in genere più i carichi di lavoro interattivi, ovvero i trigger HTTP, che i carichi di lavoro asincroni basati sui messaggi, ovvero le code o i trigger basati sugli eventi, perché la maggiore latenza viene osservata direttamente dagli utenti.
• Periodo di timeout. Nel piano a consumo il timeout dell'esecuzione di una funzione si verifica dopo un periodo di tempo configurabile per un massimo di 10 minuti.
• Isolamento della rete virtuale. L'uso di un piano di servizio app consente alle funzioni di essere eseguite all'interno di un ambiente del servizio app, ovvero un ambiente di hosting dedicato e isolato.
• Modello di prezzi. Il piano a consumo viene fatturato in base al numero di esecuzioni e consumo di risorse (memoria × tempo di esecuzione). Il piano di servizio app viene fatturato a tariffa oraria in base allo SKU dell'istanza della macchina virtuale. Spesso, il piano a consumo può essere più economico rispetto a un piano di servizio app, perché l'utente paga solo per le risorse di calcolo che usa. Ciò è particolarmente vero se il traffico presenta picchi e valli. Tuttavia, se un'applicazione riscontra una velocità effettiva elevata costante, il piano di servizio app può costare meno del piano a consumo.
• Ridimensionamento. Un grande vantaggio del modello a consumo è che viene ridimensionato in modo dinamico a seconda delle esigenze, in base al traffico in ingresso. Anche se questa scalabilità si verifica rapidamente, esiste ancora un periodo di aumento. Per alcuni carichi di lavoro, l'utente potrebbe voler eseguire deliberatamente un provisioning eccessivo delle macchine virtuali, in modo che sia possibile gestire i picchi di traffico con un tempo di preparazione pari a zero. In tal caso, prendere in considerazione un piano di servizio app.

Limiti di app per le funzioni

Un'app per le funzioni ospita l'esecuzione di una o più funzioni. È possibile usare un'app per le funzioni per raggruppare diverse funzioni come un'unità logica. All'interno di un'app per le funzioni le funzioni condividono le stesse impostazioni applicazione, piano di hosting e ciclo di vita di distribuzione. Ogni app per le funzioni ha il proprio nome host.

Usare le app per le funzioni per raggruppare le funzioni che condividono lo stesso ciclo di vita e le stesse impostazioni. Le funzioni che non condividono lo stesso ciclo di vita devono essere ospitate in app per le funzioni diverse.

È consigliabile adottare un approccio ai microservizi, in cui ogni app per le funzioni rappresenta un microservizio, se possibile costituito da diverse funzioni correlate. In un'architettura dei microservizi, i servizi dovrebbero avere un regime di controllo libero e un'elevata coesione funzionale. Regime di controllo libero significa che è possibile apportare modifiche a un servizio senza dover contemporaneamente aggiornare gli altri servizi. Coesivo significa che un servizio ha un unico obiettivo ben definito. Per altre informazioni su questi concetti, vedere Progettazione di microservizi: analisi del dominio.

Associazioni di funzioni

Usare le associazioni di funzioni quando possibile. Le associazioni offrono una modalità dichiarativa per connettere il codice ai dati e integrare altri servizi di Azure. Un'associazione di input consente di compilare un parametro di input da un'origine dati esterna. Un'associazione di output invia il valore restituito della funzione a un sink di dati, ad esempio una coda o un database.

Ad esempio, la GetStatus funzione nell'implementazione di riferimento usa l'associazione di input di Azure Cosmos DB. Questa associazione è configurata per cercare un documento in Azure Cosmos DB, usando i parametri di query acquisiti dalla stringa di query nella richiesta HTTP. Se il documento viene trovato, viene passato alla funzione come parametro.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

Tramite le associazioni, non è necessario scrivere il codice che comunica direttamente con il servizio e questo semplifica il codice della funzione e inoltre consente di eliminare i dettagli dell'origine dati o del sink. In alcuni casi, tuttavia, potrebbe essere necessaria una logica più complessa rispetto a quella offerta dall'associazione. In tal caso, usare direttamente gli SDK del client Azure.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Scalabilità

Funzioni. Per il piano a consumo, il trigger HTTP viene ridimensionato in base al traffico. Esiste un limite al numero di istanze di funzione simultanee, ma ogni istanza può elaborare più richieste alla volta. Per un piano di servizio app, il trigger HTTP viene ridimensionato in base al numero di istanze della macchina virtuale, che può essere un valore fisso oppure può essere ridimensionato in modo automatico in base a un set di regole di scalabilità automatica. Per informazioni vedere Ridimensionamento e hosting di Funzioni di Azure.

Azure Cosmos DB. La capacità di velocità effettiva per Azure Cosmos DB viene misurata in unità richiesta (UR). Una velocità effettiva di 1 UR corrisponde alla velocità effettiva necessaria per l'operazione GET su un documento da 1 kB. Per ridimensionare un contenitore di Azure Cosmos DB oltre 10.000 UR, è necessario specificare una chiave di partizione quando si crea il contenitore e includere la chiave di partizione in ogni documento creato. Per altre informazioni sulle chiavi di partizione, vedere Partizionamento e ridimensionamento in Azure Cosmos DB.

Gestione API. Gestione API consente di aumentare e supportare il ridimensionamento automatico basato su regole. Il processo di ridimensionamento richiede almeno 20 minuti. Se ci sono picchi di traffico, è necessario eseguire il provisioning per il picco di traffico massimo previsto. Tuttavia, la scalabilità automatica è utile per la gestione delle variazioni orarie o giornaliere del traffico. Per altre informazioni, vedere Ridimensionare automaticamente un'istanza di Gestione API di Azure.

Ripristino di emergenza

La distribuzione illustrata di seguito si trova in una sola area di Azure. Per un approccio più resiliente al ripristino di emergenza, sfruttare le funzionalità di distribuzione a livello geografico nei vari servizi:

• Gestione API supporta la distribuzione in più aree che può essere usata per distribuire una sola istanza di Gestione API in qualsiasi numero di aree di Azure. Per altre informazioni, vedere Come distribuire un'istanza del servizio Gestione API di Azure in più aree di Azure.

• Usare Gestione traffico per indirizzare le richieste HTTP all'area primaria. Se l'app per le funzioni in esecuzione in tale area diventa disponibile, Gestione traffico può effettuare il failover all'area secondaria.

• Azure Cosmos DB supporta più aree di scrittura, che consentono di scrivere in qualsiasi area aggiunta all'account Azure Cosmos DB. Se non si abilita la scrittura multipla, è comunque possibile eseguire il failover dell'area di scrittura primaria. Gli SDK client di Azure Cosmos DB e le associazioni di funzioni di Azure gestiscono automaticamente il failover, quindi non è necessario aggiornare le impostazioni di configurazione dell'applicazione.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Autenticazione

L'API GetStatus nell'implementazione di riferimento usa Microsoft Entra ID per autenticare le richieste. Microsoft Entra ID supporta il protocollo OpenID Connessione, ovvero un protocollo di autenticazione basato sul protocollo OAuth 2.

In questa architettura l'applicazione client è un'applicazione a pagina singola che viene eseguita nel browser. Questo tipo di applicazione client non può mantenere un segreto client o un codice di autorizzazione nascosto, quindi il flusso di concessione implicita è appropriato. Vedere Which OAuth 2.0 flow should I use? (Quale flusso di OAuth 2.0 è necessario usare?). Di seguito è riportato il flusso completo:

1. L'utente fa clic sul collegamento "Accedi" nell'applicazione Web.
2. Il browser viene reindirizzato alla pagina di accesso di Microsoft Entra.
3. L'utente effettua l'accesso.
4. Microsoft Entra ID reindirizza nuovamente all'applicazione client, incluso un token di accesso nel frammento di URL.
5. Quando l'applicazione Web chiama l'API, include il token di accesso nell'intestazione Autenticazione. L'ID dell'applicazione viene inviato come attestazione dei destinatari ("aud") nel token di accesso.
6. L'API back-end convalida il token di accesso.

Per configurare l'autenticazione:

• Registrare un'applicazione nel tenant di Microsoft Entra. Questa operazione genera un ID applicazione, che il client include con l'URL di accesso.

• Abilitare l'autenticazione Di Microsoft Entra all'interno dell'app per le funzioni. Per altre informazioni, vedere Autenticazione e autorizzazione nel servizio app di Azure.

• Aggiungere il criterio validate-jwt a Gestione API per preautorizzare la richiesta convalidando il token di accesso.

Per altri dettagli, vedere il file leggimi di GitHub.

È consigliabile creare registrazioni di app separate in Microsoft Entra ID per l'applicazione client e l'API back-end. Concedere all'applicazione client l'autorizzazione per chiamare l'API. Questo approccio garantisce la possibilità di definire più API e client e controllare le autorizzazioni per ognuno.

All'interno di un'API, usare gli ambiti per assicurare alle applicazioni un controllo specifico sulle autorizzazioni che richiedono da un utente. Ad esempio, un'API potrebbe avere gli ambiti Read e Write e una determinata app client potrebbe chiedere all'utente di autorizzare solo le autorizzazioni Read.

Autorizzazione

In molte applicazioni, l'API back-end deve verificare se un utente dispone dell'autorizzazione per eseguire una determinata azione. È consigliabile usare l'autorizzazione basata sulle attestazioni, in cui le informazioni sull'utente vengono trasmesse dal provider di identità (in questo caso, MICROSOFT Entra ID) e usate per prendere decisioni di autorizzazione. Ad esempio, quando si registra un'applicazione in Microsoft Entra ID, è possibile definire un set di ruoli applicazione. Quando un utente accede all'applicazione, Microsoft Entra ID include un'attestazione roles per ogni ruolo concesso all'utente, inclusi i ruoli ereditati tramite l'appartenenza al gruppo.

Il token ID restituito da Microsoft Entra ID al client contiene alcune delle attestazioni dell'utente. All'interno dell'app per le funzioni, queste attestazioni sono disponibili nell'intestazione X-MS-CLIENT-PRINCIPAL della richiesta. Tuttavia, è più semplice leggere queste informazioni dai dati di associazione. Per altre attestazioni, usare Microsoft Graph per eseguire query su Microsoft Entra ID. L'utente deve fornire il consenso a questa azione durante l'accesso.

Per altre informazioni, vedere Uso delle identità client.

CORS

In questa architettura di riferimento, l'applicazione Web e l'API non condividono la stessa origine. Ciò significa che quando l'applicazione chiama l'API, si tratta di una richiesta tra le origini. La sicurezza del browser impedisce a una pagina Web di creare richieste AJAX per un altro dominio. Questa restrizione è nota come criteri di corrispondenza dell'origine e impedisce a un sito dannoso di leggere dati sensibili da un altro sito. Per abilitare una richiesta multiorigine, aggiungere un criterio Condivisione risorse tra le origini, ovvero CORS al gateway di Gestione API:

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

In questo esempio, l'attributo allow-credentials è true. Questo autorizza il browser a inviare le credenziali, compresi i cookie, con la richiesta. In caso contrario, per impostazione predefinita il browser non invia le credenziali con una richiesta tra le origini.

Applicare HTTPS

Per garantire la massima sicurezza, richiedere HTTPS attraverso la pipeline della richiesta:

• Rete CDN. Per impostazione predefinita, la rete CDN di Azure supporta HTTPS nel sottodominio *.azureedge.net. Per abilitare HTTPS nella rete CDN per i nomi di dominio personalizzati, vedere Esercitazione: Configurare HTTPS in un dominio personalizzato della rete CDN di Azure.

• Hosting di siti Web statici. Abilitare l'opzione "Trasferimento sicuro obbligatorio" nell'account di archiviazione. Quando questa opzione è abilitata, l'account di archiviazione consente solo le richieste dalle connessioni HTTPS sicure.

• Gestione API. Configurare le API affinché usino solo il protocollo HTTPS. È possibile configurarle nel portale di Azure o tramite un modello di Resource Manager:

  {
      "apiVersion": "2018-01-01",
      "type": "apis",
      "name": "dronedeliveryapi",
      "dependsOn": [
          "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
      ],
      "properties": {
          "displayName": "Drone Delivery API",
          "description": "Drone Delivery API",
          "path": "api",
          "protocols": [ "HTTPS" ]
      },
      ...
  }
  

• Funzioni di Azure. Abilitare l'impostazione "Solo HTTPS".

Bloccare le app per le funzioni

Tutte le chiamate alla funzione devono passare attraverso il gateway dell'API. Per ottenere questo risultato, attenersi alla procedura seguente:

• Configurare l'app per le funzioni per richiedere una chiave della funzione. Quando chiama l'app per le funzioni, il gateway di Gestione API include la chiave della funzione. Questo impedisce ai client di chiamare direttamente la funzione, ignorando il gateway.

• Il gateway di Gestione API ha un indirizzo IP statico. Limitare Funzioni di Azure per consentire solo le chiamate da tale indirizzo IP statico. Per altre informazioni, vedere Restrizioni IP statico del Servizio app di Azure. Questa funzionalità è disponibile solo per i servizi di livello Standard.

Proteggere i segreti dell'applicazione

Non archiviare i segreti dell'applicazione, come le credenziali del database, nel codice o nei file di configurazione. Usare invece le impostazioni dell'app, che vengono archiviate con crittografia in Azure. Per altre informazioni vedere Sicurezza in Servizio app di Azure e Funzioni di Azure.

In alternativa, è possibile archiviare i segreti dell'applicazione in Key Vault. In questo modo è possibile centralizzare l'archiviazione dei segreti, controllarne la distribuzione e monitorare i momenti e la modalità in cui sono accessibili. Per altre informazioni vedere Configurare un'applicazione Web di Azure per la lettura di un segreto da un insieme di credenziali delle chiavi. Si noti tuttavia che i trigger delle funzioni e le associazioni caricano le impostazioni di configurazione dalle impostazioni dell'app. Non esiste alcun modo predefinito per configurare i trigger e le associazioni per l'uso dei segreti di Key Vault.

DevOps

Distribuzione front-end

Il front-end di questa architettura di riferimento è un'applicazione a pagina singola, con JavaScript che accede alle API back-end serverless e al contenuto statico che offre un'esperienza utente rapida. Di seguito sono riportate alcune considerazioni importanti per un'applicazione di questo tipo:

• Distribuire l'applicazione in modo uniforme agli utenti in un'ampia area geografica con un rete CDN globale, con il contenuto statico ospitato nel cloud. In questo modo si evita la necessità di un server Web dedicato. Per iniziare, vedere Integrare un account di archiviazione di Azure con Rete CDN di Azure. Proteggere l'applicazione con HTTPS. Leggere le procedure consigliate per l'uso delle reti per la distribuzione di contenuti per consigli aggiuntivi.
• Usare un servizio CI/CD veloce e affidabile, ad esempio Azure Pipelines o GitHub Actions, per compilare e distribuire automaticamente ogni modifica di origine. L'origine deve risiedere in un sistema di controllo della versione online. Per altre informazioni su Azure Pipelines, vedere Creare la prima pipeline. Per altre informazioni su GitHub Actions per Azure, vedere Distribuire app in Azure.
• Comprimere i file del sito Web per ridurre il consumo di larghezza di banda nel rete CDN e migliorare le prestazioni. Rete CDN di Azure consente la compressione in tempo reale sui server perimetrali. In alternativa, la pipeline di distribuzione in questa architettura di riferimento comprime i file prima di distribuirli nell'archivio BLOB. In questo modo si riduce il requisito di archiviazione e si offre maggiore libertà di scegliere gli strumenti di compressione, indipendentemente dalle limitazioni rete CDN.
• Il rete CDN dovrebbe essere in grado di ripulire la cache per assicurarsi che tutti gli utenti siano serviti al contenuto più aggiornato. Un'eliminazione della cache è necessaria se i processi di compilazione e distribuzione non sono atomici, ad esempio se sostituiscono i file precedenti con quelli appena compilati nella stessa cartella di origine.
• Una strategia di cache diversa, ad esempio il controllo delle versioni tramite directory, potrebbe non richiedere un'eliminazione da parte del rete CDN. La pipeline di compilazione in questa applicazione front-end crea una nuova directory per ogni nuova versione compilata. Questa versione viene caricata come unità atomica nell'archivio BLOB. Il Rete CDN di Azure punta a questa nuova versione solo dopo una distribuzione completata.
• Aumentare il TTL della cache memorizzando nella cache i file di risorse per una durata più lunga, che si estende su mesi. Per assicurarsi che i file memorizzati nella cache vengano aggiornati quando cambiano, impronta digitale i nomi file quando vengono ricompilati. Questa applicazione front-end impronta digitale tutti i file ad eccezione di file pubblici, ad esempio index.html. Poiché il index.html viene aggiornato di frequente, riflette i nomi file modificati che causano un aggiornamento della cache. Per altre informazioni, vedere Gestire la scadenza del contenuto Web in Rete CDN di Azure.

Distribuzione back-end

Per distribuire l'app per le funzioni è consigliabile usare file di pacchetto, ossia l'esecuzione dal pacchetto. Con questo approccio, si carica un file ZIP in un contenitore di archiviazione BLOB e il runtime di Funzioni monta il file ZIP come file system di sola lettura. Questa operazione atomica riduce le probabilità che una distribuzione non riuscita lasci l'applicazione in uno stato non coerente. Può anche migliorare i tempi di avvio a freddo, soprattutto per le app Node.js, perché viene effettuato lo swapping di tutti i file contemporaneamente.

Controllo delle versioni API

Un'API è un contratto tra un servizio e i client. In questa architettura, il contratto API è definito al livello di Gestione API. Gestione API supporta due concetti di controllo delle versioni distinti ma complementari.

• Versioni: consentono ai consumer di API di scegliere una versione dell'API in base alle esigenze, ad esempio v1 o v2.

• Revisioni: consentono agli amministratori di API di apportare modifiche che non causano interruzioni e distribuirle insieme a un log delle modifiche per informare i consumer di API.

Se si apporta una modifica che causa un'interruzione in un'API, pubblicare una nuova versione in Gestione API. Distribuire la nuova versione side-by-side con la versione originale, in un'app per le funzioni separata. Ciò consente di eseguire la migrazione dei client esistenti alla nuova API senza interrompere le applicazioni client. Infine è possibile deprecare la versione precedente. Gestione API supporta diversi schemi di controllo delle versioni: percorso URL, intestazione HTTP e stringa di query. Per altre informazioni sul controllo delle versioni delle API in generale, vedere Controllo delle versioni di un'API Web RESTful.

Per gli aggiornamenti che non causano modifiche all'API di rilievo, distribuire la nuova versione in uno slot di staging nella stessa app per le funzioni. Verificare che la distribuzione abbia avuto esito positivo, quindi invertire la versione con gestione temporanea e la versione di produzione. Pubblicare una revisione in Gestione API.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Usare il calcolatore dei prezzi di Azure per stimare i costi. Considerare questi punti per ottimizzare i costi di questa architettura.

Funzioni di Azure

Funzioni di Azure supporta due modelli di hosting.

• Piano a consumo.

  La potenza di calcolo viene allocata automaticamente quando il codice è in esecuzione.

• Piano di servizio app.

  Un set di macchine virtuali viene allocato per il codice. Questo piano definisce il numero di macchine virtuali e le dimensioni della macchina virtuale.

In questa architettura viene richiamata una funzione quando un client effettua una richiesta HTTP. Poiché in questo caso d'uso non è prevista una velocità effettiva costante con volumi elevati, è consigliabile usare il piano a consumo perché si paga solo per le risorse di calcolo usate.

Azure Cosmos DB

Azure Cosmos DB fattura la velocità effettiva con provisioning e l'archiviazione usata ogni ora. La velocità effettiva con provisioning è espressa in unità richiesta al secondo (UR/sec), che può essere usata per operazioni di database tipiche, ad esempio inserimenti, letture. Il prezzo si basa sulla capacità in UR/sec che si riserva.

Archiviazione vengono fatturati per ogni GB usato per i dati e l'indice archiviati.

Per altre informazioni, vedere Modello di prezzi di Azure Cosmos DB.

In questa architettura, l'applicazione per le funzioni recupera i documenti da Azure Cosmos DB in risposta alle richieste HTTP GET dal client. Azure Cosmos DB è conveniente in questo caso perché le operazioni di lettura sono notevolmente più economiche rispetto alle operazioni di scrittura espresse su UR/sec.

Rete per la distribuzione di contenuti

La tariffa di fatturazione può variare a seconda dell'area di fatturazione in base alla posizione del server di origine che recapita il contenuto all'utente finale. La posizione fisica del client non è l'area di fatturazione. Qualsiasi richiesta HTTP o HTTPS che raggiunge il rete CDN è un evento fatturabile, che include tutti i tipi di risposta: esito positivo, negativo o altro. Risposte diverse possono generare quantità di traffico diverse.

In questa architettura di riferimento la distribuzione si trova in una singola area di Azure.

Per ridurre i costi, prendere in considerazione l'aumento della durata (TTL) della cache memorizzando nella cache i file di risorse per una durata più lunga e impostando il TTL più lungo possibile nel contenuto.

Per altre informazioni, vedere la sezione Costo in Microsoft Azure Well-Architected Framework.

Distribuire lo scenario

Per distribuire l'implementazione di riferimento per questa architettura, vedere il file leggimi di GitHub.

Passaggi successivi

Documentazione sui prodotti:

• Che cos'è Archiviazione BLOB di Azure?
• Rete di distribuzione dei contenuti di Azure
• Introduzione a Funzioni di Azure
• Informazioni su Gestione API
• Introduzione ad Azure Cosmos DB
• Microsoft Entra ID
• Panoramica di Monitoraggio di Azure
• Che cos'è Azure Pipelines?

Moduli learn:

• Scegliere la migliore tecnologia serverless di Azure per lo scenario aziendale
• Creare logica serverless con Funzioni di Azure

Risorse correlate

Per altre informazioni sull'implementazione di riferimento, vedere Procedura dettagliata del codice: Applicazione serverless con Funzioni di Azure.

Informazioni correlate:

• Procedure consigliate per l'uso di rete CDN
• Modello di hosting di contenuti statici