Nell’application delivery tutto ruoterà attorno a Kubernetes, ossia ai container, ai microservizi e agli strumenti di orchestrazione, perché il mondo dello sviluppo applicativo per il business sta marciando in questa direzione e non ha alcuna intenzione di fare retromarcia.
Questa è la sintesi, forte, ma significativa e concreta con cui a cui siamo giunti parlando con un esperto ultraventennale di application delivery per il business Carlo Baffé, sales director di SUSE Italia.
Baffé sa spiegarci, con parole semplici, il senso della trasformazione in atto nell’application delivery, che a ben guardare è anche il senso di implementare una struttura DevOps. O ancora, quello di consentire a un’azienda di essere parte attiva nel digitale interiorizzando una metodologia che mette in costante collegamento sviluppo applicativo e business.
In principio c’è l’applicazione
Postulato di questo modo di agire è la considerazione che oggi la cosiddetta digital transformation parte dal business, con processi e nuove iniziative.
Stiamo parlando di un’innovazione «che fai sostanzialmente se hai delle nuove applicazioni. I ragionamenti sulla infrastruttura che serve a sostenerle vengono dopo, non sono un problema».
Altra considerazione da cui far partire il ragionamento è la constatazione che «l‘utente oggi quando è al cospetto di un’applicazione è abituato a volere tutto e subito, velocemente e con performance, altrimenti non serve».
Tutto, subito e con performance elevate evoca il concetto di amazonizzazione del mondo delle applicazioni. In altri termini, «con il digitale devi fare tutto in fretta e il business è il primo a esser impattato». In questo quadro cambia soprattutto il fattore tempo, che si riduce sensibilmente.
La considerazione, il dato di fatto a cui fa riferimento Baffé, è la seguente: «se l’lT aziendale o il fornitore non consegnano l’applicazione in tempi rapidi, o il business cambia fornitore o si adatta a cercare sul mercato».
Ma attenzione, non è che ricorrendo al software as a service le cose cambino. Anche il modello SaaS, spiega Baffé ha dei limiti che oggi non possono essere superati: «è fatto per servire tanti clienti ed è ben lontano dall’offrire una customizzazione di massa, che è quello che serve alle aziende».
Addio ai vecchi cicli di sviluppo
Quindi dentro le aziende e presso i fornitori cambiano i paradigmi e i tempi di rilascio, che passano su base settimanale. Per fare le applicazioni che servono alle aziende, infatti, i vecchi cicli di sviluppo trimestrali non ci sono più.
Non solo. Una volta c’erano le applicazioni monolitiche. Quello che all’inizio del secolo era la novità delle Service Oriented Architecture, le Soa, ora è evoluto in un approccio metodologico che spezzetta le applicazioni in tanti piccoli servizi.
«Ora le applicazioni sono fatte da microservizi – spiega Baffé – che consentono di modificarla in fretta, cambiando un solo mattone o componente, o anche correggendolo mentre la stessa applicazione sta girando, senza fermarla».
Questo modello però impatta sulle infrastrutture: Anche le macchine virtuali hanno dei limiti. Ecco allora che sono apparsi i container (sopra, l’esempio di Docker).
Il container, spiega Baffé è quel poco di necessario che serve avere di un sistema operativo, quelle librerie che servono per far girare un microservizio, racchiuso in un runtime che consente a uno sviluppatore di creare il software sul suo computer, provarne il funzionamento e poter farlo girare ovunque.
Un modello ideale per rendere agile il processo di creazione delle applicazioni, che dà la possibilità di ascoltare e mettere in pratica le idee e le esigenze del business.
Una nuova idea, però, porta un nuovo problema, spiega Baffè: «se vanno in esecuzione centinaia di container contemporaneamente, serve automatizzare le operazioni».
Una piattaforma di container as a service
Ecco quindi che appare l’orchestratore dei container, ossia lo strumento che detiene la vera intelligenza dei sistemi basati su microservizi.
In questo ambito Il progetto open standard di riferimento, spiega Baffé, è Kubernetes. Detiene la vera intelligenza, spiega Baffé, perché consente di definire i container e le logiche di scalabilità prima di creare le applicazioni e ne orchestra la disposizione per ottenere i risultati che si chiede all’applicazione in termini di Service level agreement e di target di riferimento.
Un sistema che porta Baffé a dire che «la modalità di deployment delle nuove applicazioni sarà Kubernetes».
«Suse – spiega Baffé – si occupa di infrastruttura da ventisette anni. Ora fa application delivery con uno strumento che si chiama Caasp, Container as a service platform. Contiene Kubernetes, microOs, Helm per impacchettare applicazioni e altre componenti».
Si tratta, in sostanza, di semplificare lavoro delle operation, come avvenne in passato quando nelle aziende fu introdotto Linux con il modello open. Un paragone attinente: «Noi semplifichiamo tutto quello che è complicato – spiega Baffé -. E supportiamo l’infrastruttura in ottica sicurezza, proprio come si fa con Linux enterprise, garantendo il rilascio delle patch immediatamente, senza attendere che sia la comunità a occuparsene».
L’indicazione che Kubernetes non è una moda passeggera, ma che è qui per restare e cambiare il modo in cui si fa application delivery nelle aziende, per Baffé viene dai prodotti certificati, che oggi sono 60: «Pensiamo a Openstack, che però essendo infrastruttura è anche più complicato. Quando era hype aveva attorno a sé 10 player, tutti grandi. Oggi siamo rimasti in tre: Suse, Red Hat e Canonical».
La cultura di DevOps in pratica
Questa modalità di creazione di applicazioni aziendali non può che evocare la metodologia di DevOps.
Far parlare chi fa applicazioni con chi fa operations è ormai un obbligo: «un modello organizzativo improntato al dialogo – spiega Baffé -. Pensiamo a ITIL: era l’opposto, fatto di mille passaggi, suite, per fare una cosa che non comprendeva comunicazioni fra i soggetti.
Oggi se si vuole scalabilità rapida, DevOps apre le porte di una grande stanza dove chi fa sviluppo non pretende di dettar legge. Sviluppatori e sistemisti vengono messi in condizione di chiarire chi fa cosa e come si mette in esercizio. E i benefici sono quelli che chiede il business: sviluppo continuo e testato in automatico: continuous development, integration, delivery».
Per il partner consulente dell’azienda che deve fare application delivery questo è un lavoro di mediazione culturale, che mette insieme IT e operation per capire dove sta il valore in azienda, fare un progetto win-win e poi portarlo in tutta organizzazione.
Il ruolo dei partner
Il lavoro di divulgazione metodologica che richiede Suse spetta duqnue ai partner.
Sono tre quelli italiani: BS Company di Spilamberto (Modena), la milanese BGP Management Consulting e la torinese Emerasoft.
«Noi facciamo le tecnologie e i servizi post vendita», chiosa Baffé.
E sono gli stessi partner si occupano di servire il midmarket. Chi faceva investimenti sistemistici e ha capito che non può continuare così, o passa al public cloud oppure se vuole tenere la gestione e l’infrastruttura in casa passa al nuovo modello di application delivery, con un cluster Kubernetes.
