Paolo Arcagni, Systems Engineer Manager Italy&Malta di F5 Networks, ripercorre la storia dell’application delivery ed evidenzia cosa è realmente cambiato in 10 anni. Un dato certo nel mondo dell’IT è che i cambiamenti nelle architetture e nel deployment delle applicazioni hanno un impatto diretto sulla delivery applicativa (il processo vero e proprio atto a garantire che le applicazioni siano veloci, sicure e disponibili per i loro consumatori). I cambiamenti oggi introdotti dai micro-servizi, per esempio, sono significativi dal punto di vista di come cambiano le architettura di rete e i modelli di implementazione. Si potrebbe pensare che non spostarsi verso i micro-servizi, la tecnologia container e il cloud abbia comportato un’astrazione sempre più profonda rispetto alla rete rendendo le applicazioni meno dipendenti da essa. Se questo è vero dal punto di vista degli sviluppatori e, forse, anche delle operation, bisogna considerare che comunque ci sarà sempre bisogno di una rete; i dati scambiati devono poter ancora scorrere sui cavi e i servizi che risiedono nella rete sono ancora responsabili di molte funzioni che rendono le applicazioni veloci, sicure e ne garantiscono la disponibilità. Per questo motivo i cambiamenti nel dove e nel come le applicazioni sono sviluppate e rese disponibili si ripercuotono, necessariamente, su questi servizi, anche se l’applicazione non è a conoscenza della loro esistenza. Questo rapporto tra applicazioni e servizi ha ispirato una riflessione più profonda sui cambiamenti intercorsi negli ultimi dieci anni nel campo del deployment applicativo.
Architettura di deployment: dal prodotto alla piattaforma Partiamo dal 2005, quando i team che si occupavano della rete (NetOps) distribuivano i vari servizi necessari alla delivery delle applicazioni uno dopo l’altro in una linea continua. Si trattava di soluzioni per punti individuali. Se avevate bisogno di qualcosa per rendere un’applicazione più veloce, pensavate a un prodotto per l’ottimizzazione delle prestazioni web fornito in una sorta di pacchetto privato e personale. Un altro pacchetto per il bilanciamento del carico, un altro per la sicurezza applicazione, e così via. Alla fine c’erano lunghe file di molti “pacchetti”, ognuno delle quali doveva rappresentare il punto di un percorso in entrambe le direzioni.
Nel 2005 erano già nati i controller nella delivery applicativa (una tecnologia al tempo non completamente matura, in quanto introdotta solamente l’anno prima), che hanno iniziato il loro percorso di evoluzione verso quella che oggi definiamo una piattaforma. Queste piattaforme forniscono funzionalità ed elaborazioni comuni e possono essere estese con moduli (o plug-in o add-on o comunque si voglia chiamarli). L’approccio della piattaforma ha ridotto notevolmente il tempo speso “sul filo” in modo molto simile a come l’adozione di tecnologie a “container” e la virtualizzazione riducono oggi la quantità di tempo trascorso nello spostamento tra applicazioni e servizi. La piattaforma ha offerto anche la possibilità di ridurre i costi operativi attraverso la condivisione di una base comune – la piattaforma stessa – che normalizza la gestione tra i vari servizi oggi necessari per fornire un’applicazione. L’evoluzione da prodotto a piattaforma ha rappresentato un passaggio vantaggioso perché ha portato il deployment applicativo verso architetture maggiormente disponibili e separabili, sfruttando le tecnologie emergenti come i container e i micro-servizi e la distribuzione in ambienti cloud, che possono essere utilizzati per distribuire una vasta gamma di servizi applicativi, o solo uno, utilizzando lo stesso nucleo standardizzato. Tale approccio comporta spese amministrative minori, quando l’impatto dei servizi applicativi sviluppati cresce, e la possibilità di aggiungere servizi, quando aumentano le richieste di nuove applicazioni.
Metodologie di deployment: dal manuale al programmabile Nel 2005, le interfacce grafiche utente (GUI) web-based iniziavano a rappresentare un nuovo standard di utilizzo ma il metodo principale utilizzato per il provisioning e la configurazione dei servizi applicativi erano ancora le interfacce testuali (CLI). Questo processo, come tutti i processi manuali, richiedeva tempo e, mano a mano che i servizi applicativi diventavano più complessi, continuava a richiedere più tempo. I problemi dovuti a errori umani e le loro conseguenze (trovarsi in rete aumenta in modo esponenziale il raggio di esplosione degli errori di configurazione) comportavano a quel tempo una perdita ancora maggiore di tempo e risorse. Il copia e incolla era la tecnica utilizzata in prevalenza, ma anch’esso non è infallibile, e il sovraccarico amministrativo dei servizi di gestione era tale da garantire che solo le applicazioni più importanti potessero trarre vantaggio da questi servizi.
Arrivando rapidamente al 2015 e alla rivoluzione dei DevOps, la programmabilità – sia dal punto di vista delle API sia delle configurazioni basate su modello – sta cambiando tutto, anche nella rete. I servizi applicativi possono ora essere automatizzati tramite le API che utilizzano framework popolari come Puppet e Chef, pre-integrati con soluzioni di orchestrazione come Cisco APIC o VMware NSX. I modelli di servizio applicativo consentono oggi la standardizzazione, il riutilizzo e incoraggiano la visione dell’infrastruttura “come codice” per abilitare delle pratiche di delivery continua che si possano estendere nel network. In sintesi, l’application delivery si è evoluta (e continua ad evolvere) per supportare le opzioni di deployment programmabile che riducono il time to market attraverso un provisioning più rapido del servizio così come l’abbassamento dei costi operativi grazie all’automazione e al riutilizzo.
Aspetti della struttura di deployment: dal “big iron” alla virtualizzazione Nel 2005 l’obiettivo era costruire l’hardware di rete più grande, migliore e più veloce mai esistito. L’aumento delle velocità Ethernet e l’esplosione delle applicazioni web-based comportava un’espansione complementare della struttura fisica installata in rete per supportare i requisiti di servizio delle applicazioni.
Oggi l’attenzione si è spostata sulla densità e l’utilizzo ottimale delle risorse. Ciò significa virtualizzazione e cloud computing, entrambi supportati dalla virtualizzazione delle piattaforme di application delivery. Le piattaforme di application delivery sono ora in grado di essere distribuite in ambienti cloud come AWS, Microsoft Azure e Rackspace così come in appliance virtuali che possono essere distribuite su hardware pensati per scopi specifici o prodotti in serie. Questa capacità è un requisito indispensabile, non solo per supportare gli ambienti cloud, ma anche per adattarsi alle architetture emergenti come i micro-servizi. Tutto questo significa che molti dei servizi applicativi che entrano nel dominio di DevOps – il bilanciamento del carico, la sicurezza delle applicazioni e l’ottimizzazione, per esempio – devono oggi soddisfare i criteri di un data center software-defined. Molte piattaforme di application delivery oggi lo fanno e unite alle opzioni di deployment programmabile, sono pronte ad affrontare la sfida.
Responsabilità del deployment: dai tema di rete ai DevOps Nel 2005 – e in molte organizzazioni ancora oggi – il team di networking era totalmente responsabile del deployment e della gestione dell’application delivery. Ogni aspetto della distribuzione, dal procurement al provisioning fino alla configurazione era, e spesso è ancora, gestito dai responsabili delle operazioni di rete. Questo modello sconnesso però comporta ritardi nell’identificazione dei requisiti, nella creazione dei ticket e nella configurazione e provisioning manuali dei servizi applicativi richiesti per distribuire un’app. Questo è ancora il caso di molte organizzazioni, ma l’impatto del cloud e micro-servizi combinato con l’adozione delle metodologie DevOps sta cambiando lo scenario. Il desiderio di poter usufruire dell’IT as a Service è forte, con un trasferimento di responsabilità nella configurazione di servizi applicativi alle operation o addirittura ai team di sviluppo. Vi è la necessità di servizi applicativi maggiormente affini che siano fisicamente e logicamente collocati più vicino all’app. Questo mette i DevOps fermamente in una posizione di guida e responsabilità verso il provisioning e la configurazione di tali servizi.Questo non significa però che il team di networking non si occuperà più di distribuzione delle applicazioni. Esiste una parte significativa di problematiche legate alle applicazioni e di aspetti corporate che richiedono servizi applicativi erogati in modo più tradizionale, focalizzati sul raggiungimento dell’affidabilità piuttosto che dell’agilità. Tali servizi sono ancora, e probabilmente rimarranno, nel campo di responsabilità del team di rete mentre gli altri continueranno a spostarsi sempre più sotto la responsabilità dei DevOps.
In conclusione, la distribuzione delle applicazioni ha fatto moltissima strada negli ultimi dieci anni. Si è evoluta da una serie di prodotti a una piattaforma unificata, ha guadagnato la programmabilità e si è trasferita dal “big iron” al supporto degli hypervisor e alle implementazione nel cloud. Oggi sono le applicazioni mobile, i micro-servizi e i DevOps a cambiare radicalmente il modo in cui le applicazioni vengono progettate, implementate e distribuite, e mi aspetto di assistere a un’evoluzione continua proprio di quei servizi che ultimamente forniscono queste applicazioni e ne garantiscono la velocità, la sicurezza e la disponibilità.
