I componenti dell'architettura di un'applicazione possono essere classificati come frontend o backend. In alcuni scenari, questi componenti possono essere ospitati per operare da ambienti di calcolo diversi. Nell'ambito del pattern di architettura ibrida a più livelli, gli ambienti di calcolo si trovano in un ambiente di calcolo privato on-premise e in Google Cloud.
I componenti dell'applicazione frontend sono esposti direttamente agli utenti finali o ai dispositivi. Di conseguenza, queste applicazioni sono spesso sensibili alle prestazioni. Per sviluppare nuove funzionalità e miglioramenti, gli aggiornamenti software possono essere frequenti. Poiché le applicazioni frontend solitamente si basano su applicazioni di backend per archiviare e gestire i dati, nonché eventualmente la logica aziendale e l'elaborazione degli input utente, spesso sono senza stato o gestiscono solo volumi limitati di dati.
Per essere accessibili e utilizzabili, puoi creare le tue applicazioni frontend con vari framework e tecnologie. Alcuni fattori chiave per un'applicazione frontend di successo includono le prestazioni dell'applicazione, la velocità di risposta e la compatibilità del browser.
I componenti dell'applicazione di backend in genere si concentrano sull'archiviazione e sulla gestione dei dati. In alcune architetture, la logica di business potrebbe essere incorporata nel componente di backend. Le nuove release delle applicazioni di backend tendono a essere meno frequenti rispetto alle release per le applicazioni di frontend. Le applicazioni di backend devono gestire le seguenti sfide:
- Gestione di un elevato volume di richieste
- Gestione di un volume elevato di dati
- Protezione dei dati
- Mantenimento di dati attuali e aggiornati in tutte le repliche di sistema
L'architettura a tre livelli è una delle implementazioni più utilizzate per la creazione di applicazioni web aziendali, come i siti web di e-commerce contenenti diversi componenti dell'applicazione. Questa architettura contiene i seguenti livelli. Ogni livello opera in modo indipendente, ma sono strettamente collegati e funzionano tutti insieme.
- Frontend web e livello di presentazione
- Livello di applicazione
- Livello di accesso ai dati o di backend
Inserire questi livelli in contenitori separa le relative esigenze tecniche, come i requisiti di scalabilità, e aiuta a eseguirne la migrazione in modo graduale. Inoltre, consente di eseguirne il deployment su servizi cloud indipendenti dalla piattaforma che possono essere portatili tra ambienti, utilizzare la gestione automatica e scalare con piattaforme gestite cloud, come Cloud Run o Google Kubernetes Engine (GKE) Enterprise Edition. Inoltre, i database gestiti daGoogle Cloud come Cloud SQL contribuiscono a fornire il backend come livello del database.
Il pattern di architettura ibrida a più livelli si concentra sul deployment dei componenti dell'applicazione frontend esistenti nel cloud pubblico. In questo pattern, mantieni tutti i componenti dell'applicazione di backend esistenti nel loro ambiente di calcolo privato. A seconda delle dimensioni e del design specifico dell'applicazione, puoi eseguire la migrazione dei componenti dell'applicazione frontend caso per caso. Per ulteriori informazioni, consulta la pagina Eseguire la migrazione a Google Cloud.
Se hai già un'applicazione con componenti di backend e frontend ospitati nel tuo ambiente on-premise, valuta i limiti della tua attuale architettura. Ad esempio, man mano che l'applicazione si espande e le richieste relative alle sue prestazioni e affidabilità aumentano, devi iniziare a valutare se parti dell'applicazione devono essere sottoposte a refactoring o spostate in un'architettura diversa e più ottimale. Il pattern di architettura ibrida a più livelli ti consente di spostare alcuni carichi di lavoro e componenti dell'applicazione sul cloud prima di eseguire una transizione completa. È inoltre essenziale prendere in considerazione il costo, il tempo e il rischio di una simile migrazione.
Il seguente diagramma mostra un tipico pattern di architettura ibrida a più livelli.
Nel diagramma precedente, le richieste del client vengono inviate al frontend dell'applicazione ospitato in Google Cloud. A sua volta, il frontend dell'applicazione invia nuovamente i dati all'ambiente on-premise in cui è ospitato il backend dell'applicazione (idealmente tramite un API gateway).
Con il pattern di architettura ibrida a più livelli, puoi sfruttare Google Cloud l'infrastruttura e i servizi globali, come mostrato nell'architettura di esempio nel diagramma seguente. Il frontend dell'applicazione è accessibile tramite Google Cloud. Può anche aggiungere elasticità al frontend utilizzando la scalabilità automatica per rispondere in modo dinamico ed efficiente alla domanda in crescita senza sovraprovisioning dell'infrastruttura. Esistono diverse architetture che puoi utilizzare per creare ed eseguire app web scalabili su Google Cloud. Ogni architettura presenta vantaggi e svantaggi per requisiti diversi.
Per saperne di più, guarda il video Tre modi per eseguire app web scalabili su Google Cloud su YouTube. Per scoprire di più sui diversi modi per modernizzare la tua piattaforma di e-commerce su Google Cloud, consulta Come creare una piattaforma di commercio digitale su Google Cloud.
Nel diagramma precedente, il frontend dell'applicazione è ospitato su Google Cloud per fornire un'esperienza utente ottimizzata a livello globale e su più regioni che utilizza il bilanciamento del carico, l'autoscaling e la protezione DDoS tramite Google Cloud Armor.
Nel tempo, il numero di applicazioni di cui esegui il deployment nel cloud pubblico potrebbe aumentare al punto da farti prendere in considerazione la possibilità di spostare i componenti dell'applicazione di backend nel cloud pubblico. Se prevedi di gestire un traffico elevato, optare per i servizi gestiti sul cloud potrebbe aiutarti a risparmiare sui costi di progettazione per la gestione della tua infrastruttura. Valuta questa opzione, a meno che vincoli o requisiti non prevedano l'hosting dei componenti dell'applicazione di backend on-premise. Ad esempio, se i tuoi dati di backend sono soggetti a limitazioni normative, probabilmente dovrai conservarli on-premise. Tuttavia, se applicabili e conformi, l'utilizzo di funzionalità di protezione dei dati sensibili come le tecniche di anonimizzazione può aiutarti a spostare questi dati quando necessario.
Nel pattern di architettura ibrida a più livelli, in alcuni scenari puoi anche utilizzare Google Distributed Cloud. Distributed Cloud ti consente di eseguire i cluster Google Kubernetes Engine su hardware dedicato fornito e gestito da Google e separato dal data center. Google Cloud Per assicurarti che Distributed Cloud soddisfi i tuoi requisiti attuali e futuri, tieni presente le limitazioni di Distributed Cloud rispetto a una zona GKE basata su cloud convenzionale.
Vantaggi
Concentrarsi innanzitutto sulle applicazioni frontend offre diversi vantaggi, tra cui:
- I componenti frontend dipendono dalle risorse di backend e occasionalmente da altri componenti frontend.
- I componenti di backend non dipendono dai componenti di frontend. Pertanto, l'isolamento e la migrazione delle applicazioni frontend tendono a essere meno complessi rispetto alla migrazione delle applicazioni di backend.
- Poiché le applicazioni frontend spesso non hanno stato o non gestiscono i dati da sole, la loro migrazione tende a essere meno complessa rispetto a quella dei backend.
- I componenti frontend possono essere ottimizzati nell'ambito della migrazione per utilizzare un'architettura stateless. Per saperne di più, guarda Come eseguire il porting di app web con stato in Cloud Run su YouTube.
Il deployment di applicazioni frontend esistenti o di nuova creazione nel cloud pubblico offre diversi vantaggi:
- Molte applicazioni frontend sono soggette a modifiche frequenti. L'esecuzione di queste applicazioni nel cloud pubblico semplifica la configurazione di un processo di integrazione/deployment continuo (CI/CD). Puoi utilizzare CI/CD per inviare aggiornamenti in modo efficiente e automatico. Per ulteriori informazioni, consulta CI/CD su Google Cloud.
- I frontend sensibili alle prestazioni con un carico di traffico variabile possono trarre sostanziali vantaggi dal bilanciamento del carico, dai deployment multiregionali, dal caching di Cloud CDN, dalle funzionalità serverless e di scalabilità automatica abilitati da un deployment basato su cloud (idealmente con un'architettura stateless).
L'adozione di microservizi con container utilizzando una piattaforma gestita sul cloud, come GKE, consente di utilizzare architetture moderne come i microfrontend, che estendono i microservizi ai componenti frontend.
L'estensione dei microservizi è comunemente utilizzata con i frontend che coinvolgono più team che collaborano alla stessa applicazione. Questo tipo di struttura del team richiede un approccio iterativo e una manutenzione continua. Ecco alcuni dei vantaggi dell'utilizzo dei microfrontend:
- Può essere trasformato in moduli di microservizi indipendenti per sviluppo, test e deployment.
- Offre una separazione in cui i singoli team di sviluppo possono selezionare le tecnologie e il codice che preferiscono.
- Può favorire cicli rapidi di sviluppo e deployment senza influire sul resto dei componenti frontend che potrebbero essere gestiti da altri team.
Che implementino interfacce utente o API o gestiscano l'importazione dati di internet of things (IoT), le applicazioni frontend possono trarre vantaggio dalle funzionalità dei servizi cloud come Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine o Cloud Run.
I proxy API gestiti su Cloud aiutano a:
- Disaccoppia l'API per le app dai tuoi servizi di backend, come i microservizi.
- Proteggi le app dalle modifiche al codice del backend.
- Supporta le tue architetture frontend basate su API esistenti, come BFF (backend per frontend), microfrontend e altre.
- Esponi le tue API su Google Cloud o in altri ambienti implementando proxy API su Apigee.
Puoi anche applicare il pattern ibrido a più livelli in modo inverso, eseguendo il deployment dei backend nel cloud e mantenendo i frontend in ambienti di calcolo privati. Sebbene sia meno comune, questo approccio è preferibile quando si ha a che fare con un frontend monolitico e di grandi dimensioni. In questi casi, potrebbe essere più semplice estrarre la funzionalità di backend in modo iterativo e implementare questi nuovi backend nel cloud.
La terza parte di questa serie illustra possibili modelli di networking per abilitare una tale architettura. Apigee hybrid è una piattaforma per la creazione e la gestione di proxy API in un modello di deployment ibrido. Per ulteriori informazioni, consulta Architettura accoppiata in modo lasco, incluse le architetture monolitiche e dei microservizi a più livelli.
Best practice
Utilizza le informazioni riportate in questa sezione per pianificare la tua architettura ibrida a più livelli.
Best practice per ridurre la complessità
Quando applichi il pattern di architettura ibrida a più livelli, considera le seguenti best practice che possono aiutarti a ridurre il suo complesso di deployment e operativo complessivo:
- In base alla valutazione dei modelli di comunicazione delle applicazioni identificate, seleziona la soluzione di comunicazione più efficiente ed efficace per queste applicazioni.
Poiché la maggior parte delle interazioni utente coinvolge sistemi che si connettono su più ambienti di calcolo, è importante una connettività veloce e a bassa latenza tra questi sistemi. Per soddisfare le aspettative di disponibilità e prestazioni, devi progettare per garantire un'alta disponibilità, una bassa latenza e livelli di throughput appropriati. Dal punto di vista della sicurezza, la comunicazione deve essere granulare e controllata. Idealmente, devi esporre i componenti dell'applicazione utilizzando API sicure. Per ulteriori informazioni, consulta la sezione Uscita controllata.
- Per ridurre al minimo la latenza di comunicazione tra gli ambienti, seleziona una Google Cloud regione geograficamente vicina all'ambiente di calcolo privato in cui sono ospitati i componenti di backend dell'applicazione. Per saperne di più, consulta Best practice per la scelta delle regioni Compute Engine.
- Riduci al minimo le dipendenze elevate tra sistemi in esecuzione in ambienti diversi, in particolare quando la comunicazione viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni, ridurre la disponibilità complessiva e potenzialmente comportare costi aggiuntivi per il trasferimento di dati in uscita.
- Con il pattern di architettura ibrida a più livelli, potresti avere volumi maggiori di traffico in entrata proveniente da ambienti on-premise rispetto al traffico in uscita Google Cloud.Google Cloud Tuttavia, devi conoscere il volume previsto di trasferimento di dati in uscita in uscita Google Cloud. Se prevedi di utilizzare questa architettura a lungo termine con volumi elevati di trasferimento di dati in uscita, ti consigliamo di utilizzare Cloud Interconnect. Cloud Interconnect può contribuire a ottimizzare le prestazioni della connettività e potrebbe ridurre gli addebiti per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.
- Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito. Se è richiesta la crittografia a livello di connettività, puoi utilizzare i tunnel VPN, la VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.
Per superare le incoerenze in protocolli, API e meccanismi di autenticazione su diversi backend, ti consigliamo, ove applicabile, di eseguire il deployment di un gateway API o di un proxy come facciata unificante. Questo gateway o proxy funge da punto di controllo centralizzato ed esegue le seguenti misure:
- Implementa misure di sicurezza aggiuntive.
- Protegge le app client e altri servizi dalle modifiche al codice di backend.
- Facilita le procedure di controllo per la comunicazione tra tutte le applicazioni cross-environment e i relativi componenti disaccoppiati.
- Agisce come
livello di comunicazione intermedio
tra i servizi legacy e modernizzati.
- Apigee e Apigee hybrid ti consentono di ospitare e gestire gateway ibridi e di livello aziendale in ambienti on-premise, edge, altri cloud e Google Cloud .
Per facilitare l'implementazione di configurazioni ibride, utilizza Cloud Load Balancing con connettività ibrida. Ciò significa che puoi estendere i vantaggi del bilanciamento del carico cloud ai servizi ospitati nel tuo ambiente di calcolo on-premise. Questo approccio consente di eseguire migrazioni dei carichi di lavoro in più fasi a Google Cloud con interruzioni minime o nulle del servizio, garantendo una transizione fluida per i servizi distribuiti. Per maggiori informazioni, consulta la panoramica dei gruppi di endpoint di rete con connettività ibrida.
A volte, l'utilizzo di un API Gateway o di un proxy e di un Application Load Balancer insieme può fornire una soluzione più solida per gestire, proteggere e distribuire il traffico API su larga scala. L'utilizzo del bilanciamento del carico di Cloud con i gateway API ti consente di:
- Fornisci API ad alte prestazioni con Apigee e Cloud CDN per ridurre la latenza, ospitare le API a livello globale e aumentare la disponibilità per le stagioni di picco del traffico. Per saperne di più, guarda Pubblicazione di API ad alte prestazioni con Apigee e Cloud CDN su YouTube.
- Implementa la gestione avanzata del traffico.
- Utilizza Google Cloud Armor come servizio di protezione DDoS e sicurezza della rete per proteggere le tue API.
- Gestisci un bilanciamento del carico efficiente tra i gateway in più regioni. Per saperne di più, guarda Proteggere le API e implementare il failover multiregione con Private Service Connect e Apigee su YouTube.
Utilizza la gestione delle API e il mesh di servizi per proteggere e controllare la comunicazione e l'esposizione dei servizi con l'architettura di microservizi.
- Utilizza Cloud Service Mesh per consentire la comunicazione tra servizi, che mantiene la qualità del servizio in un sistema composto da servizi distribuiti in cui puoi gestire l'autenticazione, l'autorizzazione e la crittografia tra i servizi.
- Utilizza una piattaforma di gestione delle API come Apigee che consente alla tua organizzazione e a entità esterne di utilizzare questi servizi esponendoli come API.
Stabilisci un'identità comune tra gli ambienti in modo che i sistemi possano autenticarsi in modo sicuro oltre i confini degli ambienti.
Esegui il deployment di sistemi di gestione delle configurazioni e CI/CD nel cloud pubblico. Per ulteriori informazioni, consulta Modello di architettura di rete con mirroring.
Per contribuire ad aumentare l'efficienza operativa, utilizza strumenti e pipeline CI/CD coerenti in tutti gli ambienti.
Best practice per singoli carichi di lavoro e architetture di applicazioni
- Anche se in questo pattern l'attenzione è incentrata sulle applicazioni frontend, tieni conto della necessità di modernizzare le applicazioni di backend. Se il ritmo di sviluppo delle applicazioni di backend è notevolmente più lento rispetto a quello delle applicazioni di frontend, la differenza può causare una maggiore complessità.
- Il trattamento delle API come interfacce di backend semplifica le integrazioni, lo sviluppo frontend, le interazioni con i servizi e nasconde le complessità del sistema di backend. Per risolvere questi problemi, Apigee facilita lo sviluppo e la gestione di API gateway/proxy per i deployment ibridi e multi-cloud.
- Scegli l'approccio di rendering per la tua applicazione web frontend in base ai contenuti (statici o dinamici), al rendimento dell'ottimizzazione per i motori di ricerca e alle aspettative relative alle velocità di caricamento delle pagine.
- Quando selezioni un'architettura per le applicazioni web basate su contenuti, sono disponibili varie opzioni, tra cui architetture monolitiche, serverless, basate su eventi e di microservizi. Per selezionare l'architettura più adatta, valuta attentamente queste opzioni in base ai requisiti attuali e futuri dell'applicazione. Per aiutarti a prendere una decisione di architettura in linea con i tuoi scopi commerciali e tecnici, consulta Confronto di architetture diverse per i backend delle applicazioni web basate su contenuti e Considerazioni chiave per i backend web.
Con un'architettura di microservizi, puoi utilizzare applicazioni containerizzate con Kubernetes come livello di runtime comune. Con il pattern di architettura ibrida a più livelli, puoi eseguirlo in uno dei seguenti scenari:
In entrambi gli ambienti (Google Cloud e nei tuoi ambienti on-premise).
- Quando utilizzi container e Kubernetes in diversi ambienti, hai la flessibilità di modernizzare i carichi di lavoro e poi eseguire la migrazione a Google Cloud in momenti diversi. Questo è utile quando un carico di lavoro dipende molto da un altro e non può essere sottoposto a migrazione singolarmente oppure per utilizzare la portabilità dei carichi di lavoro ibridi per utilizzare le migliori risorse disponibili in ogni ambiente. In ogni caso, GKE Enterprise può essere una tecnologia di base fondamentale. Per maggiori informazioni, consulta Ambiente ibrido GKE Enterprise.
In un Google Cloud ambiente per i componenti dell'applicazione sottoposti a migrazione e modernizzazione.
- Utilizza questo approccio se hai backend legacy on-premise che non supportano la containerizzazione o richiedono tempo e risorse significativi per essere modernizzati a breve termine.
Per ulteriori informazioni sulla progettazione e sul refactoring di un'app monolitica in un'architettura di microservizi per modernizzare l'architettura dell'applicazione web, consulta Introduzione ai microservizi.
Puoi combinare le tecnologie di archiviazione dei dati in base alle esigenze delle tue applicazioni web. L'utilizzo di Cloud SQL per i dati strutturati e di Cloud Storage per i file multimediali è un approccio comune per soddisfare diverse esigenze di archiviazione dei dati. Detto questo, la scelta dipende in gran parte dal caso d'uso. Per maggiori informazioni sulle opzioni di archiviazione dei dati per i backend delle applicazioni basate sui contenuti e sulle modalità efficaci, consulta Opzioni di archiviazione dei dati per le app web basate sui contenuti. Consulta anche Informazioni sulle opzioni del Google Cloud database.