Recentemente Red Hat ha annunciato la disponibilità di Fuse 7, nuova release della sua soluzione di integrazione, distribuita e nativa per il cloud, e contestualmente ha presentato una nuova offerta di integrazione Platform-as-a-Service (iPaas), completamente hosted, chiamata Fuse Online.
Con Fuse 7 Red Hat estende in modo nativo le proprie funzionalità di integrazione alla piattaforma Kubernetes OpenShift Container Platform. Fuse, di fatto, è una soluzione unificata per creare, estendere e implementare servizi di integrazione a container su ambienti di cloud ibrido.
Per capire il senso della proposta di servizio di integrazione ne abbiamo parlato con Vittorio Colabella, Middleware Sales Leader Red Hat Italia.
Che caratteristiche deve avere una piattaforma di integrazione as a service per essere utile alle aziende?
Deve essere in grado di andare oltre il vecchio paradigma Service Oriented Architecture, permettendo di distribuire logiche di integrazione in maniera agile e prevedendo un catalogo di servizi, disponibili ed utilizzabili autonomamente dai team di sviluppo, piuttosto che un bus di integrazione centralizzato che spesso rappresenta un collo di bottiglia sia tecnologico che organizzativo ed una barriera per migliorare il time to market.
Il cloud di destinazione di una soluzione iPaas deve essere sempre ibrido?
Non è detto, ogni contesto ha le sue specifiche esigenze. Il vantaggio di un livello di astrazione introdotto dal concetto iPaaS permette di distribuire flessibilmente logiche di integrazione in un ambiente cloud ibrido, ed abilita quindi la flessibilità di scegliere il proprio modello infrastrutturale, che molto spesso nasce on-premise, e di poterlo estendere in corsa e senza impatti verso un modello ibrido, al variare delle condizioni di mercato.
Che rapporto ha la soluzione iPaas con i microservizi?
A livello logico un layer di integrazione deve essere in grado di aggregare e orchestrare micro-logiche atomiche basate su microservizi creando delle viste di più alto livello (esposte come API) funzionali per la multicanalità o altre esigenze specifiche. In alcuni casi, i microservizi possono essere sviluppati direttamente sul layer iPaaS.
In ogni caso non esistono regole generali: a seconda del contesto o del requisito specifico è possibile definire un modello architetturale ottimale per l’esigenza. Le tecnologie di integrazione devono garantire la flessibilità di poter scegliere il modello che maggiormente si adatta al proprio contesto.
Qual è il ruolo dei connettori?
I connettori sono strumenti, pronti all’uso, che semplificano lo sviluppo di flussi di integrazione, rendendo disponibili interfacce di interazione/interoperabilità verso sistemi esterni che spesso utilizzano protocolli e formati specifici per colloquiare con l’esterno.
Pertanto i team di sviluppo, invece di sviluppare ad hoc delle logiche di integrazione verso sistemi esterni, possono utilizzare i connettori e svincolarsi dalla complessità di dover documentarsi su come accedere ad una specifica piattaforma o sistema.
Come si inserisce in una strategia di API management e DevOps?
L’API management ha un ruolo fondamentale in un framework di integrazione e rappresenta la punta dell’iceberg delle logiche di integrazione sviluppate, in quanto permette di esporre, semplificare e governare l’accesso a queste logiche da parte di un eco-sistema interno o esterno all’azienda.
Diverso il discorso del DevOps che rappresenta un tema trasversale all’integrazione, ai microservizi e a tutte le logiche di sviluppo applicativo. Per l’integrazione, in particolare, si traduce nella capacità di sviluppare e veicolare logiche di integrazione secondo i paradigmi del DevOps, consentendo di automatizzare e velocizzare tutto il ciclo di sviluppo, relativo al layer di integrazione e, conseguentemente l’efficienza e la velocità con cui si riesce ad approcciare lo sviluppo di nuovi requisiti richieste dal business.
