De ce site-ul dvs. de comerț electronic are nevoie de o abordare multi-cloud activă-active în acest sezon de sărbători

Pentru liderii de comerț electronic, sărbătorile aduc două certitudini: un aflux masiv de cumpărători și un risc crescut de întreruperi ale furnizorilor de cloud. Întreruperile majore ale cloud-ului par să devină mai frecvente și mai devastatoare. Regiunea AWS US-East-1, de exemplu, are o istorie de întreruperi semnificative în sezonul sărbătorilor. La fel, în fiecare an, în jurul lunii ianuarie, Microsoft Azure are tendința de a avea probleme de întârziere a rețelei sau întreruperi ale rețelei din cauza planului de lansare sau testare în anumite regiuni. Și nu trebuie decât să ne uităm înapoi la această vară trecută, când o întrerupere majoră a cloud-ului Google a afectat o gamă largă de aplicații, pentru a ne aminti că niciun furnizor nu este imun.

Dacă sunteți responsabil de o operațiune de comerț electronic, nu doriți să aflați că, chiar dacă ați configurat totul corect, ceva a încetat să funcționeze în timpul perioadei celei mai critice a anului. Aceste tendințe de întrerupere și probleme ale furnizorilor de cloud nu ar trebui să fie pe radarul dvs., și, sincer, nu ar trebui să fie. Dacă sunteți un inginer de fiabilitate a site-ului, nu ar trebui să vă faceți griji cu privire la faptul că o întrerupere a cloud-ului va afecta aplicația dvs., nici nu ar trebui să încercați să ajustați infrastructura dvs. pe loc în timpul unei probleme. În schimb, ar trebui să reexaminați ce știți despre cloud-ul multi-cloud.

Aplicații multi-cloud

Dacă organizația dvs. plătește taxe pentru AWS, Azure și GCP, aveți într-adevăr toate cele trei cloud-uri la dispoziție. Cu toate acestea, în timp ce puteți utiliza toate cele trei, este important să examinați ce se întâmplă atunci când mergeți la un nivel mai profund. Sunt unele dintre aplicațiile dvs. specifice pentru AWS, Azure sau GCP? Vor continua să funcționeze dacă un furnizor de cloud este închis și trebuie să treceți rapid la altul?

Aplicația dvs. trebuie să funcționeze perfect pe orice cloud. Acesta este adevăratul setup multi-cloud. Dacă doriți să fiți agnostic la cloud, nu puteți doar să plătiți pentru multi-cloud; trebuie să vă asigurați că aplicațiile dvs. sunt și ele multi-cloud.

Mai mult, să depindeți de un singur furnizor introduce constrângeri inerente asupra capacității de calcul, limitării ratei API și disponibilității regionale. O arhitectură multi-cloud reală crește puterea dvs. de calcul agregată și oferă rezistență împotriva acestor constrângeri. Vă deblochează capacitatea de a scala la cerere dincolo de limitele unui singur furnizor, de a extinde rapid capacitatea în diferite regiuni și de a asigura o performanță constantă în timpul zilelor de vârf ale cumpărăturilor. Dar avea o aplicație portabilă, agnostică la cloud, este doar primul pas; următorul pas este să o implementați într-o arhitectură cu adevărat rezilientă.

Trecerea la o abordare activă-active

Acest lucru necesită o pregătire serioasă din partea DevOps. Este incredibil de greu să aveți o strategie de Continuitate a Afacerii și Recuperare după Dezastru (BCDR) de 100% precisă, deoarece atunci când vine vorba de rularea operațiunilor live, există multiple puncte de eșec. Nu doriți să testați strategia dvs. BCDR în timpul unei întreruperi, așa că vă puteți simți că tot ce puteți face este să preziceți posibile scenarii și apoi să vă pregătiți corespunzător.

Sfatul meu pentru inginerii de fiabilitate a site-ului este să proiecteze pentru eșec din oficiu. Acest lucru înseamnă să aveți un cloud secundar sau chiar terțiar care rulează într-o stare activă. O strategie BCDR limitată la un singur furnizor este un punct unic de eșec; dacă planul de control sau rețeaua de bază a furnizorului eșuează, întregul plan de recuperare devine inutil.

În timpul sezonului sărbătorilor, este obișnuit ca numărul de vizitatori să crească brusc, forțând platforma sau aplicația dvs. să înceapă să funcționeze la o capacitate redusă. Dacă ați creat deja o copie a aplicației dvs. care funcționează, o copie secundară, puteți trece la efectuarea de echilibrare a încărcăturii, astfel încât să puteți devia unele solicitări către altă instanță a aplicației dvs.

Această abordare activă-active înseamnă că aveți produsul dvs. complet duplicat, rulând undeva altundeva. Dacă furnizorul dvs. de cloud principal experimentează o degradare severă sau o întrerupere, puteți trece fără probleme 100% din traficul dvs. către furnizorul secundar prin DNS sau un echilibrator global de încărcătură, făcându-l punctul de intrare principal fără întrerupere pentru clienții dvs.

Costul real al neadoptării abordării multi-cloud

În timp ce costul de a rula un cloud secundar nu este neglijabil, el este nesemnificativ în comparație cu impactul comercial al unei întreruperi majore: să vă ceri scuze clienților după un eșec de fiabilitate, să încercați să-i asigurați că nu se va întâmpla din nou și să-i convingeți să nu vă părăsească pentru unul dintre competitorii dvs. Să nu uităm toți banii pierduți din cauza vânzărilor pierdute pe care nu le puteți recupera. La FluidCloud, am văzut acest scenariu desfășurându-se de nenumărate ori: companiile investesc masiv într-un singur furnizor, doar pentru a se găsi pe partea greșită a unei întreruperi, fără nicio soluție imediată.

Cu toate acestea, este suficient de greu să controlați costurile dvs. dacă utilizați doar un furnizor de cloud; costurile dvs. de cloud arată probabil ca un grafic exponențial. Dacă adoptați multiple cloud-uri, acel grafic exponențial va arăta și mai abrupt.

Când duplicați infrastructura dvs. din cloud-ul principal, nu doriți în mod natural ca costurile dvs. să se dubleze. Prin urmare, vă recomand să vă concentrați pe cloud-urile mai ieftine care oferă performanțe competitive la un punct de preț mai mic. Dacă aveți o copie secundară care rulează într-un cloud mai ieftin, veți avea în continuare redundanță activă-active, dar la un cost mai mic. Este o situație câștig-câștig.

Gânduri finale

Rularea aplicațiilor active-active pe multiple furnizori de cloud nu înseamnă doar crearea unei copii de rezervă. Înseamnă construirea pentru reziliență în timp real, asigurarea că afacerea dvs. nu are un singur punct de eșec și capacitatea de a oferi viteză constantă, chiar și în timpul creșterilor de trafic.

În acest sezon de sărbători, nu doar sperați la fiabilitate. Construiți pentru ea. Proiectați sistemele dvs. pentru a rula constant, indiferent de care furnizor de cloud sau regiune eșuează. Oferiți o experiență perfectă clienților dvs. prin adoptarea unei arhitecturi multi-cloud active-active, cu adevărat.