Una tecnologia emergente nel mondo dei datacenter, etichettata dagli addetti ai lavori come “disruptive”, ossia potenzialmente rivoluzionaria, è quella conosciuta come edge computing. Si basa sul principio di portare dati e capacità elaborativa quanto più vicini possibile al luogo in cui servono, “scippandoli”, di fatto, ai grandi datacenter centralizzati.
In estrema sintesi, l’obiettivo dell’edge computing è quello di ridurre i tempi di latenza tra centro e periferia con il fine di garantire agli utenti finali risposte immediate, generate quanto più possibile sui dispositivi finali e sempre meno dipendenti dalla banda a disposizione.
Si pensi, ad esempio, a servizi nei quali il fattore tempo sia imprescindibile come nel caso della telemedicina, della gestione delle cartelle cliniche o in generale delle applicazioni in campo medico e sanitario. In tali casi, è fondamentale poter accedere a informazioni quanto più possibile “vicine” e a sistemi di trattamento dei dati indipendenti da reti di comunicazione o fattori esogeni di varia natura.
È del tutto evidente come la tecnologia apra orizzonti finora impensabili che, in un intervallo di tempo anche abbastanza ristretto, possono nuovamente modificare le architetture informatiche e i rapporti tra client e server.
Se, però, a una visione immediata e superficiale, l’edge computing possa apparire antitetica rispetto al cloud e all’attuale situazione centralizzata nei datacenter (tanto che molti analisti hanno ipotizzato la fine imminente delle “nuvole digitali”), in realtà gli scenari più probabili sono sicuramente costituiti dalla generazione di nuove infrastrutture “ibride”, nelle quali dispositivi finali potenti e performanti saranno chiamati a dialogare in maniera diretta, veloce e snella con micro-datacenter distribuiti ed in grado di fornire risorse aggiuntive impossibili da reperire in locale.
L’edge computing riduce le distanze fra client e datacenter
Come anticipato in precedenza, una tecnologia che potrà condurre i datacenter a dover mutare la propria attuale configurazione, che li vede sempre più grandi, articolati, complessi e “distanti” rispetto agli utilizzatori finali, è quella dell’edge computing, che, al contrario, è finalizzata a ridurre drasticamente le distanze intercorrenti tra i client, i dispositivi di elaborazione e i sistemi di gestione dei dati.
A livello macroscopico, è possibile raffigurare un’architettura di edge computing come una struttura digitale distribuita e fortemente decentralizzata, assimilabile, secondo la società di analisi di mercato IDC, a “una rete di micro datacenter, in grado di elaborare e memorizzare dati critici localmente, e di trasmettere tutti i dati ricevuti e/o elaborati a un datacenter centrale o a un repository di cloud storage”.
In estrema sintesi, tale soluzione implementativa, anche sfruttando la disponibilità sul mercato a un costo sempre più accessibile di componenti e sistemi elettronici di piccole dimensioni (conosciuti come SFF o small form factor), mira a portare i dispositivi basilari di elaborazione, storage e networking quanto più vicino possibile alle fonti che materialmente generano i dati.
Per comprendere al meglio il quadro di riferimento, si pensi ad esempio al caso specifico delle auto a guida autonoma nel quale è necessario acquisire, inviare ed elaborare dati in poche frazioni di secondo per poter rispondere in tempo reale e senza ritardi a scenari anche freneticamente mutevoli, dai quali dipende l’incolumità fisica di diverse persone. È del tutto evidente come sia fondamentale superare problemi connessa alla latenza, alla mancanza di banda, all’affidabilità, non affrontabili in maniera efficiente attraverso il modello cloud convenzionale. In tali casi l’utilizzo di un’architettura basata su edge computing è sicuramente in grado di ridurre la mole di informazioni da scambiare, elaborando i dati critici, sensibili ai ritardi, direttamente nel punto di origine, tramite un dispositivo intelligente, oppure inviandoli a un server intermedio, localizzato nelle immediate vicinanze. Allo stesso tempo, però, sarebbe possibile trasmettere i dati meno critici all’infrastruttura cloud o al datacenter “classico”, per consentire elaborazioni più complesse, come l’analisi di big data, le attività di training per affinare l’apprendimento degli algoritmi di machine learning, l’archiviazione di lungo periodo, l’analisi delle serie storiche, etc.
Come è possibile intuire, pertanto, l’avvento di questa tecnologia potrebbe rivelarsi un fattore catalizzatore verso una trasformazione radicale dei datacenter, che dovranno adattarsi a un futuro in cui cloud, edge computing, IoT, big data, si integreranno tra loro con il fine di fornire servizi di nuova generazione probabilmente oggi solo lontanamente intuibili o percepibili.
Anche Crm ed Erp migrano verso datacenter remoti
Un ulteriore segnale della tendenza alla delocalizzazione dei sistemi informativi verso i grandi datacenter remoti, e in generale verso il cloud, è fornito da due particolari tipologie di software, universalmente diffusi in tutte le aziende di medio-grandi dimensioni a livello mondiale e conosciuti come Enterprise Resource Planning (ERP) e Customer Relationship Management (CRM).
Si tratta, invero, di due strumenti di natura gestionale e strategica che tradizionalmente sono stati installati presso le intranet delle imprese e che oggi, dopo aver rappresentato per decenni l’emblema dei programmi “privati” se non proprio “blindati”, stanno iniziando a migrare verso datacenter remoti per consentire alle aziende minori spese, maggiore efficienza e soprattutto la possibilità di estrarre informazioni a valore aggiunto dai propri dati grazie a tecniche di data mining, machine learning o business intelligence, più facilmente implementabili in ambienti integrati e dinamici come quelli dei grandi centri di elaborazione.
Per comprendere a pieno il ritmo travolgente con il quale la trasformazione in atto stia repentinamente cambiando le abitudini delle aziende, basti pensare che, secondo uno studio Panorama Consulting, in un solo anno, tra il 2017 e il 2018, le percentuali di ERM on premise e in cloud si sono letteralmente invertite: se infatti nel 2017 il 67% delle aziende aveva ancora il proprio “gestionale” in casa, nel 2018 praticamente lo stesso numero di aziende era incredibilmente passata alla modalità cloud. Sono dati veramente indicativi di una progressione irrefrenabile, che sta modificando anche le strategie commerciali dei produttori, ora quasi completamente orientate verso offerte di tipo SaaS.
Una situazione del tutto analoga si registra nel settore dei CRM dove, secondo stime di Gartner, nel 2019 sono stati spesi in tutto il mondo circa 42 bilioni di dollari in soluzioni cloud, pari a una percentuale del 72%.
Un ulteriore studio della prestigiosa società di consulenza strategica, ricerca e analisi nel campo della tecnologia dell’informazione individua tra i fattori che spingeranno sempre più aziende a migrare verso i datacenter remoti le grandi opportunità fornite dai provider cloud di introdurre elementi di intelligenza artificiale anche nel campo della gestione dei clienti, creando ad esempio servizi a valore aggiunto nel settore del customer care o dell’analisi predittiva degli acquisti e delle esigenze degli utenti finali.
Anche in questo settore, pertanto, l’era dei piccoli datacenter privati sembra volgere verso il suo fisiologico epilogo per lasciare strada alle grandi infrastrutture digitali allocate nelle “nuvole informatiche” o, come vedremo nella prossima sessione, a micro-datacenter altamente specializzati e in grado di analizzare in maniera super-performante dati, informazioni e segnali proveniente da una pluralità di fonti anche estremamente eterogenee.
Business continuity e disaster recovery nell’architettura di sicurezza dei datacenter
Alla luce del quadro descritto, è immediatamente comprensibile come nel processo di progettazione e implementazione di un datacenter sia assolutamente indispensabile prevedere, oltre ai sistemi di sicurezza, ridondanza e resilienza già citati, anche meccanismi di “secondo livello” in grado di innescarsi in caso di estrema necessità per garantire, anche a fronte di eventi disastrosi di media e grande entità, la prosecuzione delle attività vitali di un centro di elaborazione dati.
È necessario, preliminarmente, riflettere sulle possibili implicazioni della risposta a un evento potenzialmente dannoso che, almeno in linea di principio, ossia escludendo i cosiddetti “falsi allarmi”, è stato generato o comunque non mitigato anche a causa del fallimento della prima linea di difesa, costituita dai presìdi di sicurezza (quali, ad esempio, sistemi antiincendio, porte tagliafuoco, sonde antiallagamento, etc) progettati, implementati e messi in esercizio in base agli esiti delle attività di risk assessment e mappatura dei processi.
Ad esempio, cosa succederebbe se non risultasse possibile risolvere in breve tempo un incidente e quello che inizialmente si presentava, in forma figurata, come un “principio d’incendio” si propagasse fino a bloccare totalmente una parte o la totalità delle funzionalità di un Centro di elaborazione dati?
In altri termini, quale sarebbe, ad esempio, l’impatto di un intero armadio rack non più funzionante, della perdita totale della connettività verso internet, dell’impossibilità di accedere fisicamente a parte o addirittura a tutto lo stabile in cui sono allocati i dispositivi del Centro di elaborazione dati?
Ci troveremmo, in sostanza, di fronte a un disastro, potenzialmente in grado di bloccare l’intera attività del datacenter, creando, a cascata, disfunzioni e disagi anche gravissimi per tutta l’azienda e, di conseguenza, per una porzione più o meno estesa di utenti, clienti o stakeholder.
Quello appena descritto è il contesto di riferimento di due processi tra loro profondamente interconnessi che sono universalmente conosciuti come disaster recovery e business continuity e rappresentano la chiusura ideale del cerchio perfetto in cui deve essere racchiusa l’intera architettura di sicurezza per poter garantire, in maniera completa, armonica e uniforme, la tutela dell’integrità, della disponibilità e della riservatezza delle informazioni a vario titolo trattate all’interno di un datacenter.
Mutuando le definizioni fornite da ISACA, che rappresenta uno dei soggetti più autorevoli a livello internazionale nel settore della sicurezza delle informazioni, è possibile affermare che la “business continuity management” sia un processo strategico e tattico in grado di permettere a un’organizzazione di rispondere a qualunque avvenimento e interruzione delle attività che può avere impatto sui processi aziendali di core business, garantendo un livello di servizio minimo accettabile predefinito.
Per disaster recovery si intende, invece, l’insieme delle tecnologie e dei processi atti a ripristinare sistemi, dati e infrastrutture necessarie all’erogazione di servizi di “core business” a fronte di gravi emergenze (disastri).
Alla luce di quanto finora illustrato, è possibile affermare che la continuità operativa debba avere quale obiettivo di fondo quello di consentire ai soggetti interessati di usufruire del servizio richiesto allorquando ne abbiano effettivamente necessità, mitigando, di fatto, le vulnerabilità e le criticità maggiormente diffuse nei sistemi informativi, organizzativi e gestionali delle strutture di riferimento.
È necessario, a tal fine, definire in termini oggettivi e facilmente misurabili il concetto di continuità operativa all’interno del quale, in particolare, è fondamentale, in estrema sintesi, garantire che:
- le attività ritenute più importanti e critiche di un datacenter siano preservate anche in caso di eventi avversi, che possono manifestarsi sotto le più svariate forme e fenomenologie (business continuity);
- sia possibile ripristinare i servizi più importanti in un intervallo di tempo e a un livello qualitativo accettabili in seguito a una “interruzione critica” che non è stato possibile evitare (disaster recovery);
- siano messe a punto delle politiche e delle procedure che permettano di gestire in maniera adeguata, pianificata, razionale e tempestiva gli incidenti di sicurezza, prima che si trasformino in un disastro e che quindi inneschino le procedure di business bontinuity (Incident management).
Due sono, pertanto, le variabili da considerare e monitorare in base alle diverse esigenze e mission istituzionali di ogni organizzazione e, conseguentemente, di ogni centro di elaborazione dati:
- il tempo che una organizzazione può permettersi di attendere e che i portatori di interesse (clienti, azionisti, stakeholders) possono tollerare prima che i servizi vitali riprendano in seguito ad un disastro (la domanda da porsi in concreto è: quante ore/giorni possono trascorrere dal momento dell’interruzione forzata delle attività al tempo in cui è nuovamente possibile erogare e ricevere i servizi del datacenter?). Tale grandezza è generalmente chiamata Recovery Time Objective (RTO).
- il grado di aggiornamento delle informazioni da cui ripartire in caso di disastro (a quante ore/giorni anteriori all’evento dannoso devono risalire le informazioni in possesso dell’organizzazione?). Questa variabile condiziona, naturalmente, la periodicità delle operazioni di backup e viene universalmente chiamata Recovery Point Objective (RPO).
I piani di continuità operativa e disaster recovery, infine, se da un lato permettono a una azienda di garantire una razionale e organizzata risposta alle emergenze, dall’altro possono condurre a una condizione virtuosa in cui la maggior parte dei servizi non subisce interruzioni (Disaster avoidance).
