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.