Pattern ibrido a livelli

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 diversi ambienti di elaborazione. Nell'ambito del modello di architettura ibrido a livelli, gli ambienti di computing si trovano in un ambiente di computing 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 di solito si basano su applicazioni backend per archiviare e gestire i dati e, potenzialmente, per la logica di business e l'elaborazione degli input utente, sono spesso stateless o gestiscono solo volumi limitati di dati.

Per essere accessibili e utilizzabili, puoi creare le tue applicazioni frontend con vari framework e tecnologie. Le prestazioni dell'applicazione, la velocità di risposta e la compatibilità del browser includono alcuni fattori chiave per il successo di un'applicazione di frontend.

In genere, i componenti delle applicazioni di backend sono incentrati sull'archiviazione e la gestione dei dati. In alcune architetture, la logica di business può essere incorporata nel componente backend. Le nuove release delle applicazioni di backend tendono a essere meno frequenti delle release delle applicazioni di frontend. Le applicazioni di backend presentano le seguenti sfide di gestione:

• Gestione di un grande volume di richieste
• Gestione di un grande volume di dati
• Protezione dei dati
• Mantenere dati attuali e aggiornati in tutte le repliche di sistema

L'architettura delle applicazioni a tre livelli è una delle implementazioni più popolari per la creazione di applicazioni web aziendali, come i siti web di e-commerce che contengono diversi componenti delle applicazioni. Questa architettura include 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
• Accesso ai dati o livello di backend

L'inserimento di questi strati in container consente di separare le esigenze tecniche, ad esempio i requisiti di scalabilità, e di eseguirne la migrazione in un approccio graduale. Consente inoltre di eseguirne il deployment su servizi cloud indipendenti dalla piattaforma che possono essere portabili in diversi ambienti, di utilizzare la gestione automatizzata e di scalare con piattaforme gestite dal cloud come Cloud Run o la versione Google Kubernetes Engine (GKE) Enterprise. Inoltre, i database gestiti da Google Cloud come Cloud SQL contribuiscono a fornire il backend come livello di database.

Il modello di architettura ibrida a più livelli si concentra sul deployment dei componenti delle applicazioni frontend esistenti nel cloud pubblico. Con questo pattern, mantieni tutti i componenti delle applicazioni di backend esistenti nel loro ambiente di computing privato. A seconda della scala e della progettazione specifica dell'applicazione, puoi eseguire la migrazione dei componenti dell'applicazione frontend caso per caso. Per ulteriori informazioni, consulta Eseguire la migrazione a Google Cloud.

Se hai un'applicazione esistente con componenti backend e frontend ospitati nel tuo ambiente on-premise, considera i limiti della tua architettura attuale. Ad esempio, man mano che la tua applicazione scala e le esigenze di prestazioni e affidabilità aumentano, dovresti iniziare a valutare se parti della tua applicazione debbano essere sottoposte a refactoring o spostate a un'architettura diversa e più ottimale. Il pattern di architettura ibrida a più livelli consente di spostare alcuni carichi di lavoro e componenti delle applicazioni nel cloud prima di effettuare una transizione completa. È inoltre essenziale considerare i costi, i tempi e i rischi associati a una migrazione di questo tipo.

Il seguente diagramma mostra un tipico modello 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 restituisce i dati all'ambiente on-premise in cui è ospitato il backend dell'applicazione (possibilmente tramite un gateway API).

Con il pattern di architettura ibrida a più livelli, puoi sfruttare l'infrastruttura di Google Cloud e i servizi globali, come mostrato nell'architettura di esempio nel diagramma seguente. Il frontend dell'applicazione è raggiungibile tramite Google Cloud. Può anche aggiungere elasticità al frontend utilizzando la scalabilità automatica per rispondere in modo dinamico ed efficiente alla domanda di scalabilità senza eseguire il provisioning eccessivo dell'infrastruttura. Esistono diverse architetture che puoi utilizzare per creare ed eseguire app web scalabili su Google Cloud. Ogni architettura presenta vantaggi e svantaggi a seconda dei requisiti.

Per saperne di più, guarda 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 offrire un'esperienza utente multiregionale e ottimizzata a livello globale che utilizza il bilanciamento del carico globale, la scalabilità automatica e la protezione DDoS tramite Google Cloud Armor.

Nel corso del tempo, il numero di applicazioni di cui esegui il deployment nel cloud pubblico potrebbe aumentare a tal punto che potresti prendere in considerazione lo spostamento dei componenti delle applicazioni di backend nel cloud pubblico. Se prevedi di gestire traffico elevato, optare per i servizi gestiti nel cloud potrebbe aiutarti a risparmiare il lavoro di progettazione per la gestione della tua infrastruttura. Prendi in considerazione questa opzione a meno che vincoli o requisiti impongano l'hosting dei componenti dell'applicazione backend on-premise. Ad esempio, se i tuoi dati di backend sono soggetti a restrizioni normative, probabilmente dovrai mantenerli on-premise. Ove applicabile e conforme, tuttavia, l'utilizzo di funzionalità di Sensitive Data Protection, come le tecniche di anonimizzazione, può aiutarti a spostare questi dati quando necessario.

Nel pattern di architettura ibrida a più livelli, puoi anche utilizzare Google Distributed Cloud in alcuni scenari. Distributed Cloud consente di eseguire i cluster di Google Kubernetes Engine su hardware dedicato fornito e gestito da Google e separato dal data center di Google Cloud. Per garantire che Distributed Cloud soddisfi i tuoi requisiti attuali e futuri, devi conoscere le limitazioni di Distributed Cloud rispetto a una convenzionale zona GKE basata su cloud.

Vantaggi

Concentrarsi prima 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 frontend. Pertanto, isolare e migrare le applicazioni frontend tende a essere meno complesso rispetto alla migrazione delle applicazioni di backend.
• Poiché le applicazioni di frontend sono spesso stateless o non gestiscono i dati da sole, la migrazione tendono a essere meno complessa dei backend.
  • I componenti di frontend possono essere ottimizzati come parte della migrazione per utilizzare l'architettura stateless. Per saperne di più, guarda How to port stateful web app to Cloud Run su YouTube.

Il deployment di applicazioni frontend esistenti o di recente sviluppo 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 continua/deployment continuo (CI/CD). Puoi usare CI/CD per inviare aggiornamenti in modo efficiente e automatizzato. Per ulteriori informazioni, consulta CI/CD su Google Cloud.
• I frontend sensibili alle prestazioni con carico di traffico variabile possono trarre notevole vantaggio dalle funzionalità di bilanciamento del carico, deployment in più regioni, memorizzazione nella cache di Cloud CDN, funzionalità serverless e di scalabilità automatica abilitate da un deployment basato su cloud (preferibilmente con l'architettura stateless).

• L'adozione di microservizi con container utilizzando una piattaforma gestita nel cloud, come GKE, ti consente di utilizzare architetture moderne come microfrontend, che estendono i microservizi ai componenti del frontend.

  L'estensione dei microservizi è comunemente utilizzata con frontend che coinvolgono più team che collaborano sulla stessa applicazione. Una struttura di team di questo tipo richiede un approccio iterativo e una manutenzione continua. Ecco alcuni vantaggi dell'utilizzo del microfrontend:

  • Trasformabile in moduli di microservizi indipendenti per lo sviluppo, il test e il deployment.
  • Offre una separazione in cui i singoli team di sviluppo possono selezionare le tecnologie e il codice preferiti.
  • Può favorire cicli rapidi di sviluppo e deployment senza alterare gli altri componenti del frontend che potrebbero essere gestiti da altri team.

• Che si tratti di implementare interfacce utente o API o gestire l'importazione dati 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 nel cloud aiutano a:

  • Disaccoppia l'API per le app dai tuoi servizi di backend, ad esempio i microservizi.
  • Proteggi le app dalle modifiche al codice del backend.
  • Supporta le tue architetture frontend basate su API esistenti, come backend per frontend (BFF), microfrontend e altre.
  • Esponi le tue API su Google Cloud o in altri ambienti implementando proxy API su Apigee.

Puoi anche applicare al contrario il pattern ibrido a più livelli eseguendo il deployment dei backend nel cloud e mantenendo i frontend negli ambienti di computing privati. Sebbene meno comune, questo approccio viene applicato al meglio quando abbiamo a che fare con un frontend pesante e monolitico. In questi casi, potrebbe essere più semplice estrarre in modo iterativo le funzionalità di backend ed eseguire il deployment di questi nuovi backend nel cloud.

La terza parte di questa serie illustra i possibili pattern di networking per abilitare questa architettura. Apigee ibrido aiuta come piattaforma per la creazione e la gestione di proxy API in un modello di deployment ibrido. Per ulteriori informazioni, consulta Architettura a basso accoppiamento, incluse le architetture monolitiche e a microservizi a più livelli.

Best practice

Utilizza le informazioni in questa sezione per pianificare l'architettura ibrida a più livelli.

Best practice per ridurre la complessità

Quando applichi il modello di architettura ibrida a più livelli, prendi in considerazione le seguenti best practice che possono aiutarti a ridurre il deployment complessivo e la complessità operativa:

• 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 dell'interazione degli utenti coinvolge sistemi che si connettono tra più ambienti di elaborazione, una connettività rapida e a bassa latenza tra questi sistemi è importante. Per soddisfare le aspettative di disponibilità e prestazioni, dovresti progettare un'alta disponibilità, una bassa latenza e livelli di velocità effettiva appropriati. Dal punto di vista della sicurezza, la comunicazione deve essere granulare e controllata. L'ideale sarebbe esporre i componenti dell'applicazione usando API sicure. Per maggiori informazioni, consulta Traffico in uscita con accesso limitato.

• Per ridurre al minimo la latenza della comunicazione tra gli ambienti, seleziona una regione di Google Cloud geograficamente vicina all'ambiente di computing privato in cui sono ospitati i componenti di backend dell'applicazione. Per ulteriori informazioni, consulta Best practice per la selezione delle regioni di Compute Engine.
• Riduci al minimo le dipendenze elevate tra i sistemi in esecuzione in ambienti diversi, in particolare quando la comunicazione è gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni, diminuire 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 di traffico in entrata maggiori dagli ambienti on-premise che arrivano in Google Cloud rispetto al traffico in uscita che esce da Google Cloud. Tuttavia, dovresti conoscere il volume di trasferimenti di dati in uscita previsto da Google Cloud. Se prevedi di utilizzare questa architettura a lungo termine con volumi di trasferimento di dati in uscita elevati, valuta di utilizzare Cloud Interconnect. Cloud Interconnect può aiutare 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, consigliamo di criptare tutte le comunicazioni in transito. Se è necessaria la crittografia a livello di connettività, puoi utilizzare tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.

• Per risolvere incoerenze nei protocolli, nelle API e nei meccanismi di autenticazione tra backend diversi, consigliamo, ove applicabile, di eseguire il deployment di un gateway API o di un proxy come facciata unificata. Questo gateway o proxy agisce come 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 del backend.
  • Facilita gli audit trail per la comunicazione tra tutte le applicazioni cross-environment e i relativi componenti disaccoppiati.
  • Funge da livello di comunicazione intermedio tra servizi legacy e modernizzati.
    • Apigee e Apigee ibridi consentono di ospitare e gestire gateway di livello enterprise e ibridi in ambienti on-premise, in ambienti perimetrali, in altri cloud e in ambienti Google Cloud.

• Per facilitare la creazione di configurazioni ibride, utilizza Cloud Load Balancing con la connettività ibrida. Ciò significa che puoi estendere i vantaggi del bilanciamento del carico del cloud ai servizi ospitati nell'ambiente di calcolo on-premise. Questo approccio consente migrazioni graduale dei carichi di lavoro in Google Cloud con interruzioni minime o nulle del servizio, garantendo una transizione senza problemi per i servizi distribuiti. Per maggiori informazioni, consulta Panoramica dei gruppi di endpoint di rete con connettività ibrida.

• A volte, l'utilizzo combinato di un gateway API o di un proxy e di un bilanciatore del carico delle applicazioni può fornire una soluzione più solida per la gestione, la protezione e la distribuzione del traffico API su larga scala. L'utilizzo di Cloud Load Balancing 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à durante i periodi di picco del traffico. Per ulteriori informazioni, guarda il video relativo alla distribuzione di API ad alte prestazioni con Apigee e Cloud CDN su YouTube.
  • Implementa una gestione avanzata del traffico.
  • Utilizza Google Cloud Armor come servizio di protezione dagli attacchi DDoS e sicurezza di rete per proteggere le tue API.
  • Gestisci un bilanciamento del carico efficiente tra gateway in più regioni. Per ulteriori informazioni, guarda il video Protezione delle API e implementazione del 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 a 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 all'organizzazione e alle entità esterne di utilizzare questi servizi esponendoli come API.

• Stabilisci un'identità comune tra gli ambienti in modo che i sistemi possano eseguire l'autenticazione sicura oltre i confini degli ambienti.

• Esegui il deployment di sistemi di gestione delle configurazioni CI/CD e nel cloud pubblico. Per maggiori informazioni, consulta Pattern di architettura di rete speculare.

• Per aumentare l'efficienza operativa, utilizza strumenti coerenti e pipeline CI/CD in tutti gli ambienti.

Best practice per le architetture dei singoli carichi di lavoro e delle applicazioni

• Sebbene in questo pattern l'attenzione si concentri sulle applicazioni frontend, stai consapevole della necessità di modernizzare le tue applicazioni di backend. Se il ritmo di sviluppo delle applicazioni backend è molto più lento rispetto a quello delle applicazioni frontend, la differenza può causare ulteriore complessità.
• Trattare le API come interfacce di backend semplifica le integrazioni, lo sviluppo del frontend e le interazioni con i servizi e nasconde le complessità del sistema di backend. Per affrontare queste sfide, Apigee facilita lo sviluppo e la gestione di gateway API/proxy per deployment ibridi e multi-cloud.
• Scegli l'approccio di rendering per la tua applicazione web frontend in base ai contenuti (statici o dinamici), alle prestazioni di ottimizzazione per i motori di ricerca e alle aspettative relative alla velocità di caricamento delle pagine.
• Quando si sceglie un'architettura per applicazioni web basate sui contenuti, sono disponibili varie opzioni, tra cui architetture monolitiche, serverless, basate su eventi e microservizi. Per scegliere l'architettura più adatta, valuta accuratamente queste opzioni rispetto ai requisiti delle applicazioni attuali e future. Per aiutarti a prendere una decisione relativa all'architettura in linea con i tuoi scopi commerciali e tecnici, consulta Confronto di architetture diverse per backend di applicazioni web basate sui contenuti e Considerazioni principali per i backend web.

• Con un'architettura di microservizi puoi usare applicazioni containerizzate con Kubernetes come livello di runtime. Con il pattern di architettura ibrida a più livelli, puoi eseguirlo in uno dei seguenti scenari:

  • In entrambi gli ambienti (Google Cloud e gli ambienti on-premise).

    • Quando utilizzi container e Kubernetes in più ambienti, hai la flessibilità necessaria per modernizzare i carichi di lavoro e quindi eseguire la migrazione a Google Cloud in momenti diversi. Ciò è utile quando un carico di lavoro dipende fortemente da un altro e non può essere migrato singolarmente o a utilizzare la portabilità ibrida dei carichi di lavoro per utilizzare le migliori risorse disponibili in ciascun ambiente. In tutti i casi, GKE Enterprise può essere una tecnologia fondamentale per l'abilitazione. Per maggiori informazioni, consulta Ambiente ibrido di GKE Enterprise.

  • In un ambiente Google Cloud per i componenti delle applicazioni migrati e modernizzati.

    • Utilizza questo approccio quando hai backend on-premise legacy che non supportano la containerizzazione o richiedono tempo e risorse significativi per la modernizzazione a breve termine.

    Per ulteriori informazioni sulla progettazione e il 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 a seconda delle 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 molto dal caso d'uso specifico. Per ulteriori informazioni sulle opzioni di archiviazione dei dati per i backend delle applicazioni basate sui contenuti e le modalità efficaci, consulta Opzioni di archiviazione dei dati per le app web basate sui contenuti. Vedi anche la sezione Spiegazione delle opzioni di database di Google Cloud