Floating point

Migrazione da TIBCO Mashery ad Azure API Management

Denis Dal Molin
27 Mar, 2025
07 Mins read

Avviso: Molti dei nostri clienti hanno stipulato accordi di riservatezza che tutelano i loro marchi da scopi commerciali. Pertanto potresti incontrare diciture come “Nome Cliente Riservato” oppure vedrai riportato il settore del cliente invece del suo nome.

Introduzione

Una gestione efficace delle API è cruciale per le aziende che vogliono rimanere competitive.

[Nome Cliente Riservato], leader mondiale nella produzione di tessuti d'alta gamma per l'abbigliamento di lusso, ha deciso di migrare la propria infrastruttura API per migliorare sicurezza ed efficienza operativa. Questa decisione è stata inoltre spinta dall'acquisizione di TIBCO Mashery da parte di Boomi, che ha comportato un sensibile incremento dei costi del servizio.

In collaborazione con [Nome Cliente Riservato], abbiamo realizzato la migrazione del servizio di gestione delle API di TIBCO Mashery ad Azure API Management.

Azure API Management

Azure API Management è una piattaforma PaaS end-to-end completamente integrata che consente di creare, pubblicare, proteggere e analizzare le API.

1.00

Agendo come un portale, consente di controllare l'accesso e proteggere le API da potenziali minacce. Con questo strumento, gli sviluppatori possono ottimizzare il ciclo di vita delle API, dalla progettazione alla distribuzione, fino al monitoraggio e alla scalabilità.

Caratteristiche di Azure API Management

Creazione e progettazione di API: creare e progettare con un'interfaccia facile da usare, ciò include la definizione di endpoint, la specificazione di formati di dati e la configurazione di metodi di autenticazione;
Sicurezza e Controllo di Accesso: meccanismi di autenticazione come chiavi, OAuth e certificati client. Inoltre, è possibile applicare controlli degli accessi per limitare o consentire l'accesso in base a criteri specifici;
Monitoraggio e Analisi: strumenti di monitoraggio e analisi che consentono di monitorare l'utilizzo, le prestazioni e gli errori. Queste informazioni permettono di perfezionare le API, individuare potenziali problemi e garantire un'esperienza fluida;
Limiti di velocità e quote: applicare limiti di velocità e quote per impedire l'abuso o l'uso eccessivo delle API. Ciò garantisce un utilizzo ragionevole e contribuisce a mantenere la stabilità del sistema;
Collaborazione: la piattaforma favorisce la collaborazione tra team offrendo portali per gli sviluppatori. Questi fungono da hub centrale dove gli sviluppatori possono scoprire, esplorare e comprendere le API disponibili. La documentazione, gli esempi di codice e le funzioni di test sono spesso inclusi per semplificare il processo di sviluppo;
Gestione del ciclo di vita e versioning: le API si evolvono nel tempo, il servizio incorpora il controllo delle versioni per gestire le modifiche in modo efficiente. Ciò garantisce che le applicazioni utilizzate che si basano su versioni specifiche delle API continuino a funzionare anche quando vengono introdotti nuovi aggiornamenti;
Scalabilità e alta disponibilità: il servizio è in grado di scalare rapidamente per gestire l'aumento della domanda. Fornisce inoltre funzioni per l'alta disponibilità, assicurando che le API siano sempre accessibili;
Integrazione con i servizi Azure: si integra con altri servizi, consentendo di sfruttare un ecosistema più ampio di strumenti, ciò include Azure Logic Apps, Azure Functions e Entra ID.

Ciclo di vita della gestione delle API

La gestione delle API inizia con la pianificazione, fase strategica grazie alla quale le API e i microservizi vengono progettati, stabilendone la struttura e le funzionalità da erogare.

Prima di essere pubblicate, le API vengono sottoposte a rigorosi test durante la fase di test e pubblicazione, assicurandone la qualità e la compatibilità.

1.00

Una volta operativa, un'API deve essere protetta da qualunque vulnerabilità durante la fase di sicurezza, garantendo che le minacce non compromettano l'integrità dei dati o il funzionamento dei servizi.

Per assicurare un utilizzo efficace, il ciclo di vita prevede strumenti per il monitoraggio, attraverso i quali è possibile ottimizzare le prestazioni tramite analisi.

1.00

Infine, la fase di consumo (Consume) consente il pieno sfruttamento delle API, garantendo un uso sicuro e scalabile nelle applicazioni, incluse quelle per dispositivi mobili e IoT.

Sfide Affrontate

Durante il processo di migrazione delle API, abbiamo affrontato diverse sfide legate alla complessità dell'infrastruttura esistente e alla necessità di garantire una transizione fluida.

[Nome Cliente Riservato], infatti, utilizzava da anni TIBCO Mashery, distribuito come pod all'interno di Azure Kubernetes Service (AKS).

Analisi dell'as-is

Sono state eseguite un’analisi attenta delle API e dell’infrastruttura attuale del cliente. Si è reso necessario esaminare sia la configurazione di TIBCO Mashery, che l'infrastruttura rappresentata dai servizi backend ospitati su AKS.

Le valutazioni legate alla rete e quelle in merito al servizio DNS si sono rivelate fondamentali al fine di garantire che i flussi di connessione tra i consumatori e i servizi backend rimanessero invariati dopo la migrazione.

Ambienti Dev, Test e Produzione

Per gestire in modo graduale e sicuro la migrazione, sono stati creati tre diversi ambienti: sviluppo, test e produzione.

1.00

Questo approccio, oltre a consentire una validazione progressiva, ha reso possibile implementare e affinare i dettagli di configurazione senza interruzioni.

Adeguamento delle configurazioni

Un altro aspetto critico affrontato durante la migrazione è stato il necessario adeguamento delle configurazioni: alcune impostazioni precedenti in TIBCO Mashery (come ad esempio quelle relative al CORS) violavano le best practices e gli standard più recenti.

Questo lavoro ha comportato un riposizionamento tecnico adattando le configurazioni in modo che potessero funzionare su Azure API Management e risultassero conformi alle linee guida moderne.

Limitazioni nella portabilità delle API

Un'importante difficoltà riscontrata era legata alle limitazioni nell'esportazione delle configurazioni API in TIBCO Mashery.

Non disponendo della suite TIBCO Cloud Integration, circa 50 API non potevano essere esportate in specifiche OpenAPI così da poterle importare nel servizio Azure.

1.00

Erano inoltre presenti servizi SOAP, caratterizzati da una maggiore complessità rispetto agli standard REST, dovuta alla loro struttura rigida basata su XML e WSDL.

1.00

Questo ha reso necessaria una iniziale ricostruzione manuale delle definizioni API in Azure API Management.

Successivamente è stata sviluppata una soluzione automatizzata utilizzando PowerShell scripting.

Le definizioni delle API di Mashery sono state trasferite ed elencate in un foglio Excel, che includeva tutti gli elementi necessari (url endpoint, policy, impostazioni di sicurezza, ecc.). Lo script, in base al contenuto di questo file, ha eseguito automaticamente la creazione massiva delle API in Azure API Management.

Una volta configurate le API, il loro funzionamento è stato testato utilizzando Postman per verificare la piena funzionalità del sistema.

1.00

Allineamento degli ambienti

Grazie allo script PowerShell, l'intera configurazione delle API è stata replicata tra i vari ambienti (dev, test, produzione).

In questo modo non solo siamo riusciti a risparmiare tempo, ma abbiamo garantito anche consistenza e coerenza tra le configurazioni.

Lo script è stato poi consegnato al cliente così da poterlo utilizzare a lungo termine, nel caso si presentino situazioni simili o si verifichino modifiche/rilasci di nuovi aggiornamenti alle configurazioni.

Strategia di Migrazione

Abbiamo definito una strategia di migrazione con due opzioni principali, cercando di individuare quale fosse la più appropriata in base alle esigenze, alla complessità del progetto e alla necessità di garantire un uptime significativamente elevato.

L’approccio di migrazione graduale si è rilevato particolarmente vantaggioso grazie alla sua flessibilità, consentendo un controllo più dettagliato e preciso sull'intero processo.

Opzione 1: Staged

L'approccio incrementale prevedeva la creazione di un nuovo servizio di Ingress NGINX in AKS.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: azure-ingress
  namespace: ns-tibco-dev
  annotations:
   kubernetes.io/ingress.class: "nginx"
   nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
   nginx.ingress.kubernetes.io/proxy-body-size: "50m"
   nginx.ingress.kubernetes.io/ssl-redirect: "false"
   nginx.ingress.kubernetes.io/use-regex: "true"
   nginx.ingress.kubernetes.io/upstream-vhost: "ez-apim-noprod.azure-api.net"
spec:
  tls:
   - hosts:
       - tibco-dev.cliente.com
     secretName: cert-cliente
  rules:
   - host: tibco-dev.cliente.com
     http:
       paths:
         - path: /api/v1.0
           pathType: ImplementationSpecific
           backend:
             service:
               name: azure-apim
               port:
                 number: 443

Questo servizio avrebbe agito come intermediario, configurato per instradare le richieste in base a regole specifiche definite sui percorsi (path).

In questo modo, sarebbe stato possibile:

Inoltrare selettivamente le richieste API verso Azure API Management o TIBCO Mashery;
Migrare le API una alla volta, verificandone il funzionamento in tempo reale;
Agevolare un rollback immediato e puntuale in caso di problemi con una singola API, senza coinvolgere l’intero sistema.

Questo approccio ha permesso una transizione graduale, eliminando la necessità di un cut-off totale e riducendo al minimo i rischi di interruzioni dei servizi.

Una volta completata la migrazione di tutte le API e confermata la stabilità del nuovo sistema, gli ingress sarebbero stati eliminati e i record DNS aggiornati per puntare stabilmente al servizio APIM.

Opzione 2: Cutover

L'altra strategia prevedeva l’accorciamento del time to live (TTL) del record DNS, così da minimizzare l’impatto della propagazione delle modifiche.

1.00

Durante una finestra programmata, il puntamento DNS sarebbe stato aggiornato per dirigere le richieste direttamente verso Azure API Management, bypassando l’infrastruttura esistente basata su TIBCO Mashery.

Successivamente, sarebbe stato avviato un ciclo di test per verificare che tutto funzionasse correttamente. In caso di anomalie o problemi bloccanti, era possibile effettuare un rollback ripristinando il precedente puntamento DNS.

Soluzione tecnologica

Per impostazione predefinita, l'istanza di Azure API Management è accessibile da Internet attraverso un endpoint pubblico e funge da gateway per i backend pubblici.

Il servizio però offre diverse possibilità, la tabella seguente confronta le opzioni di rete virtuale:

Modello di rete	Traffico supportato	Scenario di utilizzo
Virtual Network Injection	Il traffico in ingresso e in uscita può essere consentito a una subnet delegata di una rete virtuale, reti virtuali con peering, connessioni ExpressRoute e VPN S2S	Accesso interno a back-end privati e locali
Virtual Network Integration	Il traffico delle richieste in uscita può raggiungere le API ospitate in una subnet delegata di una singola rete virtuale connessa	Accesso esterno a back-end privati e locali
Inbound Private Endpoint	Solo il traffico in ingresso può essere consentito da Internet, reti virtuali con peering, connessioni ExpressRoute e VPN S2S	Proteggere la connessione client al gateway API

L'integrazione in uscita consente all'istanza APIM di raggiungere i servizi back-end pubblici e isolati dalla rete.

1.00

L'endpoint privato consente di raggiungere l'istanza APIM tramite una connessione privata.

1.00

E' possibile esporre alcune API tramite endpoint privati e altre pubblicamente all'interno di una singola istanza di APIM utilizzando le policy.

Dopo una dettagliata analisi delle esigenze del cliente abbiamo proposto e implementato una soluzione che integra APIM all'interno di una virtual network (integration) per dirigere il traffico verso gli endpoint backend, utilizzando inoltre un private endpoint per gestire in modo sicuro il traffico interno, mantenendo comunque l'accesso pubblico per il traffico esterno.

1.00

Valore Aggiunto

La migrazione ha portato numerosi vantaggi per il cliente, consolidando l’infrastruttura IT e migliorandone l’efficienza globale.

Riduzione significativa dei costi: uno dei principali vantaggi della migrazione è stata la drastica riduzione dei costi operativi. Azure API Management, infatti, offriva tariffe notevolmente inferiori rispetto a TIBCO Mashery e al suo modello di licensing. Questo risparmio è stato amplificato dal fatto che Azure API Management è un servizio PaaS (Platform as a Service), che elimina la necessità di gestire direttamente l'infrastruttura, inclusi gli aggiornamenti e i mantenimenti dei container TIBCO all'interno di AKS;
Automazione ed efficienza: sono state automatizzate attività ripetitive e complesse, come la creazione/modifica massiva di API, l’allineamento delle configurazioni tra gli ambienti e la gestione dei futuri cambiamenti;
Maggiore scalabilità: l’infrastruttura API è ora altamente scalabile, consentendo di supportare un numero sempre crescente di richieste da parte dei consumer, sia interni che esterni;
Potenziale innovativo: la piattaforma Azure fornisce strumenti e servizi avanzati per lo sviluppo e l'integrazione continua, favorendo l'innovazione. Si ha ora accesso a un ecosistema di strumenti come l’analisi avanzata con Application Insights, l’uso di Azure Functions per logiche serverless e l’eventuale implementazione di API basate su dati IoT o AI.

La nuova configurazione rappresenta una piattaforma moderna e flessibile che consente al cliente di consolidare la propria posizione di leader nel mercato.