Timpurile recente stau sub semnul serviciilor cloud. Funcționalități noi ale furnizorilor de cloud se lansează în fiecare zi, aducând cu ele prețuri din ce în ce mai mici. În acest moment, cei mai cunoscuți furnizori de servicii cloud sunt Amazon, Google și Microsoft.
Uitându-ne peste serviciile lor, vom vedea SLA-uri (Acorduri de nivel al serviciilor - Service Level Agreements) care ajung la o disponibilitate de 99,9%, 99,95% sau chiar 99,99%. Acest articol va aborda acordurile SLA ale furnizorilor de serviciicloud, încercând să explice de ce SLA-urile sunt atât de importante, care sunt beneficiile lor și nu în ultimul rând, cât de mulți bani am putea obține înapoi dacă un serviciu cade.
"Un acord pentru calitatea serviciilor (SLA) este un contract între un furnizor de servicii (fie intern sau extern) și utilizatorul final care definește nivelul serviciului așteptat de la furnizorul de servicii. SLA-urile sunt bazate pe rezultat (output) deoarece scopul lor este să definească anume ceea ce clientul va primi. SLA-urile nu definesc cum este oferit sau furnizat serviciul în sine."
Un SLA este un contract între un furnizor de servicii și client, care specifică "calitatea" serviciului care va fi furnizat clientului. De exemplu, dacă ne gândim la un serviciu care îți precizează ora exactă, SLA-ul va defini cât timp va fi serviciul în stare de funcționare pe parcursul unui an (99,99%).
În plus, SLA-ul definește garanțiile care sunt oferite dacă SLA-ul nu este onorat. De exemplu, dacă serviciul de oră exactă este nefuncțional pentru mai mult de 0,01% pe lună, furnizorul de servicii va reduce costul total de pe factură cu 50%.
În funcție de tipul de servicii sau de afacere despre care discutăm, aspectele care pot fi atinse sunt diferite. Este foarte comun pentru un SLA să cuprindă următoarele atribute ale unui serviciu:
Privind din nou la exemplul nostru cu serviciul de oră exactă, am putea avea un SLA care spune: "Serviciul de oră exactă funcționează 99,99% din an, timpul de răspuns din momentul în care o cerere ajunge la acest serviciu este de 0.0001 secunde și precizia este de 0.00000001 secunde."
În general, dacă vorbim de furnizorii de servicii cloud și serviciile oferite de ei, aspectul acoperit de toți este durata de funcționare. Pe lângă durata de funcționare mai sunt și alte aspecte, dar acestea variază în funcție de tipul de serviciu.
Microsoft, Google și Amazon au un SLA clar care specifică durata de funcționare pentru fiecare serviciu care este furnizat de către ei. Chiar dacă sunt companii diferite, SLA-urile sunt foarte asemănătoare între ele.
De exemplu, dacă ne uităm la serviciile de depozitare din cloud, care nu sunt replicate în centre de date sau noduri diferite, vom descoperi că Google oferă o durată de funcționare conform SLA de 99,9 %, Microsoft oferă un SLA cu durata de funcționare de 99,9%, iar Amazon oferă o funcționare de 99,95% prin SLA , cu precizarea că, dacă avem spre utilizare Read Access-Geo Redundant Storage de la Microsoft, putem ajunge chiar și la 99,99%.
După cum am putut remarca în exemplul de mai sus, SLA-urile sunt aproape identice, cu diferențe de doar 0.05%.
Această întrebare este foarte importantă, deoarece fiecare furnizor de servicii cloud specifică foarte clar în SLA cum, cine și când, în funcție de ce serviciu este măsurat.
În toate cazurile, durata de funcționare a serviciului este măsurată intern, de către sistemul lor propriu. Acest lucru nu înseamnă că măsurarea nu este reală.Ea este foarte reală, dar dacă motivul nefuncționării este un factor extern, cum ar fi probleme la rețea pe partea clientului, atunci nu mai este problema lor.
SLA-ul nu este aplicabil în cazurile în care serviciul este utilizat în afara anumitor limite specifice. De exemplu, SLA-ul se aplică numai când numărul de cereri pe secundă este sub 10 milioane, sau când există cel puțin două exemple de cerere pentru acea folosință.
Adesea, oamenii presupun în mod eronat că, dacă au un serviciu în cloud care generează 1000$ per oră, furnizorul le va asigura acea sumă de bani pe care serviciul ar fi generat-o, chiar și în condițiile unei perioade de nefuncționare. O altă presupunere greșită este că furnizorul de cloud va acoperi toate pierderile generate de o perioadă de nefuncționare.
În acest moment, nu cunosc nici un furnizor de cloud sau de servicii care ar acoperi pierderile rezultate în urma unei nefuncționări. Ambele presupuneri sunt nejustificate.
Ar putea suna ciudat, dar este normal. În primul rând, este greu să măsori și să calculezi pierderea, iar în al doilea rând, SLA-ul se referă la serviciul pe care îl utilizați și nu la sistemul sau serviciile pe care voi le oferiți pe baza acestuia.
Google, Microsoft și Amazon oferă garanții foarte asemănătoare. În funcție de perioada de nefuncționare la sfârșitul lunii, o cantitate specifică de credit servicii este oferită clientului. De exemplu, dacă perioada de funcționare a serviciului a fost sub 99,9%, clientul va primi 25% din costul acelui serviciu pentru acea lună drept credit. Acest credit va fi utilizat pentru a reduce costul facturii din luna următoare.
De asemenea, SLA-urile menționează că, dacă un anumit incident sau eveniment provoacă o defecțiune la mai mult decât un singur serviciu cloud, atunci clientul poate trimite o reclamație numai pentru un serviciu care a fost afectat de acest eveniment.
De exemplu, dacă un centru de date cade din cauza unei actualizări software și sunt afectate sistemele de stocare, calcul și mesagerie, atunci clientul poate pretinde credit numai pentru un singur serviciu.
Haideți să aruncăm o privire asupra garanțiilor care sunt oferite de către acești furnizori de cloud în cazul unei nefuncționări a sistemului lor de depozitare.
Oferta nu este identică 100%, dar este destul de similară. Chiar dacă Google oferă 50% credit de depozitare în cazul unei nefuncționări, nu mi-aș dori să fiu în situația în care durata de funcționare este de numai 90% de exemplu. Creditul oferit pentru o funcționare între 99,xx% și 99% este același. Fiecare '9' care este oferit peste 99% este foarte scump și greu de obținut. Acei 9 reprezintă adevărata bătălie și pot face deosebirea dintre un simplu serviciu și un serviciu grozav.
Toți furnizorii de cloud au mecanisme diferite pentru a-și notifica clienții atunci când un serviciu nu funcționează conform așteptărilor (pe un web site, folosind un API sau prin email). În toate aceste cazuri, chiar dacă un serviciu este nefuncțional mai mult decât se specifică în SLA, clientul nu va primi din oficiu (by default) creditul despre care am discutat mai sus.
În momentul în care clienții sunt afectați de un incident, ei trebuie să înștiințeze furnizorul de cloud și să întocmească un aviz la nivelul de suport pentru clienți. Ei trebuie să specifice care anume serviciu a fost afectat și când. Pe baza acestor informații, furnizorul de cloud va verifica sistemul de audit intern și nivelul ratei de eroare în acel interval anumit de timp.
Acesta este cuvântul cheie în lumea furnizorilor de cloud și a clienților lor. Cel mai important lucru este încrederea care există între ei. Noi, clienții, avem încredere în furnizorii noștri de cloud care își respectă SLA-urile. Același lucru se întâmplă cu orice furnizor extern.
În general, toate SLA-urile oferite de furnizorii de cloud sunt respectate. Cazurile în care există incidente sunt foarte rare și izolate.
Durata de funcționare a serviciului cloud nu coincide cu durata de funcționare a produsului nostru
Un lucru important pe care trebuie să îl luăm în considerare este că atunci când construim un produs pe cloud, timpul de funcționare al sistemului nostru nu este același cu timpul de funcționare al serviciilor cloud.
De exemplu, dacă avem un produs care este construit utilizând 20 de servicii din cloud, atunci timpul de funcționare al sistemului nostru va trebui să fie calculat ținând cont de perioada de funcționare a tuturor serviciilor cloud. Dacă fiecare dintre serviciile cloud are o durată de funcționare de 99,9%, atunci perioada de funcționare a sistemului nostru ar putea ajunge la aproximativ 98%.
După cum am menționat mai sus, SLA-urile oferite de diferiți furnizori de cloud sunt relativ asemănătoare. Cel mai important lucru este să știm exact ce anume acoperă SLA-ul și cum să gestionăm perioadele de nefuncționare.
Amazon EC2 SLA - aws.amazon.com/ec2/sla/
Google SLA - cloud.google.com/storage/sla
Microsoft SLA - azure.microsoft.com/en-us/support/legal/sla/
de Peter Lawrey
de Răzvan Costa
