Connect with us

Lideri de opinie

Începeți pregătirile acum pentru următoarea întrerupere a cloud-ului

mm

Incidente majore de cloud, cum a fost cel de săptămâna aceasta de la AWS, sunt inevitabile. Aceste patru metode pot ajuta firma dvs. să treacă prin acestea.

Cu ore nesfârșite de productivitate pierdută, sisteme financiare perturbate pentru milioane de utilizatori, și potențial sute de miliarde de dolari pierdute, întreruperea de săptămâna aceasta a AWS a fost, fără îndoială, o zi teribilă pentru echipele globale de IT. Desigur, a fost și cea mai proastă catastrofă globală de cloud de la ultima… și până la următoarea.

Indiferent dacă sunteți pe AWS, GCP, Azure sau orice altă platformă, întreruperile majore sunt o realitate a calculului în cloud. Deci, ce poate face firma dvs. pentru a atenua loviturile? Mai jos, voi oferi patru pași pe care echipa dvs. îi poate face imediat.

Aduceți-vă scepticismul – și faceți-va temele.

Adesea, echipele vor să cadă într-o capcană, intrând în aranjamente de cloud, presupunând că marile corporații de cloud sunt în mod inerent de încredere. Pentru a fi siguri, cele mai de încredere firme și-au câștigat reputația pentru un motiv. În același timp, fiecare cloud și hyperscaler oferă o gamă largă de opțiuni de infrastructură – AWS America de Nord singur are 31 de zone de disponibilitate și 31 de locații de rețea Edge – și unele opțiuni sunt mult mai fiabile decât altele.

Într-adevăr, regiunea US-EAST-1 a AWS, cauza întreruperii de săptămâna aceasta, a fost în spatele unor perturbări majore în 2020, 2021 și 2023, și a fost cunoscută de multă vreme în anumite cercuri de IT ca fiind cea mai puțin fiabilă regiune. Multe firme au înțeles probabil situația, dar au luat un risc calculat, având în vedere costul scăzut al regiunii și ofertele sale abundente. Dar, având în vedere amploarea întreruperii, este imposibil să nu ne gândim la câte firme au fost luate cu totul pe nepregătite – și ar fi optat cu siguranță pentru regiunile mai fiabile, dacă ar fi fost conștiente de compromisuri. Am întâlnit personal lideri IT care au ales să se mute în alte regiuni AWS, doar după experiențe proaste cu US-EAST-1 în trecut.

Lecția de aici este să faceți temele atunci când vine vorba de opțiuni de infrastructură de cloud, indiferent de cloud-ul cu care lucrați. Locuri în care să începeți includ unelte gratuite, cum ar fi cloudprice, Cloudping, și vederile istorice ale incidentelor de la uneltele de sănătate a serviciilor cloud oferite de hyperscaler.

Alegeți portabil în loc de cloud-native.

Când proiectați configurații de cloud, drumul cel mai simplu este să mergeți cloud-native. Dar, deși este convenabil să selectați aplicații gata făcute de și pentru furnizorul dvs. de cloud, aceste opțiuni cloud-native vă lasă mai expuși dacă cloud-ul dvs. se închide.

Pentru a evita această altă straturi de dependență de cloud, optați pentru produse independente și/sau open-source, acolo unde este posibil. Câteva exemple de înlocuiri includ următoarele:

Categorie

Exemplu de ofertă nativă

Alternative open-source includ…

Autentificare & Identitate

AWS Cognito

Keycloak

Căutare

Azure Monitor

Elasticsearch

Baze de date relationale

Google Cloud SQL

PostgreSQL

Baze de date NoSQL

AWS DynamoDB

MongoDB

Orchestrare de containere

Azure Kubernetes Service (AKS)

Kubernetes

Monitorizare & Observabilitate

Google Cloud Monitoring

Prometheus + Grafana

Cozi de mesaje

AWS SQS/SNS

Apache Kafka

Stocare de obiecte

Azure Blob Storage

MinIO

Poartă de API

Google Cloud API Gateway

Kong

Pentru a fi siguri, construirea unei părți mai mari a stivei dvs. de cloud de la zero înseamnă mai multă muncă pentru echipele dvs. Cu toate acestea, în experiența mea, odată ce aveți infrastructura funcțională, nu există practic nicio diferență între adăugarea de sarcini de lucru la o infrastructură casnică stabilită sau la una cloud-native. Și beneficiile în ceea ce privește reziliența – și nu în ultimul rând, reducerea dependenței de cloud – fac opțiunile independente extrem de valoroase.

Proiectați pentru eșec.

Având în vedere că eșecurile de cloud vor apărea, asigurați-vă că proiectați produsele dvs. cu eșecul de cloud în minte. Un exemplu de urmat este Datadog: într-un incident din 2023, firma a pierdut brusc accesul la peste jumătate din nodurile sale Kubernetes în producție și a reproiectat complet abordarea sa de dezastre în consecință. Schimbările au inclus înlăturarea blocajelor arhitecturale și abordarea datoriilor tehnice, astfel încât eșecurile parțiale să nu se propageze prin sistem, îmbunătățirea ingestiei și stocării de date pentru o disponibilitate mai mare a datelor în timpul întreruperilor și construirea de sisteme pentru a se recupera automat la scară. Un loc excelent pentru a începe în călătoria dvs. este să urmați recomandarea Datadog de a „începe cu ceea ce este important pentru utilizatorul final” și să construiți măsuri de siguranță pentru a proteja ceea ce contează cel mai mult.

Rulați pe cel puțin două cloud-uri.

Desigur, cel mai bun mod de a nu fi legat de eșecurile de cloud este redundanța multicloud. Atingerea unei adevărate fluidități multicloud este o întreprindere uriașă pentru multe firme, deoarece este extrem de greu să traduceți infrastructura de la un cloud în altul. Dar construirea de infrastructură pe doar două cloud-uri este un punct de plecare puternic – și adesea realizabil. Esențial pentru a face acest lucru să funcționeze este să aveți o echipă în loc cu un expert în fiecare dintre cloud-urile pe care le rulați.

Pentru a fi siguri, nimic nu poate proteja în totalitate firmele de impactul unei întreruperi masive, cum a fost cea de săptămâna aceasta. Dar, cu diligența potrivită, o abordare portabilă de cloud, proiectarea pentru eșec și utilizarea „dual-cloud” ca o piatră de temelie pentru adevăratul multicloud, firmele pot fi mult mai agile atunci când va apărea următorul (și, din nefericire, inevitabil) incident major de cloud.

Harshit Omar este co-fondator și CTO al FluidCloud, unde construiește viitorul infrastructurii cloud - permițând companiilor să migreze, să replice și să optimizeze încărcăturile de lucru în mod transparent în medii multi-cloud. El a fost anterior primul inginer la Accurics, unde a condus eforturile de dezvoltare core a motorului de politici și a platformei de securitate cloud.

Cu o expertiză profundă în Go, Kubernetes, Terraform și conformitate cloud, Harshit a petrecut peste un deceniu proiectând sisteme reziliente în AWS, Azure și GCP.

Misiunea lui acum este să elimine blocarea cloud și să facă infrastructura la fel de portabilă și rezilientă ca și codul.