Creșterea capacităților de calcul și dezvoltarea tehnologiilor de virtualizare a platformei x86, pe de o parte, și răspândirea outsourcing-ului IT, pe de altă parte, au dus la conceptul de utility computing (IT ca serviciu public). De ce să nu plătim pentru IT la fel ca pentru apă sau electricitate - exact atât cât și atunci când avem nevoie, nici mai mult.
În acel moment a apărut conceptul de computație în cloud - consumul de servicii IT din „cloud”, adică dintr-un anumit pool extern de resurse, fără a ne face griji cu privire la modul în care și de unde provin aceste resurse. Așa cum nu ne preocupăm de infrastructura stațiilor de pompare ale rețelei de apă. Până în acel moment, a fost elaborată și cealaltă parte a conceptului - și anume noțiunea de servicii IT și cum să le gestionăm în cadrul ITIL / ITSM.
A fost dezvoltat un întreg set de definiții pentru cloud-uri (computația în cloud), dar nu trebuie să le considerăm ca fiind adevărul absolut - acestea sunt doar un mod de a formaliza modalitățile de furnizare a utility computing.
- „Computația în cloud este o tehnologie de procesare distribuită a datelor, în care resursele și puterea de calcul sunt oferite utilizatorului ca un serviciu pe Internet” Wikipedia
- „Computația în cloud reprezintă un model pentru furnizarea unui acces convenabil la un pool comun de resurse de calcul configurabile (de exemplu, rețele, servere, sisteme de stocare a datelor, aplicații și servicii) la cerere, care pot fi rapid alocate și furnizate cu eforturi minime de gestionare sau cu un minim de intervenție din partea furnizorului de servicii” NIST
- „Computația în cloud este o paradigmă pentru furnizarea de acces la rețea la un pool scalabil și flexibil de resurse fizice sau virtuale distribuite, oferite în regim de autoservire și administrate la cerere” ISO/IEC 17788:2014. Tehnologia informației - Computația în cloud - Prezentare generală și vocabular.
Conform NIST, există trei tipuri principale de cloud-uri:
- IaaS – Infrastructure as a Service — Infrastructură ca serviciu
- PaaS – Platform as a Service — Platformă ca serviciu
- SaaS — Software as a Service — Software ca serviciu
Pentru o înțelegere foarte simplificată a diferenței, să luăm în considerare modelul Pizza-as-a-Service:
NIST definește următoarele caracteristici necesare ale serviciului IT, care îl fac să fie considerat cloud.
- Accesul universal la rețea (broad network access) – serviciul trebuie să aibă o interfață de rețea universală, care să permită conectarea și utilizarea serviciului aproape de oricine, cu cerințe minime. De exemplu, pentru a utiliza rețeaua electrică de 220V, este suficient să te conectezi la orice priză cu o interfață standard universală (priza), care nu se schimbă indiferent dacă este un fierbător, un aspirator sau un laptop.
- Măsurabilitatea serviciului (measured service) – o caracteristică cheie a serviciului cloud este măsurabilitatea acestuia. Revenind la analogia cu electricitatea – vei plăti exact cât ai consumat, cu o granularitate minimă, inclusiv costul pentru a fierbe o dată apă pentru ceai, dacă pe parcursul unei luni ai fost acasă o singură dată și ai băut o ceașcă de ceai.
- Configurarea autonomă a serviciilor la cerere (on demand self service) – furnizorul de cloud oferă clientului posibilitatea de a configura serviciul în mod rațional, fără a fi nevoie de interacțiune cu angajații furnizorului. Pentru a fierbe apă, nu este necesar să contactezi în avans furnizorul de electricitate și să le comunici sau să obții permisiunea. Din momentul în care casa este conectată (contractul este semnat), toți consumatorii pot dispune de puterea oferită în mod autonom.
- Elasticitate rapidă (rapid elasticity) – furnizorul de cloud oferă resurse cu capacitatea de a crește sau reduce imediat puterea (în anumite limite rezonabile). De îndată ce fierbătorul este pornit, furnizorul furnizează imediat 3 kW de putere în rețea, iar odată ce este oprit, reduce livrarea la zero.
- Consolidarea resurselor într-un pool (resource pooling) – mecanismele interne ale furnizorului de servicii permit consolidarea capacităților generatoare individuale într-un pool comun de resurse, cu furnizarea ulterioară a resurselor ca serviciu diferitelor consumatori. Inclusiv fierbătorul, ne preocupă cel mai puțin de la ce stație electrică specifică provine puterea. Și toți ceilalți consumatori folosesc această putere împreună cu noi.
Este important să înțelegem că caracteristicile cloud-ului descrise mai sus nu sunt extrase dintr-o pălărie, ci reprezintă o concluzie logică din conceptul de utility computing. Și serviciul public ar trebui să dețină aceste caracteristici în cadrul conceptului. Atunci când un anumit caracteristici nu este îndeplinit, serviciul nu devine mai rău și nu devine „toxic”, ci pur și simplu încetează să mai fie cloud. Ei bine, cine a spus că toate serviciile trebuie să fie așa?
De ce vorbesc despre asta în mod special? În cei 10 ani scurși de la apariția definiției NIST, au existat multe dezbateri despre „adevărata cloud-itate” conform acelei definiții. În Statele Unite, uneori se folosește în domeniul juridic expresia „corespunde literei legii, dar nu spiritului” — și în cazul calculului cloud, esențial este spiritul, resursele fiind închiriate cu două clicuri de mouse.
Trebuie menționat că cele 5 caracteristici menționate mai sus se aplică cloud-ului public, dar odată cu trecerea la cloud privat, majoritatea dintre ele devin opționale.
- Accesul universal la rețea (broad network access) – în cadrul cloud-ului privat, organizația controlează complet atât capacitățile generatoare, cât și clienții-consumatori. Astfel, această caracteristică poate fi considerată automat îndeplinită.
- Măsurabilitatea serviciului (measured service) – acesta este caracteristica cheie a conceptului de utility computing, plata realizându-se în funcție de consum. Dar cum plătește o organizație ei însăși? În acest caz, se face o împărțire între generare și consum în cadrul companiei, IT-ul devenind furnizor, iar departamentele de afaceri consumatori ai serviciilor. Iar decontarea are loc între departamente. Pot exista două moduri de operare: chargeback (în cazul decontărilor reale și circulației financiare) și showback (sub formă de rapoarte privind consumul de resurse în lei, dar fără circulație financiară).
- Configurarea autonomă a serviciilor la cerere (on demand self service) – în cadrul organizației poate exista un serviciu IT comun, iar în acest caz caracteristica își pierde sensul. Cu toate acestea, în cazul în care există proprii specialiști IT sau administratori de aplicații în departamentele de afaceri, este necesar să se organizeze un portal de autoservire. Concluzia – caracteristica este opțională și depinde de structura afacerii.
- Elasticitatea instantanee (rapid elasticity) își pierde sensul în cadrul organizației din cauza fixității setului de echipamente pentru un cloud privat. Poate fi aplicată limitat în cadrul compensărilor interne. Concluzie – nu este aplicabil pentru cloud privat.
- Consolidarea resurselor într-un pool (resource pooling) – în prezent, practic nu există organizații care să nu utilizeze virtualizarea serverelor. Prin urmare, această caracteristică poate fi considerată executată automat.
Întrebare: Deci, ce este acest cloud privat? Ce trebuie să cumpere și să implementeze o companie pentru a-l construi?
Răspuns: cloudul privat reprezintă o tranziție către un nou model administrativ de interacțiune între IT și afaceri, care constă în 80% din măsuri administrative și doar 20% din tehnologii.
Plata doar pentru resursele consumate și accesul ușor, fără a fi necesar să investești câteva sute de milioane în cheltuieli de capital, au determinat un nou peisaj tehnologic și apariția unor companii miliardare. De exemplu, gigantii moderni Dropbox și Instagram au apărut ca startup-uri pe AWS cu nicio infrastructură proprie.
Este important să subliniem că instrumentele de gestionare a serviciilor cloud devin semnificativ mai mediate, iar o responsabilitate cheie a directorului IT devine selectarea furnizorilor și controlul calității. Să analizăm problema acestor două noi responsabilități.
Apărut ca o alternativă la infrastructura clasică, cu centre de date proprii și echipamente dedicate, cloud-urile par a fi ușoare. Accesul în cloud este simplu, dar problema ieșirii este adesea ignorată. Ca în orice alt domeniu, furnizorii de cloud aspiră la protecția afacerii și complicarea concurenței. Singurul moment competitiv semnificativ apare doar la alegerea inițială a furnizorului de servicii cloud, iar ulterior, acesta va depune toate eforturile pentru a se asigura că clientul nu pleacă. Din păcate, nu toate eforturile se vor concentra pe calitatea serviciilor sau pe diversitatea acestora. În primul rând, este vorba despre furnizarea de servicii unice și utilizarea software-ului de sistem non-standard, care complică migrarea la alt furnizor. Așadar, la alegerea furnizorului de servicii, este necesar să se contureze simultan un plan de tranziție de la acesta (de fapt, un DRP – plan de recuperare în caz de dezastre) și să se gândească la arhitectura stocării datelor și a copiilor de rezervă.
Al doilea aspect important al noilor responsabilități ale directorului IT este controlul calității serviciilor de la furnizor. Practic toți furnizorii de cloud respectă SLA-urile conform unor metrici interne, care pot avea o semnificație extrem de indirectă pentru procesele de business ale clientului. Astfel, implementarea unui sistem propriu de monitorizare și control devine unul dintre proiectele cheie la mutarea sistemelor IT semnificative la furnizorul de cloud. Continuând discuția despre SLA-uri, trebuie subliniat că majoritatea covârșitoare a furnizorilor de cloud își limitează responsabilitatea pentru neîndeplinirea SLA-ului la plata lunară sau la un procent din plată. De exemplu, AWS și Azure oferă o reducere de 100% la taxa de abonament în cazul în care se depășește pragul de disponibilitate de 95% (36 de ore pe lună), iar Yandex.Cloud oferă 30%.
Și bineînțeles, nu trebuie uitat că cloud-urile nu sunt disponibile doar în varianta gigantilor precum Amazon sau Yandex. Există și cloud-uri mai mici — de dimensiunea unei pisici sau chiar a unei șoimi. Așa cum a arătat exemplul CloudMouse, uneori cloud-ul pur și simplu se termină. Nu veți primi nicio compensație, nicio reducere — nu veți primi nimic, în afară de o pierdere totală de date.
Având în vedere problemele menționate mai sus în implementarea sistemelor IT de înaltă performanță în infrastructurile cloud, în ultimii ani a fost observat fenomenul "repatrierii cloud".
Până în 2020, a fost atins vârful așteptărilor exagerate pentru computația în cloud, iar conceptul se află pe calea dezamăgirii (conform ciclului de hype Gartner). Conform cercetărilor și până la 80% dintre clienții corporativi revin și intenționează să returneze sarcini din cloud în centrele lor de date din motive precum:
- Creșterea disponibilității / performanței;
- Reducerea costurilor;
- Pentru a respecta cerințele de securitate.
Ce este de făcut și cum stau lucrurile "de fapt"?
Nu există nicio îndoială că cloudurile au venit serios și pentru mult timp. Iar, cu fiecare an, rolul lor va crește. Totuși, trăim nu în viitorul îndepărtat, ci în 2020 într-o situație foarte specifică. Ce este de făcut cu cloudurile, dacă nu ești un startup, ci un client corporativ clasic?
- Cloudurile sunt, în primul rând, locul pentru servicii cu o încărcătură sezonieră imprevizibilă sau bine definită.
- În cele mai multe cazuri, serviciile cu o încărcătură stabilă și previzibilă sunt mai ieftine de întreținut în propriile centre de date.
- Trebuie să începi lucrul cu cloudurile cu medii de testare și servicii de prioritate scăzută.
- Analiza plasării sistemelor informaționale în cloud începe cu elaborarea unei metodologii de migrare dintr-un cloud în altul (sau înapoi în propriul centru de date).
- Plasarea unui sistem informațional în cloud începe cu elaborarea unui plan de backup în infrastructura pe care o controlezi.
Sursa: habr.com
