Cosa si intende per integrazione?

Con integrazione dell'IT, o dei sistemi, si intende la connessione di dati, applicazioni, API e dispositivi, volta ad agevolare efficienza, produttività e agilità dell'intero team IT. L'integrazione è fondamentale quando si parla di trasformazione, ovvero dell'adozione di nuovi modelli in linea con le novità del mercato, per consentire a tutte le risorse IT di funzionare in un unico ambiente. L'integrazione non si limita alla connessione, ma aggiunge valore tramite le nuove funzionalità ottenute attraverso la connessione dei diversi sistemi. Ad esempio, grazie alla piattaforma open source Apache Kafka puoi integrare il flusso di dati nelle applicazioni, attingendo ai dati in tempo reale.

L'integrazione IT non deve essere confusa con l'integrazione continua (CI), una pratica di sviluppo che prevede la condivisione continua di copie del codice in uso, in un repository centrale. L'obiettivo della CI è l'automazione della compilazione e delle verifiche, così da consentire il rilevamento precoce dei problemi con una conseguente accelerazione dello sviluppo.

Con la crescita e lo sviluppo nel tempo dei sistemi IT, si è verificata una proliferazione incontrollata che ha causato problemi di incompatibilità tra le soluzioni di diversi fornitori. Di conseguenza, l'unico elemento a collegare un insieme di tecnologie IT è spesso unicamente il fatto di essere di proprietà della stessa azienda. Occorre quindi un modo per eliminare l'incompatibilità delle risorse, così da evitare la duplicazione delle attività, soprattutto quando si tratta di implementare e agire sulla logica aziendale.

*Nota: quanto segue è oggetto di dibattito sulla semantica: confronto tra topologie fisiche e topologie logiche e tra approcci, architetture e tecnologie. Le spiegazioni fornite di seguito sono da intendersi come panoramiche generali.

Integrazione delle applicazioni di livello enterprise

Una soluzione a questa proliferazione incontrollata di sistemi disparati è stata l'integrazione delle applicazioni aziendali (EAI), ovvero tecnologie, strumenti e un framework che implementa un'integrazione in tempo reale basata sui messaggi tra le app. I messaggi vengono attivati da modifiche o parametri creati all'interno delle singole app. L'integrazione delle applicazioni aziendali è stata realizzata in due modi: point-to-point e hub-and-spoke.

Con il modello point-to-point ogni applicazione doveva essere personalizzata per comunicare con le altre applicazioni e parti dell'ambiente IT. La personalizzazione avviene per ogni risorsa IT e per ogni risorsa a cui si connette. Si tratta di un processo molto noioso e, comprensibilmente, molto soggetto a errori. Per complicare ulteriormente le cose, con il continuo aggiornamento dell'infrastruttura e delle app, questo modello può essere molto difficile da mantenere nel tempo.

Per risolvere questo problema entra in gioco il modello hub-and-spoke, che prevede la gestione delle connessioni tra app e servizi mediante un broker, o hub, centrale. Gli spoke che collegano l'hub alle app e ai servizi possono essere gestiti individualmente. Ciò consente alle app stesse di essere più focalizzate, con tutte le parti delle integrazioni gestite tramite hub e spoke. Il principale svantaggio di questo approccio è la centralizzazione dell'hub, che diventa un singolo punto di vulnerabilità per il sistema e per le comunicazioni dell'infrastruttura. Tutte le integrazioni nel modello hub-and-spoke EAI dipendono, per progettazione, dal funzionamento dell'hub.

L'approccio Enterprise Service Bus

All'approccio hub-and-spoke EAI ha fatto seguito l'approccio Enterprise Service Bus (ESB), uno strumento che ha consentito l'astrazione basata su messaggi, ovvero la modularizzazione dei servizi tra le applicazioni.

Un ESB funge anche da hub centrale in cui tutti questi servizi modulari vengono condivisi, instradati e organizzati per connettere tra loro app e dati. È una soluzione migliore rispetto all'hub-and-spoke EAI ma forse non una soluzione decisiva per le organizzazioni dato che, man mano che crescono e aggiungono risorse, hanno bisogno di maggiore velocità in tutti i loro sistemi e risorse software.

A questo punto avrai dedotto che un ESB assomigli molto al modello hub-and-spoke. Questo è vero, ma un ESB ha alcune caratteristiche molto particolari che lo distinguono in termini di funzionalità.

• Gli ESB si presentano come un servizio che utilizza standard aperti, e ciò elimina la necessità di scrivere interfacce univoche per ogni applicazione.
• I servizi di integrazione possono essere distribuiti con modifiche minime alle applicazioni.
• Gli ESB si affidano a protocolli e interfacce aperti e standard del settore per facilitare i nuovi deployment.

Tuttavia, i tipici deployment ESB portano spesso alle architetture centralizzate, per la ragione descritta nel modello hub-and-spoke: la necessità di un unico punto in cui ospitare e controllare tutti i servizi di integrazione. Alle architetture e ai deployment ESB centralizzati si associa una rigida governance centralizzata che, non agevolando la veloce erogazione di soluzioni adattabili, è di ostacolo alla trasformazione digitale. Inoltre, gli stessi ESB diventano spesso applicazioni monolitiche.

Perché scegliere Red Hat per l'agile integration?

Finora abbiamo esaminato l'integrazione in sé, ovvero le tecnologie che consentono a tutti i componenti IT di funzionare nello stesso ambiente. Cos'è l'agile integration? Deriva dal modo in cui Red Hat vede il futuro dei sistemi connessi, e come questi supportano il lavoro effettivo che i team devono svolgere per sostenere cambiamenti sempre più frequenti.

Red Hat ritiene che l'approccio tradizionale all'integrazione, caratterizzato da team centralizzati che controllano tecnologie monolitiche, ostacoli lo sviluppo e comprometta l'utilità a lungo termine delle applicazioni distribuite. Le tecnologie di integrazione tradizionali, come ESB, offrono vantaggi come l'importanza prioritaria della sicurezza e l' integrità dei dati, ma dipendono da un solo team che definisce le integrazione per l'intera azienda.

Le architetture applicative cloud native con basso livello di accoppiamento e sviluppate attraverso i metodi Agile e DevOps di oggi, però, hanno bisogno di un approccio altrettanto agile e scalabile all'integrazione. Nella visione di Red Hat, l'agile integration è esattamente questo: un approccio al collegamento delle risorse che combina tecnologie di integrazione, tecniche di distribuzione agile e piattaforme cloud native per migliorare la velocità e la sicurezza nella distribuzione del software. In particolare l'integrazione Agile implica il deployment di tecnologie di integrazione, come le API, nei container Linux e l'estensione dei ruoli di integrazione ai team interfunzionali. Un'architettura di agile integration è caratterizzata da tre capacità: integrazione distribuita, container e API.

Perché secondo Red Hat è possibile ottenere un'infrastruttura agile attraverso un'architettura d'integrazione distribuita e iterativa, anziché infrastrutture centralizzate e suddivise in compartimenti stagni. Cosa prevede? Un framework architetturale che allinei microservizi containerizzati, cloud ibrido e le interfacce di programmazione delle applicazioni (API) alle metodologie agili e DevOps utilizzate dagli sviluppatori.

Perché scegliere Red Hat per l'integrazione Agile?