Zasady architektury dla chmury

Przetwarzanie w chmurze nie powinno by� trudne do przyj�cia, pod warunkiem, �e Twoja organizacja jest kompetentna, ch�tna do wprowadzania zmian i posiada odpowiednie zasoby. Je�li zastosowa�e� si� ju� do zasad zawartych w dw�ch pierwszych cz�ciach tej ksi��ki, oznacza to, �e jeste� kompetentny i ch�tny do wprowadzania zmian, dlatego te� nie powinien mie� problem�w obejmuj�cych przetwarzanie w chmurze. Pe�niejsze przyj�cie przetwarzania w chmurze jest ogromnym przedsi�wzi�ciem, ale mo�e by� do�� bezbolesne, je�li zostanie w�a�ciwie wykonane. Problem z pe�niejszym wykorzystaniem chmury obliczeniowej polega na tym, �e znacznie pogarsza zar�wno braki organizacyjne, jak i techniczne. Je�li ju� dzi� zmagasz si� z utrzymaniem platformy, chmura z pewno�ci� pogorszy Twoje problemy. Z drugiej strony chmura mo�e by� r�wnie transformuj�ca w odpowiednich r�kach. Przetwarzanie w chmurze jest pot�ne, a ci, kt�rzy go opanuj�, b�d� mieli przewag� konkurencyjn� w nadchodz�cych latach. W tym rozdziale om�wimy, jak e-commerce jest wyj�tkowy z punktu widzenia architektury, a nast�pnie, jak zaprojektowa� e-commerce dla chmury. Dodatkowa uwaga zostanie skoncentrowana na tym, czym jest skalowalno�� i jak j� osi�gn��. Kolejne cz�ci tej cz�ci ksi��ki omawiaj�, jak faktycznie przyj�� r�ne formy przetwarzania w chmurze.

Dlaczego eCommerce jest wyj�tkowe?

Przyjrzyjmy si� kilku wyj�tkowym cechom e-commerce. Oto powody, dla kt�rych platformy eCommerce s� projektowane i wdra�ane inaczej ni� wi�kszo�� innych system�w.

Generowanie przychod�w

Wraz ze wzrostem sprzeda�y detalicznej wielokana�owej wi�kszo�� przychod�w p�ynie teraz przez platform� e-commerce organizacji. Awaria na ca�ej platformie zapobiegnie uzyskiwaniu przychod�w przez ca�� organizacj�. Jest to odpowiednik blokowania klientom dost�pu do wszystkich fizycznych sklep�w detalicznych. Wiele organizacji jest teraz w stanie dok�adnie obliczy�, ile ka�da sekunda przestoju kosztuje ich utracone przychody. Jednak rzeczywistym d�ugoterminowym kosztem przestoju s� szkody wyrz�dzone reputacji marki. Wielu klient�w nie wr�ci po awarii. Z powodu tego, jak wa�ny jest e-commerce, wi�kszo�� rodowisk jest ogromnie przepe�niona.

Widoczno��

Widoczno�� charakteryzuje wi�kszo�� platform e-commerce, cz�sto s�u��c jako twarz publiczna i coraz cz�ciej zaplecze organizacji. Ka�de ��danie HTTP odzwierciedla t� mark�, podobnie jak stan fizyczny sklepu. Ka�da milisekunda op�nionego czasu reakcji s�abiej odbija si� na tej marce. 100-milisekundowa reakcja zachwyci klient�w i sprawi, �e marka zab�y�nie, a 10-sekundowa reakcja zdenerwuje klient�w i zniszczy mark�.

Spikiness ruchu

Cech� charakterystyczn� e-commerce jest to, �e podlega on cz�sto nieprzewidywalnym skokom ruchu, kt�ry jest o jeden lub dwa rz�dy wielko�ci wi�kszy ni� stan ustalony. Wi�kszo�� oprogramowania po prostu nie zosta�a stworzona do obs�ugi ogromnych skok�w ruchu. Na przyk�ad pule po��cze� z bazami danych na serwerach aplikacji cz�sto nie mog� natychmiast podwoi� lub potroi� wielko�ci danej puli po��cze�. Oprogramowanie zaprojektowano z my�l� o �wiecie, w kt�rym by�o ono wdra�ane statycznie, a obci��enia by�y do�� stabilne. W dzisiejszym �wiecie przepustowo�� mo�na zapewni� i natychmiast zatrzasn�� przy pe�nym obci��eniu ruchem. Dobrze zaprojektowane oprogramowanie jest cz�sto w stanie poradzi� sobie z tymi skokami ruchu, ale nie zawsze.

Bezpiecze�stwo

Wszyscy s�usznie troszcz� si� o bezpiecze�stwo. Organizacje cz�sto ponosz� odpowiedzialno�� za naruszenia, a nawet niewielkie naruszenia kosztuj� dziesi�tki milion�w dolar�w, nie wspominaj�c ju� o negatywnej reklamie i utracie zaufania ze strony klient�w. Naruszenia zwykle s� dalekosi�ne, z ujawnieniem wszystkich zarz�dzanych danych. Rzadko zdarza si�, aby zagro�ony by� tylko podzbi�r informacji o kliencie. Wprowadzenie przetwarzania w chmurze, w zale�no�ci od sposobu jego wykorzystania, mo�e oznacza�, �e wi�cej danych jest cz�ciej przesy�anych przez niezaufane sieci i przetwarzanych na wsp�u�ytkowanym sprz�cie, co dodatkowo zwi�ksza z�o�ono�� zabezpieczenia tych danych.

Stanowo��

��dania HTTP mo�na podzieli� na dwie klasy: te, kt�re wymagaj� stanu i te, kt�re nie wymagaj� stanu. Stan jest zwykle reprezentowany jako sesja HTTP. Jest to tymczasowy obszar przechowywania, kt�ry jest unikalny dla danego klienta i trwa�y dla ��da� HTTP. Na przyk�ad koszyki s� zwykle przechowywane w sesji HTTP. Status uwierzytelnienia jest r�wnie� utrwalany przez czas trwania sesji. Protok� HTTP jest z definicji bezstanowy, ale stan dodawany jest na wierzchu przez serwery aplikacji i klient�w, aby zapewni� podstawow� funkcj� e-commerce. ��dania HTTP od anonimowych klient�w dotycz�ce statycznych stron nietransakcyjnych (np. Strony g��wnej, strony ze szczeg�ami produktu) zasadniczo nie wymagaj� stanu. Stan zazwyczaj zaczyna si� po zalogowaniu lub dodaniu do koszyka. Wyzwaniem zwi�zanym z e-commerce jest to, �e klienci cz�sto przegl�daj� anonimowo przez d�u�szy czas, zanim zidentyfikuj� si� po zalogowaniu. Wi�kszo�� du�ych witryn zmusza Ci� do natychmiastowego zalogowania si� (np. Media spo�eczno�ciowe, e-mail, bankowo�� internetowa) lub wcale (wiadomo�ci , wyszukiwarki, Wikipedia). Loguj�c si� w witrynie e-commerce, musisz scali� wszystko, co wydarzy�o si� w trakcie sesji, z danymi, kt�re utrwalono na temat klienta. Na przyk�ad personalizacj� mo�na zastosowa�, aby uzyska� zni�k� na wszystkie buty Nike po obejrzeniu 10 but�w Nike i nie kupieniu niczego. Anonimowy klient, kt�ry obejrza� osiem par but�w Nike, nie uruchomi�by zni�ki. Ale co si� stanie, gdy anonimowy u�ytkownik zaloguje si� na konto, kt�re ju� zarejestrowa�o cztery wy�wietlenia strony Nike? Promocja zostanie nast�pnie uruchomiona po pomy�lnym po��czeniu anonimowego profilu klienta i zalogowanego profilu klienta. Om�wimy to bardziej w cz�ci 10, ale innym problemem jest problem wielu r�wnoczesnych logowa� dla tego samego konta. Co si� stanie, je�li m�� i �ona zaloguj� si� na to samo konto, jednocze�nie wprowadzaj�c zmiany do tego samego zam�wienia i profilu klienta w bazie danych? W przypadku jednego centrum danych nie stanowi to problemu, poniewa� udost�pniasz jedn� logiczn� baz� danych. Ale co si� dzieje, gdy u�ywasz publicznej infrastruktury jako us�ugi do hostingu i rozpo�cierasz platform� e-commerce na dwa centra danych, a ka�de centrum danych ma w�asn� baz� danych? Utrzymanie stanu w ��daniach HTTP najcz�ciej oznacza, �e dany klient musi zosta� przekierowany do tego samego centrum danych, modu�u r�wnowa�enia obci��enia, serwera WWW (je�li jest u�ywany) i instancji serwera aplikacji. Utrzymanie tej lepko�ci wymaga dodatkowej uwagi, z kt�r� wiele innych aplikacji nie musi sobie poradzi�.

Co to jest skalowalno��?

�ci�le m�wi�c, skalowalno�� to zdolno�� systemu do zwi�kszenia wydajno�ci (na przyk�ad obs�ugiwanych jednoczesnych u�ytkownik�w lub ��da� HTTP na sekund�) poprzez dodanie wi�kszej liczby danych wej�ciowych (na przyk�ad dodatkowego serwera). Aby by� idealnie skalowalnym, twoje dane wej�ciowe musz� zawsze by� r�wne twoim wynikom w tej samej proporcji. Na przyk�ad, je�li tw�j pierwszy serwer zapewnia 200 wy�wietle� strony na sekund�, tw�j 1.000 serwer powinien r�wnie� zapewni� 200 wy�wietle� strony na sekund�. Je�li Tw�j pierwszy serwer zapewnia 200 wy�wietle� strony na sekund�, a Tw�j 1000 serwer zapewnia 20 wy�wietle� stron na sekund�, tw�j system ma problem ze skalowalno�ci�. Wszystkie warstwy stosu musz� by� jednakowo skalowalne, od DNS do pami�ci. Om�wimy dwie formy skalowalno�ci: skalowanie w g�r� (w pionie) i skalowanie w g�r� (w poziomie).

Wydajno��

Przepustowo�� odnosi si� do ilo�ci pracy lub pojemno�ci, kt�re mo�e obs�u�y� jednostka danych wej�ciowych (np. Serwer, w�ze� siatki pami�ci podr�cznej, w�ze� bazy danych) lub ca�y system. Typowe przyk�ady metryk u�ywanych do reprezentowania przepustowo�ci obejmuj�:

• Wy�wietlenia strony na sekund�
• Transakcje na sekund�
• Wsp�bie�ni klienci

Nie nale�y myli� przepustowo�ci z og�ln� skalowalno�ci� ca�ego systemu, poniewa� oba s� od siebie niezale�ne. Przepustowo�� pojedynczej jednostki wej�ciowej (np. Serwera aplikacji) mo�e by� niska, ale o ile mo�na stale uzyskiwa� ten sam poziom marginalnej wydajno�ci (np. Ods�on stron na sekund�), gdy zwi�ksza si� liczb� danych wej�ciowych, system jest skalowalny.

Skalowanie

Skalowanie w g�r�, znane r�wnie� jako skalowalno�� pionowa, zwi�ksza wydajno�� (np. Liczb� ods�on na sekund�) sta�ej jednostki wej�ciowej (np. Serwer aplikacji dzia�aj�cy na 8 rdzeniach). Gdy zwi�kszysz wydajno�� serwera aplikacji z 200 wy�wietle� strony na sekund� do 250 wy�wietle� strony na sekund�, zwi�kszy�e� ten zas�b. Skalowanie mo�e by� wykonywane przez optymalizacj� (wi�ksze buforowanie, zwi�kszenie wydajno�ci kodu itd.) Lub dodanie wi�kszej ilo�ci zasob�w fizycznych (np. Przej�cie z 8 vCPU na 12). Jest to w przeciwie�stwie do skalowania, gdzie liczba wy�wietle� strony na sekund� zosta�aby zwi�kszona poprzez dodanie kolejnej instancji serwera aplikacji. �adne oprogramowanie nie jest naprawd� niesko�czenie skalowalne. W pewnym momencie zaczniesz otrzymywa� malej�ce zwroty. Na przyk�ad Apache historycznie nie skalowa� si� daleko poza garstk� fizycznych rdzeni. Osi�gn��by� wi�ksz� ca�kowit� przepustowo��, uruchamiaj�c cztery instancje Apache na jednym 32-rdzeniowym serwerze CPU, ni� gdyby� uruchomi� jedn� instancj� Apache na tym samym serwerze. Niekt�re programy musz� by� skalowane ze wzgl�du na ograniczenia w jego architekturze. Cz�sto stare systemy backendowe nie skaluj� si� zbyt dobrze, poniewa� zosta�y zaprojektowane z my�l� o czasach, w kt�rych procesory mia�y tylko jeden rdze�. Procesory wielordzeniowe s� do�� nowoczesnym wynalazkiem

tudium przypadku: Problem C10K

W 2003 r. Programista Dan Kegel opublikowa� stron� internetow� stwierdzaj�c�, �e nowoczesne serwery internetowe powinny by� w stanie obs�u�y� 10 000 r�wnoczesnych klient�w. Nazywa� on problem C10K, gdzie C oznacza po��czenia, a 10K oznacza 10 000. Jego sprytn� obserwacj� by�o to, �e sprz�t poczyni� ogromne post�py w ci�gu ostatnich kilku lat, ale zdolno�� serwera WWW do skalowania i u�ywania tego sprz�tu nie uleg�a zmianie. W tym czasie wiele serwer�w by�o w stanie obs�u�y� tylko 1000. Dan i dalsze prace wykaza�y, �e 10 000 jednoczesnych po��cze� mo�e zosta� utrzymanych dzi�ki zmianom w systemie operacyjnym i oprogramowanie serwera WWW. Dziesi�� lat p�niej, w 2013 r., Robert Graham pokaza�, �e nowoczesne serwery mog� obs�ugiwa� 10 milion�w jednoczesnych klient�w.2 Ponownie, rozwi�zaniem by�o oprogramowanie. Te dwie inicjatywy pokaza�y, �e w�skim gard�em w skalowalno�ci pionowej by�o g��wnie oprogramowanie. Sprz�t ma znaczenie, ale nie tak bardzo, jak dobre oprogramowanie.

Skalowanie

Skalowanie, znane r�wnie� jako skalowalno�� pozioma, zwi�ksza wydajno�� (np. Liczb� ods�on na sekund�) systemu poprzez dodanie wi�kszej liczby danych wej�ciowych (np. Wi�cej serwer�w aplikacji dzia�aj�cych na wi�kszej ilo�ci sprz�tu). Przyk�adem skalowania zasobu jest dodanie serwera, w przeciwie�stwie do zwi�kszenia pami�ci lub mocy obliczeniowej istniej�cego. Je�li marginalne wej�cie (np. Dodatkowy serwer) jest r�wne marginalne wyj�cie (np. Liczba ods�on na sekund�), masz doskonale skalowalny system. Je�li dodatkowe jednostki wej�ciowe (np. Fizyczne serwery) s� r�wne coraz mniej jednostkom wyj�ciowym (np. Liczba wy�wietle� strony na sekund�), system nie jest skalowalny. Rysunek dotyczy w r�wnym stopniu zar�wno poszczeg�lnych jednostek, jak i ca�ego systemu

Zasady skalowania

Podczas gdy skalowanie w g�r� jest absolutn� konieczno�ci�, skalowanie w g�r� jest r�wnie� wa�ne. Im bardziej si� skalujesz, tym mniej musisz skalowa� i tym ni�sze koszty kra�cowe. Mo�esz unikn�� ca�ej klasy problem�w, lepiej projektuj�c system w celu zwi�kszenia przepustowo�ci ka�dego serwera. Nowoczesne serwery towarowe x86 mog� obs�ugiwa� 10 milion�w jednoczesnych po��cze� HTTP dzi�ki architekturom opartym na p�tli zdarze� bez blokady, preferowanym przez nowsze serwery WWW / us�ugi r�wnowa�enia obci��enia, takie jak Nginx i Node.js. Apache jest teraz w stanie obs�u�y� ponad kilka tysi�cy r�wnoczesnych ��da� HTTP na jednym serwerze towarowym, ale jest to w du�ej mierze spowodowane ulepszeniami sprz�towymi i poprawkami. Ogromny wzrost przepustowo�ci tych nowszych serwer�w sieciowych wynika wy��cznie z ich lepszej architektury. Oprogramowanie do skalowania sprowadza si� do dw�ch zasad. Pierwszym jest umo�liwienie ka�demu systemowi wykonania pracy, kt�r� musi wykona�, przy mo�liwie jak najmniejszej liczbie przeszk�d. Po��czenia ze zdalnymi systemami s� prawid�owe, pod warunkiem �e nie blokuj�. Zablokowane w�tki zabijaj� zar�wno przepustowo��, jak i wydajno��. Unikanie w�tk�w tam, gdzie to mo�liwe, eliminuje problem blokowania w�tk�w. Drug� i jeszcze silniejsz� barier� skalowalno�ci jest ludzka strona technologii. Zatrudnianie odpowiednich ludzi przyniesie dywidendy na nadchodz�ce dziesi�ciolecia i mo�e mie� wp�yw na sukces lub pora�k� Twojej firmy. Poszczeg�lne osoby s� skalowalne w pionie tylko do pewnego momentu. Skalowanie i powi�kszanie personelu jest wymagane do sukcesu. W poni�szej sekcji om�wiono ka�d� z nast�puj�cych zasad:

• Konwertuj synchroniczny na asynchroniczny
• Zmniejszy� blokowanie
• Uproszcza�
• Usu� stan
• Inteligentne buforowanie
• Zatrudnij odpowiednich ludzi
• Planuj, planuj, planuj
• Rozmiar odpowiednio
• U�yj odpowiedniej technologii

Konwertuj synchroniczny na asynchroniczny

W przetwarzaniu synchronicznym wykonanie jednego zadania (np. Serwera aplikacji generuj�cego odpowied� HTTP) zale�y od wykonania jednego lub wi�kszej liczby innych zada� (np. Zapytania do bazy danych). Typowym przyk�adem tego jest e-mail potwierdzaj�cy wysy�any synchronicznie po z�o�eniu zam�wienia. Zak�adaj�c, �e transakcje s� w�a�ciwie wykorzystywane, pomy�lne z�o�enie zam�wienia jest ca�kowicie zale�ne od czego� tak niepowa�nego, jak dost�pno�� i wydajno�� serwera SMTP. Przy prawid�owym oddzieleniu tych dw�ch system�w zam�wienie zostanie z�o�one normalnie, ale zamiast synchronicznego wys�ania wiadomo�ci zostanie zrzucone w kolejce i dostarczone asynchronicznie na dost�pny serwer SMTP. Synchroniczne wywo�ania dowolnego systemu umieszczaj� go na �cie�ce krytycznej, co powoduje, �e skalowalno�� ca�ego systemu zale�y od najmniej skalowalnego zasobu. Na przyk�ad system zarz�dzania zam�wieniami mo�e mie� problemy z obs�ug� ruchu z najbardziej obci��onych dni w roku. Je�li ��czysz si� synchronicznie z systemem zarz�dzania zam�wieniami, skalowalno�� ca�ej platformy b�dzie zale�a�a od skalowalno�ci tego jednego systemu. W �wiecie wielokana�owym, w kt�rym wszystkie kana�y u�ywaj� tych samych system�w zaplecza, niekt�re z Twoich system�w nie b�d� mog�y skalowa�. Ka�da czynno��, kt�ra nie jest bezpo�rednio zwi�zana z generowaniem przychod�w lub nie wymaga natychmiastowej reakcji, powinna by� wykonywana asynchronicznie, aby nie zak��ca�a generowania przychod�w.

Studium przypadku: Node.js

Tradycyjne serwery WWW i aplikacji dzia�aj� na zasadzie w�tk�w, w kt�rych pojedyncze ��danie HTTP wi��e pojedynczy w�tek, dop�ki odpowied� nie zostanie w pe�ni wygenerowana. Wszystko odbywa si� synchronicznie. W przypadku tradycyjnej kombinacji serwera WWW i serwera aplikacji oznacza to, �e ka�dy w�tek serwera WWW czeka na odpowied� serwera aplikacji, a w�tek ka�dego serwera aplikacji czeka na odpowiedzi z r�nych baz danych, siatek pami�ci podr�cznej, system�w innych firm i tak dalej. W�tki sp�dzaj� du�o czasu zablokowane, czekaj�c na co�. W�tki s� drogie, poniewa� ka�dy wymaga dedykowanej pami�ci. Model ten zosta� stworzony dla �wiata, w kt�rym klienci pasywnie pobierali statyczne strony internetowe. Node.js to framework oparty na JavaScript, kt�ry s�u�y zar�wno jako serwer WWW, jak i �rodowisko programistyczne po stronie klienta. Obydwie pracuj� razem, aby zaoferowa� pe�n� dwukierunkow� komunikacj� mi�dzy serwerem WWW a klientem, a tak�e asynchroniczny model wykonania, kt�ry eliminuje w�tki. Nieu�ywaj�c w�tk�w, ka�da instancja Node.js mo�e obs�ugiwa� milion lub wi�cej r�wnoczesnych po��cze�. Spos�b dzia�ania polega na tym, �e przychodz� ��dania HTTP, a poniewa� systemy zaplecza wykonuj� swoje zadania (np. Wyszukiwanie zapas�w, ��danie za�adowania szczeg��w produktu za po�rednictwem ��dania HTTP z odpowiedzi� REST), odpowied� jest stopniowo przekazywana do klienta . Dzi�ki temu przegl�darka internetowa mo�e zacz�� renderowa� odpowied� r�wnolegle podczas jej generowania. Na dowolnej platformie, a szczeg�lnie w chmurze, bazy danych mog� s�u�y� jako w�skie gard�o. Bazy danych s� cz�sto u�ywane w handlu elektronicznym, poniewa� aplikacje s� tak rozbudowane. Poza chmur� bazy danych s� wdra�ane na dedykowanym sprz�cie wspieranym przez wysokiej jako�ci pami�� masow� z szybkim sprz�tem sieciowym ��cz�cym komponenty systemu. W publicznej chmurze Infrastruktura jako us�uga masz niewielk� kontrol� nad swoim �rodowiskiem. Nie mo�esz optymalnie dostroi� du�o poza systemem operacyjnym i masz do czynienia ze sprz�tem i sieciami, kt�re s� wsp�lne dla wielu najemc�w. Chocia� dostawcy us�ug chmurowych podejmuj� wielkie �rodki ostro�no�ci w celu odizolowania ruchu, nigdy nie jest idealny. Aby nie dopu�ci� do tego, aby bazy danych by�y w�skim gard�em, mo�esz u�y� pami�ci podr�cznej zapisu dla wszystkich lub podzbioru zapis�w. Oznacza to, �e aplikacja korzysta z pami�ci podr�cznej jako systemu zapisu, a pami�� podr�czna odczytuje i zapisuje asynchronicznie baz� danych

Mo�e to pozwoli� na skalowanie i skalowanie systemu przy jednoczesnym zwi�kszeniu wydajno�ci. Dla klient�w zapis odbywa si� natychmiast w lokalnej pami�ci podr�cznej, co umo�liwia natychmiastowe wygenerowanie odpowiedzi. Chocia� mo�e to nie by� odpowiednie dla czego� wa�nego, takiego jak inwentaryzacja, doskonale nadaje si� do takich rzeczy, jak recenzje produkt�w, aktualizacje profilu klienta, aktualizacje koszyka - wszystko, gdzie system �r�d�owy jest nieaktualny o kilka milisekund. Najbardziej skalowalne platformy ca�kowicie oddzieli�y swoje nak�adki od zaplecza. Wszystkie po��czenia z frontendu do backendu s� asynchroniczne, z wprowadzeniem kolejkowania, aby pozwoli� backendowi znika� na pewien czas. Z opuszczonym backendem interfejs nadal przyjmuje przychody.

Zmniejszy� blokowanie

Z definicji praca (np. ��dania HTTP) na platformie e-commerce jest wykonywana jednocze�nie w wielu w�tkach. Mog� to by� w�tki w zarz�dzanym �rodowisku wykonawczym, w�tki w bazie danych lub w�tki w siatce pami�ci podr�cznej. Serwery sieciowe i us�ugi r�wnowa�enia obci��enia zwykle nie blokuj� si� bardzo i coraz cz�ciej odchodz� od w�tk�w, wi�c nie ma problem�w. Istniej� obiekty, kt�re wymagaj� aktualizacji przez wiele w�tk�w jednocze�nie. �wietnym przyk�adem tego jest sytuacja, gdy miliony ludzi pr�buj� kupi� najnowszy smartfon, gdy tylko b�dzie dost�pny w sprzeda�y. Inwentaryzacja na ca�ej platformie zazwyczaj sprowadza si� do aktualizacji jednego rekordu w scentralizowanej siatce pami�ci podr�cznej, w wierszu bazy danych i tak dalej. Bez odpowiedniej wsp�bie�no�ci w�tki bazy danych i serwera aplikacji mog� czeka� zbyt d�ugo na aktualizacj�, powoduj�c kaskadowe blokowanie na ca�ej platformie. Jest to cz�sta przyczyna awarii. Blokowanie mo�e r�wnie� wyst�pi� w ramach jednego procesu, co ogranicza jego zdolno�� do zwi�kszania skali. Twoja aplikacja mo�e mie� kilka wsp�lnych gor�cych obiekt�w, kt�re s� zablokowane przez ka�dy w�tek obs�ugi ��dania. Kiedy masz zbyt wiele w�tk�w, ka�dy w�tek musi czeka� d�u�ej, aby si� zablokowa�, a ostatecznie staje si� zbyt d�ugi i nie mo�esz ju� powi�ksza� skali. Blokowanie mo�e by� szybkim sposobem na ograniczenie mo�liwo�ci skalowania w g�r� i w g�r�. Dlatego nale�y tego unika� za wszelk� cen�. Mo�esz w du�ej mierze wyeliminowa� blokowanie, stosuj�c zdrowy rozs�dek podczas projektowania systemu. Zamiast ca�y czas czyta� ekwipunek, mo�esz ustawi� flagi o niskim ekwipunku lub przydzieli� parti� ekwipunku do ka�dej instancji, je�li dost�pnych jest wiele ekwipunku. W celu aktualizacji zapas�w mo�na zamiast tego wykonywa� proste inkrementacje i dekrementacje po��cze� z siatk� pami�ci podr�cznej lub podobnym systemem w pami�ci, kt�ry wykorzystuje struktur� danych bez blokady. Po��czenie mo�e by� tak proste:

http://www.website.com/InventoryUpdate?productId=X&value=-1&securityToken=ABC123

Mo�esz nawet wykona� po��czenie asynchronicznie, je�li wiesz, �e masz wystarczaj�co du�o zapas�w, aby przetrwa� przez chwil�. Po prostu informuj�c system zarz�dzania zapasami o zwi�kszaniu lub zmniejszaniu, unikniesz konieczno�ci czytania obiektu, ustawiania jego warto�ci i czekania, a� baza danych go zatwierdzi dysk. To jest po prostu znacznie szybsze. Ka�dy j�zyk programowania ma koncepcj� niezablokowanych struktur danych. Wewn�trznie te struktury danych mog� wykorzystywa� bardziej wydajne nieblokuj�ce techniki na poziomie systemu operacyjnego, takie jak por�wnywanie i zamiana. Korzystanie z tych struktur danych znacznie zmniejsza rywalizacj� w�tk�w w ramach jednego procesu i pozwala na znacznie wi�ksze skalowanie.

Upraszcza�

Twoja architektura powinna by� tak prosta, jak to mo�liwe. Prostota rodzi skalowalno��. Obejmuje to szeroki zakres temat�w, w tym:

• Usuwanie poziom�w z platformy
• Usuwanie serwer�w internetowych.
• Uproszczenie konfiguracji
• Zmienianie adres�w IP na nazwy host�w, ca�kowite usuwanie nazw host�w, eliminowanie singleton�w i tak dalej.
• Usuwanie niepotrzebnych opakowa� / kopert
• Prze��czanie z SOAP na SOA, nieu�ywanie SSL / TLS, gdy nie jest to naprawd� konieczne, i tak dalej.
• Budowanie dyskretnych interfejs�w mi�dzy systemami

Pozwala to lepiej oddzieli� swoje systemy. Dyskretne interfejsy mo�na zapisywa� do iz magistrali us�ug i podobnych technologii. Uproszczenia musz� by� wbudowane od samego pocz�tku. Powr�t do uproszczenia starego kodu jest bardzo trudny. Zbuduj go poprawnie od samego pocz�tku, zatrudniaj�c odpowiednich ludzi i czyni�c prostot� najwy�szym celem.

Usu� stan z poszczeg�lnych serwer�w

Jak wspomniano wcze�niej, stan to tymczasowy obszar przechowywania, kt�ry jest unikalny dla danego klienta i trwa�y dla ��da� HTTP. W�zki sklepowe, status uwierzytelnienia, promocje itd. Zale�� od stanu. Stan zawsze b�dzie sta�ym elementem, bior�c pod uwag� natur� handlu elektronicznego. Utrzymanie stanu w ��daniach HTTP najcz�ciej oznacza, �e dany klient musi zosta� przekierowany do tego samego centrum danych, modu�u r�wnowa�enia obci��enia, serwera WWW (je�li jest u�ywany) i instancji serwera aplikacji. Gdy szybko dodajesz i usuwasz serwery w chmurze poprzez automatyczne skalowanie, nie zawsze mo�esz zagwarantowa�, �e dany serwer b�dzie dost�pny. Serwery w chmurze s� z natury efemeryczne. Zmuszanie klienta do ponownego zalogowania si�, poniewa� stan zosta� utracony po wyrejestrowaniu serwera, jest niedopuszczalny. Serwery w chmurze s� z natury efemeryczne. Nie przechowuj w nich stanu. Pa�stwo ma powa�ne implikacje techniczne z kilku powod�w:

• Stan mo�e by� ci�ki, zazwyczaj pod wzgl�dem wykorzystania pami�ci. Nic nie zabija twojej zdolno�ci zwi�kszania skali, podobnie jak sesje 1 MB.
• Utrzymanie stanu e-commerce wymaga utrwalenia go po stronie serwera i udost�pnienia go ka�demu serwerowi aplikacji, kt�ry o to poprosi. Ponownie, serwery mog� szybko przechodzi� w g�r� i w d�. Je�li anulujesz rezerwacj� serwera, klient nie powinien wiedzie�.
• Pa�stwa musz� zosta� po��czone. Jak om�wiono wcze�niej w cz�ci, klienci przegl�daj� anonimowo, ca�y czas gromadz�c stan. Gdy klient si� loguje, ten stan sesji musi zosta� scalony ze stanem trwa�ym, kt�ry jest trwa�y w sesjach HTTP.

Aby zminimalizowa� szkodliwe skutki stanu, pami�taj o nast�puj�cych zasadach:

• Stan powinien by� jak najl�ejszy - najwy�ej kilka kilobajt�w. Wszystko, co nieistotne, powinno zosta� pomini�te.
• Stan nale�y sprowadzi� do jak najmniejszej liczby system�w. Chocia� serwer aplikacji ma sens, aby dba� o jego stan, po��czenie aplikacji z niezale�n� us�ug� zarz�dzania zapasami powinno by� bezstanowe. Przejrzyj ka�de zdalne po��czenie i potwierd�, czy stan jest naprawd� wymagany.
• Nale�y unika� pa�stwa, chyba �e jest to konieczne. Na przyk�ad roboty wyszukiwarek indeksuj�ce Twoj� witryn� nie maj� poj�cia o sesjach i utworz� zupe�nie now� sesj� HTTP przy ka�dym wy�wietleniu strony. Albo zapobiegaj tworzeniu sesji HTTP, albo rozwa� uniewa�nienie sesji HTTP utworzonych przez wyszukiwark� przez boty (kt�re mo�na zidentyfikowa� za pomoc� ci�gu agenta u�ytkownika) po ka�dym ��daniu HTTP. Podobnie anonimowi klienci wy�wietlaj�cy stron� g��wn� prawdopodobnie nie potrzebuj� sesji.
Najwa�niejsze pytanie dotyczy tego, gdzie nale�y przechowywa� stan. Tradycyjnie serwery aplikacji by�y odpowiedzialne za zarz�dzanie cyklem �ycia sesji HTTP. Aplikacje wdro�one na serwerach aplikacji dodaj� dane do sesji. Nast�pnie mo�esz zreplikowa� sesj� HTTP lub nie. Replikacja mo�e odbywa� si� w ca�o�ci w pami�ci, poprzez baz� danych, siatk� pami�ci podr�cznej lub przez prawie ka�dy inny spos�b przenoszenia danych mi�dzy procesami. Aby zmniejszy� obci��enie zwi�zane z utrzymywaniem stanu po stronie serwera, naturalne by�oby przekazanie go do klienta (np. Przegl�darki internetowej, aplikacji mobilnej), jak to jest cz�sto w przypadku wielu innych obci��e�. Cz�sto jest to osi�gane w przegl�darkach internetowych za pomoc� plik�w cookie lub HTML 5. Ale w �wiecie wielokana�owym to nie dzia�a dobrze, poniewa� u�ywasz tak wielu r�nych kana��w, z kt�rych ka�dy wymaga reprezentacji stanu przez klienta i wersj�. Poniewa� HTTP jest z definicji bezstanowy, ka�dy klient musi wprowadzi� stan. Na przyk�ad przegl�darki internetowe u�ywaj� plik�w cookie, podczas gdy aplikacje na Androida u�ywaj� interfejsu API opartego na Javie z natywnym mechanizmem trwa�o�ci. Niekt�rzy klienci nawet nie obs�uguj� mo�liwo�ci utrwalania danych mi�dzy ��daniami HTTP. Ze wzgl�du na r�norodno�� klient�w i ich ci�gle zmieniaj�ce si� interfejsy API najlepiej jest pozwoli� serwerowi aplikacji kontynuowa� zarz�dzanie stanem. Nie zak�adaj, �e klienci wspieraj� co� tak podstawowego, jak ciasteczka. Aplikacje i serwery aplikacji powinny by� skonfigurowane tak, aby utrzymywa�y stan w systemie rozproszonym, takim jak baza danych NoSQL lub siatka pami�ci podr�cznej. Nast�pnie mo�esz obs�u�y� ��danie HTTP z dowolnego serwera z dost�pem do bazy danych NoSQL lub siatki pami�ci podr�cznej. Buforuj jak najwi�cej, jak najbli�ej klienta. Buforowanie jest wyj�tkowo wa�ne dla e-commerce, poniewa� klienci wymagaj� absolutnie najlepszej dost�pnej wydajno�ci. Jednocze�nie buforowanie mo�e zaoszcz�dzi� ogromne zasoby komputerowe, umo�liwiaj�c skalowanie poszczeg�lnych serwer�w znacznie dalej inaczej by�oby mo�liwe. W ostatnim dziesi�cioleciu warto�ci� oferowan� przez wart� wiele miliard�w dolar�w bran�� Content Delivery Network (CDN) by�a niemal wy��cznie ich zdolno�� do buforowania tre�ci. Zasada buforowania polega na tym, �e najlepiej buforowa� tak du�o, jak to mo�liwe, jak najbli�ej klienta ko�cowego. Im bli�ej pami�ci podr�cznej, tym mniej ka�dy system po�rednicz�cy mi�dzy klientem a systemem �r�d�owym faktycznie generuj�cym tre�� musi dzia�a�.

Je�li masz odpowiedni� architektur�, w�skim gard�em systemu powinny by� procesory z serwerem aplikacji. Wcze�niejsze w�skie gard�a stanowi�y pami��, pami�� masowa, sieci i inne warstwy, ale obecnie s� to procesory z serwerem aplikacji. Wykonywanie kodu w celu generowania stron poch�ania wi�kszo�� procesora. Wi�kszo�� stron sk�ada si� z fragment�w. Chocia� ca�a strona mo�e mie� zbyt du�o tre�ci, aby mo�na j� by�o buforowa� w warstwie po�redniej, same fragmenty strony s� dynamiczne. Na przyk�ad ten ca�y fragment pokazany tu, prawdopodobnie nie ulegnie zmianie. Zamiast ci�g�ego wykonywania kodu w celu wygenerowania fragmentu strony, o kt�rym wiesz, �e nigdy si� nie zmieni, mo�esz zamiast tego buforowa� wykonanie tego fragmentu, przekazuj�c zmienne. Wi�kszo�� framework�w internetowych ma mo�liwo�� buforowania fragment�w, w tym parametr�w wej�ciowych b�d�cych kluczami pami�ci podr�cznej. Aby buforowa� fragment, we�miesz odpowiednik:

< jsp: include page = "/ menu_bar.jsp" / >

i przekonwertowa� na:

< jsp: include page = "/ menu_bar.jsp" >
< jsp: param name = "anonymous" value = "false" / >
< jsp: param name = "user_segment" value = "bay_area_male_engineer" / >
< jsp: param name = "locale" value = "us_EN" / >
< / jsp: include >

Dzi�ki parametrom anonimowym, user_segment i locale tworz�cym klucz, mo�esz po prostu tworzy� kopie ka�dej kombinacji i buforowa� HTML. �atwiej jest do��czy� wst�pnie buforowany blok HTML ni� wykona� tysi�ce wierszy kodu, kt�re wchodz� w generowanie HTML ze �r�d�a. Fragmenty nale�y buforowa� w miar� mo�liwo�ci. Buforowanie jest jedn� z najbardziej podstawowych zasad w informatyce i powinno by� stosowane w spos�b swobodny. U�ywaj odpowiedniej technologii Technologia jest niezwykle modn� bran��, w kt�rej decyzje o wyborze technologii cz�sto kieruj� si� mod�, a nie pragmatyzmem. Ludzie myl� u�ywanie nowej, niesprawdzonej technologii z innowacj�, gdy s� one prawie ca�kowicie niezwi�zane. Innowacje powinny pochodzi� z tego, jak wykorzystujesz technologie do osi�gania cel�w biznesowych, a nie same technologie. Chocia� nowa technologia ma swoje miejsce, zawsze nale�y r�wnowa�y� marginalne korzy�ci, jakie zapewnia nowa technologia, z nast�puj�cymi cechami bardziej ugruntowanych opcji:

• Dojrza�o��
• Dost�pno�� umiej�tno�ci na rynku
• Wsparcie
• Trwaj�cy serwis
• Jak dobrze mo�na to monitorowa�

Na przyk�ad u�ycie nowego j�zyka programowania mo�e pozwoli� Ci napisa� 10% mniej kodu, ale je�li nie mo�esz znale�� IDE lub programist�w, czy 10% naprawd� jest tego warte? Prawdopodobnie nie. Jednak takie decyzje s� podejmowane ca�y czas, cz�sto z powodu wym�wki "nie skaluje si�". Ale skalowalno�� to znacznie wi�cej ni� spos�b korzystania z technologii ni� sama technologia. Zasadniczo najlepiej jest zleca� na zewn�trz lub stosowa� ugruntowan� technologi� dla dowolnej cz�ci systemu, kt�rej nie robisz szybciej / lepiej / taniej ni� konkurenci. W�a�nie z tej zasady e-commerce nale�y wdra�a� w chmurze. Wprowadzaj innowacje we wdra�aniu i / lub rozwoju aplikacji e-commerce. Tw�rz pi�kne i funkcjonalne interfejsy u�ytkownika. Po��cz si� z fizycznymi sklepami, zapewniaj�c takie funkcje, jak w czasie rzeczywistym, zapasy na poziomie sklepu i ceny. Obs�uguje szerok� gam� klient�w. Spraw, by by� szybki i wysoce dost�pny. Pozostaw rozw�j element�w sk�adowych (np. Sprz�tu, oprogramowania, us�ug) dostawcom technologii lub spo�eczno�ci open source. Upewnij si�, �e masz proces oceny wybranej technologii. Osoby wybieraj�ce technologi� mog� nie mie� widoku ca�kowitego kosztu korzystania z danej technologii. Po�wi�� czas na dostarczanie swoich kluczowych kompetencji, a nie na budowanie utowarowanych komponent�w.

Zasady nietechniczne

Zatrudnij odpowiednich ludzi Og�lnie rzecz bior�c, potrzebujesz architekt�w i programist�w, aby zapewni� platform� wysokiej jako�ci. Oczywi�cie zaanga�owanych jest wiele innych r�l pomocniczych, ale potrzebujesz ludzi do projektowania (architekt�w) i ludzi do implementacji (programist�w). Architekci s� odpowiedzialni za projektowanie ca�ego systemu, od tego, jak i gdzie kod jest wdra�any, a� do projektowania na poziomie metody. Architektura zmieni�a si� w ci�gu ostatnich dw�ch dekad, od projektowania system�w od zera po wykorzystanie element�w konstrukcyjnych. Obecnie elementami sk�adowymi s� us�ugi w chmurze (Software-as-a-Service, Platform-as-a-Service, Infrastructure-as-a-Service), platformy programistyczne i produkty takie jak siatki pami�ci podr�cznej. Bardzo niewiele z tych element�w sk�adowych istnia�o jeszcze dziesi�� lat temu. Musia�e� zbudowa� wszystko, co chcia�e� r�cznie. Architekci maj� teraz o wiele wi�cej dost�pnych opcji - co jest dobre, je�li wiesz, co robisz, ale z�e, je�li nie. Praca zmieni�a si� bardziej z tego, jak na co. Jest to fundamentalna zmiana, kt�ra wymaga zatrudnienia kilku bardzo wykwalifikowanych architekt�w, w przeciwie�stwie do du�ej liczby przeci�tnych lub poni�ej przeci�tnych architekt�w. Po prostu nie potrzebujesz dzisiaj tak wielu ludzi. Ca�y ekosystem, w kt�rym pracuj� programi�ci, znacznie dojrza� w ci�gu ostatniej dekady. J�zyki programowania, ramy programistyczne, narz�dzia i �rodowiska wykonawcze pozwalaj� programistom pisa� mniej kodu o wy�szej jako�ci w kr�tszym czasie ni� kiedykolwiek wcze�niej. Jeden dobry programista ma teraz wydajno�� 10 lub wi�cej przeci�tnych programist�w. Dzi�ki nowoczesnym narz�dziom dobry programista mo�e by� jeszcze bardziej wydajny. Wsp�cze�ni programi�ci nie pisz� tyle kodu niskiego poziomu. Te pytania do wywiadu "odwr�� po��czon� list� na bia�ej tablicy" s� w najlepszym wypadku bezu�yteczne, poniewa� dobry programista powinien po prostu wybra� metod� sortowania. Wi�kszo�� programist�w dzisiaj powinna pisa� kod kleju, co bardziej sprowadza si� do wykorzystania framework�w programistycznych i wykorzystania gotowych bibliotek ni� pisanie du�ej ilo�ci kodu od zera. Napisany kod musi zosta� skomentowany, przetestowany jednostkowo, poddany kontroli jako�ci, przetestowany pod k�tem wydajno�ci i utrzymany. Wszystko to kosztuje czas i pieni�dze. Dobrzy programi�ci nie powinni pisa� du�o kodu, a sam kod powinien by� prosty i jasno udokumentowany. Nie trzeba mie� stopnia informatyki, aby zrozumie�, co robi wi�kszo�� kodu. Dobrzy programi�ci musz� tak�e mie� siln� �wiadomo�� tego, gdzie i jak wykonywany jest ich kod. To nie tylko praca architekta. Chocia� cz�sto wymagane s� podstawowe umiej�tno�ci informatyczne, dla architekt�w i programist�w wa�niejsza jest umiej�tno�� komunikowania si� z interesariuszami, wsp�pracy z kolegami, popierania stanowisk, samodzielnego uzgadniania stanowisk i na og� wykorzystywania umiej�tno�ci mi�kkich, a nie twardych, aby osi�gn�� cele. Wracaj�c do problemu "odwr�� powi�zan� list�", dobry programista powinien by� w stanie skorzysta� z IDE, aby znale�� metod� do wywo�ania, przeprowadzi� szybkie wyszukiwanie w Internecie, aby znale�� metod�, lub zapyta� dewelopera siedz�cego obok niego, co metoda jest. Z�y programista wdro�y algorytm r�cznie, a nie przy u�yciu dost�pnych narz�dzi do znalezienia metody. Podczas gdy umiej�tno�ci mi�kkie s� wa�nym warunkiem sukcesu, entuzjazm, kompetencje i wytrwa�o�� s� trzema cechami najlepszych architekt�w i programist�w. Entuzjazm i wytrwa�o�� s� nieod��cznymi cechami, kt�rych nie mo�na nauczy�, a kompetencje pochodz� z do�wiadczenia. Najlepiej jest budowa� stosunkowo ma�e zespo�y wysoko wykwalifikowanych programist�w. Kilku dobrych programist�w. Colocated mo�e wykona� ogromn� prac�. Wiele najlepszych startup�w zbudowa�o garstka ludzi. Amazon s�ynie ze "zespo��w sk�adaj�cych si� z dw�ch pizz", co oznacza, �e ka�dy zesp� powinien by� na tyle ma�y, aby m�g� go karmi� dwie pizze. �wietnym sposobem na zorganizowanie projektu jest podzielenie projektu na ma�e zespo�y, z kt�rych ka�dy koncentruje si� na dostarczaniu us�ugi z przejrzystym interfejsem. Na przyk�ad mo�esz wyznaczy� architekta i gar�� programist�w, aby zbudowali system zarz�dzania zapasami. Zdefiniuj interfejsy i pozw�l zespo�owi odej��, aby go zbudowa�, jednocze�nie koduj�c reszt� platformy, aby korzysta� z tych interfejs�w. Rozbicie platformy nie tylko ma zalety techniczne, ale �atwiej jest przypisa� odpowiedzialno��, a ludzie lubi� co� posiada�. Kiedy wszyscy s� w�a�cicielami, nikt tak naprawd� nie jest w�a�cicielem niczego. Przy zatrudnianiu chodzi przede wszystkim o jako��, a nie o ilo��. Przy zatrudnianiu chodzi przede wszystkim o jako��, a nie o ilo��. Zatrudniaj najlepszych, organizuj je w ma�e zespo�y, jasno okre�laj odpowiedzialno�� i pracuj nad usuni�ciem przeszk�d dla ludzi wykonuj�cych swoj� prac�.

Wsp�praca z liniami biznesowymi

Zbyt cz�sto wa�ne decyzje biznesowe s� podejmowane przez dzia� IT w izolacji, w oparciu o nieprawid�owe lub nieaktualne za�o�enia. Komunikacja musi by� cz�sta, dwukierunkowa i bez po�rednik�w. Mo�e przyjmowa� form� osobistych spotka�, wiadomo�ci e-mail, wiadomo�ci b�yskawicznych, a nawet wiadomo�ci tekstowych. Ka�de medium jest w porz�dku. Budowanie platformy, kt�ra nie zaspokaja potrzeb biznesowych, to ogromna strata czasu i energii. Jest to wsp�lny wysi�ek. Umowy dotycz�ce poziomu us�ug (SLA) musz� by� zdefiniowane dla ka�dego aspektu systemu. Obejmuje to czas reakcji po stronie serwera i klienta, ile system musi by� dost�pny, ile czasu powinno zaj�� odzyskanie po awarii (cel czasu odzyskiwania) oraz ile strat danych jest akceptowalnych podczas awarii (cel punktu odzyskiwania ). Wy�sze umowy SLA oznaczaj� wy�szy koszt. Na przyk�ad, je�li wymaga si�, aby nigdy nie by�o �adnych przestoj�w platformy, musisz wdro�y� platform� w wielu strefach geograficznych przez wielu dostawc�w chmury. To si� komplikuje i kosztuje. To zawsze jest kompromis. Liczy si� to, �e liczby te s� wsp�lnie uzgadniane i istnieje odpowiedzialno��, gdy cele nie zostan� osi�gni�te. Ka�de wydarzenie, kt�re mo�e zwi�kszy� ruch na Twojej platformie (np. B�yskawiczna sprzeda�, kupony, wyj�tkowe rabaty), musi zosta� zaplanowane z wyprzedzeniem. Z platformami e-commerce dost�pnymi na ca�ym �wiecie, a tak�e szybko�ci�, z jak� wiadomo�ci mog� przemieszcza� si� przez serwisy spo�eczno�ciowe , mo�esz szybko zosta� obl�onym ruchem. Chocia� prawid�owe u�ycie chmury powinno umo�liwi� automatyczne skalowanie systemu w celu spe�nienia zwi�kszonego zapotrzebowania, dobrze jest, aby zdarzenia o wysokiej widoczno�ci by�y skalowane z wyprzedzeniem dla dodatkowego bezpiecze�stwa. Zawsze, gdy jest to mo�liwe, powinien istnie� solidny system zatwierdzania, aby dzia�y IT informowa�y o kampaniach marketingowych. Na przyk�ad �atwo jest przypadkowo osadzi� identyfikator pliku cookie z bie��cej sesji (np. Jsessionid = 0000000fec3dff553fc1532a937765d43fc42836ed3f8894) w adresie URL linku, kt�ry wysy�asz do klient�w w kampanii e-mail. Mo�esz skalowa� �rodowisko w dowolny spos�b, ale je�li osadzisz identyfikator sesji, wszyscy klienci trafi� na ten sam serwer, je�li masz ci�g�o�� sesji. Aby pom�c IT zrozumie�, w jaki spos�b ich decyzje wp�ywaj� na biznes, dobrze jest okre�li� ilo�ciowo wp�yw r�nych wska�nik�w IT na przychody. Na przyk�ad obliczy�, ile ka�da minuta przestoju kosztuje utracone przychody lub ile ka�da dodatkowa milisekunda czasu �adowania strony negatywnie wp�ywa na przychody. Okre�lenie tych koszt�w pomaga spojrze� na decyzje podejmowane przez ludzi. Zmienia ca�y spos�b my�lenia. Na przyk�ad 20-minutowa przerwa w konserwacji nie wydaje si� zbyt du�a dla wi�kszo�ci administrator�w IT, ale wiedza o tym, �e awaria kosztuje 300 000 USD utraconych przychod�w, sprawi�aby, �e kto� pomy�la�by o sposobach skr�cenia d�ugo�ci awarii lub ca�kowitego jej wyeliminowania. Coraz cz�ciej platformy e-commerce s� tak wa�ne, �e s� wdra�ane w wielu centrach danych, a nawet u r�nych dostawc�w us�ug w chmurze, aby zapewni� jak najwi�ksz� dost�pno�� platformy.

e-Commerce w ChmurzeHandel

Zasady architektury dla chmury