Come stanno evolvendo le infrastrutture che erogano servizi e applicazioni nell’attuale transizione del mercato ICT e nel panorama della trasformazione digitale? Possiamo ottenere un riscontro tecnologico significativo, analizzando l’evoluzione dell’offerta delle componenti del Data Center che un tempo prendevano semplicemente il nome di “load balancer”.
Come migliorare la Governance applicativa con gli ADC
Tradizionalmente un dispositivo di bilanciamento del carico è situato tra il firewall e la server farm, per gestire l’accesso alle applicazioni, garantendo funzioni di bilanciamento, accelerazione tramite meccanismi di caching, ottimizzazione delle elaborazioni di cifratura delle connessioni e firewall di livello applicativo. Nel corso del tempo, tali dispositivi hanno assunto compiti addizionali rispetto al semplice indirizzamento del traffico per distribuirlo bilanciandolo verso i server. Hanno quindi assunto anche una denominazione più completa, appunto ADC, controller di delivery delle applicazioni.
Ma non è tutto: non si tratta soltanto di osservare la loro evoluzione in termini di funzioni addizionali, poiché è il contesto in cui si trovano oggi ad operare che evolve e insieme con esso, la tecnologia degli ADC.
Se vogliamo considerare i principali “vendor” che offrono prodotti e soluzioni in questo segmento di mercato troviamo infatti già una distinzione tra i produttori di tecnologie più tradizionali ed i nuovi player, cionondimeno possiamo osservare anche tra quelli tradizionali nuove soluzioni, quando non addirittura acquisizioni dei nuovi player (e nuove tecnologie) da parte loro.
In questo senso, una prevalente distinzione si applica ai prodotti basati solo sul software verso quelli tradizionali, tra i primi si possono citare i più rilevanti:
- Avi Networks (ora acquisita da VMware)
- Kemp Technologies
- Nginx (ora acquisizione di F5)
- Pulse Secure (prodotto derivante dall’acquisizione della soluzione Brocade)
- Snapt
Tra i più tradizionali, tra gli altri, ricordiamo i seguenti, anch’essi comunque in evoluzione, con soluzioni orientate all’implementazione software ed attraverso acquisizioni tecnologiche:
- A10
- Barracuda
- Citrix
- F5
- Radware
Come cambia l’application delivery con l’ADC
Come cambia l’application delivery con l’ADC
Possiamo operare una distinzione tra le soluzioni software centriche – più indicate a seguire le evoluzioni delle infrastrutture di computing, in particolare articolate attraverso il cloud, le macchine virtuali e i container – e le implementazioni tradizionali, collocabili in contesti di gestione di applicazioni classiche in data center privati.
Leggendo pertanto il cambiamento nelle tecnologie di gestione delle funzioni di application delivery, risulta evidente l’analogo cambiamento nelle modalità di erogazione delle applicazioni e nella diversificazione delle piattaforme che le erogano, che abbiamo infatti appena citate: macchine virtuali, cloud, container. L’elemento ADC in queste nuove architetture è un anello fondamentale della catena di erogazione dei servizi. Si combina con parti dell’infrastruttura altresì in evoluzione, come lo sono le componenti di networking e security.
È pertanto questa una delle ragioni per cui diventa estremamente interessante comprendere il segmento di mercato in cui si collocano gli ADC, poiché sono parte di un nuovo modo di erogare servizi e la loro presenza all’interno di un progetto non rappresenta che uno dei tanti elementi significativi di cui occuparsi in fase di progettazione delle attività di System Integration.
Evoluzione IT e “nuovi” workload
Evoluzione IT e “nuovi” workload
Seguire i “workload” per capire dove e come vengono gestiti dà un indicatore utile da valutare. Alcuni analisti infatti sostengono che: “Oggi vediamo sempre più spesso workload in più posti, a differenza del passato, quando singole grosse applicazioni disponevano nel loro contesto di tutto ciò che serviva per girare”; ed ancora: “Oggi i workload sono più ridotti, specialmente se basati sui containers, ed in termini di servizi di delivery, necessitano di ADC ma non con le stesse funzionalità di prima”.
Nel contesto di un progetto di system integration, ove si collocano scelte progettuali di selezione delle tecnologie e sviluppo dei servizi basati sulla formazione delle competenze, è fondamentale comprendere le sfide che vengono lanciate dalla maturazione di nuove esigenze esposte dai clienti, individuando nel panorama d’offerta disponibile le soluzioni più adatte a rispondere adeguatamente a tali necessità. Capire altresì le strategie di prodotto che il mercato tecnologico definisce attraverso l’offerta di nuove soluzioni per rispondere alle nuove esigenze di gestione dei workload e di integrazione nelle varie architetture tecnologiche: Cisco, VMware, Docker, Kubernetes.
Integrazioni CISCO e AVI: come rendere più dinamiche le infrastrutture
Integrazioni CISCO e AVI: come rendere più dinamiche le infrastrutture
Per fare un esempio concreto prendiamo in considerazione, tra le tecnologie Cisco, la piattaforma CSP (Cloud Service Platform) che costituisce un sistema integrato di realizzazione di appliance con hardware Cisco e software ADC AVI.
Allo stesso modo l’integrazione AVI con la piattaforma ACI di Cisco, così come nel caso di F5, A10, Citrix, permette di realizzare l’infrastruttura della rete del DC nelle logiche delle architetture SDN, integrando i servizi di application delivery.
Citare SDN porta immediatamente alla mente l’esigenza di dinamicità delle infrastrutture per l’erogazione di workload, per la quale questo tipo di architettura nasce. In questo contesto si collocano funzionalità di:
- Software Load Balancer,
- Intelligent Web Application Firewall
- Elastic Service Mesh
Quando si cominciano ad analizzare tali funzionalità si entra nel merito dell’articolazione dell’architettura, quindi nel progetto di system integration che si sviluppa in logiche più ampie rispetto all’individuazione di un prodotto e delle sue funzioni.
Ipotizziamo ad esempio, un progetto per la creazione di un sistema multi-tenant, self-service con un’infrastruttura automatizzata dal layer 2 al layer 7. L’integrazione tra la soluzione SDN di Cisco ACI e la piattaforma ADC selezionata, l’automazione ed il livello di interazione tra i software di provisioning e le piattaforme di erogazione del servizio devono offrire il massimo grado di funzionalità, così da evitare di dover applicare configurazioni manuali. L’applicazione delle policy di funzionamento dell’ambiente operativo per l’erogazione dei servizi deve avvenire nella logica end-to-end, per ottimizzare la gestione del ciclo di vita delle applicazioni gestite. Il controllo del provisioning deve pertanto essere centralizzato rispetto agli elementi di implementazione dell’infrastruttura, permettendo l’operatività self-service e per tenant. Inoltre, l’elasticità nell’allocazione del servizio lo rende adeguato alle necessità di utilizzo della piattaforma applicativa, permettendo l’erogazione della prestazione ottimale che garantisce un’adeguata esperienza dell’utilizzatore.
La soluzione incentrata su AVI Networks e Cisco ACI nasce sulla base di una natura complementare delle due tecnologie, con un’unica linea di approccio architetturale che utilizza un singolo punto di controllo, gestione e automazione per gli elementi della rete del data center, aderendo alle specifiche definite dalle policy di funzionamento.
AVI Networks pone al centro della propria architettura di servizio distribuita, su cui si fonda la propria tecnologia ADC, HYDRA: Hyperscale Distributed Resources Architecture, basandola sui principi di funzionamento SDN. Fondamentale in quest’ottica la separazione dei piani operativi dei dati dalle funzioni di controllo, (control-plane vs. data-plane), come evidenziato nella figura seguente dagli elementi Controller e Service Engine.
Da un punto di vista realizzativo, AVI Networks propone un ADC basato su software che gira su server x86. La centralizzazione delle funzioni di controllo permette di ottenere un data plane scalabile secondo i modelli scale-out, di governare centralmente la multi-tenancy e permettere le operazioni self-service, implementando i servizi, quali load balancing, application firewalling e acceleration. Consente attraverso il proprio engine inline di erogare funzioni di analisi L4-L7 per garantire visibilità sui servizi erogati in modo complementare alle funzioni di analisi L2-L3 della piattaforma Cisco ACI. L’integrazione tra i controller Cisco APIC e AVI avviene tramite interfaccia REST, così da poter importare le informazioni relative ai Tenant configurati tramite APIC e registrare verso l’APIC i dispositivi ADC.
Nell’APIC viene creato l’apposito template di service graph per collegare End Point Group e ADC da utilizzare nella definizione dell’apposito contratto tra gli EPG. Questa definizione viene acquisita tramite la gestione del controller AVI dove, creando il servizio virtuale riguardante l’applicazione, vengono rilevate le definizioni di service graph e contratto inserite tramite l’APIC. Questa integrazione delle informazioni è dinamica, ad esempio se nel EPG tramite APIC vengono aggiunti o rimossi i server che erogano l’applicazione, tale modifica si riflette dinamicamente nella configurazione del pool del servizio definito tramite il controller AVI. A questo punto la configurazione che determina l’avvio dei service engine, sotto forma di macchine virtuali, viene comunicata al hypervisor per l’avvio delle relative VM, su cui viene applicata la policy di load balancing desiderata e via REST viene comunicata all’APIC la configurazione necessaria a stabilire la connettività.