Questo articolo è apparso originariamente su Data Informed.
Quando le organizzazioni cercano di aumentare la propria agilità, l'IT e le linee di business devono connettersi più velocemente. Le aziende devono adottare più rapidamente le applicazioni di cloud e devono essere in grado di accedere e analizzare tutti i loro dati, siano essi provenienti da un data warehouse legacy, da una nuova applicazione SaaS o da una fonte di dati non strutturati come i social media. In breve, una piattaforma di integrazione unificata è diventata un requisito fondamentale per la maggior parte delle aziende.
Secondo Gartner, "le attività di integrazione di applicazioni e dati inutilmente separate portano a pratiche controproducenti e a costi di implementazione sempre più elevati".
Non lasciate che la vostra organizzazione cada in questa trappola. Sia che stiate valutando ciò che avete già o che stiate acquistando qualcosa di completamente nuovo, dovreste misurare qualsiasi piattaforma in base alla sua capacità di soddisfare le "tre A" dell'integrazione: Qualsiasi cosa, in qualsiasi momento e ovunque.
Tutto ciò che è possibile
Per le aziende di oggi, lo spettro di ciò che deve essere integrato è più ampio che mai. La maggior parte delle aziende ha a che fare con molte fonti e obiettivi di dati diversi, dalle applicazioni software-as-a-service agli ERP/CRM on-premises, ai database e ai data warehouse, ai sensori dell'Internet of Things (IoT), ai flussi di clic, ai log e ai dati dei social media, solo per citarne alcuni. Alcune vecchie fonti vengono ritirate, ma se ne aggiungono di nuove, quindi non aspettatevi la semplicità a breve. Concentratevi piuttosto sul rendere la vostra azienda pronta per "qualsiasi cosa".
Oltre il punto a punto. Forse in passato avete gestito l'integrazione da punto a punto. Si tratta di un approccio ad alta intensità di lavoro, che richiede una codifica manuale per essere operativo e un'ulteriore codifica ogni volta che viene apportata una modifica a uno dei due "punti". In questo caso, l'integrazione degli endpoint potrebbe avere dei problemi e bisognerebbe aspettare che il reparto IT si occupi di risolverli. Ma il problema più serio è che questo approccio poco flessibile non è in grado di supportare l'integrazione a livello aziendale in un'epoca di continui cambiamenti.
Alcuni concetti moderni, se applicati all'integrazione, forniscono questa flessibilità e scala.
Microservizi. Un approccio architettonico in cui l'IT sviluppa un singolo servizio come una suite di piccoli servizi che comunicano tra loro utilizzando leggere API REST, i microservizi sono diventati, da circa un anno, l'architettura standard per lo sviluppo di applicazioni aziendali.
Se applicate alle integrazioni, queste aprono enormi opportunità per ottenere integrazioni su larga scala a costi molto bassi. Invece di un grande motore di esecuzione che esegue tutte le integrazioni, motori di esecuzione più piccoli eseguono alcune integrazioni. In questo modo, è possibile fornire più potenza di calcolo alle integrazioni che ne hanno bisogno, quando ne hanno bisogno. È inoltre possibile distribuire le integrazioni tra i nodi di un cluster in base alle variazioni di volume per una scalabilità orizzontale.
Il modello di dati del documento. Le moderne applicazioni non producono solo dati su righe e colonne. Come si fa a ottenere un accoppiamento lasco e a supportare contemporaneamente dati semi-strutturati e non strutturati, senza sacrificare le prestazioni? È possibile raggruppare i dati in modo più naturale e logico e allentare le restrizioni sullo schema del database, utilizzando un modello di dati basato su documenti per memorizzare i dati. I modelli di dati basati su documenti contribuiscono a un accoppiamento libero, alla brevità delle espressioni e al riutilizzo generale.
In questo approccio, ogni record e i dati ad esso associati sono considerati come un "documento", un'unità indipendente che migliora le prestazioni e facilita la distribuzione dei dati su più server, preservandone la localizzazione. È possibile trasformare i dati gerarchici degli oggetti in documenti. Ma questa non è una soluzione perfetta. I documenti sono un sottoinsieme di record basati su righe e colonne, quindi mentre è possibile inserire righe e colonne in un documento, non funziona il contrario.
Qualsiasi momento è tempo reale, e sta accadendo adesso
I casi d'uso odierni, come i motori di raccomandazione, l'analisi predittiva e il rilevamento delle frodi, richiedono sempre più spesso l'acquisizione e l'elaborazione dei dati dalle applicazioni in tempo reale e "in qualsiasi momento". Una moderna piattaforma di integrazione deve disporre di un livello di streaming in grado di gestire i casi d'uso in tempo reale e l'elaborazione batch.
Molte organizzazioni sono abituate a scegliere gli strumenti in base al momento dei dati: piattaforme ESB per integrazioni di applicazioni basate su eventi e a bassa latenza e strumenti ETL per lavori batch ad alto volume. Ora, però, le aziende devono cercare la semplicità e la flessibilità di un framework in grado di supportare sia l'elaborazione batch che quella in tempo reale, "in qualsiasi momento", e architetture come quella Lambda sono il risultato di questa esigenza.
L'architettura Lambda è progettata per bilanciare latenza e throughput nella gestione di casi d'uso batch e real-time. Il livello batch fornisce viste complete e accurate. Può rielaborare l'intero set di dati a sua disposizione in caso di errori. Tuttavia, ha una latenza elevata, quindi per compensare, ha anche un livello di velocità che fornisce l'elaborazione in tempo reale dei dati in streaming. Il livello di servizio di questa architettura consiste in un database appropriato per i livelli speed e batch, che possono essere combinati e interrogati per ottenere risposte dai dati.
A causa di questi casi d'uso in tempo reale, le piattaforme di streaming sono diventate molto desiderabili.
Ovunque dovrebbe sembrare ovunque
Con l'odierna architettura ibrida di dati e distribuzione, i dati possono trovarsi ovunque, in qualsiasi formato, e potrebbero richiedere un trattamento diverso in base al caso d'uso specifico. Ad esempio:
- Se tutte le applicazioni e i dati si trovano all'interno di cloud, è necessario un approccio cloud-first per tutte le altre parti dell'ecosistema applicativo, compresa l'integrazione.
- Se si dispone di un'architettura ibrida che comprende sia dati on-premises che applicazioni cloud , potrebbe essere necessario limitare l'uscita dei dati dalla sede. Considerate un piano dati on-premises per l'elaborazione all'interno del firewall.
- Se disponete di un ecosistema di big data, probabilmente avete bisogno della flessibilità di eseguire in modo nativo su Hadoop utilizzando il gestore di risorse YARN e di utilizzare MapReduce per elaborare qualsiasi lavoro di integrazione o trasformazione.
Nel frattempo, Spark si è fatto strada per l'elaborazione di lavori a bassa latenza. Per alcuni casi d'uso che richiedono analisi in tempo reale, come il rilevamento delle frodi, l'elaborazione dei log e l'elaborazione dei dati provenienti dall'IoT, Spark è un motore di elaborazione ideale.
L'integrazione è al centro di ogni iniziativa di successo in ambito social, mobile, analytics (big data), cloud e IoT. Non è più possibile scalare verso il successo dovendo scegliere tra più strumenti e team per l'integrazione di applicazioni, processi e dati. Le imprese di successo oggi hanno bisogno di accedere alle risorse e di gestirle istantaneamente attraverso un'unica piattaforma. Quando si dispone della piattaforma giusta, in grado di fornire qualsiasi cosa, in qualsiasi momento e ovunque sia necessaria, gli utenti non dovranno mai fermarsi a chiedere quali risorse sono utilizzate, se le informazioni sono aggiornate o dove si trovano. Tutto ciò di cui hanno bisogno sarà a loro disposizione quando ne avranno bisogno e ovunque si trovino.
Ho pubblicato questo articolo anche su LinkedIn. I commenti sono benvenuti su Data Informed, LinkedIn o qui.
