Dezvoltarea Cloud Computing i impactul acestuia asupra ntreprinderii

Unul dintre motivele pentru care interesul n cloud computing a crescut este opina general, propagat i de ctre furnizorii de servicii de cloud, cum c, prin utilizarea cloud-ului public, se pot reduce semnificativ costurile IT. n continuare vom examina considerentele economice ale cloud computing-ului. Avnd n vedere c exist dou tipuri de oferte de servicii cloud, servicii de cloud de tip infrastructur precum i servicii de cloud de tip platform, considerm costurile pentru infrastructur, precum i posibilele avantaje ntr-un mediu de dezvoltare, inclusiv productivitatea. Vom privi considerentele economice att din perspectiva utilizatorului, ct i din cea a furnizorului de servicii cloud. De asemenea, vom compara i considerentele economice ale serviciilor de cloud publice i private.

6.1. Este infrastructura cloud-ului mai ieftina?

La data scrierii materialului bibliografic, tarifele publicate pentru infrastructura serviciului de cloud (folosind Amazon EC2) ncep de la $0.10 per CPU-or de calcul i $0.10 per Gbyte lun de depozitare, pentru cea mai mic configurare posibil de sever; serverele mai mari cost mai mult pe or. n exemplul de mai jos vom folosi serverul "extra-large" care cost $0.68 pe CPUor i l vom compara cu un ordin de cumprare real pentru un server echivalent pentru a putea examina dac i n ce msur este mai ieftin fa de folosirea unei infrastructuri in-house echivalente, ce ruleaz ntr-un centru de date enterprise. Un factor de decizie important pentru economia serviciului de cloud se refer la modul n care este planificat i achiziionat capacitatea hardware-ului. Privind din perspectiva utilizatorului final, cloud computing-ul ofer iluzia unei capaciti de potenial infinit, beneficiind de capacitatea suplimentar atunci cnd este nevoie, i s plteasc doar pentru ceea ce consum. Utiliznd un serviciu cloud public nltur, prin urmare, necesitatea de a planifica dinainte costurile pentru situaiile de utilizare maxim i convertete costurile fixe n costuri variabile, care se vor modifica de-a lungul utilizrii efective, eliminnd astfel pierderile. Pe de alt parte, calcularea costurilor pentru situaiile de utilizare maxim este o necesitate n cadrul centrelor de date private; i fr o scar adecvat scad ansele amortizrii capacitii n diverse aplicaii, i,

astfel, cele mai multe centre de date funcioneaz la un nivel de utilizare ridicol de mic de 5-20 la sut!

6.1.1. Considerente economice n cazul IaaS S consideram un exemplu simplu, serverul "extra-large", de pe cloud-ul Amazon EC2 care are 8 uniti de calcul, 15 GB de memorie i 1600 GB de disc. Cum am menionat anterior, o astfel de situaie ar costa 0.68 dolari pe CPU-or. Acum s lum n considerare achiziionarea unui server echivalent in-house. Bazndu-ne pe experiena anterioar, un server x86 cu 3 quad-core (adic 12 de nuclee de procesare), 12GB de memorie i disc de 300GB cost $9,500. Acum s comparm costurile de funcionare ale unui server de tip in-house timp de trei ani sau 26260 de ore de funcionare cu un server echivalent "extra-large" din Amazon EC2. n tabelul de mai jos sunt sintetizate calculele. La un pre de achiziionare de $9,500, preul de un server inhouse este de $0.36 per or pe parcursul ciclului su de via; sau $0.03 per nucleu-or. Pe de alt parte, preul unui nucleu ore pe un server EC2 este de $0.085 (0,68 / 8, deoarece serverul mare are 8 nuclee), care este de 2.82 ori mai scump dect un server in-house. Chiar dac obinem un discount din faptul c serverul in-house are 12 nuclee, comparativ cu serverul EC2 de 8 nuclee, ce e de fapt justificabil, avnd n vedere memoria mai mare a serverului EC2, observm c preul pe or al serverului EC2 "extra large" este de 1.88 ori mai mare dect al serverului inhouse.

Tabel Considerentele economice ale infrastructurii cloud-ului

Deci se pare c serverul de cloud este mai scump. Dar s lum n considerare acum faptul c cele mai multe servere din centrul de date sunt puternic subutilizate, s spunem doar 40%, pe cnd utilizarea cloud poate fi scalat cu uurin n sus sau n jos la cerere i, prin urmare, se bucur de o utilizare mult mai mare, s zicem 80%. Lund aceste lucruri n considerare, costul per or de capacitate efectiv in-house devine $0.90 (de exemplu, $0.36/0.4), n esen acelai ca pentru un server instalat n cloud (de exemplu, $ 0.85 = $ .68/0.8). Mai mult, puterea i rcirea pentru un server in-house de-a lungul duratei de via este cel puin la fel de mare ca preul de baz amortizat al serverului ($0.36 per-or), i, deseori, chiar i mai mult. Astfel, n tabelul de mai sus, vom aduga pentru curent i rcire ali $0.36 per-or n cazul serverul-ului in-house. n continuare, vom lua n considerare costurile forei de munc pentru gestionarea infrastructurii, i anume sarcini de genul realizrii de backup, monitorizare i mentenan periodic. n practic, folosind automatizarea centrelor de date din cloud, costurile de gestionare a infrastructurii urmeaz regula general: numrul de servere n pe care p persoane le poate gestiona este proporional cu p2. Ct timp un centru de date in-house poate, n principiu, obine un nivel al eficienei similar cazului gestionrii infrastructurii din centrele de date din cloud, este puin probabil s funcioneze la acelai nivel. S-a constatat c costurile forei de munc pentru gestionarea unui centru de date foarte mare, s spunem cteva sute de mii servere, poate fi sczut, cam $0,01 pe or per server, astfel nct un centru de date mai mic, cu doar cteva mii de servere ar cheltui $0.1 pe or pe fiecare server. Acum, s lum n considerare o ntreprindere care utilizeaz mii de servere in cloud spre deosebire de in-house. ntr-o mare msur, furnizorul de servicii de cloud deja gestioneaz aceste servere, i costurile de gestionare au fost incluse n preul per or al unui server. Deci, teoretic, ntreprinderea nu suport nici un cost pentru gestionarea serverelor n cloud. Cu toate acestea, chiar dac presupunem c nc exist unele costuri suportate de o parte a unei ntreprinderi pentru a gestiona serverele n cloud, acesta vor fi cu mult mai mici dect pentru serverele implementate in-house. n calculele noastre, am presupus c un centru de date in-house, care cuprinde de mii de servere, cost $0.1 per or pe server pentru gestionare, n timp ce costurile suportate de o ntreprindere pentru a gestiona servere n cloud ajung la $ 0,01 per or pe server, urmnd regula de mai sus privind comportamentul costurilor de management.

Tabelul de mai sus rezum calculele noastre, ce includ eficiena utilizrii, alimentarea i rcirea, precum i costurile de management. Avnd toate aceste costuri, acum se pare c serverul n nor din EC2 are un avantaj clar (cu un factor de aproape 1,6) asupra serverului in-house. De reinut este faptul c n analiza noastr am considerat un centru de date in-house mare ( de mii de servere), care ruleaz la un randament de 40%. n practic, beneficiile cloud computing-ului vor fi chiar mai mari pentru centrele de date mai mici ce funcioneaz la nivel de eficien in jurul valorii de 20%, i n cazurile n care cheltuielile de administrare a infrastructurii ncep s depeasc costurile serverului.

6.2. Considerentele economice ale cloud-urilor private Ar putea prea c n seciunea anterioar, considerentele economice se bazeaz pe o ipotez care presupune o utilizare sczut a unui centru de date in-house. Deseori se discut c utiliznd virtualizarea i provizionarea automat a tehnologiilor in-house ar trebui s fie posibil s se creeze un cloud privat, unde aceste ineficiene ar putea s dispar i beneficiile cloud computingului ar putea fi realizate plecnd de la aceast premis. Disponibilitatea software-ului open source, cum este Eucalyptus, care permite, n esen, provizionarea automat de tipul Amazon EC2, nseamn c o astfel de abordare este, de asemenea, fezabil. n continuare vom analiza n detaliu considerentele economice a unor astfel de cloud-uri private i vom vedea modul n care acestea se compar cu costurile din cazul cloud-urilor publice.

Figura Supraprovizionarea n cloud-urile private Fie di(t) cererea de putere de calcul a aplicaiei i care ruleaz ntr-o ntreprindere la momentul t, cererea agregat D(t) = , cererea maxim Dmax = maxt D(t). Relaia dintre D(t) i Dmax

poate varia puternic n funcie de profilul operaional al aplicaiei, aa cum este ilustrat n Figura 6.1. n cazul n care maximele i minimele cererile sunt puternic corelate, aa cum e ilustrat n figura din stnga, D(t) poate varia foarte mult de la maxim; pe de alt parte, n cazul n care exist corelaie mic sau nu exist, i, pentru un numr mare de aplicaii, D(t) poate fi netezit i destul de aproape de Dmax, aa cum e ilustrat n figura din dreapta. Acum s presupunem c am reuit s crem un mediu puternic virtualizat n cadrul centrului de date unde resursele reale provizionate pentru utilizare (de exemplu, active i alocate) pot varia n mod dinamic i automat de-a lungul timpului. Mai exact, fie timpul de ntrziere pentru provizionarea resurselor de calcul suplimentare la cerere. n mod evident, n cazurile n care rata de provizionare 1 / este mult mai mic dect rata de schimbare a cererii dD / dt, nu exist nici un beneficiu al provizionrii dinamice virtuale i cineva ar putea la fel de bine s provizioneze capacitatea maxim Dmax n orice moment. Considerm cazul n care este mic, astfel nct capacitatea provizionat poate urmri ndeaproape cererea, aa cum este ilustrat prin curba V(t) din figur. De reinut este faptul c, din cauza ntrzierii de provizionare , o parte din capacitatea virtual n exces trebuie s fie provizionat ntotdeauna n vederea asigurrii capacitii adecvate pentru a satisface cererea, iar acest lucru este proporional cu rata de schimbare a cererii; astfel, capacitatea virtual necesar la momentul t este: V(t) = D(t) + .

Capacitatea virtual total provizionat de-a lungul unui interval de timp T este: = , unde DT este suprafaa sub curba cererii D(t).

Acum vom compara costurile suportate n cazul utilizrii unui cloud privat cu cele ale unui cloud public. Pentru un centru de date in-house, capacitatea fizic total care trebuie s fie achiziionat trebuie s corespund cererii maxime Dmax, prin urmare, n cazul n care costul pe or amortizat al acestei achiziii a procesorului este c, aceasta implic un cost de cTDmax. Pe de alt parte, lund n considerare utilizarea unui serviciu de cloud public al crui pre este 2c per CPU or, atunci costul ar fi 2cV. Avem, de asemenea, trebuie s lum n considerare i costurile cu energia electric, care sunt incluse n preul cloud-ului, dar care trebuie s fie pltite pentru in-house. S presupunem c costul amortizat al puterii de calcul este p per or computaional, apoi costul total al puterii este de cel puin pV, presupunnd c serverele care nu sunt utilizate pot fi nchise

complet, astfel nct s nu consume curent. Apoi, raportul ntre costurile in-house i cele ale unei infrastructuri echivalente de cloud pot fi aproximate la:

Mai departe, pentru simplificarea calculelor vom presupune c p = c, dup cum s-a observat deseori n practic. Folosind expresiile de mai sus, vom ajunge la: ( )

Pentru a verifica rezultatele, trebuie reinut faptul c cu o amortizare perfect a capacitii asupra cererii DT = TDmax i Dmax = Dmin i c nu exist nici o diferen ntre costurile cloud-urilor publice i a celor private. Cu toate acestea, n practic, ncrcarea de procesare tipic pentru sarcinile de tip tranzacii pot varia cu factori de 5 sau 10 n cursul fiecrei zile, i prin ordinea magnitudinii n perioadele maxime ale anului. n continuare profilul de cerere pentru mai multe aplicaii business din aceeai ntreprindere este probabil s fie similare, astfel nct, n practic, de obicei, Dmax >> Dmin i DT << TDmax, astfel nct cloud-urile publice ctig n urma calculelor noastre de mai sus. Ecuaia (*) cuantific beneficiile elasticitii, i anume capacitatea de a proviziona rapid resursele de care are cineva nevoie i s plteasc doar pentru acestea. Analiza noastr arat c, chiar dac se mbuntesc utilizrile din centrul de date prin virtualizare, din cauza aplicaiilor critice, care consum resurse semnificative i trebuie s fie previzionate pentru o sarcina de vrf, potenialul beneficiilor virtualizrii este rareori neles pe deplin. n practic, provizionarea peste capacitate va fi tot timpul cerut, cu att mai mult n cazul serverelor locale din motivele menionate mai sus.

6.2.1. PaaS vs. IaaS Vom compara acum modelele de cloud IaaS i PaaS dintr-o perspectiv economic. Modelul PaaS, exemplificat prin ofertele de cloud Google App Engine i Microsoft Azure, poate prezenta avantaje economice n comparaie cu modelul IaaS pentru anumite categorii de aplicaii. Vom lua n considerare o aplicaie web care trebuie s fie disponibil 24 7, dar n care volumul tranzaciilor este extrem de imprevizibil, i poate varia rapid. Folosind un cloud IaaS, un numr

de minim de servere ar trebui s fie provizionate n orice moment, pentru a asigura disponibilitatea serviciului web. n schimb, cu un model PaaS, cum ar fi Google App Engine, doar implementarea aplicaiei nu cost nimic. Astfel, o aplicaie poate fi disponibil 24 7 cu nici un cost. Odat cu creterea consumului dincolo de limitele de utilizare gratuit, vor ncepe s fie percepute anumite taxe, i o aplicaie bine proiectat va scala n mod automat pentru a satisface cererea. De ndat ce cererea scade, resursele nu mai sunt consumate i nu sunt percepute taxe. Mai mult, deoarece provizionarea serverelor suplimentare pentru o aplicaie dureaz o perioad finit de timp, s spunem cteva minute, capacitatea minim provizionat n IaaS trebuie s ia n considerare aceast ntrziere, planificnd i pltind pentru capacitatea n exces chiar i n mediul cloud. Cu o platform PaaS, cum ar fi Google App Engine, un numr mare de servere web ce deservesc platforma funcioneaz permanent, astfel nct fiecare codul aplicaie a fiecrui utilizator este disponibil pentru toate serverele prin intermediul sistemului de stocare distribuit. Salturi brute ale cererii sunt automat rutate ctre servere web gratuite de ctre divizorul de sarcini, asigurnd o degradare minim a performanei; singurul overhead suportat este cel al ncrcrii codului i al datelor din sistemul de fiiere atunci cnd un astfel de server de web se ocup de o cerere ctre o nou aplicaie pentru prima dat. Astfel, pentru servicii web de volum mic sau variabil o alternativ mai ieftin este PaaS, cu condiia ca utilizatorul sa fie dispus s-i reconstruiasc aplicaiile pentru formatele de date nonstandard oferite de aceste platforme (att Google App Engine, precum i Microsoft Azure). Pentru aplicaii mai voluminoase de tip back-end (cum ar fi cele n spatele front-end-urilor web sau cele folosite pentru prelucrarea n loturi), IaaS este mai potrivit. Este posibil ca o combinaie intre PaaS i IaaS s fie o arhitectur viabil n anumite cazuri, cu o soluie tip PaaS oferind front-end-ul web i o soluie IaaS oferind puterea de procesare la cerere.