Managementul multi-cloud

„Multi-cloud” este adesea folosit ca termen strategic — un motiv pentru a te diversifica dincolo de un singur furnizor, a negocia prețuri mai bune sau a îndeplini o cerință de rezidență a datelor. Managementul multi-cloud este stratul operațional mai restrâns, aflat sub această strategie: instrumentele și procesele care permit unei echipe de infrastructură să ruleze efectiv sarcini de lucru la mai mulți furnizori, fără să trateze fiecare dintre ei ca pe un proiect separat. Fără el, „multi-cloud” înseamnă, în practică, o consolă, un set de credențiale și o terminologie separate pentru fiecare furnizor — și niciun loc unic în care să răspunzi la o întrebare de bază: ce infrastructură există chiar acum și cine a modificat-o ultima dată.

Fiecare furnizor vine cu propria consolă, CLI, model IAM și vocabular pentru aceleași primitive de bază — o mașină virtuală, un grup de securitate, o zonă DNS, un volum de stocare. Această fragmentare este problema reală pe care o rezolvă managementul multi-cloud. Totul începe cu descoperirea: conectezi un cont la un furnizor și vezi imediat un inventar al a ceea ce rulează deja acolo, înainte ca ceva să fie migrat sau modificat. De acolo, se aplică un flux de lucru unic și consistent pentru acțiunile obișnuite din ciclul de viață — provizionare, pornire, oprire, redimensionare, distrugere — indiferent de furnizorul la care se află resursa. Implementările mai solide gestionează configurația live și sincron direct la furnizor, nu printr-o copie stocată în propria bază de date, astfel încât o modificare făcută prin instrument este exact aceeași modificare pe care ai vedea-o autentificându-te în consola proprie a furnizorului respectiv.

Managementul multi-cloud depășește ciclul de viață al resurselor de calcul și se extinde la părțile din operațiuni care creează un risc real atunci când sunt inconsistente între furnizori. Controlul accesului trebuie să funcționeze la fel peste tot — single sign-on, permisiuni bazate pe roluri și elevare condiționată de aprobare pentru acțiunile sensibile, în loc de un model de identitate diferit pentru fiecare furnizor. Fiecare modificare trebuie să poată fi atribuită unei persoane, motiv pentru care un jurnal de audit care acoperă toți furnizorii conectați contează aici mai mult decât într-o configurație single-cloud — este diferența dintre o întrebare la care se poate răspunde și o investigație. Și pentru că costul infrastructurii este unul dintre primele lucruri care devine ilizibil între furnizori, vizibilitatea costurilor și detectarea anomaliilor trebuie să se afle în același loc cu provizionarea, nu într-un tabel separat reconciliat o dată pe lună. Multe echipe rulează și infrastructură care nu e deloc cloud — servere on-premise sau bare-metal — și se așteaptă ca aceeași disciplină de monitorizare și aplicare a patch-urilor să se extindă și acolo.