L'IoT e le tecnologie immersive spingeranno l'elaborazione delle informazioni maggiormentesull’edge. In tal modo ridefinendo e rimodellando ciò che i leader I&O dovranno implementare e gestire. L’edge è la posizione fisica in cui cose e persone si connettono al mondo digitale interconnesso in rete. L’infrastruttura tenderà sempre più verso l’edge.

A livello macroscopico un’architettura di edge computing si presenta come un’architettura IT distribuita e decentralizzata, ma più in dettaglio la società di analisi di mercato IDC la definisce come “una rete mesh di micro data center, in grado di elaborare e memorizzare dati critici localmente, e di trasmettere tutti i dati ricevuti e/o elaborati a un data center centrale o a un repository di cloud storage”.
In sostanza, questa topologia di rete, anche sfruttando la disponibilità sul mercato di componenti e sistemi elettronici SFF (small form factor) di costo decrescente, porta i componenti base di elaborazione, storage e networking più vicino alle fonti che generano i dati. Il caso d’uso tipico è, appunto, quello dei dispositivi e delle implementazioni IoT, che spesso devono fronteggiare problemi di latenza, mancanza di banda, affidabilità, non indirizzabili attraverso il modello cloud convenzionale:
qui l’architettura di edge computing è in grado di ridurre la mole di dati da inviare nel cloud, elaborarando i dati critici, sensibili alla latenza, nel punto di origine, tramite uno smart device, oppure inviandoli a un server intermedio, localizzato in prossimità;
i dati meno ‘time-sensitive’ possono invece essere trasmessi all’infrastruttura cloud o al data center dell’impresa, per consentire elaborazioni più complesse, come l’analisi di big data;
le attività di training per affinare l’apprendimento degli algoritmi di machine learning (ML);
lo storage di lungo periodo;
l’analisi di dati storici.

Studi di mercato prevedono che entro il 2025 l'80% delle organizzazioni migrerà interamente dai data center on-premise.
L’attuale tendenza di spostare i carichi di lavoro su colocation, hosting e cloud, porta a chiudere il tradizionale data center.

 

La rete è alla base di tutto ciò che fa l'IT: servizi cloud, Internet of Things, servizi edge e così via.
E continuerà a esserlo anche andando avanti. Le richieste sul network sono destinate a crescere con l'avvento del 5G, la crescita di maturità del cloud e l'esplosione del numero di dispositivi IoT.

La Network Agility è una disciplina architettonica per reti di computer. Può essere definito come:
La capacità del software e dell'hardware di rete di controllare e configurare automaticamente se stesso e altre risorse di rete su qualsiasi numero di dispositivi su una rete.
Per quanto riguarda l'hardware di rete, l'agilità di rete viene utilizzata quando ci si riferisce alla configurazione hardware automatica e alla riconfigurazione dei dispositivi di rete, ad es. router, switch, dispositivi SNMP.

L'agilità di rete, come disciplina del software, prende in prestito da molti campi, sia tecnici che commerciali.
Dal punto di vista tecnico, le soluzioni di agilità di rete sfruttano tecniche di aree come:

• Architettura orientata ai servizi (SOA)
• Design orientato agli oggetti
• Modelli architettonici
• Streaming di dati liberamente accoppiati (ad es .: servizi web)
• Design iterativo
• Intelligenza artificiale
• Programmazione induttiva
• Calcolo on-demand
• Utility computing

Commercialmente, l'agilità di rete riguarda la risoluzione di problemi aziendali reali utilizzando la tecnologia esistente. Forma un ponte a tre vie tra processi aziendali, risorse hardware e risorse software. Più in dettaglio, prende come input:

• i processi aziendali - cioè ciò che la rete deve raggiungere in termini di business reali;
• l'hardware che risiede all'interno della rete; e
• il set di risorse software che girano su questo hardware.

Gran parte di questo input può essere ottenuto attraverso la ricerca automatica - la ricerca dell'hardware, i suoi tipi e posizioni, software, licenze, ecc. I processi di business possono essere dedotti in una certa misura, ma sono questi processi che i manager aziendali devono essere in grado di controllare e organizzare.

Le risorse software scoperte sulla rete possono assumere una varietà di forme: alcune risorse possono essere prodotti software con licenza, altri come blocchi di codice di servizio software a cui è possibile accedere tramite qualche portale di servizi aziendali, ad esempio (ma non necessariamente) servizi Web.
Questi servizi possono risiedere internamente o essere "on-demand" tramite un servizio di abbonamento online. In effetti, la motivazione principale dell'agilità di rete consiste nel rendere l'uso più efficiente delle risorse disponibili, ovunque risiedano, e nell'identificare aree in cui gli obiettivi dei processi aziendali non sono soddisfatti per alcuni livelli di riferimento (e idealmente per offrire possibili soluzioni).

Gli strumenti di agilità di rete sono quindi in grado di ottimizzare l'hardware esistente per eseguire le risorse software necessarie per raggiungere gli obiettivi del processo di business. Poiché l'utilizzo della rete non è mai lineare, i requisiti del mix hardware / software cambieranno dinamicamente in vari segmenti temporali (settimanali, trimestrali, annuali ecc.)
E le modifiche dei passaggi saranno richieste di volta in volta quando gli obiettivi del processo aziendale cambiano / evolvono / sono aggiornato (ad esempio durante / dopo una riorganizzazione aziendale).

I vantaggi per il business dell'approccio di agilità della rete sono ovvi: risparmi sui costi nelle licenze software e maggiore efficienza delle risorse hardware, il che porta a una migliore produttività.

Il serverless computing è un pattern emergente di architettura software che promette di eliminare la necessità di provisioning e gestione dell'infrastruttura.
I responsabili I&O dovrebbero adottare un approccio “application-centric” per il serverless computing, mediante la gestione di API e SLA, piuttosto che di infrastrutture fisiche.
Il serverless non sostituisce i container o le macchine virtuali, quindi è fondamentale imparare come e dove usare al meglio tale tecnologia.

È bene chiarire che siamo nell’ambito del cloud computing. Com’è noto tre sono i modelli di cloud computing principali, che si differenziano per il diverso livello di controllo, la flessibilità e la gestione delle risorse:

• Infrastructure as a Service (IaaS), che ingloba gli elementi fondamentali di base dell’infrastruttura, tra cui aspetti di rete, macchine (virtuali o su hardware dedicato) e storage.
• Platform as a Service (PaaS), con cui ci si svincola dalla gestione dell’infrastruttura sottostante (hardware e sistemi operativi) in modo da concentrarsi sulla distribuzione e sulla gestione delle applicazioni. Con questo modello non è più necessario dedicarsi all’approvvigionamento delle risorse, la manutenzione del software, l’applicazione di patch ecc.
• Software as a Service (SaaS) che offre infine una piattaforma completa gestita dal provider di servizi e permette agli utenti di concentrarsi sul livello applicativo.

Negli ultimi anni si è assistito all’evoluzione dei modelli appena descritti. Sono dunque nati ulteriori paradigmi di gestione ed utilizzo delle risorse: uno di questi è il cosiddetto Function as a Service (Faas), detto anche serverless computing.

Il serverless computing  è un paradigma di elaborazione cloud che permette l’esecuzione di applicazioni senza preoccuparsi dei problemi legati all’’infrastruttura sottostante.
Il termine “serverless” potrebbe essere fuorviante: si potrebbe infatti pensare che questo modello non preveda l’utilizzo di server per l’elaborazione. In realtà sta ad indicare che il provisioning, la scalabilità e la gestione dei server su cui le applicazioni sono eseguite sono amministrati in automatico, in maniera completamente trasparente per lo sviluppatore. Il tutto è possibile grazie a un nuovo modello di architettura, detta appunto serverless.
Il primo modello di FaaS risale al rilascio del servizio AWS Lambda nel 2014, da parte di Amazon. Con il tempo alla soluzione di Amazon si sono aggiunte ulteriori alternative, sviluppate da altri grandi vendor, come Microsoft, con le sue Azure Functions, e da IBM e Google, con le proprie Cloud Functions.

Esistono inoltre valide soluzioni open-source: tra le più utilizzate, abbiamo Apache OpenWhisk, usata dalla stessa IBM su Bluemix per il proprio serverless offering, ma anche OpenLambda e IronFunctions, quest’ultima basata sulla tecnologia dei container di Docker.

Cos’è una Function?

Una function contiene del codice che uno sviluppatore vuole venga eseguito in risposta a determinati eventi. Lo sviluppatore si preoccupa di configurare tale codice e specificare i requisiti in termini di risorse, all’interno della console del fornitore di riferimento. Tutto il resto, compreso il dimensionamento delle risorse, è gestito in modo automatico dal provider, in base al carico di lavoro richiesto.

Quali sono i vantaggi di questo approccio rispetto al cloud computing tradizionale? Come mai si è sentita l’esigenza di optare per un nuovo modello di computazione?

I benefici derivanti dal serverless computing sono molteplici:

• Nessuna gestione dell’infrastruttura: gli sviluppatori possono concentrarsi sul prodotto da realizzare piuttosto che sul funzionamento e sulla gestione dei server a runtime.

• Scalabilità automatica: le risorse vengono ricalibrate in modo automatico per far fronte a ogni tipo di workload, senza richiedere una configurazione per lo scaling, ma reagendo agli eventi in real-time.
• Ottimizazione dell’uso delle risorse: dato che le risorse di elaborazione e di storage vengono allocate dinamicamente, non è più necessario investire in capacità in eccesso preventivamente.

• Riduzione dei costi: nel cloud computing tradizionale, è previsto il pagamento delle risorse in esecuzione anche quando queste non vengono effettivamente utilizzate. Nel caso serverless, le applicazioni sono event-driven, per cui quando il codice dell’applicazione non è in esecuzione, non viene addebitato nessun costo, quindi non è necessario pagare per risorse inutilizzate.

• Alta disponibilità: I servizi che gestiscono l’infrastruttura e l’applicazione garantiscono elevata disponibiità e tolleranza ai guasti.

• Miglioramento del Time-To-Market: L’eliminazione degli oneri di gestione dell’infrastruttura permette agli sviluppatori di concentrarsi sulla qualità del prodotto e di portare il codice in produzione più velocemente.

Possibili problemi e limiti

Come sempre, non è tutto oro quel che luccica. Ci sono dei contro da tenere in considerazione quando si valuta l’adozione di questo paradigma:

• Possibile perdita di performance: se il codice non viene utilizzato molto frequentemente, potrebbero verificarsi problemi di latenza nella sua esecuzione, rispetto al caso in cui risulta in continua esecuzione su un server, una virtual machine o un container. Ciò accade perché, contrariamente a quanto si verifica utilizzando politiche di autoscaling, con il modello serverless il cloud provider spesso dealloca completamente le risorse se il codice non è utilizzato. Questo implica che se il runtime richiede un certo tempo per l’avvio (si prenda per esempio JRE), si crea inevitabilmente latenza aggiuntiva nella fase iniziale di start.
• Assenza di stato: le funzioni serverless operano in modalità stateless. Questo significa che se si vuole aggiungere una logica di salvataggio di alcuni elementi, ad esempio dei parametri da passare come argomenti a una funzione differente, occorre aggiungere un componente di storage persistente al flusso dell’applicazione, e legare gli eventi tra loro. In questo caso, Amazon mette a disposizione un ulteriore strumento, chiamato AWS Step Functions, atto a coordinare e gestire lo stato di tutti i microservizi e componenti distribuiti delle applicazioni serverless.
• Limite alle risorse: il serverless computing non è adatto ad alcuni tipi di workload o casi d’uso, in particolare a quelli ad elevate prestazioni, sia per i limiti sull’uso delle risorse che vengono imposti dal cloud provider (per esempio AWS limita il numero di esecuzioni concorrenti delle Lambda functions), sia per la difficoltà nel provisioning del numero di server desiderati in un arco temporale limitato e fissato.
• Debugging e monitoring: se ci si affida a soluzioni non open-source, gli sviluppatori dipenderanno dai vendor per quanto riguarda il debugging e il monitoring delle applicazioni, e non riusciranno pertanto a diagnosticare nel dettaglio eventuali problemi tramite l’utilizzo di ulteriori profilers o debuggers, dovendo affidarsi agli strumenti messi a disposizione dai rispettivi provider.

I file .htaccess, che per comodità chiameremo solo htaccess, sono dei semplici file di testo contenenti le direttive di apache per la configurazione. Questi file possono essere editati con un normale editor di testo come notepad o context su windows, mentre su linux, ad esempio, con vi, nano o mcedit. 

Ecco come come funziona 

I file htaccess di apache funzionano in maniera estramente semplice: apache quando riceve una richiesta, prima di eseguirla, verifica se esiste un file htaccess nella cartella del file richiesto o in una cartella precedente, ed in caso lo legge e lo interpreta a run-time e si configura in modo da rispettare le direttive presenti all'interno di quel file. È molto importante notare che apache ricarica il file ad ogni richiesta in modo non dover essere riavviato in caso di modifiche, com'è invece necessario se viene modificato il file di configurazione principale.