Considerazioni sulla progettazione di app ibride
Microsoft Azure è l'unico cloud ibrido coerente. Consente di riutilizzare gli investimenti di sviluppo e di abilitare le app che possono estendersi su Azure globale, i cloud di Azure sovrani e Azure Stack, che è un'estensione di Azure nel data center. Le app che si estendono su cloud sono dette anche app ibride .
La guida all'architettura delle applicazioni di Azure descrive un approccio strutturato per la progettazione di app scalabili, resilienti e a disponibilità elevata. Le considerazioni descritte nella guida all'architettura delle applicazioni di Azure ugualmente valide per le app progettate per un singolo cloud e per le app che si estendono su cloud.
Questo articolo illustra i concetti fondamentali
Gli scenari ibridi variano notevolmente con le risorse disponibili per lo sviluppo e considerazioni dettagliate, ad esempio geografia, sicurezza, accesso a Internet e altre considerazioni. Anche se questa guida non può enumerare le considerazioni specifiche, può fornire alcune linee guida chiave e procedure consigliate da seguire. La progettazione, la configurazione, la distribuzione e la gestione di un'architettura di app ibrida comportano molte considerazioni di progettazione che potrebbero non essere intrinsecamente note all'utente.
Questo documento mira a aggregare le possibili domande che possono verificarsi durante l'implementazione di app ibride e fornisce considerazioni (questi pilastri) e procedure consigliate per usarle. Risolvendo queste domande durante la fase di progettazione, si evitano i problemi che potrebbero causare nell'ambiente di produzione.
Essenzialmente, queste sono domande che è necessario considerare prima di creare un'app ibrida. Per iniziare, è necessario eseguire le operazioni seguenti:
- Identificare e valutare i componenti dell'app.
- Valutare i componenti dell'app rispetto ai pilastri.
Valutare i componenti dell'app
Ogni componente di un'app ha un proprio ruolo specifico all'interno dell'app più grande e deve essere esaminato con tutte le considerazioni di progettazione. I requisiti e le funzionalità di ogni componente devono essere mappati a queste considerazioni per determinare l'architettura dell'app.
Scomporre l'app nei relativi componenti studiando l'architettura dell'app e determinando di cosa è costituita. I componenti possono includere anche altre app con cui l'app interagisce. Quando si identificano i componenti, valutare le operazioni ibride desiderate in base alle relative caratteristiche ponendo queste domande:
- Qual è lo scopo del componente?
- Quali sono le interdipendenze tra i componenti?
Ad esempio, un'app può avere un front-end e un back-end definiti come due componenti. In uno scenario ibrido, il front-end si trova in un cloud e il back-end si trova nell'altro. L'app fornisce canali di comunicazione tra il front-end e l'utente e anche tra il front-end e il back-end.
Un componente dell'app è definito da molti scenari e moduli. L'attività più importante consiste nell'identificarli e nella posizione locale o nel cloud.
I componenti comuni delle app da includere nell'inventario sono elencati nella tabella 1.
Tabella 1. Componenti comuni delle app
| componente |
linee guida per le app ibride |
|---|---|
| Connessioni client | L'app (in qualsiasi dispositivo) può accedere agli utenti in diversi modi, da un punto di ingresso singolo, inclusi i modi seguenti: - Modello client-server che richiede l'installazione di un client da parte dell'utente per l'uso con l'app. Un'app basata su server a cui si accede da un browser. - Le connessioni client possono includere notifiche quando la connessione viene interrotta o gli avvisi quando possono essere applicati addebiti per il roaming. |
| Autenticazione | L'autenticazione può essere necessaria per un utente che si connette all'app o da un componente che si connette a un altro. |
| Api | È possibile fornire agli sviluppatori l'accesso a livello di codice all'app con set di API e librerie di classi e fornire un'interfaccia di connessione basata su standard Internet. È anche possibile usare le API per scomporre un'app in unità logiche in modo indipendente. |
| Servizi | È possibile usare servizi concisi per fornire le funzionalità per un'app. Un servizio può essere il motore in cui viene eseguita l'app. |
| Code | Puoi usare le code per organizzare lo stato dei cicli di vita e degli stati dei componenti dell'app. Queste code possono fornire funzionalità di messaggistica, notifiche e buffering per le entità di sottoscrizione. |
| Archiviazione dei dati | Un'app può essere senza stato o con stato. Le app con stato richiedono l'archiviazione dei dati che può essere soddisfatta da numerosi formati e volumi. |
| Memorizzazione nella cache dei dati | Un componente di memorizzazione nella cache dei dati nella progettazione può risolvere in modo strategico i problemi di latenza e svolgere un ruolo nell'attivazione del bursting nel cloud. |
| Inserimento dati | I dati possono essere inviati a un'app in molti modi, da valori inviati dall'utente in un modulo Web a un flusso di dati con volumi continui. |
| Elaborazione dati | Le attività di elaborazione dati, ad esempio report, analisi, esportazioni batch e trasformazione dei dati, possono essere elaborate nell'origine o caricate in un componente separato usando una copia dei dati. |
Valutare i componenti dell'app per i pilastri
Per ogni componente, valutarne le caratteristiche per ogni pilastro. Quando si valuta ogni componente con tutti i pilastri, le domande che potrebbero non essere state considerate potrebbero diventare note all'utente che influiscono sulla progettazione dell'app ibrida. L'azione su queste considerazioni può aggiungere valore nell'ottimizzazione dell'app. La tabella 2 fornisce una descrizione di ogni pilastro in relazione alle app ibride.
Tabella 2. Pilastri
| pilastro | Descrizione |
|---|---|
| Collocamento | Posizionamento strategico dei componenti nelle app ibride. |
| Scalabilità | Capacità di un sistema di gestire un carico maggiore. |
| Disponibilità | Percentuale di tempo in cui un'app ibrida è funzionale e funzionante. |
| Resilienza | Possibilità di ripristino di un'app ibrida. |
| Maneggiabilità | Processi operativi che mantengono un sistema in esecuzione nell'ambiente di produzione. |
| Sicurezza | Protezione delle app ibride e dei dati dalle minacce. |
Collocamento
Un'app ibrida ha intrinsecamente una considerazione sul posizionamento, ad esempio per il data center.
Il posizionamento è l'importante attività di posizionamento dei componenti in modo che possano garantire il servizio ottimale di un'app ibrida. Per definizione, le app ibride si estendono su posizioni, ad esempio dall'ambiente locale al cloud e tra cloud diversi. È possibile inserire componenti dell'app nei cloud in due modi:
app ibride verticali
I componenti dell'app vengono distribuiti tra le posizioni. Ogni singolo componente può avere più istanze che si trovano solo in un'unica posizione.app ibride orizzontali
I componenti dell'app vengono distribuiti tra le posizioni. Ogni singolo componente può avere più istanze che si estendono su più posizioni.Alcuni componenti possono essere a conoscenza della loro posizione, mentre altri non hanno alcuna conoscenza della loro posizione e posizionamento. Questa virtuosità può essere ottenuta con un livello di astrazione. Questo livello, con un framework di app moderno come i microservizi, può definire il modo in cui l'app viene gestita dal posizionamento dei componenti dell'app che operano sui nodi tra cloud.
Elenco di controllo per il posizionamento
Verificare le posizioni necessarie. Assicurarsi che l'app o uno dei relativi componenti sia necessaria per funzionare o richiedere la certificazione per un cloud specifico. Ciò può includere i requisiti di sovranità dell'azienda o dettati dalla legge. Determinare anche se sono necessarie operazioni locali per una determinata posizione o impostazioni locali.
Verificare le dipendenze di connettività. I percorsi obbligatori e altri fattori possono determinare le dipendenze di connettività tra i componenti. Quando si inseriscono i componenti, determinare la connettività e la sicurezza ottimali per la comunicazione tra di esse. Le scelte includono VPN,ExpressRoute, e connessioni ibride.
Valutare le funzionalità della piattaforma. Per ogni componente dell'app, verificare se il provider di risorse necessario per il componente dell'app è disponibile nel cloud e se la larghezza di banda può soddisfare i requisiti di velocità effettiva e latenza previsti.
Pianificare la portabilità. Usare framework di app moderni, ad esempio contenitori o microservizi, per pianificare le operazioni di spostamento e impedire le dipendenze del servizio.
Determinare i requisiti di sovranità dei dati. Le app ibride sono destinate all'isolamento dei dati, ad esempio in un data center locale. Esaminare la posizione delle risorse per ottimizzare il successo per soddisfare questo requisito.
Pianificare la latenza. Le operazioni tra cloud possono introdurre una distanza fisica tra i componenti dell'app. Verificare i requisiti per soddisfare qualsiasi latenza.
Controllare i flussi di traffico. Gestire il picco di utilizzo e le comunicazioni appropriate e protette per i dati di informazioni personali quando si accede dal front-end in un cloud pubblico.
Scalabilità
La scalabilità è la capacità di un sistema di gestire un carico maggiore in un'app, che può variare nel tempo, in quanto altri fattori e forze influiscono sulle dimensioni del pubblico, oltre alle dimensioni e all'ambito dell'app.
Per una discussione di base su questo pilastro, vedere scalabilità nei cinque pilastri dell'eccellenza dell'architettura.
Un approccio di scalabilità orizzontale per le app ibride consente di aggiungere altre istanze per soddisfare la domanda e quindi disabilitarle durante periodi più silenziosi.
Negli scenari ibridi, la scalabilità orizzontale dei singoli componenti richiede considerazioni aggiuntive quando i componenti vengono distribuiti tra cloud. Il ridimensionamento di una parte dell'app può richiedere la scalabilità di un'altra. Ad esempio, se il numero di connessioni client aumenta ma i servizi Web dell'app non vengono ridimensionati in modo appropriato, il carico nel database potrebbe saturare l'app.
Alcuni componenti dell'app possono aumentare il numero di istanze in modo lineare, mentre altri hanno dipendenze di ridimensionamento e potrebbero essere limitati alla misura in cui sono in grado di ridimensionare. Ad esempio, un tunnel VPN che fornisce connettività ibrida per le posizioni dei componenti dell'app ha un limite alla larghezza di banda e alla latenza a cui può essere ridimensionato. Come vengono ridimensionati i componenti dell'app per garantire che questi requisiti siano soddisfatti?
Elenco di controllo per la scalabilità
Verificare le soglie di ridimensionamento. Per gestire le varie dipendenze nell'app, determinare la misura in cui i componenti dell'app in cloud diversi possono essere ridimensionati in modo indipendente l'uno dall'altro, pur rispettando i requisiti per eseguire l'app. Le app ibride spesso devono ridimensionare aree specifiche nell'app per gestire una funzionalità mentre interagisce e influisce sul resto dell'app. Ad esempio, il superamento di un numero di istanze front-end potrebbe richiedere il ridimensionamento del back-end.
Definire le pianificazioni di scalabilità. La maggior parte delle app ha periodi di attività, quindi è necessario aggregare i tempi di picco nelle pianificazioni per coordinare il ridimensionamento ottimale.
Usare un sistema di monitoraggio centralizzato. Le funzionalità di monitoraggio della piattaforma possono offrire la scalabilità automatica, ma le app ibride necessitano di un sistema di monitoraggio centralizzato che aggrega l'integrità e il carico del sistema. Un sistema di monitoraggio centralizzato può avviare il ridimensionamento di una risorsa in una posizione e il ridimensionamento a seconda della risorsa in un'altra posizione. Inoltre, un sistema di monitoraggio centrale può tenere traccia delle risorse di scalabilità automatica dei cloud e quali cloud non lo fanno.
Sfruttare le funzionalità di scalabilità automatica (disponibile). Se le funzionalità di scalabilità automatica fanno parte dell'architettura, si implementa la scalabilità automatica impostando le soglie che definiscono quando è necessario aumentare, ridurre o ridurre le prestazioni di un componente dell'app. Un esempio di scalabilità automatica è una connessione client ridimensionata automaticamente in un cloud per gestire una maggiore capacità, ma causa anche la scalabilità di altre dipendenze dell'app, distribuite in cloud diversi. È necessario verificare le funzionalità di scalabilità automatica di questi componenti dipendenti.
Se la scalabilità automatica non è disponibile, è consigliabile implementare script e altre risorse per supportare il ridimensionamento manuale, attivato dalle soglie nel sistema di monitoraggio centralizzato.
Determinare il carico previsto in base alla posizione. Le app ibride che gestiscono le richieste client possono basarsi principalmente su un'unica posizione. Quando il carico delle richieste client supera una soglia, è possibile aggiungere risorse aggiuntive in un percorso diverso per distribuire il carico delle richieste in ingresso. Assicurarsi che le connessioni client possano gestire i carichi aumentati e determinare anche eventuali procedure automatizzate per le connessioni client per gestire il carico.
Disponibilità
La disponibilità è il momento in cui un sistema funziona e funziona. La disponibilità viene misurata come percentuale di tempo di attività. Gli errori delle app, i problemi dell'infrastruttura e il carico di sistema possono ridurre la disponibilità.
Per una discussione di base su questo pilastro, vedere disponibilità nei cinque pilastri dell'eccellenza dell'architettura.
Elenco di controllo della disponibilità
Fornire ridondanza per la connettività. Le app ibride richiedono la connettività tra i cloud distribuiti nell'app. Si dispone di una scelta di tecnologie per la connettività ibrida, quindi, oltre alla scelta della tecnologia principale, usare un'altra tecnologia per fornire ridondanza con funzionalità di failover automatizzato in caso di errore della tecnologia primaria.
Classificare i domini di errore. Le app a tolleranza di errore richiedono più domini di errore. I domini di errore consentono di isolare il punto di errore, ad esempio se un singolo disco rigido non riesce in locale, se un commutatore top-of-rack diventa inattivo o se il data center completo non è disponibile. In un'app ibrida, una posizione può essere classificata come dominio di errore. Con più requisiti di disponibilità, più è necessario valutare come classificare un singolo dominio di errore.
Classificare i domini di aggiornamento. I domini di aggiornamento vengono usati per garantire che le istanze dei componenti dell'app siano disponibili, mentre altre istanze dello stesso componente vengono gestite con aggiornamenti o aggiornamenti delle funzionalità. Come per i domini di errore, i domini di aggiornamento possono essere classificati in base al posizionamento in posizioni diverse. Devi determinare se un componente dell'app può supportare l'aggiornamento in un'unica posizione prima che venga aggiornato in un'altra posizione o se sono necessarie altre configurazioni di dominio. Un'unica posizione può avere più domini di aggiornamento.
Tenere traccia delle istanze e della disponibilità. I componenti dell'app a disponibilità elevata possono essere disponibili tramite il bilanciamento del carico e la replica sincrona dei dati. È necessario determinare il numero di istanze che possono essere offline prima che il servizio venga interrotto.
Implementare la riparazione automatica. Nel caso in cui un problema causi un'interruzione della disponibilità dell'app, un rilevamento da parte di un sistema di monitoraggio potrebbe avviare attività di riparazione automatica all'app, ad esempio svuotando l'istanza non riuscita e ridistribuendolo. Molto probabilmente è necessaria una soluzione di monitoraggio centrale, integrata con una pipeline di integrazione continua ibrida e recapito continuo (CI/CD). L'app è integrata con un sistema di monitoraggio per identificare i problemi che potrebbero richiedere la ridistribuzione di un componente dell'app. Il sistema di monitoraggio può anche attivare ci/CD ibrido per ridistribuire il componente dell'app e potenzialmente qualsiasi altro componente dipendente nella stessa posizione o in altre posizioni.
Gestire i contratti di servizio. La disponibilità è fondamentale per tutti i contratti per mantenere la connettività ai servizi e alle app presenti con i clienti. Ogni località su cui si basa l'app ibrida potrebbe avere un contratto di servizio specifico. Questi contratti di servizio diversi possono influire sul contratto di servizio complessivo dell'app ibrida.
Resilienza
La resilienza è la possibilità per un'app ibrida e un sistema di eseguire il ripristino da errori e continuare a funzionare. L'obiettivo della resilienza è restituire l'app a uno stato completamente funzionante dopo un errore. Le strategie di resilienza includono soluzioni come backup, replica e ripristino di emergenza.
Per una discussione di base su questo pilastro, vedere resilienza nei cinque pilastri dell'eccellenza dell'architettura.
Elenco di controllo per la resilienza
Individuare le dipendenze del ripristino di emergenza. Il ripristino di emergenza in un cloud potrebbe richiedere modifiche ai componenti dell'app in un altro cloud. Se uno o più componenti da un cloud vengono eseguiti il failover in un'altra posizione, all'interno dello stesso cloud o in un altro cloud, è necessario che i componenti dipendenti siano consapevoli di queste modifiche. Sono incluse anche le dipendenze di connettività. La resilienza richiede un piano di ripristino delle app completamente testato per ogni cloud.
Stabilire il flusso di ripristino. Una progettazione efficace del flusso di ripristino ha valutato i componenti dell'app per la capacità di supportare buffer, tentativi, tentativi di trasferimento dei dati non riusciti e, se necessario, eseguire il fallback a un servizio o a un flusso di lavoro diverso. È necessario determinare il meccanismo di backup da usare, la relativa procedura di ripristino e la frequenza con cui viene testato. È inoltre necessario determinare la frequenza per i backup incrementali e completi.
Testare i ripristini parziali. Un ripristino parziale per parte dell'app può garantire agli utenti che non sono tutti disponibili. Questa parte del piano deve garantire che un ripristino parziale non abbia effetti collaterali, ad esempio un servizio di backup e ripristino che interagisce con l'app per arrestarlo normalmente prima dell'esecuzione del backup.
Determinare gli instigatori di ripristino di emergenza e assegnare la responsabilità. Un piano di ripristino deve descrivere chi e quali ruoli possono avviare azioni di backup e ripristino oltre a ciò che è possibile eseguire il backup e il ripristino.
Confrontare le soglie di riparazione automatica con il ripristino di emergenza. Determinare le funzionalità di riparazione automatica di un'app per l'avvio automatico del ripristino e il tempo necessario per la riparazione automatica di un'app per essere considerato un errore o un esito positivo. Determinare le soglie per ogni cloud.
Verificare la disponibilità delle funzionalità di resilienza. Determinare la disponibilità delle funzionalità e delle funzionalità di resilienza per ogni posizione. Se una posizione non fornisce le funzionalità necessarie, prendere in considerazione l'integrazione di tale posizione in un servizio centralizzato che fornisce le funzionalità di resilienza.
Determinare i tempi di inattività. Determinare il tempo di inattività previsto dovuto alla manutenzione per l'app nel suo complesso e come componenti dell'app.
Procedure di risoluzione dei problemi dei documenti. Definire le procedure di risoluzione dei problemi per ridistribuire risorse e componenti dell'app.
Maneggiabilità
Le considerazioni sulla gestione delle app ibride sono fondamentali per la progettazione dell'architettura. Un'app ibrida ben gestita fornisce un'infrastruttura come codice che consente l'integrazione di codice dell'app coerente in una pipeline di sviluppo comune. Implementando test coerenti a livello di sistema e singoli test delle modifiche apportate all'infrastruttura, è possibile garantire una distribuzione integrata se le modifiche superano i test, consentendo loro di essere unite nel codice sorgente.
Per la discussione di base su questo pilastro, vedere DevOps nei cinque pilastri dell'eccellenza dell'architettura.
Elenco di controllo per la gestibilità
Implementare il monitoraggio. Usare un sistema di monitoraggio centralizzato dei componenti dell'app distribuiti tra cloud per offrire una visualizzazione aggregata dell'integrità e delle prestazioni. Questo sistema include il monitoraggio sia dei componenti dell'app che delle funzionalità della piattaforma correlate.
Determinare le parti dell'app che richiedono il monitoraggio.
Coordinare i criteri. Ogni posizione estesa da un'app ibrida può avere criteri specifici che riguardano i tipi di risorse consentiti, le convenzioni di denominazione, i tag e altri criteri.
Definire e usare i ruoli. In qualità di amministratore del database, è necessario determinare le autorizzazioni necessarie per utenti diversi (ad esempio un proprietario dell'app, un amministratore del database e un utente finale) che devono accedere alle risorse dell'app. Queste autorizzazioni devono essere configurate nelle risorse e all'interno dell'app. Un sistema di controllo degli accessi in base al ruolo consente di impostare queste autorizzazioni per le risorse dell'app. Questi diritti di accesso sono difficili quando tutte le risorse vengono distribuite in un singolo cloud, ma richiedono ancora più attenzione quando le risorse vengono distribuite tra cloud. Le autorizzazioni per le risorse impostate in un cloud non si applicano alle risorse impostate in un altro cloud.
Usare le pipeline CI/CD. Una pipeline di integrazione continua e sviluppo continuo (CI/CD) può offrire un processo coerente per la creazione e la distribuzione di app che si estendono su cloud e per garantire la garanzia di qualità per l'infrastruttura e l'app. Questa pipeline consente di testare l'infrastruttura e l'app in un cloud e distribuirla in un altro cloud. La pipeline consente anche di distribuire determinati componenti dell'app ibrida in un cloud e in altri componenti in un altro cloud, essenzialmente formando le basi per la distribuzione di app ibride. Un sistema CI/CD è fondamentale per gestire i componenti dell'app per le dipendenze l'uno per l'altro durante l'installazione, ad esempio l'app Web che richiede una stringa di connessione al database.
Gestire il ciclo di vita. Poiché le risorse di un'app ibrida possono estendersi in posizioni, ogni singola funzionalità di gestione del ciclo di vita deve essere aggregata in una singola unità di gestione del ciclo di vita. Valutare come vengono creati, aggiornati ed eliminati.
Esaminare le strategie di risoluzione dei problemi. La risoluzione dei problemi di un'app ibrida comporta più componenti dell'app rispetto alla stessa app in esecuzione in un singolo cloud. Oltre alla connettività tra i cloud, l'app viene eseguita su due piattaforme anziché una. Un'attività importante nella risoluzione dei problemi relativi alle app ibride consiste nell'esaminare l'integrità aggregata e il monitoraggio delle prestazioni dei componenti dell'app.
Sicurezza
La sicurezza è una delle considerazioni principali per qualsiasi app cloud e diventa ancora più critica per le app cloud ibride.
Per una discussione di base su questo pilastro, vedere Security nei cinque pilastri dell'eccellenza dell'architettura.
Elenco di controllo per la sicurezza
Presupporre una violazione. Se una parte dell'app viene compromessa, assicurarsi che siano presenti soluzioni per ridurre al minimo la diffusione della violazione, non solo all'interno della stessa posizione, ma anche in posizioni diverse.
Monitorare l'accesso alla rete consentito. Determinare i criteri di accesso alla rete per l'app, ad esempio l'accesso all'app solo da una subnet specifica e consentire solo le porte e i protocolli minimi tra i componenti necessari per il corretto funzionamento dell'app.
Usare un'autenticazione affidabile. Uno schema di autenticazione affidabile è fondamentale per la sicurezza dell'app. Prendere in considerazione l'uso di un provider di identità federato che fornisce funzionalità di Single Sign-On e usa uno o più degli schemi seguenti: accesso di nome utente e password, chiavi pubbliche e private, autenticazione a due fattori o a più fattori e gruppi di sicurezza attendibili. Determinare le risorse appropriate per archiviare dati sensibili e altri segreti per l'autenticazione dell'app, oltre ai tipi di certificato e ai relativi requisiti.
Usare la crittografia. Identificare le aree dell'app che usano la crittografia, ad esempio per l'archiviazione dei dati o la comunicazione client e l'accesso.
Usare canali sicuri. Un canale sicuro nei cloud è fondamentale per fornire controlli di sicurezza e autenticazione, protezione in tempo reale, quarantena e altri servizi nei cloud.
Definire e usare i ruoli. Implementare i ruoli per le configurazioni delle risorse e l'accesso a identità singola nei cloud. Determinare i requisiti di controllo degli accessi in base al ruolo per l'app e le relative risorse della piattaforma.
Controlla il sistema. Il monitoraggio del sistema può registrare e aggregare i dati dai componenti dell'app e dalle operazioni della piattaforma cloud correlate.
Sommario
Questo articolo fornisce un elenco di controllo degli elementi che sono importanti da considerare durante la creazione e la progettazione delle app ibride. La revisione di questi pilastri prima di distribuire l'app impedisce l'esecuzione di queste domande nelle interruzioni di produzione e potrebbe richiedere di rivedere la progettazione.
Può sembrare un'attività dispendiosa in termini di tempo, ma si ottiene facilmente il ritorno sugli investimenti se si progetta l'app in base a questi pilastri.
Passaggi successivi
Per altre informazioni, vedere le risorse seguenti: