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

Incidentele majore de cloud, cum a fost cel de săptămâna aceasta de la AWS, sunt inevitabile. Următoarele patru metode pot ajuta firma dvs. să treacă prin aceste situații.
Cu ore nesfârșite de productivitate pierdută, sisteme financiare perturbate pentru milioane de utilizatori și posibil sute de miliarde de dolari pierdute, întreruperea de săptămâna aceasta a serviciului AWS a fost o zi teribilă pentru echipele de IT globale. Desigur, a fost și cea mai proastă catastrofă de cloud la nivel global de la ultima dată… și până la următoarea.
Indiferent dacă sunteți pe AWS, GCP, Azure sau pe orice altă platformă, întreruperile majore sunt o realitate a calculului de 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-veți temele.
Adesea, echipele se îndreaptă spre dezastru, 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 are singur 31 de zone de disponibilitate și 31 de locații de rețea de margine – și unele opțiuni sunt mult mai fiabile decât altele.
Într-adevăr, regiunea US-EAST-1 a AWS, care a cauzat întreruperea de săptămâna aceasta, a fost în spatele unor perturbări majore în 2020, 2021 și 2023, și a fost cunoscută î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 și ofertele abundente ale regiunii. Dar, având în vedere amploarea întreruperii, este imposibil să nu ne gândim la câte firme au fost luate complet pe nepregătite – și ar fi ales cu siguranță regiunile mai fiabile, dacă ar fi fost conștiente de compromisurile implicate. Am întâlnit personal lideri de IT care au ales să se mute în alte regiuni AWS doar după experiențe negative 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 pe care lucrați. Puncte de plecare includ unelte gratuite, cum ar fi cloudprice, Cloudping și vederile istorice ale incidentelor de la uneltele de sănătate a serviciilor de cloud oferite de hyperscalers.
Alegeți portabil în loc de cloud-native.
Atunci când proiectați configurații de cloud, ruta mai simplă 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 în cazul în care cloud-ul dvs. se închide.
Pentru a evita această stratificare suplimentară de dependență de cloud, optați pentru produse independente și/sau open-source, acolo unde este posibil. Câteva exemple de înlocuiri includ cele de mai jos:
|
Categorie |
Exemplu de ofertă nativă |
Alternative open-source includ… |
|
Autentificare și identitate |
AWS Cognito |
Keycloak |
|
Căutare |
Azure Monitor |
Elasticsearch |
|
Baze de date relationale |
Google Cloud SQL |
PostgreSQL |
|
Baze de date NoSQL |
AWS DynamoDB |
MongoDB |
|
Orchestration de containere |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
Monitorizare și 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ă de acasă 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 redesenat complet abordarea sa pentru dezastre în urma acestuia. Schimbările au inclus eliminarea blocajelor arhitecturale și adresarea 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 bun punct de plecare în călătoria dvs. este să urmați recomandarea Datadog de a “începe cu ceea ce este important pentru utilizatorul final” și de a construi sisteme 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 legați 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 firmele complet de impactul unei întreruperi masive de cloud, 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.












