Architetture di backend per i backend di app web basate sui contenuti

L'architettura di backend fa riferimento al modo in cui è strutturato il backend della tua applicazione web. L'architettura di backend determina il modo in cui le parti dell'applicazione comunicano tra loro per elaborare le richieste in entrata e creare risposte. Quando crei un'applicazione web, seleziona un'architettura di backend in base ai tuoi requisiti e fattori specifici, tra cui il costo (in corso e su larga scala), la complessità della tua applicazione, gli obiettivi di scalabilità e l'esperienza del tuo team.

In particolare per le applicazioni web basate sui contenuti, come l'e-commerce, i giornali o i blog, i requisiti fondamentali includono la coerenza dei dati e le prestazioni, soprattutto quando l'applicazione cresce su scala globale e potrebbe diventare più distribuita. Per le applicazioni web basate sui contenuti, anche l'archiviazione dei dati utilizzata dall'applicazione è fondamentale e viene discussa in modo più dettagliato nella guida all'archiviazione dei dati. Andare oltre le tipiche architetture delle applicazioni, ospitare i contenuti e renderli accessibili è fondamentale per ottimizzare le prestazioni dell'app. Scopri di più su come scegliere la strategia di hosting giusta e ottimizzare la tua app nella guida di hosting.

Se hai già un backend per un'applicazione web, considera i limiti dell'architettura attuale. Ad esempio, man mano che la tua applicazione fa lo scale up e le richieste di prestazioni e affidabilità aumentano, valuta se sia necessario eseguire il refactoring delle parti dell'applicazione o spostarle in un'architettura diversa più adatta alla tua maggiore scalabilità. Ad esempio, le architetture ibride (o multi-cloud) ti consentono di spostare alcuni carichi di lavoro nel cloud prima di effettuare una transizione completa. Anche considerare il costo, il tempo e i rischi associati a una migrazione di questo tipo è essenziale.

Architetture monolitiche

Un'architettura monolitica ha una struttura unificata, con tutti i componenti dell'applicazione strettamente integrati in un unico codebase. L'intera applicazione è creata come un'unica unità indipendente. L'architettura monolitica è multi-livello, in cui diversi livelli dell'applicazione svolgono attività specifiche.

Livelli strutturali

• L'interfaccia utente (UI), che include componenti per presentare le funzionalità dell'applicazione, è in genere un'applicazione basata sul web o desktop che interagisce con gli utenti.
• Nella logica dell'applicazione risiede la funzionalità di base.Questa parte del codebase contiene le regole, i calcoli e le operazioni che definiscono il funzionamento dell'applicazione.
• Il livello di accesso ai dati contiene funzioni per la lettura e la scrittura di dati e la traduzione tra le strutture di dati dell'applicazione e lo schema del database. Questo livello è responsabile dell'interazione con il database o l'archiviazione dei dati dell'applicazione.
• Il database è il luogo in cui l'applicazione archivia i propri dati. Di solito esiste un singolo database in cui sono archiviati tutti i dati dell'applicazione, inclusi i dati utente, le configurazioni e altre informazioni.
• I componenti middleware gestiscono attività come autenticazione, routing delle richieste e convalida dei dati. Questi componenti aiutano a gestire il flusso di dati e richieste.
• Alcune applicazioni monolitiche dispongono di punti di integrazione con servizi esterni o API. Questi punti consentono all'applicazione di interagire con servizi, origini dati o altri sistemi di terze parti.

I livelli strutturali di solito fanno parte di un unico codebase. Questo codebase contiene l'intera applicazione ed è solitamente organizzato in directory, moduli e classi. Gli sviluppatori lavorano su varie parti del codebase per creare e gestire l'applicazione. Tuttavia, il deployment dell'intera applicazione viene generalmente eseguito come singola unità. Quando vengono apportate modifiche o aggiornamenti, viene eseguito nuovamente il deployment dell'intera applicazione.

Potenziali sfide

• Con la crescita delle applicazioni monolitiche, il codebase tende a diventare complesso e difficile da gestire. Ciò può comportare lunghi cicli di sviluppo e difficoltà a comprendere l'intero codebase.
• Il deployment di modifiche a un'applicazione monolitica può essere rischioso poiché le modifiche apportate in una parte del codice potrebbero inavvertitamente influire su altre parti dell'applicazione. Ciò può creare un processo di deployment lungo e soggetto a errori.
• La scalabilità delle applicazioni monolitiche può essere difficile perché il deployment viene eseguito come singola unità. devi scalare l'intera applicazione, anche se la domanda aumenta con un solo componente.
• Le applicazioni monolitiche spesso si basano su un unico stack tecnologico o linguaggio di programmazione, pertanto la capacità di utilizzare lo strumento migliore per un'attività specifica all'interno dell'applicazione potrebbe essere limitata.
• Anche durante i periodi di domanda ridotta, le applicazioni monolitiche richiedono risorse significative per funzionare. Inoltre, i costi di manutenzione aumentano man mano che l'applicazione invecchia, man mano che diventa più difficile aggiornare e applicare la patch all'applicazione senza causare regressioni.
• I team di sviluppo che lavorano su applicazioni monolitiche sono spesso organizzati in tutta l'applicazione, il che porta a team più grandi e a un coordinamento più complesso tra i membri.

Utilizzo suggerito

Le architetture monolitiche sono adatte quando un'applicazione ha requisiti modesti e il team di sviluppo è ridotto. Man mano che un'applicazione aumenta in complessità e scalabilità o quando parti diverse dell'applicazione richiedono tecnologia o strategie di deployment diverse, le architetture monolitiche possono diventare meno flessibili e più difficili da gestire.

Puoi creare e gestire macchine virtuali in grado di eseguire applicazioni monolitiche su Compute Engine. Hai il controllo completo sui sistemi operativi, sul software e sulla gestione di queste macchine virtuali per eseguire la tua applicazione monolitica.

Con un servizio Platform as a Service, come App Engine, puoi creare la tua applicazione ed eseguirla su un'infrastruttura completamente gestita che scala automaticamente con le richieste.

Se la tua applicazione monolitica è containerizzata, puoi eseguirla utilizzando Google Kubernetes Engine (GKE) o Cloud Run. È possibile utilizzare servizi come Cloud SQL o CloudSpanner per archiviare dati per applicazioni monolitiche. Prendi in considerazione una combinazione di servizi e sistemi in base ai requisiti specifici della tua applicazione.

Architetture serverless

Grazie all'architettura serverless, puoi creare ed eseguire applicazioni senza gestire server fisici o virtuali. Il cloud provider gestisce automaticamente l'infrastruttura, la scalabilità e l'allocazione delle risorse in modo che gli sviluppatori possano concentrarsi sulla scrittura del codice per le loro applicazioni. Le architetture serverless possono semplificare lo sviluppo, ridurre l'overhead operativo e ottimizzare i costi eliminando la necessità di gestire i server. Sono particolarmente adatti per microservizi, elaborazione dati in tempo reale, applicazioni web con carichi di lavoro variabili ed elaborazione di eventi.

Architetture serverless basate su eventi

Le architetture serverless basate su eventi sono un tipo specifico di architettura di serverless computing che si basa su eventi o trigger per avviare l'esecuzione di funzioni o microservizi. I componenti del sistema comunicano tramite eventi e le funzioni vengono richiamate in risposta agli eventi. Spesso si basano sulla comunicazione asincrona, in quanto le funzioni vengono attivate da eventi e poi le elaborano in modo indipendente e possono generare eventi che attivano azioni successive. Questo tipo di architettura serverless è una buona opzione per creare sistemi scalabili, adattabili e a basso accoppiamento.

Google Cloud Functions e Cloud Functions for Firebase ti consentono di creare funzioni basate su eventi ed eseguirne il deployment in un ambiente completamente gestito e serverless. Consente di eseguire codice in risposta a vari eventi e trigger, tra cui richieste HTTP, messaggi Cloud Pub/Sub, modifiche a Google Cloud Storage, aggiornamenti di Firebase Realtime Database, senza la necessità di gestire l'infrastruttura. Le funzionalità chiave includono supporto di più lingue, scalabilità, fatturazione granulare, integrazioni di terze parti, logging e monitoraggio affidabili e integrazione con altri servizi Google e Firebase.

Le architetture serverless possono essere convenienti per molti casi d'uso, in particolare per applicazioni con carichi di lavoro variabili, esigenze di sviluppo rapido e traffico imprevedibile. L'affidabilità dipende dal cloud provider, con accordi sul livello del servizio (SLA) per garantire target specifici di prestazioni e affidabilità. Devi valutare il tuo caso d'uso e i tuoi requisiti specifici per determinare se l'architettura serverless è l'opzione migliore.

Containerizzazione

La containerizzazione consente di pacchettizzare le applicazioni e le loro dipendenze in container leggeri e portabili. Forniscono un ambiente applicativo coerente che supporta lo sviluppo e il deployment su diversi sistemi e piattaforme. Alcune piattaforme serverless consentono di eseguire carichi di lavoro containerizzati. L'esecuzione di container in un ambiente serverless può essere utile quando hai carichi di lavoro complessi o stateful che non possono essere espressi come funzioni di base. Offre flessibilità in termini di supporto dei linguaggi e ambienti di runtime.

Cloud Run è una piattaforma di serverless computing che consente agli sviluppatori di distribuire ed eseguire applicazioni containerizzate in un ambiente completamente gestito. Offre un modo semplice per creare, eseguire il deployment e scalare le applicazioni, senza gestire l'infrastruttura. È adatto per un'ampia gamma di applicazioni web e di microservizi, in particolare per quelle con carichi di lavoro variabili, e dove la containerizzazione offre vantaggi in termini di pacchettizzazione e coerenza delle applicazioni.

Architetture di microservizi

Le applicazioni sono suddivise in piccole parti a basso accoppiamento e implementano caratteristiche o capacità distinte. Questi servizi possono comunicare tramite messaggi asincroni, canali basati su eventi o direttamente esponendo un'interfaccia. Ogni servizio viene sviluppato, testato e scalato in modo indipendente nel proprio container, che spesso è gestito tramite un servizio di orchestrazione, come Kubernetes, o di cui viene eseguito il deployment mediante una piattaforma gestita come Cloud Run.

In genere, i deployment di microservizi sfruttano anche il paradigma delle applicazioni serverless, non basandosi su un server centralizzato.

Separare un'applicazione in servizi autonomi può semplificare un sistema complesso. Limiti e obiettivi ben definiti possono accelerare lo sviluppo e migliorare la manutenzione. Ogni microservizio può essere sviluppato in modo indipendente utilizzando i framework o gli strumenti più efficaci. La comunicazione tra i servizi viene spesso gestita utilizzando eventi, comunicazione publish-subscribe, pipeline di messaggi o chiamate di procedure da remoto come gRPC.

Per l'orchestrazione delle attività all'interno di un'architettura di microservizi, valuta la possibilità di utilizzare un framework che supporti le piattaforme scelte come target, una profondità sufficiente per le attività e i tipi di flussi di lavoro che stai orchestrando, nonché la gestione degli errori e la telemetria per il debug dei problemi. Le opzioni più diffuse includono Conductor o le offerte di un cloud provider come Google Workflows.

Le applicazioni basate su microservizi possono essere complesse da sviluppare e mantenere a causa della loro natura distribuita e della necessità di comunicazioni intra-service. Pertanto, la gestione dei deployment, il monitoraggio e il logging sono più complessi rispetto alle altre opzioni di architettura. Poiché l'affidabilità dipende dall'architettura dei singoli servizi, la natura distribuita può offrire resilienza aggiuntiva, soprattutto se viene eseguito il deployment e la telemetria del monitoraggio e, se necessario, sono abilitati.

Confronto di architetture diverse per backend di applicazioni web basate sui contenuti

La tabella seguente mette a confronto le architetture con i requisiti chiave per il backend di un'applicazione web basata sui contenuti.

	Architetture monolitiche	Architetture serverless basate su eventi	Architetture serverless con microservizi
Complessità e manutenzione	Facilità di implementazione per progetti piccoli e autonomi, ma la complessità aumenta con la scalabilità. Richiede manutenzione e coordinamento manuali.	La scalabilità è ben supportata e integrata nella piattaforma. La risoluzione dei problemi e il debug possono essere impegnativi. Nessuna necessità di gestire l'infrastruttura.	Servizi autonomi testati e di cui viene eseguito il deployment in modo indipendente per semplificare la manutenzione di ogni unità. Richiede un'attenta comunicazione tra i servizi. Richiede strumenti di gestione e orchestrazione per una gestione su scala più ampia.
Scalabilità e prestazioni	È efficiente su piccola scala, difficile da scalare oltre una dimensione specifica. Esigenze specifiche di infrastruttura, con limitazioni alle opzioni di scalabilità dinamica. Scalabilità manuale (o utilizzo di servizi manuali) all'interno dell'architettura, ad esempio tramite il bilanciamento del carico.	Scalabilità integrata attraverso l'uso di una piattaforma gestita. Scala in entrambe le direzioni.	Ogni servizio è personalizzato in base a un'esigenza specifica e può essere scalato e ottimizzato in modo indipendente.
Strategie di resilienza e fallback	Il deployment è complesso e può comportare tempi di inattività ("tutto o niente").	Intrinseco del cloud provider. Ogni funzione indipendente può essere tentata in modo indipendente.	Ogni servizio è autonomo e ciò rende il sistema complessivo più resiliente attraverso test e sviluppo indipendenti.
Esperienza di sviluppo	Sviluppo rapido su piccola scala grazie allo stretto accoppiamento dell'architettura (ad esempio tramite query efficienti). Tempi di creazione lunghi e collaborazione e test difficili con l'aumentare della complessità.	Non c'è alcuna infrastruttura da mantenere e gestire, velocizzando lo sviluppo. Il test e il debug di un'applicazione live dipende dai servizi del cloud provider.	I servizi sono indipendenti e possono essere sviluppati in modo indipendente l'uno dall'altro. Un gran numero di servizi deve essere coordinato e gestito.
Costo	Uno sviluppo complesso può comportare un aumento dei costi. Richiede investimenti significativi in hardware o infrastruttura, soprattutto su scala più ampia. L'efficienza in termini di costi derivante dallo scale up e dallo scale down è difficile da realizzare.	Nessun costo hardware dedicato. Fare lo scale up e lo scale down per ottimizzare l'utilizzo e i costi delle risorse (fino a zero).	Nessun costo hardware dedicato. Fare lo scale up e lo scale down per ottimizzare l'utilizzo delle risorse e i costi entro i confini. Costi aggiuntivi derivanti dal monitoraggio e dalla gestione di un ampio insieme di servizi indipendenti.

Scopri di più sulle architetture di backend per le applicazioni web basate sui contenuti

Ecco alcune risorse per saperne di più sulle architetture per le applicazioni web basate sui contenuti, incluso come eseguire la migrazione dell'app a un'architettura diversa:

• Scopri di più sulle architetture dei backend delle app web a basso accoppiamento, incluse le applicazioni web monolitiche e serverless a più livelli.

• Migrazione di un'app monolitica a un'architettura di microservizi.

• Casi d'uso tipici per funzioni Cloud Functions serverless.