Eseguire l'offload delle funzionalità dei servizi condivise o specializzate in un proxy gateway. Questo modello consente di semplificare lo sviluppo di applicazioni grazie allo spostamento di funzionalità di servizi condivisi, quali l'uso di certificati SSL, da altre parti dell'applicazione nel gateway.
Contesto e problema
Alcune funzionalità usate comunemente in più servizi richiedono l'esecuzione di attività di configurazione, gestione e manutenzione. Un servizio condiviso o specializzato che viene distribuito con ogni distribuzione dell'applicazione implica un incremento del carico amministrativo, nonché delle probabilità di errori di distribuzione. Tutti gli aggiornamenti di una funzionalità condivisa devono essere distribuiti in tutti i servizi che condividono tale funzionalità.
Per gestire correttamente problemi di sicurezza (convalida dei token, crittografia, gestione dei certificati SSL) e altre attività complesse, i membri del team devono essere altamente specializzati. Ad esempio, un certificato richiesto da un'applicazione deve essere configurato e distribuito in tutte le istanze dell'applicazione. Con ogni nuova distribuzione il certificato deve essere gestito per assicurarsi che non scada. In prossimità della scadenza, tutti i certificati comuni devono essere aggiornati, testati e verificati in ogni distribuzione dell'applicazione.
L'implementazione e la gestione di altri servizi comuni, tra cui l'autenticazione, l'autorizzazione, la registrazione, il monitoraggio e la limitazione delle richieste, possono risultare complicate in un numero elevato di distribuzioni. Può quindi essere opportuno consolidare questo tipo di funzionalità per ridurre il sovraccarico e la probabilità di errori.
Soluzione
Eseguire l'offload di alcune funzionalità in un gateway, in particolare problematiche trasversali, ad esempio gestione dei certificati, autenticazione, terminazione SSL, monitoraggio, conversione del protocollo o limitazione.
Il diagramma seguente illustra un gateway che termina le connessioni SSL in ingresso. Richiede dati per conto del richiedente originale da qualsiasi server HTTP upstream del gateway.
I vantaggi di questo schema includono:
Semplificazione dello sviluppo di servizi, perché non è più necessario distribuire e gestire risorse di supporto, ad esempio i certificati server Web e la configurazione dei siti Web sicuri. La semplificazione della configurazione facilita la gestione e la scalabilità, semplificando a sua volta gli aggiornamenti del servizio.
Possibilità per i team dedicati di implementare funzionalità che richiedono competenze specifiche, come la sicurezza. In questo modo il core team può concentrarsi sulle funzionalità dell'applicazione, lasciando queste problematiche trasversali agli esperti del settore.
Implementazione di un certo livello di coerenza per la registrazione e il monitoraggio di richieste e risposte. Anche se un servizio non è instrumentato correttamente, è possibile configurare il gateway in modo da garantire un livello minimo di monitoraggio e registrazione.
Considerazioni e problemi
- Assicurarsi che il gateway sia a disponibilità elevata e resiliente agli errori. Evitare singoli punti di errore eseguendo più istanze del gateway.
- Assicurarsi che il gateway che sia progettato per soddisfare i requisiti di capacità e scalabilità dell'applicazione e degli endpoint. Assicurarsi che il gateway non diventi un collo di bottiglia per l'applicazione e che sia sufficientemente scalabile.
- Eseguire l'offload solo delle funzionalità usate in tutta l'applicazione, ad esempio il trasferimento di dati o la sicurezza.
- La logica di business non deve mai essere scaricata nel gateway.
- Se è necessario tenere traccia delle transazioni, provare a generare ID di correlazione ai fini della registrazione.
Quando usare questo modello
Usare questo modello quando:
- La distribuzione di un'applicazione implica problematiche condivise, come i certificati SSL o la crittografia.
- Una funzionalità è in comune tra più distribuzioni di applicazioni che potrebbero avere requisiti diversi in termini di risorse, ad esempio risorse di memoria, capacità di archiviazione o connessioni di rete.
- Si vuole demandare a un team specializzato la responsabilità di problemi quali la sicurezza di rete, la limitazione delle risorse o altre problematiche relative ai limiti di rete.
Questo modello potrebbe non essere adatto se introduce l'accoppiamento tra i servizi.
Progettazione del carico di lavoro
Un architetto deve valutare il modo in cui il modello di offload del gateway può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:
| Concetto fondamentale | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| Le decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resilienti a malfunzionamenti e di assicurarsi che venga ripristinato in uno stato completamente funzionante dopo che si verifica un errore. | L'offload di questa responsabilità in un gateway riduce la complessità del codice dell'applicazione nei nodi back-end. In alcuni casi, l'offload sostituisce completamente la funzionalità con una funzionalità affidabile fornita dalla piattaforma. - RE:01 Semplicità ed efficienza |
| Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro. | L'aggiunta di un gateway nel flusso di richiesta consente di centralizzare le funzionalità di sicurezza, ad esempio web application firewall e connessioni TLS con i client. Qualsiasi funzionalità offloaded fornita dalla piattaforma offre già una maggiore sicurezza. - Controlli di rete SE:06 - Risorse di protezione avanzata SE:08 |
| L'ottimizzazione dei costi è incentrata sul mantenimento e sul miglioramento del ritorno del carico di lavoro sugli investimenti. | Questo modello consente di reindirizzare i costi dalle risorse che verrebbero spesi per nodo nell'implementazione del gateway. I costi nel modello di elaborazione centralizzato sono spesso inferiori a quelli del modello distribuito. - CONSOLIDAMENTO CO:14 |
| L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team. | In questo modello, la configurazione e il backup della funzionalità offloaded provengono da un singolo punto anziché gestirla da più nodi. - Strumenti e processi di OE:04 |
| L'efficienza delle prestazioni consente al carico di lavoro di soddisfare in modo efficiente le richieste tramite ottimizzazioni in termini di scalabilità, dati, codice. | L'aggiunta di un gateway di offload al processo di richiesta consente di usare meno risorse per nodo perché la funzionalità è centralizzata nel gateway. È possibile ottimizzare l'implementazione della funzionalità offloaded indipendentemente dal codice dell'applicazione. È già probabile che la funzionalità fornita dalla piattaforma offloaded sia altamente efficiente. - PE:03 Selezione dei servizi |
Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.
Esempio
Usando Nginx come appliance di offload SSL, la configurazione seguente consente di terminare una connessione SSL in ingresso e di distribuire la connessione a uno dei tre server HTTP a monte.
upstream iis {
server 10.3.0.10 max_fails=3 fail_timeout=15s;
server 10.3.0.20 max_fails=3 fail_timeout=15s;
server 10.3.0.30 max_fails=3 fail_timeout=15s;
}
server {
listen 443;
ssl on;
ssl_certificate /etc/nginx/ssl/domain.cer;
ssl_certificate_key /etc/nginx/ssl/domain.key;
location / {
set $targ iis;
proxy_pass http://$targ;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
}
}
In Azure questo risultato si può ottenere impostando la terminazione SSL nel gateway applicazione.