Questo post è apparso originariamente sul blog di Glenn Donovon.
Di recente ho deciso di dare un'occhiata approfondita a cloud iPaaS (integration platform as a service) e, in particolare, a SnapLogic, grazie al fatto che un mio amico si è unito a loro per contribuire alla creazione del loro programma di account nominativi. Si tratta di una piattaforma interessante che ritengo abbia il potenziale per aiutare l'IT nell'"ultimo miglio" della creazione di cloud in azienda, non solo per le sue caratteristiche, ma piuttosto per il cambiamento nell'ingegneria del software e nella progettazione che è iniziato in luoghi come Google, Amazon e Netflix - e nelle startup che non potevano permettersi uno "stack tecnologico aziendale" - e che ora si sta facendo strada nelle aziende.
Tuttavia, discutendo con il mio amico, è emerso chiaramente che è necessario comprendere la storia dei server di integrazione, del middleware EAI, della SOA, dell'ESB e degli standard WS per contestualizzare le lezioni che sono state apprese lungo il percorso per quanto riguarda l'effettiva agilità dell'IT. Ma permettetemi di qualificarmi prima di entrare nel merito. Il mio punto di vista si basa sull'esperienza di venditore di tecnologia aziendale che ha venduto middleware a bassa latenza, middleware basato su standard, middleware EAI, un bus di grid-messaging SOA e applicazioni come CRM, BPM e gestione del rischio di mercato/credito a livello aziendale, che hanno requisiti di integrazione di sistema enormi. Pur avendo frequentato un po' di università e di codifica nella mia vita (per un po' ho fatto consulenza su database di piccole imprese), non sono un architetto, un codificatore e nemmeno un analista di sistemi. Ho visto da vicino perché queste tecnologie sono state acquistate, come si sono evolute nel tempo, cosa ne hanno ricavato i clienti e come si sono svolti tutti i nostri piani e le nostre aspirazioni. Quindi, sto cercando di mettere insieme una narrazione che colleghi i punti per persone diverse dagli sviluppatori di middleware e dai CTO/Architect. Detto questo, allacciate le cinture.
Il terreno
Definiamo alcuni termini: middleware è un termine generico, io lo uso per riferirmi ai bus di messaggi/ESB e ai server di integrazione (EAI). La storia di questi domini ci ha portato allo stato attuale e ci aiuta a capire dove dobbiamo andare e perché il vecchio modo di fare integrazione di sistemi e di costruire SOA sta scomparendo a favore di una progettazione basata su microservizi e servizi web RESTful in generale.
Server di integrazione - che si tratti di IBM o di sfidanti dell'epoca come SeeBeyond (per cui lavoravo), lo scopo di un server di integrazione era quello di porre fine alla pratica di scrivere a mano il codice per ogni sistema/progetto per accedere ai dati/sistemi. A quei tempi si parlava spesso di integrazioni "punto a punto" e, quando si costruivano sistemi complessi in grandi aziende prima dei server di integrazione, i flussi di dati tra i sistemi sembravano spesso un piatto di spaghetti. Mi viene sempre in mente un progetto aziendale sul rischio di mercato a cui ho lavorato presso la Bank of New York. I flussi di dati di oltre 100 punti di integrazione da cui il sistema di rischio consumava i dati erano stati raccolti in un unico diagramma che abbiamo plastificato su carta 11×17, facendone una sorta di tovaglietta. Per me è diventato un simbolo di questo tipo di problema. Aveva più o meno questo aspetto:
(Immagine attribuita a John Schmidt, autorità riconosciuta nel campo della governance dell'integrazione e autore di libri sull'Integration Competency Centre e sulla Lean Integration)
Così è arrivato il "server di integrazione". Lo scopo era quello di fornire un'interfaccia comune e strumenti da utilizzare per collegare i sistemi senza scrivere codice da zero, in modo che le integrazioni tra i sistemi fossero facili da costruire e mantenere, oltre che sicure e performanti. Un'altra motivazione importante è stata quella di accoppiare in modo lasco i sistemi di destinazione e i sistemi che consumano i dati, per isolare entrambi dalle modifiche al codice sottostante. Il servizio risultante era disponibile essenzialmente come API, erano sistemi proprietari e in un certo senso erano scatole nere da cui si consumavano o si contribuiva ai dati. Eseguivano le trasformazioni, gestivano il traffico, caricavano i dati in modo efficiente, ecc. Naturalmente, c'erano anche quelli dedicati ai dati bulk/batch, come Informatica e più tardi Ab Initio, ma è curioso che questi due mondi molto correlati non si siano mai uniti in un'offerta unificata di successo.
Questo approccio, tuttavia, non ha cambiato radicalmente il modo in cui i sistemi software venivano progettati, sviluppati o distribuiti. L'obiettivo era piuttosto quello di isolare i requisiti di integrazione e di realizzarli meglio attraverso un server e un toolkit dedicati. Questo approccio ha fornito molto valore alle imprese in termini di costruzione di solide integrazioni di sistemi e ha anche aiutato le grandi aziende ad adottare software pacchettizzato con una minore scrittura di codice, ma alla fine ha offerto solo miglioramenti marginali nell'efficienza dello sviluppo, iniettando un'ulteriore dipendenza dal sistema (nuovo strumento, personale specializzato, costi operativi continui) nello "stack". Certo, si potevano costruire centri di competenza e "fabbriche", ma ancora oggi questi approcci finiscono per creare più burocrazia, più dipendenze e complessità, aggiungendo sempre meno valore rispetto a quello che uno sviluppatore può costruire da solo con servizi/microservizi RESTful, e la maggior parte delle cose con cui ci si vuole integrare oggi hanno già API ben definite, per cui è spesso molto più facile connettersi e condividere i dati in ogni caso. Idee innovative come "dati coerenti alla fine" e gli incredibili vantaggi di costo e di calcolo dell'open source rispetto alle tecnologie proprietarie, oltre all'IaaS pubblico che accoglie tali carichi di lavoro a livello di container, beh, diciamo che sta cambiando molto di più della semplice integrazione. Le persone intelligenti con cui parlo mi dicono che usare un ESB come spina dorsale di un sistema basato su microservizi è contrario all'architettura.
Bus di messaggistica/ESB - Si tratta di un sistema per la gestione del traffico di messaggistica su un bus di uso generale dal quale uno sviluppatore può pubblicare, sottoscrivere, trasmettere e inviare più messaggi da servizi/sistemi di destinazione e di origine. Questa piattaforma è antecedente al Web ed era presente alla fine degli anni '80 e negli anni '90 nei sistemi di messaggistica specializzati ad alta velocità per i trading floor, così come nelle industrie manifatturiere e in altri contesti industriali dove la bassa latenza era fondamentale e i picchi di traffico erano la norma. Il successo iniziale di Tibco nelle trading room era dovuto al fatto che forniva un'architettura basata sui servizi per il consumo dei dati di mercato, che si scalava e consentiva di costruire sistemi con design a servizi/message bus. Questi ultimi consentivano di avvicinarsi ai requisiti di tempo quasi reale di tali ambienti, ma erano proprietari, estremamente costosi e non erano assolutamente applicabili per l'informatica generale. Tuttavia, l'uso di un'architettura a servizi e bus con comunicazioni pub/sub, broadcast, multipoint e point to point disponibili come servizi per gli sviluppatori è stato formidabile per isolare le applicazioni dalle dipendenze dei dati e per gestire i picchi di traffico di tali dati.
Con il tempo, è diventato chiaro che la costruzione di sistemi a partire da servizi era molto promettente in generale (ereditando le idee di base della progettazione orientata agli oggetti), ed è allora che ha cominciato a emergere l'idea dei servizi Web. Si formarono interi organismi di standardizzazione e molti progetti open source e di altro tipo nacquero per supportare l'approccio basato sugli standard alla progettazione e alla distribuzione dei sistemi di servizi Web. Le architetture orientate ai servizi divennero di gran moda: mentre lavoravo a SeeBeyond, ho lavorato a un progetto per Travelers Insurance in cui abbiamo esposto molte delle loro applicazioni mainframe come servizi Web. Questo approccio avrebbe dovuto liberare l'agilità nello sviluppo IT.
Ma lungo il percorso è apparso evidente un problema. I costi, le competenze, la complessità e il tempo necessari per costruire sistemi framework così elegantemente progettati e governati erano in contrasto con la necessità di costruire sistemi in modo rapido. Un buon sviluppatore poteva ottenere qualcosa che funzionasse e fosse di alta qualità senza ricorrere all'uso di tutti quei servizi standardizzati WS e alla conformità alla loro struttura. Tra i problemi centrali c'era l'uso dell'XML per rappresentare i dati, perché la potenza di elaborazione necessaria per trasformare queste strutture era sempre troppo costosa rispetto al guadagno. SOAP era anche un protocollo altamente specializzato, che introduceva un ulteriore livello di sistemi/conoscenze/dipendenze/complessità nella costruzione di sistemi con un alto grado di integrazione.
L'intero framework WS era troppo formalizzato, quindi gli sviluppatori più intraprendenti si sono chiesti: "Come posso usare un'architettura basata sui servizi a mio vantaggio quando costruisco un sistema senza fare affidamento su tutte queste sciocchezze? È qui che entrano in gioco i servizi web RESTful e poi JSON, che cambia tutto. Improvvisamente, nuovi servizi web complessi e sofisticati cominciarono a essere richiamabili semplicemente tramite HTTP. La creazione e l'utilizzo di tali servizi sono diventati banalmente facili rispetto al vecchio modo. Le prestazioni e la sicurezza potevano essere gestite in altri modi. Ciò che è andato perduto è stata l'idea di operare con standard di "sistemi aperti" dal punto di vista della progettazione dei sistemi, ma si è scoperto che in pratica era meno valida, dato tutto l'overhead.
Il punto di vista dell'IT
La dirigenza IT sospetta già che i framework di bus di messaggistica non abbiano dato loro il vantaggio più importante che cercavano, ovvero l'agilità, eppure hanno tutta questa infrastruttura di messaggistica e tutti questi servizi web incredibilmente ben comportati in esecuzione. In un certo senso, si può vedere tutto questo come parte del modo in cui le organizzazioni IT stanno imparando a capire come si presenta la vera agilità quando si utilizzano architetture basate sui servizi. Credo che molte siano pronte a scaricare tutte le spese generali, altamente complesse e costose, che si accompagnavano ai bus di messaggistica, quando arriva una piattaforma di classe enterprise che consente loro di farlo.
Ma l'IT ama ancora i server di integrazione. Credo che siano desiderosi di un server di integrazione legittimo, ibrido e basato sucloud (iPaaS), che offra loro un modo semplice per creare e mantenere interfacce per vari progetti a costi inferiori rispetto alle soluzioni basate su ESB, pur funzionando in cloud e on-prem. Dovrà fornire i vantaggi di un'architettura basata sui servizi - relazioni a livello contrattuale - senza la complessità e i costi generali dei bus di messaggistica. Deve sfruttare la flessibilità di JSON, fornendo al contempo un controllo a livello di meta-dati sui servizi, insieme a un quadro completo di governance e gestione operativa. Deve inoltre scalare in modo massiccio ed essere distribuito per poter essere preso in considerazione per questo ruolo centrale nei sistemi aziendali.
Il vero motore dell'adozione di Cloud
Quello che a volte si perde con tutta la nostra attenzione tecnica è che è soprattutto l'economia a guidare l'adozione di cloud . Con l'enorme differenziale di costo che si sta aprendo nel public computing rispetto ai data center on-prem o addirittura in outsourcing, grazie alle decine di miliardi che IBM, Google, MSFT, AWS e altri stanno investendo nei loro servizi, il cloud pubblico diventerà la piattaforma di scelta per tutto il computing in futuro. All'interno di una buona organizzazione IT si discute solo su quanto tempo ci vorrà per questa transizione.
Molte grandi organizzazioni IT vedono chiaramente che il punto di svolta in termini di costi è già a portata di mano per quanto riguarda IaaS e PaaS. Questo è già successo in molti mercati cloud - Salesforce non ha davvero schiacciato Siebel fino a quando i suoi canoni di abbonamento annuali non sono stati inferiori ai canoni di manutenzione on prem di Siebel. Ricordate, non c'era alcun vantaggio funzionale in Salesforce rispetto a Siebel. Suggerimento: poiché l'economia è il fattore trainante, non si tratta di avere la soluzione più elegante, ma di essere in grado di svolgere il lavoro in qualche modo, anche se non è bello o comporta dei compromessi.
Un suggerimento più profondo: se si offre a un buon sistemista la possibilità di scegliere tra la navigazione in un nugolo di strumenti, standard e servizi, con tutte le penalizzazioni sulle prestazioni, l'overhead, i compromessi funzionali e le dipendenze che essi comportano, e la necessità di scrivere un po' più di codice e di essere attento alla gestione dei sistemi, si sceglierà sempre la seconda opzione. Un altro modo per dire che la complessità e l'astrazione sono molto costose quando si costruiscono sistemi e i benefici devono essere davvero grandi perché il compromesso abbia senso, e non credo che alla fine gli ESB e gli standard WS per la spina dorsale della SOA abbiano mai dato i frutti sperati. E non lo faranno mai. Il settore ha pagato molto per imparare questa lezione, eppure sembra che ci sia una grande riluttanza a discuterne apertamente. La lezione? Semplicità = Agilità IT.
La domanda più importante è quali siano i carichi di lavoro aziendali fondamentali che possono essere trasferiti sul sito cloud pubblico, e questo è ancora un lavoro in corso. Piattaforme come Apprenda e altre soluzioni ibride cloud sono parte cruciale di questo mix, in quanto si deve essere in grado di assegnare i dati e i processi alle risorse appropriate dal punto di vista della sicurezza/privacy e delle prestazioni/costi. Una futura singola applicazione "cloud" realizzata da un'azienda potrebbe avere alcuni dei suoi dati in server su Azure in tre diversi data center per gestire la residenza dei dati, altri dati in data store on prem, accedere ai dati da app SaaS e accedere ad altri dati in semplici data store super economici su AWS. In sostanza, si tratta di una questione di "policy" e direi che se un iPaaS ibrido come Snaplogic riesce a inserirsi in queste policy, a comportarsi bene con esse e a facilitare la connessione di questi sistemi, ha ottime possibilità di essere una parte centrale della grande ricostruzione dei sistemi IT di base a cui assisteremo nei prossimi 10 anni. Questo perché fornisce all'azienda ciò di cui ha bisogno, un server di integrazione che sfrutta servizi RESTful, architetture basate su microservizi e JSON senza un ESB.
Tutto questo si sta concretizzando ora, quindi si assisterà a un crescente interesse nell'abbandonare le vecchie architetture di server di integrazione/message bus nelle organizzazioni incentrate sulla trasformazione e sull'agilità come valori fondamentali. Credo che la leadership della maggior parte delle organizzazioni IT sia pronta a lasciarsi alle spalle i vecchi standard WS e le architetture di bus/messaggio/servizio, ma le loro organizzazioni tecniche sono ancora costruite attorno ad essi, quindi ci vorrà del tempo. È anche vero che i bus di messaggi non saranno eliminati del tutto, poiché i servizi di messaggistica trovano spazio nello sviluppo dei sistemi, ma non come collante della SOA. Naturalmente, i bus a bassa latenza saranno ancora utili per la creazione di applicazioni in tempo quasi reale, ad esempio in ambito ingegneristico o nei trading floor, ma l'uso dei bus di messaggi come modello di progettazione generale scomparirà dalla vista.
La conclusione è che i leader dell'IT sono altrettanto frustrati per non aver ottenuto l'agilità della costruzione di sistemi che utilizzano modelli di messaging bus/SOA, quanto gli sponsor aziendali per i costi e la latenza di questi sistemi. Tutti i settori sono desiderosi di un nuovo paradigma e questo è il momento di avviare un dialogo su questa nuova visione. A mio avviso, questa è una delle ultime parti cruciali dell'infrastruttura IT che deve essere modernizzata e abilitata a cloud per spostare i carichi di lavoro informatici aziendali su cloud e credo che SnapLogic abbia ottime possibilità di aiutare le aziende a realizzare questa visione.
______
Sull'autore
Glenn Donovon è stato consulente o dipendente di 23 startup e ha una vasta esperienza di lavoro con organizzazioni IT B2B aziendali. Per saperne di più su Glenn, visitate il suo sito web.
