Aggiornamento Amazon: colpa della rete

Questo articolo spiega in modo abbastanza comprensibile cos’è successo. Un errore nel routing “when engineers upgraded the capacity of the primary network in a single availability zone” è alla causa di una serie di eventi a catena che ha portato al blocco e alla perdita di dati. Questo mette in evidenza il ruolo cruciale, ovvio ma spesso sottostimato, della rete in un’infrastruttura cloud o virtualizzata. Mette anche in evidenza un problema che sottolieo sempre quando si parla di Business Continuity: lo strumento principe (quello che probabilmente avrebbe evitato i problemi di Aruba) è l’utilizzo di più datacenter fisicamente separati e remoti, ma questo difficilmente aiuta quando il guasto è logico, perché a quel punto la separazione fisica serve a poco. Serve una separazione anche logica, che è una cosa difficile da ottenere quando i datacenter sono tutti attivi e in comunicazione, come nel cloud appunto. Ma c’è un altro passaggio che vale la pena di sottolineare:”Amazon said it will automatically provide customers with 10 days of credit to equal to 100 per cent of their usage of EBS volumes, EC2 instances and RDS database instances that were running in the affected availability zone at the time of the outage. It did not mention credits for services operating in the other availability zones.”. Qui siamo agli SLA: supponiamo che abbiate avuto un fermo di, mi pare, 36 ore nella vostra attività, magari saltando scadenze, perdendo clienti eccetera. Vi sentireste soddisfatti come compensazione da uno sconto di meno del 3% sul canone annuo? Mi piacerebbe sapere se anche solo questo sconto è previsto a livello di SLA, o non c’è nemmeno quello. Lasciando stare Amazon, diciamo che tuttora, la maggior parte dei servizi legati a Internet, siano di connettività, hosting, webmail o altro, hanno come “penale” qualche giorno di servizio in più che, diciamolo chiaramente, generalmente per il fornitore ha un costo trascurabile. Non c’è nessun legame con il valore che il servizio ha per il cliente, e quindi l’affidabilità del servizio dovrebbe essere considerata in proporzione a quanto l’outsourcer è disposto a impegnarsi (economicamente) al riguardo. Se un disservizio vale qualche giorno di servizio in più… beh, la sua affidabilità deve essere valutata in base a quello, non allo SLA dichiarato.