Ce este guvernanța în Azure și de ce ar trebui să îmi pese?

Esențial în acest context este echilibrul.
Pe de-o parte avem dezvoltarea și inovația, având drept scop explorarea de noi oportunități și crearea de tool-uri ce cresc productivitatea și satisfacția utilizatorilor. Aici este nevoie de acces neîngrădit la resurse, precum și dezvoltarea unui ciclu rapid de producție și release, ce, în general, sunt topic-uri pentru care management-ul de costuri nu e unul din subiectele majore de interes. 

Pe de altă parte, corpul de guvernanța e mandatat să reglementeze și să aplice politici organizaționale, reglementari și securitate, dar sa si adreseze aspecte adiacente precum costuri, redundanța și fragmentarea, și multe altele.

Se întâmpla ocazional ca aceste doua entități să intre în conflict de interese, însă, în același timp, trebuie să colaboreze și să facă compromisuri. Prin compromisuri ne referim la găsirea celei mai bune soluții care să satisfacă cerințele cruciale ale ambelor parți, și nu la reducerea sau flexibilizarea acestor cerințe, ce ar putea afecta integritatea operațională.

Venind în întâmpinarea acestui scenariu, dar nu numai, Microsoft a dezvoltat un framework ce ajuta la o adopție și o tranziție mai ușoară în cloud, numit Cloud Adoption Framework (CAF).

CAF propune cinci discipline primare, necesare în implementarea guvernanței în cloud.

Managementul de costuri – pentru majoritatea clienților, costurile sunt unul din factorii esențiali în ceea ce privește adopția sau sustenabilitatea în cloud. Provocarea constă în a crea o soluție ce va ajuta în optimizarea costurilor de implementare și operare, evitarea depășirii bugetului, sau a plăti extra pentru resurse neutilizate la întregul potențial (right-sizing).

Identitatea – odată cu mutarea din ce în ce mai mult a graniței de securitate din zona clasică, către identitate, ca fiind noul perimetru, trebuie să fim conștienți de anumite aspecte precum “credential leaking”, integrarea cu alți provideri de identitate (Facebook, Google, etc) sau dependențe de platforme de identitate de generație anterioară. Conștientizarea acestor aspecte va ajuta în adopția unui mecanism robust de identitate, care să fie în conformitate cu standardele și cerințele din cloud actuale si viitoare.

Securitate – Postura “Zero Trust” trebuie să devină un standard de facto atunci când considerăm crearea unei guvernanțe ce are de-a face cu unul din cele mai importante zone de interes pe care o organizație trebuie să le aibă. Având în vederea multitudinea de servicii și produse ce apar constant în cloud, suprafața de atac cibernetic se schimbă de la zi la zi, și, deci, securizarea deopotrivă a sistemelor/aplicațiilor critice, dar nu numai, devine de importanță capitală.

Consistența resurselor -Are în sfera de interes crearea de procese standardizate și repetabile, necesare în gestionarea și utilizarea de resurse, optimizând în același timp aspectul costului, dar și care să ajute în reducerea timpului necesar pentru recuperarea din situații critice și avarii (RPO – recovery point objective și RTO – recovery time objective).  În același timp, consistența trebuie asigurată și de alte mecanisme mai puțin vizibile, dar la fel de importante, precum convenția numelor și expunerea metadatelor acestora, spre a fi consumate în organizație.

Accelerarea dezvoltărilor și implementărilor – Având în vedere ca trebuie să evitam cat mai mult posibil perturbarea serviciilor prin mentenanță și situații neprevăzute, deployment-ul manual, chiar daca vine la pachet cu o documentație solidă, e de dorit să devină o practică din ce în ce mai rară. Metode mai suple, precum DevOps devin noul standard, fiind create pentru și permițând un deployment continuu, dar și crescând substanțial gradul de automatizare. Împreună cu mecanisme integrate, reduc posibilitatea ca modificările  nedorite și greșelile atribuite factorului uman să afecteze mediul de producție și experiența utilizatorului.

De ce avem nevoie de guvernanță?

Așa cum am menționat la început, unul din scopurile principale este acela de a minimiza riscurile proiectelor IT.

Acest risc este în mod special vizibil în companiile care sunt prezente în al doilea val de adopție în cloud.

Primul val, reprezentat de mutarea resurselor în cloud prin metoda de rehost-ing (lift-n-shift), deși de comun acceptat ca un pas natural în direcția adopției, este aproape întotdeauna insuficient atunci când îl aliniem cu cele cinci discipline. Modelul de distribuție a responsabilității în acest caz e adresat numai parțial și nu aduce beneficii sustenabile te termen lung.

Al doilea val este reprezentat de maturarea aplicațiilor și resurselor deja utilizate, cu un focus substanțial pe schimbarea arhitecturii astfel încât să beneficiem de avantajele superioare ale dezvoltărilor făcute explicit pentru cloud.

În același timp, companiile trebuie să răspundă rapid nevoilor clienților, aderând simultan la, si impunând standarde consistente ce satisfac reglementările instituțiilor de acreditare externe.

În trecut, crearea de mecanisme care să satisfacă această nevoie prin metode clasice duceau la o reducere a abilității de inovație și încetineau adopția, în mare parte datorită faptului că erau implementate manual. În unele cazuri când companiile făceau rabat la implementarea unei guvernanțe solide, deși viteza implementărilor creștea, rezultatul nu era conform cu standardizările.

Nici unul din aceste scenarii nu e ideal și devine clar ca organizațiile și clienții deopotrivă au nevoie de control, dar și de viteza, în aceeași măsură.

Așadar, avem nevoie de guvernanța în cloud din aceleași motive pentru care un oraș are nevoie de intersecții, semafoare și limitatoare de viteza. Fără niște bune practici, exista un risc real ca lucrurile să degenereze rapid în haos, indiferent de forma ce acesta o poate lua.

Cum putem începe implementarea unei guvernanțe?

Există o percepție prezentă în mod curent, conform căreia crearea unei guvernanțe în cloud e necesară înainte de a începe adopția.

În realitate, probabilitatea ca acest lucru să se întâmple e relative redusă. În mare măsură se datorează faptului ca inovația (reprezentata de obicei de Shadow IT și developeri) va fi deja adoptat parțial tehnologia cloud, și va fi împărtășit  beneficiile acestuia. Pe de altă parte, mai ales în organizațiile medii și mari, având în vedere complexitatea proceselor și a business-ului, crearea acestei guvernanțe ar fi un efort major care ar întârzia suplimentar adopția în cloud.
În același timp însă, e obligatoriu ca în primele faze ale adopției, să începem lucrul la o guvernanța de tip MVP (Minimal Viable Product), care să ne permită identificarea corecte a nevoii de transformare digitala, să avem în vedere considerentele de tip “privacy & compliance”, și care să găsească o modalitate sustenabilă prin care să ajutam organizația să înțeleagă și să accepte schimbările din punct de vedere al tehnologiei și productivității.

Acest MVP va evolua ulterior ca să încorporeze toate cele cinci discipline, însă în diferite proporții, bazat pe direcția dictata de factorii de risc ce trebuie adresați.

E totuși foarte recomandat ca MVP-ul să conțină identitatea, securitatea și accelerarea implementărilor ca discipline fundamentale.

Ce mecanisme avem la dispoziție pentru implementarea guvernanței?

 Management groups (MG) – permit organizarea subscripțiilor într-o forma logic-ierarhica, iar aplicarea condițiilor și politicilor de guvernanță se face cascadat, în conformitate cu ierarhia.  Concret, toate resursele prezente în subscripțiile dintr-un MG vor moșteni automat condițiile. Ne putem gândi la aceasta ierarhie ca fiind similară cu alocarea permisiunilor la nivel de sistem de fișiere: permisiunile date pe un director părinte vor fi moștenite de toate celelalte directoare și fișiere prezente sub acest părinte. Avantajul adus de acest serviciu e dat de simplificarea substanțială a aspectului operațional în ceea ce privește deployment-ul și change management.

 Azure Policy (AP) – ne ajută să menținem un mediu conform cu standardele dictate de entitățile interne sau externe organizației, prin crearea și implementarea unor seturi de reguli care să fie aplicabile resurselor din Azure. AP e indispensabil daca vrem să:

• creăm politici care să auditeze și aplice condiții resurselor din portofoliu – ex: dacă resursele de tip storage din resource group-ul de producție sunt accesibile doar de la o anumită adresă IP;
• creăm  seturi de politici (initiative) care să fie aplicabile ca un tot unitar, simplificând în acest fel aspectul operațional – ex: dorim ca pentru toate resursele de tip mașină virtuala să verificam daca au disk-urile criptate, și dacă fac parte dintr-o familie/dimensiune anume;
• adresăm resurse și configurații neconforme – ex: verificăm dacă toate bazele de date din mediul de producție sunt susceptibile la ștergere accidentală, și dacă da, creăm  un „delete lock” automat pentru protecție, care vor împiedica ștergerea atâta vreme cât acest lock e prezent;
• refuzăm crearea sau modificarea resurselor, condiționate de regulile de guvernanță ale organizației – ex: permitem crearea unei mașini virtuale numai în anumite regiuni, și/sau făcând parte numai din anumite dimensiuni.

În plus, AP vine prepopulat cu o mulțime de politici predefinite pentru un număr variat de scenarii, iar daca ceva trebuie ajustat , putem pleca de la o politică predefinită pe care o putem extinde, sau putem crea politici noi de la zero.

 Blueprints (BP) – în timp ce Azure Policy vizează managementul și atribuirea politicilor definite, BP-urile împachetează unul sau mai multe artefacte într-o definiție proprie. Artefactele reprezintă obiecte și acțiuni ce pot fi deploy-ate independent sau în combinație și care au ca scop managementul resurselor într-un mod unificat și repetabil. De exemplu, dacă dorim să creăm  în mod automatizat aceleași resurse cu aceleași proprietăți în mediul de dezvoltare și de producție, iar acestor resurse să le aplicam un set de condiții guvernante.

BP sunt foarte benefice pentru companii ce au nevoie să controleze mai multe medii și subscripții, folosindu-se de o soluție de tip “one click”, preconfigurată cu resurse, politici, securitate, permisiuni de acces, etc.

 Resource Graph (RG) – ne ajută să explorăm și să inventariem resursele din Azure într-un mod eficient, în același timp obținând și o vedere completă în ceea ce privește relaționarea dintre ele, în mod ierarhic.
Query-urile prin care facem acest lucru sunt bazate pe Keyword Query Language (KQL), același limbaj folosit de către Azure Monitor.
Având în vedere că RG interoghează un “snapshot” al resurselor, beneficiem bineînțeles de o viteză de răspuns superioară.
Mai mult decât atât, putem expune aceste resurse, într-un mod grafic, prin intermediul Azure Dashboard, astfel încât să avem o privire de ansamblu asupra configurației și sănătății resurselor.

 Cost management – nu în ultimul rând, soluțiile de management de costuri pe care Azure le expune permit o analiza în timp real a costurilor asociate, în care se poate face “drill down” granulat astfel încât să putem verifica consumul resurselor în funcție de diferiți parametri si factori. Împreuna cu funcția de bugetare, permite o prognoză asupra consumului, precum și a tendințelor. În același timp, descoperă și alertează asupra diferitelor anomalii de consum, iar, împreună cu Azure Advisor, face o combinație excelenta menita să permită dimensionarea corecta a resurselor (right-sizing).

Surse video: Microsoft Mechanics, Microsoft Developer, Microsoft Azure