Come far dialogare progettisti e sviluppatori con i network engineers? Usate Cisco ACI.
In passato sono stato un Enterprise Architect e ho guidato la progettazione e lo sviluppo di molti sistemi software complessi. Quando eravamo nella fase di acquisizione e, poi, di costruzione dei vari ambienti (sviluppo, test, collaudo, produzione), spesso ero infastidito dalle riunioni con i responsabili dell’infrastruttura.
Tutto ciò di cui io avevo bisogno era una certa quantità di memoria e di potenza di calcolo, che calcolavo in base al carico previsto. Poi avevo bisogno di connettività tra le diverse componenti dell’architettura applicativa (un cluster di web server, un cluster di application server, uno o più database e alcuni sistemi preesistenti), più qualche servizio come i bilanciatori di carico.
I responsabili dei sistemi e della sicurezza volevano discutere invece una lunga lista di requisiti e di configurazioni: vlan, ip address, subnet, firewall, quality of service, access list: tutti punti che non mi interessavano granché.
Io ero interessato solo ai livelli logici (tier) dell’applicazione, alle dipendenze, lo SLA, le performance complessive e alla compliance e volevo discutere queste cose nel mio linguaggio, non nel loro slang alieno.
Come i responsabili dei sistemi vedono il mondo (un numero di apparati con la loro configurazione):
Come io vedo il mondo (un numero di server con il loro ruolo nell’applicazione). Potremmo chiamarli gli End Point:
La comunicazione può essere descritta come un contratto, offerto da alcuni end point, consumato da altri e salvato come una policy riusabile, che può essere applicata a diversi End Point Group:
Eventualmente, si possono aggiungere servizi di rete come i load balancer o i firewall (creando un service graph):
Potete facilmente intuire che le nostre riunioni non fossero proprio semplici.
Non era colpa loro (e tanto meno mia). Vedevamo solamente il mondo da diversi punti di vista, o forse con occhiali differenti.
Per le persone che lavorano con il software astrarre la topologia del deployment è essenziale. Per i sistemisti il dettaglio della configurazione è fondamentale e hanno bisogno di conoscere che tipo di traffico deve passare per progettare bene il sistema.
Avere un insieme di policy che descrive il comportamento desiderato renderebbe la conversazione più semplice.
Dopo lunghe discussioni e – a volte – escalation, la configurazione dell’ambiente richiesto non era mai veloce come ci sarebbe piaciuto. Non erano ancora i tempi di DevOps, tuttavia cercavamo di rilasciare frequentemente nuove versioni del software per una prototipazione rapida e ottenere dei risultati tangibili in corso d’opera (i famosi quick win).
Immaginiamo ora di essere riusciti a metterci d’accordo sulla definizione delle policy.
Avere un’applicazione immediata di queste policy su tutti gli apparati di rete senza doverli configurare uno a uno, in un modo coerente che escluda l’errore umano e garantisca la compliance per default, e averlo immediatamente sarebbe una specie di magia.
Adesso esiste un’architettura di rete che rende possibile questa magia: si tratta di Cisco ACI (Application Centric Infrastructure). Un unico controller software (ridondante, naturalmente) gestisce tutta la connettività di rete, la security e i servizi di rete come load balancer e firewall.
La rete è un fabric hardware, con grandi performance, scalabilità e affidabilità e che si estende facilmente fino alle reti virtuali di ogni vendor o alle soluzioni open source per applicare le policy ai server fisici e alle VM, visti come end point senza alcuna differenza.
Il controller (che si chiama APIC) ha una GUI ma, soprattutto, un ricco insieme di open API che possono essere invocate dai vostri script, da strumenti di orchestrazione di Cisco o terze parti, da qualsiasi CMS (cloud management system). Da qui si possono creare le policy, ma anche vedere la “telemetria” della rete con una visualizzazione facile dello stato di salute dell’intero fabric o delle singole applicazioni individualmente.
Alla fine, quali vantaggi si ottengono da ACI?
Gestione centralizzata dell’automazione basata sulle policy
– Soluzione olistica orientata alle applicazioni che fornisce flessibilità e automazione per un IT agile
– Deployment e configurazione automatica del fabric con un singolo punto di management
– Automazione dei compiti ripetitivi, riducendo gli errori di configurazione
Sicurezza End-to-End completa e open
– Open API, open standard e elementi open source che abilitano la flessibilità dei team DevOps per il software, e integrazione di firewall e application delivery controller (ADC) dei partner
– Cattura automatica di tutte le modifiche alla configurazione, integrata con le soluzioni esistenti per audit e compliance tracking
– Role-based access control (RBAC) dettagliato, con una segmentazione del fabric estremamente granulare
Visibilità in Real-Time e Health Score per ogni applicazione
– Monitoraggio centralizzato real-time dello stato di salute delle reti fisiche e virtuali
– Visibilità istantanea delle performance delle applicazioni combinata con decisioni intelligenti di allocazione
– Troubleshooting più veloce per le operazioni in esercizio
Agilità per le applicazioni
– Gestione del ciclo di vita delle applicazioni dallo sviluppo al deployment, al decommissioning in pochi minuti
– Deployment automatico delle applicazioni e provisioning rapido basato su profili predefiniti
– Delivery continuo e rapido di applicazioni virtualizzate e distribuite
Perché adesso i due team riescono a parlarsi?
Grazie al policy model introdotto da Cisco ACI è molto più facile rappresentare (anche graficamente) i requisiti di comunicazione tra le componenti di un’applicazione distribuita.
Si può fare riferimento a policy predefinite (dai responsabili dei sistemi) che vengono riutilizzate, garantendo la compliance con le regole aziendali (e quindi sicurezza, affidabilità e gestibilità).
I sistemisti si sentono tranquilli, avendo delimitato il campo, e possono offrire il valore della propria esperienza senza dover inventare una soluzione ad hoc per ogni progetto. Le loro policy diventano mattoncini da costruzione (come quelli del Lego) offerti all’architetto della soluzione complessiva.
Il progettista del software è ben felice di adottare un modello più facile da capire e di lavorare – quasi – in modalità self service, abbreviando il percorso verso il deployment dell’intero sistema. Inoltre il passaggio attraverso gli ambienti di sviluppo, test e produzione può essere, volendo, automatizzato.
Se devono fare una riunione per discuterne, il linguaggio è ora alla portata di entrambi i team e non richiede il sacrificio di una delle due parti.
Documentazione di prodotto
ACI Marketing page
ACI at a glance
ACI in one page
Application Centric Infrastructure (ACI) Documentation
Cartoons (2 min. ciascuno)
2015 ACI Video Episode 1: An Impossible Deadline
2015 ACI Video Episode 2: The Needle in the Haystack
2015 ACI Video Episode 3: Operation Clean Up
