In un panorama dell'IT che va sempre più verso modelli serverless e basati sulla virtualizzazione più "leggera" possibile, anche l'integrazione cambia inevitabilmente volto. Da qualche tempo si parla infatti di Agile Integration, intendendo con questo il passaggio verso forme di "dialogo" tra moduli applicativi che rispecchino la ricerca di agilità e rapidità che interessa lo sviluppo dei moduli applicativi stessi. Ne abbiamo parlato con Vittorio Colabella, Middleware Sales Lead di Red Hat Italia

Che differenze ci sono, concettualmente, tra Agile Integration e l'integrazione IT "statica" che abbiamo visto in questi decenni?
Sempre più, il successo nel business dipende dalla capacità di reagire al cambiamento e l’agilità diventa sempre più un fattore chiave per essere competitivi in qualsiasi mercato. Le tecnologie di integrazione sono nate per indirizzare questo requisito fondamentale, permettendo di integrare dati, servizi e logiche applicative eterogenee in breve tempo e, conseguentemente, di sviluppare e realizzare nuove applicazioni e servizi rapidamente. In particolare, l’avvento della multicanalità ha dato un impulso molto più forte all’adozione di tecnologie di integrazione centralizzate, in quanto ha consentito di accelerare e rendere più efficiente lo sviluppo di applicazioni web, mobile e, in generale, per qualsiasi device. Questo abilitando un back-end di servizi comune che consente di svincolare chi sviluppa applicazioni multi-canale dalla complessità dei sistemi legacy cresciuti e proliferati nel tempo, che rimangono comunque la sorgente di dati, informazioni e servizi core dell’azienda.

Oggi stiamo assistendo ad un’accelerazione ancora più forte con l’avvento del paradigma microservizi, che amplifica enormemente la possibilità di velocizzare tutto il ciclo di sviluppo, dall’idea alla messa in produzione. Infatti tale paradigma permette di scomporre e distribuire la complessità di un’applicazione in oggetti più piccoli ed autoconsistenti. In questo senso anche i team di sviluppo possono essere divisi in team più ristretti che lavorano autonomamente su logiche più semplici, con metodologia Agile e sono in grado quindi di sviluppare e rilasciare molto velocemente ed in maniere indipendente dagli altri team di sviluppo che, a loro volta, sviluppano e rilasciano in modo autonomo.


In questo contesto, i modelli di integrazione centralizzati tradizionali, come Enterprise Service Bus, possono rappresentare un collo di bottiglia, in quanto limitano l’autonomia dei team di sviluppo che dovranno costantemente interagire con team e infrastrutture tecnologiche di integrazione centralizzati, per la realizzazione e messa in produzione di servizi e applicazioni. In generale in un’era in cui si tende a distribuire per velocizzare, qualsiasi infrastruttura e tecnologia centralizzata rappresenta un debito tecnologico che rende più tortuoso un percorso verso un modello Agile.

Fortunatamente questo limite è stato superato dal modello Agile Integration, che consente di sfruttare il meglio delle logiche e tecnologie di integrazione, ma in maniera distribuita. L’avvento del paradigma container e del modello PaaS, in generale, consente infatti di sviluppare o semplicemente utilizzare logiche di integrazione in maniera decentralizzata e quindi indipendente. In particolare, il team di sviluppo può direttamente sviluppare o utilizzare logiche di integrazione già preconfezionate in un catalogo direttamente nel proprio ambiente di sviluppo, senza dover interagire con team di integrazione ed acquisendo quindi l’autonomia e l’indipendenza necessaria per andare verso un modello agile.


Come si concretizza poi, a livello di piattaforme utilizzate, Agile Integration nell'ambito dei processi estesi di integrazione?
Sono tre i pilastri tecnologici che abilitano un modello di integrazione realmente agile.
Tecnologie di integrazione distribuibili, che rendono disponibili pattern standard di integrazione pronti all’uso e connettori verso tecnologie e piattaforme verticali, in un contesto multi-vendor. Inoltre oltre a tecnologie di messaging asincrono che garantiscono una comunicazione affidabile tra sistemi, si stanno sempre più diffondendo tecnologie evolute come Kafka, che consente di velocizzare di diversi ordini di grandezza la propagazione di informazioni ed eventi tra applicazioni e sistemi

API Management, che consente di esporre, in un ecosistema interno o esterno all’azienda, logiche di servizio riutilizzabili e costruite mediante le tecnologie citate al punto precedente o anche direttamente sotto forma di microservizi

Container, che oltre a consentire di distribuire le logiche di integrazione, abilitano il paradigma DevOps e quindi l’autonomia dei team di sviluppo, nei confronti dei team infrastrutturali e di operation, nello sviluppare ed utilizzare questo tipo di logiche - e molte altre non afferenti all’area integrazione - in modalità sempre più self-service. Inoltre, il paradigma container/PaaS abilita by design la capacità di lavorare in un contesto hybrid/multicloud, con la flessibilità di distribuire queste logiche su ogni tipo di infrastruttura, accelerando il percorso di adozione di un modello ‘cloud native’ ed eliminando ogni vincolo


Quali elementi specifici di Agile Integration permettono di estenderla tanto alle nuove architetture IT "cloud like" quanto ai sistemi più legacy?
Il paradigma funziona proprio da collante tra i due diversi mondi legacy e cloud native che, per definizione, si muovono a diverse velocità. E consente di astrarre e disaccoppiare la complessità dei sistemi legacy nei confronti dello sviluppo del ‘nuovo’, che di solito definiamo ‘greenfield’, che possono procedere rapidamente nello sviluppo di nuovi requisiti funzionali ed applicazioni.

Di certo bisogna avere una strategia di graduale dismissione del legacy e il disaccoppiamento aiuta molto da questo punto di vista: finché logiche da sviluppare o aggiornare su sistemi legacy faranno parte della mia mia catena di sviluppo e rilascio, avrò sempre un collo di bottiglia che non consente di aumentare la frequenza dei rilasci.

Pertanto, il paradigma Agile Integration abilita questo percorso di graduale dismissione dei sistemi legacy e di riduzione del debito tecnologico ma, al contempo, mi consente di lavorare in maniera flessibile e distribuita come discusso in precedenza, evitando di creare colli di bottiglia tecnologici ed organizzativi.

Come DevOps ha impattato sulla cultura dei team di sviluppo e delle operations, Agile Integration richiede una analoga evoluzione dei modelli culturali e dell'approccio di chi si occupa di integrazione in azienda?
Sicuramente il modello Agile Integration, che sposa in pieno ed introduce la filosofia DevOps, richiede un cambio di organizzazione, cultura e approccio all’integrazione. Ma questo tipo di cambiamento può essere svolto in maniera graduale, minimizzando impatti e rischi. Inoltre, le tecnologie e i relativi strumenti di sviluppo non cambiano nel nuovo modello, pertanto possiamo dire che l’impatto in definitiva è più organizzativo/culturale che tecnico.