I service providers NON sono grandi aziende

Sento spesso parlare di nuove soluzioni di virtualizzazione, siano essere relative a software di orchestrazione, piuttosto che prodotti storage, networking, servers o altro, da parte dei vari produttori che le realizzano, e una delle frasi che sento solitamente è “questo prodotto è pensato per le grandi aziende E i service providers”. L’idea di fondo, nelle intenzioni di chi ipotizza questi due casi d’uso per i propri prodotti, è che una grande azienda è del tutto paragonabile a un service provider. A un primo approccio, il ragionamento è corretto, ma vi è una sostanziale differenza che in ultima analisi rende questo ragionamento una forzatura.

Le dimensioni contano

Sicuramente, uno dei motivi che porta ad associare grandi aziende e service provider sono le dimensioni. Un’azienda che eroga servizi a 10.000 dipendenti non è molto differente per dimensioni da un service provider che ospita virtual machines il cui numero complessivo di utenti è il medesimo: in entrambi i casi avremo 10.000 caselle di posta, 10.000 accessi ai siti web, 10.000 login ai file servers aziendali, e così via.
Se i workloads in esecuzione hanno le stesse dimensioni e richieste di prestazioni, l’infrastruttura necessaria per eseguirli sarà paragonabile.

Ci sono poi altre caratteristiche, che in ambienti di grandi dimensioni sono comuni: una su tutte l’automazione. Non è pensabile gestire ambienti con migliaia di server e virtual machine senza un qualche strumento di automazione. Che sia Puppet, Chef o altri strumenti più o meno noti (tra cui alcuni guarda caso nati per le grandi aziende e riconvertiti per asservire anche  service provider), queste soluzioni diventano letteralmente vitali quando si supera una certa dimensione, dato che soprattutto quello che cambia è il rapporto tra numero di sistemi da gestire e numero di persone che le gestiscono. Tanto che l’efficienza di un ambiente di grandi dimensioni viene anche misurato in base al rapporto sysadmin:server.

Tutto sotto controllo?

Verrebbe quindi da pensare che l’accostamento tra queste due entità sia tutto sommato corretto. In gran parte è vero, ma c’è almeno UN elemento che le differenzia in modo totale, e che spesso molti vendor ignorano, o fanno finta di ignorare: gli utenti, e il modo in cui usufruiscono delle risorse che sono messe a loro disposizione.

In una grande azienda, per quanto di dimensioni ciclopiche, è possibile con oramai un’ottima approssimazione, prevedere i ritmi di crescita dell’infrastruttura informatica, e progettare quindi conseguentemente la stessa. Tutte le richieste dei vari dipartimenti vengono valutate, analizzate, e in ultima analisi tradotte in una soluzione infrastrutturale che tra le varie caratteristiche prevede anche un capacity plannin, nel quale è stato valutato il ritmo di crescita che la soluzione dovrà avere.

In un service provider, almeno quelli di certe dimensioni, una volta che un utente (o cliente) ha ottenuto accesso al servizio, non vi è un modo diretto e preciso di sapere cosa verrà messo in esercizio, in termini di potenza di calcolo od occupazione sullo storage ad esempio. A meno di non imporre a priori limiti alla crescita di un cliente (e benchè viene spesso fatto, questo va in ultima analisi contro lo spirito del servizio), in ogni momento un cliente ha la possibilità di creare nuovi workload secondo necessità.

Prendiamo un esempio semplice: per un nuovo progetto di e-commerce, l’utente deve realizzare su un’infrastruttura virtualizzata un classico ambiente a tre livelli composto da database, application server e web server. Se l’utente è una divisione di una grande azienda, contatterà il proprio reparto IT per discutere e progettare insieme questa soluzione, in modo da avere la garanzia che le risorse infrastrutturali necessarie siano disponibili. Se però l’utente è il cliente di un service provider, non farà altro che collegarsi al servizio e iniziare a creare le virtual machine necessarie. In poco tempo, il provider potrebbe ritrovarsi con 50 nuove virtual machines e 10 TB di spazio disco occupato.

Capacity Planning vs Design to Scale

Va da se che il metodo con cui le due realtà vengono progettate deve essere completamente differente. Per un service provider, non vi è niente di più doloroso di un cosiddetto “forklift upgrade”: quel momento in cui un sistema non è più espandibile, e l’unico modo per espandersi ulteriormente è la sua sostituzione totale con un altro sistema. Se si tratta in particolare di sistemi storage, questo vuol dire soprattutto dover migrare tutti i dati contenuti nel vecchio sistema verso quello nuovo, con tutta una serie di problemi da risolvere per portare a termine la migrazione.

In una grande azienda, benchè si possano comunque adottare design in grado di eliminare o limitare i forklift upgrade, un aggiornamento di un componente è meno traumatico, in quanto appunto il controllo dei workload permette innanzitutto di progettare un’infrastruttura che abbia una vita utile almeno pari al ciclo di vita dei vari componenti, sia perchè la pianificazione della migrazione è “gestibile”: coinvolgendo i vari reparti impattati dall’aggiornamento, è possibile pianificare i fermi ad esempio, e procedere all’aggiornamento.

In un service provider, benchè sia comunque possibile questo tipo di aggiornamento, lo stesso dovrebbe avvenire senza che esso venga avvertito dal cliente, e in ultima analisi senza impattare lo SLA che è stato contrattualizzato. Non è impossibile, ma sicuramente è una strada molto difficile da percorrere.

Pertanto, più che concentrarsi su un dettagliato studio di capacity planning, penso che un provider debba maggiormente concentrarsi sul concetto di “Design to Scale”. Questo prevede l’utilizzo, ovunque possibile, di componenti modulari piuttosto che monolitici, in grado di scalare orizzontalmente nel tempo in modo lineare e trasparente. Nella parte compute questo avviene già da diverso tempo, dato che VMware ad esempio basa la sua soluzione vSphere su una serie di server ESXi che possono essere tolti e aggiunti a un cluster in modo dinamico. Nello storage questo ancora non avvienre sempre, e sono poche le soluzioni di tipo scale-out adottate, se paragonati all’enorme quantità di soluzioni scale-up esistenti. Ho scritto un articolo alcuni mesi fa dal titolo “Il futuro dello storage è Scale Out”, dove spiego appunto perchè penso che uno storage di tipo scale out sia più effciente, vi invito a leggervelo.

Un service provider è parecchio limitato nella sua capacità di fare capacity planning, almeno nell’accezione che se ne da solitamente. Quello su cui può concentrarsi maggiormente è invece il “Design to Scale”, in modo da poter reagire più facilmente alle mutabili richieste dei propri clienti.

Note finali

In definitiva, un service provider funziona in modo differente da una grande azienda, anche se con questa condivide alcune caratteristiche. Voler a tutti i costi paragonare uno all’altro in modo che un singolo prodotto sia vendibile a entrambi non sempre è una scelta vincente. Esistono sicuramente alcuni prodotti che sono adatti ad entrambi gli scenari, ma molti altri al contrario possiedono caratteristiche tali per cui la loro adozione nell’ambiente sbagliato può portare a problemi, magari non visibili immediatamente, ma proprio per questo pericolosi perchè si manifestano solo quando vi è da accingersi ad una (dolorosa) sostituzione.

Se siete un service provider, ragionate per scenari estremi: non pensate a un sistema che deve crescere del 30% annuo per i prossimi 3 anni, ma piuttosto “questo sistema potrà essere RADDOPPIATO in dimensioni nel giro di una settimana? E se sì, come?”