Quello degli SLA del cloud è un tema strategico. Potremmo anzi dire che i veri vantaggi dell’approccio as-a-service sono quelli che vengono definiti nel momento in cui si identificano i livelli di servizio della fornitura e li si condivide con il proprio provider. Ed è proprio qui il punto: i Service Level Agreement devono essere necessariamente il frutto di un lavoro fatto a quattro mani dai team interni e dal partner.
Definire gli SLA del cloud: l’importanza di una Business Impact Analysis
Ci sono provider che offrono soluzioni chiavi in mano, generalizzando la proposition in base ai livelli medi dei servizi presenti sul mercato o proponendo performance esagerate, con un approccio prudenziale. In ogni caso, senza mai fare un ragionamento sulla situazione specifica del cliente e sulle esigenze reali dei suoi processi e del suo parco applicativo. Per questo mi sento di dire: prendetevi tempo per analizzare le effettive esigenze quando vi viene proposto un pacchetto a scatola chiusa.
La verità è che ciascuna azienda dovrebbe fare una Business Impact Analysis preliminare prima di definire insieme al proprio partner gli SLA del cloud. Questo significa censire e analizzare tutti i processi, quantomeno quelli critici o che hanno interazioni con questi, che sono stati digitalizzati, per capire quali possono essere le cause di malfunzionamenti o blocchi: non solo chiarendo gli obiettivi strategici e operativi di una migrazione al cloud, ma anche ipotizzando i danni potenzialmente derivati da un processo che si ferma e coinvolgendo nell’analisi fornitori e clienti, e più in generale l’intera catena degli stakeholder.
Tutto ciò senza dimenticare che gli SLA del cloud vanno considerati come un di cui del compliance risk assessment. Il che significa che conformità normativa e policy interne vanno tradotte in requisiti di servizio sul piano dei tempi di risposta, della sicurezza e del supporto che il cloud provider andrà a fornire.
Esatto, parliamo di resilienza, un concetto astratto rispetto al mondo informatico che ha però un preciso significato: il sistema deve funzionare a prescindere da eventi previsti e imprevisti, rispondendo in modo dinamico a qualcosa che può succedere nel contesto peculiare in cui opera l’organizzazione.
Cosa considerare quando si negoziano fee e livelli di servizio
Una volta effettuata la Business Impact Analysis arriva il momento di concordare con il provider gli SLA del cloud e stabilire le fee per l’erogazione del tipo di servizio che soddisfa le esigenze aziendali identificate. Bisogna chiarire subito una cosa: non è possibile garantire in modo assoluto che i costi non varino nel tempo. Le esigenze del business cambiano in fretta, e su un periodo di cinque anni – la tipica durata di un contratto di fornitura cloud – fare previsioni accurate in tal senso è tutt’altro che semplice. Quindi suggerisco di inserire all’interno del contratto elementi che assicurino la possibilità di crescere nel rapporto a condizioni quanto più predeterminate possibili.
Basti pensare a cosa potrebbe succedere a una startup, che comincia da un’architettura minimale e che magari, nel corso del tempo, attiva un servizio e-commerce. I requisiti sul piano dell’availability dei sistemi, che devono girare H24, sarebbero destinati a crescere. Se l’infrastruttura e gli SLA del cloud non si evolvono di pari passo con i servizi offerti dalla startup, nel caso ipotizzato, sarebbe sufficiente che i processi si fermassero un giorno o anche per ore per perdere potenzialmente cifre significative di fatturato.
Gli SLA possono essere flessibili, anche se spesso questa opportunità non è esplicitata o evidente, per le aziende che non sono abituate ad acquistare servizi in outsourcing. Meglio dunque puntualizzarlo in fase di stipula del contratto, inserendo una clausola di rinegoziazione che tuteli l’impresa in caso di rapida crescita del business.
D’altra parte, può anche essere vero il contrario: un cliente pretende determinati livelli di servizio che poi, alla prova dei fatti, risultano sottoutilizzati. La cosa, di tanto in tanto, succede anche in WIIT, ed è per questo che offriamo ai clienti che ce lo richiedono una quota di flessibilità.
Vale la pena, a questo proposito, parlare dei modi in cui un cliente può tenere sotto controllo le performance dei servizi offerti dal provider e verificare che gli SLA del cloud siano rispettati. Il partner dovrebbe garantire durante l’intero periodo di erogazione della fornitura il rilascio di report che non solo certifichino l’adempimento effettivo degli obblighi contrattuali, ma che evidenzino anche i KPI in base ai quali fare eventuali nuove implementazioni per migliorare ulteriormente le prestazioni.
Il ruolo degli SLA nell’Hybrid e Multicloud e la prevenzione del lock-in tecnologico
La corretta impostazione degli SLA del cloud deve essere funzionale anche a garantire livelli di servizio e resilienza in un modello che è sempre più ibrido e multi cloud. In WIIT siamo abituati a lavorare con imprese molto fidelizzate che nel tempo possono avere l’esigenza di attivare o migrare sistemi e servizi dall’on premise al cloud pubblico, al privato o viceversa, ma che a prescindere da dove siano i sistemi hanno l’esigenza di avere SLA definiti e servizi coerenti con le loro esigenze.
Ma attenzione: non basta la buona volontà del partner per rendere semplice la migrazione fra i vari “mondi” cloud. È necessario elaborare preventivamente una cloud strategy adoption. Altrimenti il famigerato lock-in diventa un rischio, spesso per mere questioni di incompatibilità architetturale.
Prima di scegliere un partner per il cloud, infatti, un’azienda deve valutare bene il tipo di architettura che desidera e che il provider effettivamente può rendere disponibile. Molti public cloud, per esempio, sono costruiti su architetture a microservizi e offrono applicazioni cloud-native, che sono una cosa ben diversa dagli ambienti open. In questi casi, se fosse necessario, diventa poi difficile riconvertire tutto e andare su altre architetture che potrebbero invece garantire vantaggi di diversa natura, anche economica. Parliamo di progetti molto complessi, che potrebbero implicare costi di reingegnerizzazione superiori a una migrazione classica. Ecco perché la strategia va ponderata prima e, ribadisco, con estrema attenzione.
Proprio per andare incontro a questo tipo di esigenza e minimizzare l’impatto che eventuali migrazioni potrebbero avere sui nostri clienti, WIIT ha scelto e sviluppato da tempo un approccio hybrid e multicloud, in base al quale consigliamo quali ambienti ha senso implementare in private, e quali conviene ospitare nel public cloud con, a corredo, qualche microservizio. Bilanciando bene i carichi, diventa possibile evitare qualsiasi tipo di lock-in. Ma anche in questo caso parliamo chiaramente di una strategia che va definita prima, non fosse altro per assicurare una gestione omogenea dell’infrastruttura.
Il tema delle responsabilità del provider: un chiarimento
Mi rimane solo da affrontare un ultimo – ma non per importanza – aspetto, quello della definizione delle garanzie e delle penali relative agli SLA del cloud. A volte mi capita di dover spiegare, soprattutto a clienti nuovi al tema dell’outsourcing, che un cloud provider non è una compagnia di assicurazioni e non può prevedere meccanismi che risarciscano eventuali perdite del business causate da un disservizio.
Un conto è una penale per un disservizio, e rappresenta un disincentivo a non operare al di sotto degli standard del valore del contratto, altro conto è un’assicurazione, e qui si tocca un nervo scoperto. Quando mi accorgo che il mio interlocutore si aspetta da me una vera e propria polizza su eventuali perdite di fatturato, gli chiedo di provare a contattare il proprio assicuratore, anticipandogli che la compagnia invierà un perito, il quale – dopo un’analisi dei processi di business – farà un preventivo. A quel punto, basterà confrontare il preventivo dell’assicuratore con quello di un qualsiasi cloud provider per far comprendere al cliente che si tratta di due lavori completamente diversi.
Detto questo, è chiaro che il cliente si debba tutelare, introducendo e concordando per esempio il limite di responsabilità del fornitore e soprattutto inserendo una clausola specifica per le penali nel momento in cui il provider non performa correttamente su ambiti strategici e misurabili. Scegliere correttamente gli SLA del cloud, in ultima analisi, serve proprio a questo.
