Mainframe e modernizzazione midrange con App per la logica di Azure
Questa guida descrive come l'organizzazione può aumentare il valore aziendale e l'agilità modernizzando gli ambienti mainframe e midrange usando App per la logica di Azure. L'attuale mondo aziendale sta vivendo un'epoca di iper-innovazione ed è in cerca permanente di ottenere efficienza aziendale, riduzione dei costi, crescita e allineamento aziendale. Le organizzazioni cercano modi per modernizzare e una strategia efficace consiste nell'aumentare il valore aziendale usando gli asset legacy esistenti.
Per le organizzazioni con investimenti in sistemi mainframe e midrange, ciò significa usare al meglio le piattaforme che hanno contribuito a inviare gli esseri umani alla luna o hanno contribuito a costruire i mercati finanziari correnti e a estendere il loro valore usando il cloud e l'intelligenza artificiale (IA). Questo scenario è il punto in cui App per la logica di Azure e le sue funzionalità native per l'integrazione con i sistemi mainframe e midrange entrano in gioco, aprendo la porta al mondo dell'IA per gli investimenti legacy. Tra le altre funzionalità, App per la logica di Azure incorpora le funzionalità principali di Host Integration Server (HIS), che è stato usato per l'integrazione mainframe e midrange al centro dei clienti più strategici di Microsoft oltre 20 anni. Di conseguenza, App per la logica di Azure è diventata una piattaforma di integrazione distribuita come servizio (iPaaS) per i sistemi mainframe e midrange.
Quando gli sviluppatori aziendali creano flussi di lavoro di integrazione con App per la logica di Azure, possono distribuire più rapidamente nuove applicazioni usando poco o meno codice personalizzato. Gli sviluppatori che usano Visual Studio Code e Visual Studio possono essere più produttivi di quelli che usano strumenti e tecnologie di sviluppo mainframe IBM perché non richiedono conoscenze sui sistemi e sull'infrastruttura mainframe. App per la logica di Azure consente agli analisti aziendali e ai decision maker di analizzare e segnalare più rapidamente informazioni legacy vitali. Possono accedere direttamente ai dati nelle origini dati mainframe, eliminando così la necessità di creare programmi che estraggono e convertono strutture mainframe complesse.
Funzionalità native del cloud per l'integrazione del sistema mainframe e midrange
Dal 1990, Microsoft ha fornito l'integrazione con i sistemi mainframe e midrange tramite Microsoft Communications Server. Un'ulteriore evoluzione di Microsoft Communications Server ha creato Host Integration Server (HIS) nel 2000. Mentre HIS è iniziato come SNA (System Network Architecture), HIS è stato ampliato per includere gli archivi dati IBM (DB2, VSAM e Informix), i sistemi di transazione IBM (CICS, IMS e IBM i) e IBM messaging (MQ Series). I clienti strategici di Microsoft hanno usato queste tecnologie per più di 20 anni.
Per consentire ai clienti che eseguono applicazioni e dati in Azure di continuare a usare queste tecnologie, App per la logica di Azure e Visual Studio hanno gradualmente incorporato queste funzionalità. Ad esempio, la finestra di progettazione HIS per app per la logica eseguita in Visual Studio e lo strumento di progettazione 3270 consentono di creare artefatti di metadati richiesti dai connettori predefiniti usati per l'integrazione mainframe e midrange in App per la logica di Azure. Questi connettori predefiniti vengono eseguiti usando le stesse risorse di calcolo dei flussi di lavoro delle app per la logica Standard. Questa progettazione non solo consente di ottenere scenari a bassa latenza, ma estende anche la copertura per soddisfare maggiori esigenze di ripristino di emergenza e disponibilità elevata dei clienti.
Per altre informazioni sulle funzionalità di Microsoft per l'integrazione mainframe e midrange, continuare con le sezioni seguenti.
Microsoft HIS Designer per app per la logica
Questo strumento crea artefatti di metadati di sistema mainframe e midrange per App per la logica di Azure e funziona con Microsoft Visual Studio fornendo una finestra di progettazione grafica in modo da poter creare, visualizzare, modificare e mappare gli oggetti metadati agli artefatti mainframe. App per la logica di Azure usa queste mappe per eseguire il mirroring dei programmi e dei dati nei sistemi mainframe e midrange. Per altre informazioni, vedere La finestra di progettazione his per app per la logica.
Strumento di progettazione di Microsoft 3270
Questo strumento registra schermate, percorsi di spostamento, metodi e parametri per le attività nell'applicazione in modo da poter aggiungere ed eseguire tali attività come azioni del connettore 3270. Mentre la finestra di progettazione HIS per App per la logica è destinata a sistemi e dati transazionali, lo strumento di progettazione 3270 è destinato a 3270 applicazioni. Per altre informazioni, vedere Strumento di progettazione 3270.
connettori App per la logica di Azure per i sistemi ibm mainframe e midrange
Le sezioni seguenti descrivono i connettori predefiniti basati su provider di servizi che è possibile usare per accedere e interagire con i sistemi IBM mainframe e midrange quando si creano flussi di lavoro Standard in App per la logica di Azure.
Nota
Anche se alcuni dei connettori seguenti sono disponibili come connettori "condivisi" eseguiti in Azure globale, questa guida è incentrata sui connettori predefiniti basati su provider di servizi, disponibili solo quando si creano flussi di lavoro Standard in App per la logica di Azure.
IBM 3270
Questo connettore App per la logica di Azure per 3270 consente ai flussi di lavoro Standard di accedere ed eseguire applicazioni mainframe IBM che in genere si guidano passando attraverso le schermate dell'emulatore 3270. Il connettore usa il flusso TN3270. Per altre informazioni, vedere Integrare 3270 app basate sullo schermo in mainframe IBM con Azure usando App per la logica di Azure e il connettore IBM 3270.
IBM Customer Information Control System (CICS)
Questo connettore App per la logica di Azure per CICS fornisce flussi di lavoro Standard con la possibilità di interagire e integrarsi con programmi CICS usando più protocolli, ad esempio TCP/IP e HTTP. Se è necessario accedere agli ambienti CICS usando LU6.2, è necessario usare Host Integration Server (HIS). Per altre informazioni, vedere Integrare programmi CICS in mainframe IBM con flussi di lavoro Standard in App per la logica di Azure usando il connettore IBM CICS.
IBM DB2
Questo connettore App per la logica di Azure per DB2 consente le connessioni tra flussi di lavoro Standard e database DB2 locali o in Azure. Il connettore offre ai professionisti IT aziendali e agli sviluppatori l'accesso diretto alle informazioni vitali archiviate nei sistemi di gestione di database DB2. Per altre informazioni, vedere Accedere e gestire le risorse IBM DB2 usando App per la logica di Azure.
File host IBM
Questo App per la logica di Azure "connettore" per i file host fornisce un wrapper sottile intorno alla funzionalità "Parser file flat" in Host Integration Server. Questo "connettore" offline fornisce operazioni che analizzano o generano dati binari da e verso i file host. Queste operazioni richiedono che questi dati provengano da qualsiasi trigger o da un'altra azione che produce dati binari. Per altre informazioni, vedere Analizzare e generare file host IBM usando App per la logica di Azure.
IBM i
Questo connettore App per la logica di Azure per IBM i consente ai flussi di lavoro Standard di interagire e integrarsi con i programmi COBOL e RPG in esecuzione nei sistemi IBM i usando TCP/IP. Se è necessario accedere agli ambienti IBM i usando LU6.2, è necessario usare Host Integration Server (HIS). Per altre informazioni, vedere Integrare programmi COBOL e RPG su midrange IBM con flussi di lavoro Standard in App per la logica di Azure usando il connettore IBM i.
IBM Information Management System (IMS)
Questo connettore App per la logica di Azure per IMS usa il componente IBM IMS Connessione, che consente l'accesso ad alte prestazioni dai flussi di lavoro Standard alle transazioni IMS tramite TCP/IP. Questo modello usa la coda dei messaggi IMS per l'elaborazione dei dati. Per altre informazioni, vedere Integrare programmi IMS in mainframe IBM con flussi di lavoro Standard in App per la logica di Azure usando il connettore IBM IMS.
IBM MQ
Questo connettore App per la logica di Azure per MQ consente le connessioni tra flussi di lavoro Standard e server IBM MQ in locale o in Azure. Microsoft offre anche funzionalità di integrazione IBM MQ con Host Integration Server e BizTalk Server. Per altre informazioni, vedere Connessione a un server IBM MQ da un flusso di lavoro in App per la logica di Azure.
Sfide per la modernizzazione dei sistemi mainframe e midrange
I sistemi mainframe e midrange possono ospitare più ambienti che contengono programmi, dati, file e strumenti. Nel corso degli anni, questi ambienti potrebbero non essere stati sottoposti a refactoring o sono stati lasciati crescere e raggiungere i loro limiti, nonostante gli aggiornamenti hardware. Questi ambienti potrebbero anche essere stati gestiti da più sviluppatori e amministratori IT, che seguono diversi modelli e tecniche di programmazione o reclutati altre parti per aiutare con attività che richiedono competenze scarse nel mercato. Insieme a un pool di professionisti esperti, tutti questi fattori creano un lavoro complesso e impegnativo per modernizzare l'ambiente mainframe e midrange.
Anche se l'elenco seguente non è completo, la definizione di una strategia di modernizzazione riuscita include in modo minimo i modi per gestire le attività seguenti:
- Mantenere gli indicatori e gli obiettivi correnti a livello di servizio per gli ambienti.
- Gestire la coesistenza tra i dati legacy e i dati migrati.
- Eseguire DevOps in ambienti durante la coesistenza.
- Gestire le interdipendenze dell'applicazione.
- Definire il futuro dell'utilità di pianificazione e dei processi mainframe.
- Definire una strategia per sostituire i prodotti commerciali off-the-shelf (HANDLE).
- Eseguire attività di test funzionali e non funzionali ibride.
- Gestire le dipendenze o le interfacce esterne.
Tenendo presente queste attività, i clienti scelgono in genere uno dei percorsi seguenti per condurre la modernizzazione dei sistemi mainframe e midrange:
Big bang
Questo approccio si basa in gran parte sul modello di distribuzione software a cascata, ma con iterazioni in fasi. L'approccio big bang viene adottato più da clienti con piccoli sistemi mainframe o midrange e ambienti a bassa complessità a causa di un numero ridotto di righe di codice, densità di applicazioni ridotte e sistemi legacy noti o linguaggi di programmazione.
Onde agile
Questo approccio segue i principi Agile dell'ingegneria del software. L'approccio Agile waves viene adottato più da clienti con sistemi mainframe o midrange più grandi e ambienti ad alta complessità a causa di un numero elevato di righe di codice, densità elevata delle applicazioni, sistemi meno noti o linguaggi di programmazione e un numero elevato di dipendenze e interfacce.
La scelta tra questi percorsi dipende dalle esigenze e dagli scenari dell'organizzazione. Ogni percorso presenta vantaggi e svantaggi da considerare. Le sezioni seguenti forniscono altre informazioni su questi approcci di modernizzazione.
Big bang o cascata
Una migrazione big bang presenta in genere le fasi seguenti:
Ideazione: Kickoff
Pianificazione: identificare e preparare i risultati finali della pianificazione, ad esempio ambito, tempo e risorse.
Edificio: inizia dopo l'approvazione dei risultati della pianificazione
Questa fase prevede anche che tutto il lavoro per le dipendenze sia stato identificato e che le attività di migrazione possano iniziare. Per completare il lavoro di migrazione si verificano più iterazioni.
Stabilizzazione o test: inizia quando l'ambiente, le dipendenze e le applicazioni di cui è stata eseguita la migrazione vengono testate rispetto alle aree di test nell'ambiente mainframe.
Distribuisci: dopo l'approvazione di tutti gli elementi, la migrazione passa all'ambiente di produzione.
Le organizzazioni che in genere scelgono questo approccio riguardano il tempo di blocco, l'ambito di migrazione e le risorse. Questo percorso sembra una scelta positiva, ma include i rischi seguenti:
Le migrazioni possono richiedere mesi o persino anni.
Le distribuzioni nell'ambiente di produzione sono più rischiose.
L'analisi eseguita all'inizio del percorso di migrazione o durante la pianificazione non è più accurata perché tali informazioni sono in genere obsolete.
Le organizzazioni in genere si concentrano sulla disponibilità di documentazione completa per ridurre i rischi di consegna per il recapito.
Tuttavia, il tempo impiegato per fornire artefatti di pianificazione causa esattamente l'effetto opposto. Concentrarsi sulla pianificazione più che sull'esecuzione tende a creare ritardi di esecuzione, causando un aumento dei costi a lungo termine.
Onde agile
Un approccio Agile è orientato ai risultati e incentrato sulla creazione di software e non sulla pianificazione dei risultati finali. Le prime fasi di un recapito Agile potrebbero essere caotiche e complesse per le barriere organizzative che devono abbattere e allineare il team di migrazione. Tuttavia, dopo la maturità del team di migrazione dopo diversi sprint di esecuzione, il percorso diventa più fluido. L'obiettivo di questo approccio è quello di rilasciare spesso le funzionalità per la produzione e di fornire valore aziendale prima che con un approccio big bang.
Una migrazione a onde Agile prevede in genere gli sprint seguenti:
Sprint zero (0)
- Definire il team, un backlog di lavoro iniziale e le dipendenze principali.
- Identificare le funzionalità e un MVP (Minimum Viable Product) da distribuire.
- Avviare la preparazione del mainframe con un set selezionato di elementi di lavoro o storie utente per iniziare il lavoro.
Sprint 1, 2, ..., N
Ogni sprint ha un obiettivo in cui il team mantiene una mentalità di spedizione, ovvero si concentra sul completamento degli obiettivi di migrazione e sul rilascio dei risultati finali alla produzione. Il team può usare un gruppo di sprint per fornire una funzionalità specifica o un'ondata di funzionalità. Ogni funzionalità include sezioni dei carichi di lavoro di integrazione.
Gli elementi condivisi, ad esempio processi e interdipendenze, esistono e hanno un impatto sull'intero ambiente. Una strategia di successo è incentrata sull'abilitazione parziale dei processi, sulla riprogettazione delle applicazioni per la modernizzazione e sull'abbandono dei sistemi con la maggior parte delle interdipendenze fino alla fine per ridurre prima la quantità di lavoro di migrazione e quindi completare l'ambito dello sforzo di modernizzazione.
Microsoft consiglia di modernizzare i carichi di lavoro del sistema mainframe e midrange seguendo un modello iterativo basato su onde Agile concentrandosi sugli investimenti nella nuova piattaforma, limitando al contempo la crescita dei sistemi legacy. Questo approccio riduce notevolmente i rischi di implementazione preservando il valore aziendale esistente, introducendo l'ambiente modernizzato. In questo modo, il team può anche sfruttare le competenze tecnologico che consentono all'azienda di essere più competitivi. Questo scenario è la posizione in cui App per la logica di Azure può essere utile nel percorso di modernizzazione.
Modelli di modernizzazione
Una buona progettazione include fattori quali coerenza e coerenza nella progettazione e nella distribuzione dei componenti, manutenibilità per semplificare l'amministrazione e lo sviluppo e la riutilizzabilità che consente ad altre applicazioni e scenari di riutilizzare componenti e sottosistemi. Per le applicazioni e i servizi ospitati nel cloud, le decisioni prese durante la fase di progettazione e implementazione hanno un impatto enorme sulla qualità e sul costo totale di proprietà.
Il Centro architetture di Azure fornisce modelli di progettazione e implementazione testati che descrivono il problema affrontato, considerazioni per l'applicazione del modello e un esempio basato su Microsoft Azure. Sebbene esistano più modelli di progettazione e implementazione, alcuni dei modelli più rilevanti per la modernizzazione del mainframe includono gli schemi "Livello anti-danneggiamento", "Strangler Fig", "Saga" e "Coreografia".
Modello livello anti-danneggiamento
Indipendentemente dall'approccio di modernizzazione selezionato, è necessario implementare un "livello anti-danneggiamento" usando App per la logica di Azure. Questo servizio diventa il livello facciata o adattatore tra il sistema legacy mainframe e Azure. Per un approccio efficace, identificare i carichi di lavoro mainframe da integrare o coesistere come carichi di lavoro di integrazione del mainframe. Creare una strategia per ogni carico di lavoro di integrazione, ovvero il set di interfacce che è necessario abilitare per la migrazione di un'applicazione mainframe.
Per altre informazioni, vedere Livello anti-danneggiamento.
Modello Fig strangler
Dopo aver implementato il livello anti-danneggiamento, la modernizzazione avviene progressivamente. Per questa fase, è necessario usare il modello "Strangler Fig" in cui si identificano i carichi di lavoro o le funzionalità mainframe che è possibile modernizzare in modo incrementale. Ad esempio, se si sceglie di modernizzare un'applicazione CICS, è necessario modernizzare non solo i programmi CICS, ma probabilmente le 3270 applicazioni insieme alle corrispondenti dipendenze esterne, dati e processi.
Infine, dopo aver sostituito tutti i carichi di lavoro o le funzionalità nel sistema mainframe con il nuovo sistema, si completa il processo di migrazione, il che significa che è possibile rimuovere le autorizzazioni del sistema legacy.
Per altre informazioni, vedere Modello Fig strangler.
Saga e coreografie
Le transazioni distribuite, ad esempio il protocollo 2PC (Two-Phase Commit), richiedono che tutti i partecipanti di una transazione eseseguono il commit o il rollback prima che la transazione possa procedere. Le architetture ibride cloud funzionano meglio seguendo un paradigma di coerenza finale anziché un modello di transazione distribuita.
Il modello di progettazione "Saga" è un modo per gestire la coerenza tra i servizi in scenari di transazioni distribuite. Una saga è una sequenza di transazioni che aggiorna ogni servizio e pubblica un messaggio o un evento per attivare il passaggio successivo della transazione. Se un passaggio non riesce, la saga esegue transazioni di compensazione che contrastano le transazioni precedenti. Per altre informazioni, vedere Modello di transazioni distribuite saga.
In App per la logica di Azure, i flussi di lavoro possono fungere da coreografi per coordinare le saghe. Le azioni del flusso di lavoro sono atomiche, quindi è possibile eseguirle di nuovo singolarmente. Il tipo di azione Ambito offre la possibilità di eseguire un gruppo di azioni solo dopo l'esito positivo o negativo di un altro gruppo di azioni. App per la logica di Azure esegue transazioni di compensazione a livello di ambito, mentre Griglia di eventi di Azure e bus di servizio di Azure fornire la gestione degli eventi necessaria per domini specifici. Tutti questi servizi, che costituiscono Azure Integration Services, forniscono il supporto richiesto dai clienti quando hanno bisogno di una piattaforma di integrazione affidabile per scenari cruciali. Per altre informazioni, vedi Modello coreografico.
Anche se questo articolo illustra diversi modelli di modernizzazione, le soluzioni complesse richiedono molti più modelli e che si conoscono chiaramente gli obiettivi di modernizzazione dell'organizzazione. Anche se l'attività di estendere il valore degli asset legacy è complessa, questa opzione è il modo migliore per preservare gli investimenti in questi asset e prolungare il valore aziendale.