Ce este Cloud Hosting?

Cloud hosting este un hosting on-demand care poate să scaleze rapid și automat în sus și în jos bazat pe nevoile imediate.

Cloud nu este doar despre găzduirea magazinului online cu un furnizor de hosting cloud cum ar fi AWS, Microsoft Azure, Google Cloud Platform, Digital Ocean sau alții, ci este mai degrabă despre cum este construită arhitectura de hosting.

Pentru a înțelege diferențele între hosting de cloud și hosting tradițional, vom compara următoarele:

• Hosting Shared sau Dedicated

• Multi-Server

• Serverless & Kubernetes - ceea ce utilizăm la Zento

O comparație practică: Autostrăzile

Înțelegerea hostingului de Cloud poate fi dificilă, deci vom încerca să facem o comparație cu un echivalent ușor de înțeles din lumea reală: autostrăzile. Autostrăzile noastre imaginare sunt gratuit de construit, dar costă să fie operate, exact ca și serverele.

Să presupunem că avem o autostradă capabilă să suporte un trafic de 1000 mașini/oră, iar traficul mediu este de 500 mașini/oră. În timpul orelor de vârf, traficul urcă la 800 mașini/oră, ceea ce încă oferă o viteză de rulare bună. Dar înainte de un weekend prelungit, traficul urcă la 5000 mașini/oră, ceea ce rezultă la un blocaj complet; unii pasageri se întorc din drum și caută rute alternative. În același timp, în timpul nopții sunt sub 50 de mașini/oră, ceea ce este mult sub capacitatea de 1000 de mașini/oră.

Lărgirea autostrăzii cu benzi suplimentare înainte de weekendul prelungit este posibil în lumea noastră teoretică, însă impune închiderea temporară a autostrăzii; aceeași închidere temporară este necesară și la eliminarea benzilor suplimentare după weekendul aglomerat. Iar o problemă și mai mare este că trebuie să știm în avans dacă vom avea un trafic de 1500 sau 4000 de mașini/oră.

Mai există și cazul zilnic al unui transport cu gabarit depășit, ceea ce încetinește traficul normal în perioada în care tranzitează autostrada. De asemenea, dacă apare o alunecare de teren toată autostrada va fi închisă.

Să vedem cum fiecare dintre aceste scenarii imaginare se aplică la un setup de hosting.

Hosting Shared sau Dedicated

Acest setup este probabil cel mai răspândit setup de hosting și este soluția oferită de toți providerii de hosting non-cloud, precum și setup-ul default pe care îl ai atunci când pornești un server la un provider de cloud și configurezi magazinul online pe el.

În acest setup, magazinul tău rulează pe un server shared (partajat), un VPS (virtual private server) sau un server dedicat. Opțional, baza de date poate fi pe un server separat, ceea ce deși teoretic este multi-server, din punctul de vedere al aplicației este tot un singur server.

Cu un server shared, magazinul tău online împarte serverul fizic și resursele acestuia cu alte site-uri care rulează pe server, ceea ce poate cauza probleme de performanță chiar și când magazinul tău online nu are trafic crescut, dar un alt site de pe server are.

În cazul VPS-urilor, magazinul tău online rulează pe un server virtual într-un server fizic mai mare și are resurse rezervate doar pentru el. În acest caz, încărcarea altor VPS-uri din acel server nu ar trebui să afecteze performanțele VPS-ului tău.

Cu servere dedicate, magazinul tău rulează pe un server fizic complet separat de alte servere, însă în fapt este identic cu un VPS mai mare.

În toate aceste setup-uri, tot traficul magazinului online este direcționat la un singur server principal, care nu poate scala să răspundă nevoilor de trafic.

Ca și în exemplul cu autostrăzi, serverul este dimensionat puțin peste necesarul de trafic bazat pe mediile anuale din perioadele obișnuite, însă în timpul unor campanii de vânzări, această dimensiune este complet insuficientă. Scalarea orizontală nu este posibilă, deci singura soluție este scalarea verticală : se oprește serverul, se crește capacitatea sa și se pornește înapoi după un downtime; acest lucru poate să nu fie posibil cu un server dedicat sau dacă providerul de hosting non-cloud nu are capacitate disponibilă să scaleze VPS-ul (ceea ce este foarte posibil în perioade cum ar fi Black Friday). Ce se întâmplă atunci când hostingul nu poate scala pentru a acoperi acele creșteri sau dacă creșterile sunt neprevăzute? Magazinul online devine tot mai lent și la un moment dat pică și devine complet indisponibil, iar tu nu poți face nimic să remediezi problema, decât să aștepți ca utilizatorii să renunțe și traficul să revină la nivelul normal.

Transportul cu gabarit depășit din exemplul cu autostrăzile este prezent pe serverul tău sub forma unor task-uri mari care rulează periodic, cum ar fi update-uri în masă ale catalogului. Aceste task-uri încarcă serverul și încetinesc magazinul online, ceea ce poate fi frustrant pentru utilizatori și poate scădea conversiile.

În fine, dacă orice problemă apare pe server, magazinul tău este offline, exact ca și o autostradă afectată de o alunecare de teren.

Aceste setup-uri de hosting sunt ieftine și ușor de realizat, însă ele nu sunt scalabile odată cu traficul și sunt ineficiente financiar din cauza faptului că trebuie dimensionate pentru traficul de vârf și nu traficul mediu. Ele au de asemenea un risc de crash , pentru că orice s-ar întâmpla cu acel server principal ar face ca magazinul să fie offline.

Să vedem cum sunt setup-urile multi-server mai bune.

Multi-Server

Într-un setup multi-server, magazinul online rulează pe mai multe servere, ceea ce permite adăugarea de noi servere care să proceseze traficul în creștere. Acest lucru se numește scalare orizontală .

Cu provideri de hosting non-cloud, adăugarea de noi servere poate să dureze câteva ore sau chiar zile și va necesita intervenția programatorilor pentru configurare.

Cu providerii de hosting cloud, adăugarea unui nou server se întâmplă în 15 minute, iar cu un efort considerabil din partea echipei de programatori, poate fi configurat să se facă fără a necesita operațiuni manuale de configurare din partea lor.

Însă provocarea mare este că magazinul online trebuie să fie pregătit să ruleze pe un setup multi-server, ceea ce nici una dintre soluțiile populare open-source nu este capabilă să o facă astăzi, fără dezvoltări suplimentare. Așadar, există o investiție inițială considerabilă pentru a face un astfel de setup posibil.

Revenind la comparația cu autostrăzile: acest setup ar echivala cu construirea a două autostrăzi paralele, fiecare cu o capacitate de 1000 mașini/oră. Înainte de weekendurile prelungite, se pot adăuga încă 3 autostrăzi paralele capabile de un trafic total de 5000 mașini/oră iar când weekendul trece, ele se pot opri fără întreruperea traficului. Adăugarea de noi autostrăzi durează puțin, deci apar probleme doar dacă creșterile sunt subite.

Setupul minimal necesită cel puțin 2 servere cu un load balancer . Când este nevoie, se adaugă încă un server (adică scalare orizontală ) și traficul este automat transmis și către acesta. Cu provideri de hosting cum ar fi AWS, Azure sau GCP, se pot realiza setup-uri care să scaleze cu un click, însă tot poate dura 15 minute pentru ca noi servere să primească trafic; cu provideri non-cloud, automatizarea este de cele mai multe ori imposibilă, iar durata de timp poate fi de câteva ore.

Task-urile solicitante care rulează periodic vor trebui rulate pe un al 3-lea server, separat de cele care deservesc trafic către utilizatori, pentru a nu afecta performanța acestora. Avem așadar un setup de 2 servere pentru vizitatori, 1 server pentru aceste task-uri și apoi servere separate pentru baza de date și caching. Acestea însumează un cost operațional foarte crescut.

Setup-urile multi-server sunt complexe și drept urmare costisitoare de realizat, însă sunt în general scalabile odată cu traficul și izolate de crash-uri . Ele sunt foarte scumpe de operat din moment ce este nevoie de cel puțin 4 servere și din moment ce acesta trebuie scalate în zona maximală de trafic zilnic (având în vedere timpul necesar de scalare).

Să vedem cum un setup de cloud cu Serverless & Kubernetes este mai bun.

Serverless & Kubernetes

Kubernetes este un sistem de management de containere despre care povestim pe larg în articolul M2 în Kubernetes , dar pe scurt, împachetează o aplicație software cu tot ce are nevoie în mici containere (numite pod -uri) care rulează pe servere (numite node -uri). Denumirea de container vine de la containerele de transport maritim care au o dimensiune standardizată și pot fi încărcate pe vapoare, indiferent de conținutul lor.

Serverless este similar cu conceptul de containere, cu diferența majoră a faptului că managementul lor este realizat de providerul de cloud și se taxează fiecare execuție, adică pagină servită (pentru 1 milion de apelări costul este de $6.67 dacă execuția durează 0.3s și utilizează 1GB memorie). Astfel un magazin nu trebuie să plătească pentru timpii în care așteaptă trafic, iar asta este ceva ce providerii de cloud oferă fără un cost suplimentar.

Serverless este disponibil doar la providerii de cloud mari, iar Kubernetes deși poate fi configurat și la provideri non-cloud, rar este, din cauza complexității ridicate.

În exemplul cu autostrăzile, Kubernetes ar fi autostrada viitorului: noi benzi de 100 mașini/oră sunt automat adăugate în câteva secunde în funcție de nevoile de trafic; la creșterile de trafic prevăzute sau subite, autostrada scalează cu noi benzi în câteva secunde și ulterior când traficul scade, aceste benzi sunt închise automat; în timpul nopții, autostrada scade la 2 benzi. Serverless este și mai avansat: nu trebuie gestionată infrastructura autostrăzii sau scalarea, ci se plătește în funcție de numărul de mașini care tranzitează. Traficul cu gabarit depășit primește propria bandă largă, izolată de traficul normal.

Cu Kubernetes există o separare completă între servere (node-uri) și containerele care rulează pe ele (pod-uri), deci ele pot scala independent oricât este nevoie. Poți afla mai multe detalii în articolul M2 în Kubernetes .

Cu Serverless, separarea este și mai bună, căci gestiunea sistemelor de sub containere cade în sarcina providerului de cloud.

Singurul dezavantaj al Kubernetes este că setup-urile sunt complex de construit și întreținut. Adaptarea aplicației pentru rularea în Kubernetes este și ea dificilă, iar pentru Serverless este uneori imposibilă.

Deci Kubernetes și Serverless sunt complexe de construit într-un setup propriu, dar ele sunt cele mai scalabile soluții, complet izolate de crash-uri și cele mai eficiente ca și cost din moment ce se plătește doar pentru capacitatea utilizată. Ele sunt și cea mai bună opțiune pentru aplicații headless, în care frontend-ul și backend-ul sunt decuplate și astfel fiecare componentă a aplicației poate scala în propria infrastructură.

Concluzii

Când ne gândim la hostingul Cloud, avantajele sunt legate de scalabilitate, redundanță și eficiență financiară.

Hostingul Zento care rulează pe Kubernetes și Serverless este cel mai avansat setup disponibil azi și este concentrat pe scalabilitate, stabilitate și eficiență financiară.