In questo scenario un'azienda di e-commerce operante nel settore dei viaggi esegue la migrazione di un'applicazione Web legacy con Gestione API di Azure. La nuova interfaccia utente verrà ospitata come applicazione PaaS (Platform as a Service, piattaforma distribuita come servizio) in Azure e dipenderà dalle API HTTP sia nuove che esistenti. Queste API verranno rilasciate con un set di interfacce progettato in modo più efficiente, che garantisce prestazioni migliori, un'integrazione più semplice ed estendibilità futura.
Architettura
Scaricare un file Visio di questa architettura.
Workflow
- L'applicazione Web locale esistente continua a usare direttamente i servizi Web locali esistenti.
- Le chiamate dalle app Web esistenti ai servizi HTTP esistenti rimangono invariate. Queste chiamate sono interne alla rete aziendale.
- Le chiamate in ingresso vengono effettuate da Azure ai servizi interni esistenti:
- Il team responsabile della sicurezza consente al traffico proveniente da API Management di passare attraverso il firewall aziendale ai servizi locali usando il trasporto sicuro (HTTPS or SSL).
- Il team operativo consente le chiamate in ingresso ai servizi solo dall'istanza di API Management. Questo requisito viene soddisfatto aggiungendo l'indirizzo IP dell’istanza di API Management all'elenco di elementi consentiti all'interno del perimetro della rete aziendale.
- Un nuovo modulo viene configurato nella pipeline di richiesta locale per i servizi HTTP (per agire solo sulle connessioni che hanno origine esternamente). La pipeline convalida un certificato fornito da API Management.
- La nuova API:
- Viene esposta solo tramite l'istanza di API Management, che fornisce la facciata dell'API. Non è possibile accedere direttamente alla nuova API.
- Viene sviluppata e pubblicata come App per le API Web PaaS di Azure.
- Viene configurato (tramite le impostazioni per la funzionalità App Web del Servizio app di Azure) in modo da accettare solo l'indirizzo IP virtuale di API Management (VIP).
- Viene ospitata in App Web con il trasporto sicuro (HTTPS o SSL) attivato.
- Ha abilitato l'autorizzazione, fornita dal Servizio app di Azure tramite Microsoft Entra ID e Open Authorization (OAuth) 2.
- La nuova applicazione Web basata sul browser dipende dall'istanza di API Management di Azure per entrambe le API, quella HTTP esistente e quella nuova.
- L'azienda di e-commerce di viaggio può ora indirizzare alcuni utenti alla nuova interfaccia utente (per l'anteprima o il test) mantenendo l'interfaccia utente precedente e le funzionalità esistenti affiancate.
L'istanza di API Management viene configurata per eseguire il mapping dei servizi HTTP legacy a un nuovo contratto API. In questa configurazione, la nuova interfaccia utente Web non è a conoscenza dell'integrazione con un set di nuove API e di servizi/API legacy.
In futuro, il team del progetto convertirà gradualmente la funzionalità alle nuove API e ritirerà i servizi originali. Il team gestirà queste modifiche nella configurazione API Management, lasciando l'interfaccia utente front-end immutata ed evitando nuove attività di sviluppo.
Componenti
- API Management di Azure astrae le API back-end e aggiunge funzionalità di taglio incrociato e individuazione per sviluppatori e applicazioni. In questo scenario, la ricomposizione delle API back-end legacy esistenti e l'aggiunta di nuove funzionalità API è resa possibile usando Gestione API come facciata per la nuova applicazione client da utilizzare in modo coerente e usando standard moderni. Poiché API Management facciata sia le API esistenti che nuove, è possibile per gli sviluppatori modernizzare i back-end legacy dietro la facciata API Management in modo iterativo e con un impatto minimo su zero sullo sviluppo del nuovo front-end.
- Servizio app di Azure è un servizio PaaS (Platform as a Service) chiavi in mano per l'hosting Web che offre funzionalità predefinite, ad esempio sicurezza, bilanciamento del carico, scalabilità automatica e gestione automatica. Servizio app di Azure è un'ottima scelta per le nuove API sviluppate per questa soluzione perché offre un hosting turn-key flessibile, consentendo al team DevOps di concentrarsi sulla distribuzione delle funzionalità.
Alternative
Se l'organizzazione pianifica di spostare interamente la sua infrastruttura in Azure, incluse le macchine virtuali (VM) che ospitano le applicazioni legacy, API Management rimarrebbe l'opzione ideale perché può fungere da facciata per qualsiasi endpoint HTTP indirizzabile.
Se l'organizzazione decidesse di mantenere privati gli endpoint esistenti e di non esporli pubblicamente, l'istanza di API Management dell'organizzazione potrebbe essere collegata a una rete virtuale di Azure:
- Quando API Management è collegato a una rete virtuale di Azure, l'organizzazione potrebbe indirizzare direttamente il servizio back-end tramite indirizzi IP privati.
- Nello scenario locale l'istanza di API Management potrebbe raggiungere il servizio interno privatamente tramite un Gateway VPN di Azure e una connessione VPIN IPSec o Azure ExpressRoute. Questo scenario diventerà quindi un ibrido di Azure e locale.
L'organizzazione può mantenere privata l'istanza di API Management distribuendola in modalità interna. L'organizzazione può quindi usare la distribuzione con Gateway applicazione di Azure per abilitare l'accesso pubblico per alcune API mentre altre rimangono interne. Per maggiori informazioni, consultare la sezione Integrazione di API Management in una rete virtuale interna con il gateway applicazione.
L'organizzazione potrebbe decidere di ospitare le API in locale. Una delle cause di questa modifica potrebbe essere che l'organizzazione non è riuscita a spostare le dipendenze del database downstream nell'ambito di questo progetto nel cloud. In tal caso, l'organizzazione può comunque sfruttare API Management in locale usando un gateway self-hosted.
Il gateway self-hosted è una distribuzione in contenitori del gateway API Management che si connette ad Azure in un socket in uscita. Il primo prerequisito è che i gateway self-hosted non possono essere distribuiti senza una risorsa padre in Azure, che comporta costi aggiuntivi. In secondo luogo, è necessario il livello Premium di API Management.
Dettagli dello scenario
Una società di e-commerce del settore dei viaggi sta modernizzando lo stack software legacy basato su browser. Sebbene lo stack esistente sia per lo più monolitico, alcuni servizi HTTP basati su SOAP (Simple Object Access Protocol) esistono da un progetto recente. L'azienda sta prendendo in considerazione la creazione di flussi di ricavi aggiuntivi per monetizzare parte della proprietà intellettuale interna che ha sviluppato.
Gli obiettivi per il progetto includono la gestione del debito tecnico, il miglioramento della manutenzione periodica e l'accelerazione dello sviluppo di funzionalità con meno bug di regressione. Il progetto userà un processo iterativo per evitare rischi, con alcuni passaggi eseguiti in parallelo:
- Il team di sviluppo modernizzerà il back-end dell'applicazione, costituito da database relazionali ospitati in macchine virtuali.
- Il team di sviluppo interno scriverà nuove funzionalità di business che verranno esposte tramite nuove API HTTP.
- Un team di sviluppo di contratti compilerà una nuova interfaccia utente basata su browser, che sarà ospitata in Azure.
Le nuove funzionalità dell'applicazione verranno distribuite in più fasi. Queste funzionalità sostituiranno gradualmente le funzionalità esistenti dell'interfaccia utente di tipo client-server basata su browser (ospitata in locale) che è attualmente alla base dell'attività di e-commerce dell'azienda.
I membri del team di gestione non desiderano modernizzare inutilmente l'applicazione. Vuole anche mantenere il controllo dell'ambito e dei costi. A tale scopo, hanno deciso di mantenere i servizi SOAP HTTP esistenti. Intende anche ridurre al minimo le modifiche all'interfaccia utente esistente. Questo può far sì che API Management di Azure soddisfi molti dei requisiti e dei vincoli del progetto.
Potenziali casi d'uso
Questo scenario evidenzia la modernizzazione degli stack software basati su browser legacy.
È possibile usare questo scenario per:
- Informazioni su come l'azienda può trarre vantaggio dall'uso dell'ecosistema di Azure.
- Pianificare la migrazione dei servizi ad Azure.
- Informazioni su come un passaggio ad Azure influisce sulle API esistenti.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che aiuta a migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.
- Valutare la possibilità di distribuire l'istanza di API Management di Azure con le zone di disponibilità abilitate. L'opzione per distribuire API Management nelle zone di disponibilità è disponibile solo nel livello di servizio Premium.
- Le zone di disponibilità possono essere usate insieme a istanze del gateway aggiuntive distribuite in aree diverse. Ciò migliora la disponibilità del servizio se un'area passa offline. La distribuzione in più aree è inoltre disponibile solo nel livello di servizio Premium.
- Considerare l'integrazione con Azure Application Insights, che espone le metriche tramite Monitoraggio di Azure per il monitoraggio. Ad esempio, la metrica della capacità può essere usata per determinare il carico complessivo sulla risorsa API Management e se sono necessarie unità di scalabilità orizzontale aggiuntive. Il rilevamento della capacità e dell'integrità delle risorse migliora l'affidabilità.
- Assicurarsi che le dipendenze downstream, ad esempio i servizi back-end che ospitano le API di API Management, siano resilienti.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.
API Management è disponibile in quattro livelli: Developer, Basic, Standard e Premium. È possibile trovare indicazioni dettagliate sulle differenze tra questi livelli nella guida ai prezzi di API Management di Azure.
È possibile sfruttare la scalabilità di API Management aggiungendo o rimuovendo unità. La capacità di ogni unità dipende dal livello.
Nota
È possibile usare il livello Developer per la valutazione delle funzionalità di API Management. Non usarlo per la produzione.
Per visualizzare i costi previsti ed eseguire la personalizzazione in base alle specifiche esigenze di distribuzione, è possibile modificare il numero di unità di scala e di istanze del Servizio app nel calcolatore dei prezzi di Azure.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Ben Gimblett | Senior Customer Engineer
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
Documentazione sui prodotti:
Moduli di apprendimento:
- Esplorare Servizio app di Azure
- Distribuire un sito Web in Azure con il servizio app di Azure
- Proteggere le API in Gestione API di Azure