La scorsa settimana abbiamo ospitato un webcast molto apprezzato con il Dr. Stefan Ried, Principal Analyst e Vice President di Forrester al servizio dei CIO. Stefan ha fornito una panoramica dettagliata della ricerca Forrester sull'integrazione basata su cloud, sulle tendenze del mercato e ha spiegato perché l'ibrido è la realtà IT di oggi e del prossimo futuro. Il webcast ha anche offerto una panoramica di alto livello del
SnapLogic Integration Cloud e un Q&A interattivo su una vasta gamma di argomenti. Il Q&A ha approfondito i motivi per cui l'Enterprise Service Bus (ESB) legacy non è adatto agli scenari di integrazione cloud , i vantaggi della multi-tenancy e le sfide che le tecnologie di integrazione legacy devono affrontare per far fronte ai moderni requisiti di integrazione.
Prima della discussione, Stefan ha riassunto la posizione di SnapLogic sul mercato dicendo:
"Come si è visto, SnapLogic può essere sia un'integrazione in cloud che un'integrazione con cloud. Se si desidera che Snaplex sia on-premise, si ha una governance dei dati on-premise e si può puntare alle applicazioni SaaS a cui ci si vuole collegare. Ma se la maggior parte delle applicazioni si trova in cloud, si desidera che Snaplex si trovi in cloud. Questa architettura è molto flessibile per mantenere aperte entrambe le opzioni".
Ecco la trascrizione delle domande e risposte:
Domanda: Lei ha detto che gli ESB in genere non sono multi-tenant e non sono adatti per cloud. Ci sono ragioni specifiche per cui un ESB non è la scelta giusta per l'integrazione ? per cui un ESB non è la scelta giusta per l'integrazione in cloud ?
Risposta: Per un paio di motivi.
- La scalabilità di un ESB. Gli ESB possono diventare molto grandi, come potreste vedere nella vostra infrastruttura se gestite un ESB di grandi dimensioni, ma gli ESB faticano a diventare molto piccoli. Sembra strano, ma non lo è. Ad esempio, se si utilizza lo scenario di integrazione basato su cloud per realizzare l'integrazione B2B. In questo modo è possibile non solo integrare il sistema Salesforce.com nel sistema ERP, ma anche integrare tutti i partner di canale del tenant Salesforce.com nel sistema ERP. È possibile realizzare un'integrazione di canale molto elegante come questa. Se doveste creare un ESB per ognuno di loro e venisse usato solo per un paio di messaggi al giorno, sprechereste un sacco di infrastrutture (e di licenze, tra l'altro). Questi sono esempi che toccano i limiti delle architetture ESB tradizionali.
- Il paradigma dello sviluppo di scenari di integrazione complessi. Questi sono utili se avete requisiti molto complessi, ma se volete sincronizzare i dati dei vostri clienti NetSuite con i dati dei vostri clienti SAP, o qualsiasi altro ERP che avete in sede, questo è uno strumento eccessivo. Ho visto che i clienti che cercano di utilizzare un ESB tradizionale per questi scenari cloud si ritrovano con costi molto più elevati e quindi con competenze da acquistare anche esternamente, mentre l'alternativa è l'integrazione basata su cloud .
Domanda: Perché non posso farlo semplicemente con il middleware esistente e qual è la raccomandazione per utilizzare il middleware esistente con alcuni di questi nuovi scenari?
Risposta: Prima di tutto, vorrei motivare e incoraggiare tutti a provare le nuove soluzioni. Non solo perché si tratta di una conversazione sponsorizzata da SnapLogic, ma anche perché sia l'integrazione delle applicazioni tradizionali che l'integrazione dei dati tradizionali sono semplicemente troppo pesanti in molti casi per i requisiti di sincronizzazione dei dati con cloud. Ciò significa che vorrei incoraggiarvi a provarle, a scoprire quali casi d'uso della vostra azienda rientrano in questo contesto e quindi a trovare un equilibrio tra l'utilizzo del vostro vecchio middleware e l'estensione a questi casi d'uso o l'apprendimento di qualcosa di nuovo e la concessione di una nuova licenza. Molte aziende di medie e grandi dimensioni finiscono per utilizzare entrambe le cose. L'integrazione basata su cloud non è quindi un sostituto, ma un complemento. Fornisce quei casi in cui l'ESB tradizionale o gli strumenti tradizionali di integrazione dei dati sono semplicemente eccessivi.
Domanda: Può spiegare meglio il concetto di collaborazione sui metadati e perché le piattaforme di integrazione cloud sono più adatte rispetto a quelle on-premise?
Risposta: Se si gestiscono i metadati in cloud, ovviamente è possibile utilizzare semplicemente la collaborazione di cloud . Ad esempio, è possibile creare un mercato. Oppure si possono creare scenari di crowdsourcing in cui si possono semplicemente condividere i metadati, sia che siano stati creati da un integratore o da un fornitore professionale, sia che siano stati creati da un collega, magari di un'azienda completamente diversa, con lo stesso tipo di configurazione o gli stessi due endpoint. Ciò significa che si può immaginare di trattare i metadati come se si trattasse di un foglio di calcolo di Google, ad esempio. È possibile condividere facilmente con altre persone in tempo reale. Il vecchio modo di gestire i metadati nel middleware tradizionale era più simile a quello di Microsoft Office, dove si invia un foglio di calcolo Excel. Quando arriva è già obsoleto.
Questa è la differenza nel sito cloud. È più collaborativo. È più condiviso. È possibile immaginare un mercato e un crowdsourcing, la condivisione di metadati in un modo completamente diverso. E questo, in ultima analisi, riduce i costi di implementazione e rende le competenze molto più economiche, perché le persone apprezzano la semplicità e si limitano a prendere esempio da altre persone invece di leggere grandi manuali o acquistare un consulente.
Domanda: La mulitenancy è ancora importante? Quali sono le ragioni per cui è importante in una piattaforma di integrazione cloud ?
Risposta: La multitenancy comporta sicuramente una riduzione significativa dei costi. Tecnicamente è possibile ottenere molte delle cose di cui abbiamo parlato oggi avviando una macchina virtuale dedicata su Amazon o altrove e si può ottenere lo stesso risultato tecnico. Ma ovviamente se avete creato una macchina virtuale nel vostro ambiente, non potete fare le cose che abbiamo appena discusso sulla condivisione dei metadati. Ma se si dispone di un ambiente condiviso, l'ambiente può definire la condivisione dei metadati o il prelievo dei metadati in un Appstore - collaboriamo sui metadati, ma manteniamo i dati stessi segreti e privati. Questa è la forma attuale che Forrester ha iniziato a chiamare "Collaborative Tenancy". Ciò significa essere privati nelle parti che devono essere private, come i flussi di dati, ma essere molto collaborativi nelle parti che possono essere collaborative, come i metadati. Questi concetti sono ovviamente molto diversi da quelli che si potrebbero ottenere in un ambiente single tenant.
Infine, ho già citato l'esempio di una maggiore scalabilità. In un ambiente multitenant, se un tenant non è necessario si addormenta. Non richiede più alcuna infrastruttura. In questo modo si finisce per ridurre sia l'infrastruttura che, potenzialmente, i prezzi delle licenze basati sulle transazioni. Nel vecchio mondo, guardate i vostri ESB, sono tutti prezzi basati sulla CPU. Se rimangono inutilizzati, sono comunque costosi. Qui è tutto molto diverso.
Domanda: Recentemente abbiamo avuto un dibattito sul patrimonio di un fornitore di integrazione. Come cambiano i fornitori tradizionali? Possono cambiare? Cosa c'è di importante sotto il cofano?
Risposta: Non è possibile modificare il software dell'architettura di base. Non è possibile. Se è basato su un ambiente Java tradizionale e costruito con un modello a oggetti tradizionale, non è possibile trasformarlo in una rappresentazione JSON. Semplicemente non è così facile. Tuttavia, si cerca di mapparlo. Alla fine si possono ovviamente servire le applicazioni scritte in entrambi i paradigmi in entrambi i modi, ma non si ottengono le prestazioni. Ciò significa che se il traffico è intenso, i nuovi ambienti di cloud, ad esempio se si tratta di un'applicazione rivolta ai clienti, una vecchia GS o un'applicazione per gestire i clienti che è anche connessa a Facebook e ha volumi di traffico imprevedibili, penso che le nuove architetture middleware come quella di SnapLogic abbiano sicuramente dei vantaggi. Alla fine, il problema è il costo. Si tratta del volume dell'infrastruttura fisica necessaria per servire il traffico e se si utilizza un'architettura moderna si è sicuramente in grado di gestire il traffico.
Consultate la nostra pagina degli eventi per i prossimi programmi web e dal vivo. Potreste trovare interessante anche questo post: perché la SOA è morta grazie all'ESB.
