Chmura hybrydowa

Chocia� aplikacje e-commerce tradycyjnie by�y postrzegane jako monolityczne, a nak�adki (np. HTML, CSS, JavaScript) by�y nierozerwalnie po��czone z backendami (np. Kod zawieraj�cy logik� biznesow� pod��czon� do bazy danych), nie musi tak by�. W dzisiejszym �wiecie wielokana�owym podej�cie polegaj�ce na nierozerwalnym po��czeniu tych dw�ch element�w nie ma ju� sensu z technicznego ani strategicznego punktu widzenia. Je�li podzielisz sw�j frontend od backendu, wi�kszo�� wy�wietle� stron mo�e by� wy�wietlana z twojego frontendu bez dotykania go. Tylko wtedy, gdy dokonujesz transakcji - dodajesz do koszyka, kasujesz, aktualizujesz profil i tak dalej - w rzeczywisto�ci musisz dotkn�� backendu. W tym modelu backend znacznie si� kurczy i pozostaje pod twoj� siln� kontrol�, a frontend mo�e elastycznie wch�ania� wi�kszo�� ods�on w publicznej chmurze. DNS ostatecznie rozwi�zuje problem z interfejsem u�ytkownika, kt�ry nast�pnie wywo�uje go w razie potrzeby.Dok�adnie tak dzia�a wi�kszo�� innych kana��w, z wyj�tkiem Internetu. Grube aplikacje klienckie, takie jak te znalezione w kioskach lub smartfonach, ju� dzia�aj� w ten spos�b z twoim backendem. Czas, aby Internet nadrobi� zaleg�o�ci w stosunku do tego modelu. Opr�cz powod�w strategicznych istniej� praktyczne powody, dla kt�rych nale�y je rozdzieli�. Potrzeby hostingowe dla frontendu r�ni� si� od potrzeb backendu. Tw�j backend wymaga:

• Jedna lub wi�cej wysoce dost�pnych iw pe�ni zabezpieczonych baz danych
• Terabajty pami�ci o wysokiej dost�pno�ci i pe�nej kopii zapasowej
• Wysokiej jako�ci, niezawodny sprz�t
• Wiele zap�r ogniowych
• Integracja z innymi systemami zaplecza
• Najwy�sza mo�liwa dost�pno��
• Najwy�sze mo�liwe bezpiecze�stwo danych w spoczynku
Chocia� chmury mog� to zaoferowa�, wielu b�dzie �atwiej i bezpieczniej zachowa� to w domu. Tw�j interfejs wymaga:

• Szybka elastyczno��
• Du�a przepustowo��
• Najwy�sze mo�liwe bezpiecze�stwo danych w ruchu
• By� niedrogim

Te atrybuty sprawiaj�, �e chmura naturalnie pasuje do frontend�w. Zanim poznasz r�ne smaki rozdzielania frontend�w od backend�w, sprawd�my, w jaki spos�b ta architektura jest naturalnym produktem ubocznym architektury omnichannel.

Chmura hybrydowa jako produkt uboczny architektury Omnichannel

Tradycyjnie aplikacje e-commerce zosta�y napisane i wdro�one w jednym pakiecie zawieraj�cym:

• HTML / CSS / JavaScript
• Kod skryptowy po stronie serwera, taki jak JSP i ASP
• Kod po stronie serwera, taki jak Java lub C #

Ten pakiet by� zwykle wdra�any na serwerze aplikacji jako pojedyncze archiwum, takie jak plik WAR lub EAR. Aby dosta� si� do skompilowanego kodu po stronie serwera, musia�e� najpierw przej�� przez kod skryptu po stronie serwera. Programi�ci pracowali zar�wno nad kodem frontendowym, jak i backendowym. Kiedy internet by� jedynym kana�em, dzia�a�o to dobrze. Wielokana�owy osi�gn�� pe�noletno�� w po�owie 2000 roku, kiedy mobilno�� zacz�a si� rozwija�. Nie wprowadzono �adnych istotnych zmian w architekturze, aby obs�ugiwa� urz�dzenia mobilne i nowe kana�y, kt�re po nim nast�pi�y. Opr�cz istniej�cego stosu zbudowano dodatkowe kana�y obs�uguj�ce interfejs u�ytkownika HTML oparty na przegl�darce internetowej, a integracja sklei�a wszystko razem. Ka�dy kana� dzia�a� w silosie, nie�wiadomy tego, co si� dzia�o w innym kanale, chyba �e mi�dzy dwoma kana�ami by�a pe�na integracja dwukierunkowa. Nawet przy pe�nej dwukierunkowej integracji wra�enia klient�w by�y nadal s�abe, poniewa� integracja heterogenicznych system�w jest z natury podatna na b��dy, a aktualizacje s� zawsze asynchroniczne. Jak omawiali�my w poprzednich rozdzia�ach, rozwi�zaniem tego problemu jest zbudowanie pojedynczej platformy omnichannel, w kt�rej podstawowa funkcjonalno�� (sk�adanie zam�wienia, dodawanie do koszyka, rejestracja nowego konta) jest ujawniana jako us�uga, z dowolnym interfejsem u�ytkownika zdolnym do ich wykorzystania us�ugi .Ta architektura ca�kowicie eliminuje potrzeb� wykonywania jakiejkolwiek integracji, poniewa� r�ne specyficzne dla kana�u interfejsy u�ytkownika s�u�� teraz jako kana�y do tej samej platformy zaplecza. Zar�wno sprzeda� detaliczna omnichannel, jak i chmury hybrydowe wymagaj� oddzielenia frontonu od backendu. Podzia� jest naturalnym wynikiem architektury opartej na omnichannel. Po zerwaniu nak�adki z zaplecza mo�esz wdro�y� ka�d� warstw� osobno, a wszystkie interakcje odbywaj� si� za pomoc� jasno zdefiniowanego interfejsu API. Ten interfejs API mo�e by� ponownie wykorzystywany we wszystkich kana�ach i interfejsach, przy czym wszyscy klienci przeprowadzaj� transakcje z tym samym backendem. Klienci uwielbiaj� p�ynn� interakcj� mi�dzy kana�ami z nast�puj�cych powod�w:

• Ceny, promocje, zapasy, asortyment produkt�w i wszystkie inne dane s� takie same we wszystkich kana�ach.
• Klienci nie musz� tworzy� profili unikalnych dla ka�dego kana�u.
• Klienci mog� aktualizowa� ten sam koszyk na wiele kana��w. Na przyk�ad klient mo�e rozpocz�� zam�wienie na urz�dzeniu mobilnym i zako�czy� je na komputerze stacjonarnym w pracy.
• Klienci mog� poprosi� agent�w Contact Center lub pracownik�w w sklepie fizycznym o pomoc w realizacji zam�wienia rozpocz�tego online.

Wielokana�owy z natury prowadzi do fragmentacji, kt�ra denerwuje klient�w. Z drugiej strony Omnichannel pozwala na bezproblemowe zaanga�owanie klient�w we wszystkich kana�ach. Zanim b�dziemy mogli om�wi� r�ne podej�cia do chmury hybrydowej i jej skrzy�owania z sprzeda�� omnichannel, musimy om�wi�, jak najlepiej po��czy� backend z frontendem w chmurze.

��czenie z chmur�

Kiedy tw�j frontend jest fizycznie oddalony od twojego backendu, musisz po��czy� je razem z po��czeniem. Ka�de ��danie HTTP do twojego interfejsu mo�e skutkowa� od zera do potencjalnie dziesi�tek ��da� do twojego interfejsu. ��dania s� zazwyczaj HTTP, ale mog� nawet by� wywo�aniami bazy danych. Po��czenie om�wione w tej cz�ci jest niezwykle wa�nym ��cznikiem mi�dzy dwiema po��wkami platformy, wi�c musi by� przynajmniej wysoce dost�pne i zapewnia� wystarczaj�c� przepustowo��. Poza tym po��czenie mo�e opcjonalnie zapewnia� bezpiecze�stwo i niskie op�nienia. Mimo �e wydaje si� to wa�nym atrybutem, bezpiecze�stwo nie ma a� tak wielkiego znaczenia. Zawarto�� ka�dego ��dania HTTP lub innego protoko�u komunikacyjnego musi by� zabezpieczona (np. SSL / TLS w przypadku HTTP), ale komunikacja mo�e odbywa� si� przez Internet. Na przyk�ad sieci VPN zabezpieczaj� �adunek, ale dzia�aj� przez Internet. Najwa�niejsze jest zabezpieczenie �adunku, poniewa� nale�y za�o�y�, �e po��czenie jest zawsze zagro�one. Op�nienie jest r�wnie� mniej wa�nym atrybutem, cho� zale�y od architektury. Im wi�cej po��cze� wykonujesz z frontend�w do backend�w i im wi�cej tych po��cze� jest zsynchronizowanych, tym bardziej potrzebujesz niskich op�nie�. Niekt�re aplikacje b�d� wymaga�y niemal kolokacji frontendu z backendem ze wzgl�du na liczb� wyszukiwa� w systemach backendowych. Aby poprawi� wydajno��, zdecydowanie rozwa� u�ycie akceleratora WAN. Je�li udost�pniasz backend z dw�ch lub wi�cej centr�w danych, zdecydowanie rozwa� skierowanie frontend�w do backend�w za pomoc� globalnego modu�u r�wnowa�enia obci��enia z routingiem opartym na op�nieniu. Zapewni to, �e ka�dy frontend ��czy si� z dost�pnym backendem, kt�ry oferuje najni�sze mo�liwe op�nienia. Przy wyborze dostawcy nale�y powa�nie rozwa�y� szeroki zakres i g��boko�� opcji ��czno�ci oferowanych przez potencjalnego dostawc� w chmurze. Przeanalizujmy trzy og�lne podej�cia do ��czenia backend�w z frontendami w chmurze.

Publiczny Internet

Pierwsze podej�cie polega na korzystaniu z publicznego Internetu. Mo�esz udost�pni� sw�j backend w Internecie za po�rednictwem domeny takiej jak backend.website.com. To w�a�nie dzieje si� dzisiaj dla ka�dego kana�u opr�cz Internetu. Dane mog� by� nast�pnie przesy�ane mi�dzy frontendem a backendem przez HTTPS, dok�adnie tak, jak mi�dzy klientem a chmur�. Innymi s�owy, dane w locie mi�dzy twoim frontendem a backendem nie s� bardziej niezabezpieczone ni� mi�dzy klientem a chmur�. Dzi�ki takiemu podej�ciu HTTP GET (np. Https://backend.website.com/AddToCart?order- Id = 12345 & skuId = 67890 i qty = 1) jest niezabezpieczony, poniewa� mimo �e tre�� dania HTTP jest bezpieczna, adres URL jest widoczny dla �wiat. Aby unikn�� tego problemu, musisz wys�a� HTTP POST danych na https://backend.website.com/AddToCart:

{
"orderId": "12345",
"skuId": "67890",
"qty": 1,
…
}

Opr�cz HTTPS b�dziesz chcia� u�y� dodatkowego mechanizmu bezpiecze�stwa, aby nikt poza twoim frontendem nie m�g� dokonywa� transakcji za pomoc� backendu. W przeciwnym razie ka�dy w Internecie by�by w stanie dowolnie wykonywa� polecenia przeciwko backendowi. Wzajemne uwierzytelnianie oparte na certyfikatach jest �wietnym sposobem na zrobienie tego, chocia� istniej� inne. Wymagane jest, aby tylko uwierzytelnieni klienci mogli wysy�a� ��dania HTTP do backendu. Mo�esz skonfigurowa� modu� r�wnowa�enia obci��enia zaplecza, aby akceptowa� tylko ruch z zakresu adres�w IP nale��cych do dostawcy us�ug w chmurze, ale przy tak elastycznym handlu elektronicznym nigdy nie b�dziesz m�g� skonfigurowa� modu�u r�wnowa�enia obci��enia zaplecza, aby doda� do bia�ej listy ka�dy adres IP. Haker nie potrzebowa�by r�wnie� du�o, aby zapewni� serwerowi chmur� publiczn� i wys�a� stamt�d ��dania HTTP, aby omin�� filtr zasi�gu

VPN

Opr�cz HTTPS mo�esz doda� kolejn� warstw� zabezpiecze� w komunikacji mi�dzy frontendem a backendem, korzystaj�c z VPN opartej na protokole IPsec. Ruch odbywa si� nadal przez Internet, ale teraz masz dwie warstwy zabezpiecze�: SSL / TLS dla HTTPS i IPsec. Dostawcy us�ug w chmurze oferuj� te sieci VPN jako integraln� cz�� swojej oferty. Jak zawsze nale�y unika� u�ywania protoko�u HTTP GET do przenoszenia poufnych danych w obie strony.

Po��czenia bezpo�rednie

Wielu dostawc�w us�ug w chmurze oferuje dostawcom colo mo�liwo�� prowadzenia dedykowanych linii �wiat�owodowych w swoich centrach danych. Umo�liwia to dostawcom colo budowanie centr�w danych w tym samym obszarze metra co dostawc�w chmur i oferowanie w chmurze prywatnych po��cze� LAN. Dzi�ki fizycznie zamkni�tym centrom danych uzyskuje si� op�nienie na poziomie milisekund i przepustowo�� na poziomie wielu gigabit�w na sekund�. Po��czenia te s� dedykowane i nie dotykaj� Internetu, tym samym dodaj�c kolejn� warstw� bezpiecze�stwa.

Podej�cia do chmury hybrydowej

Buforowanie ca�ych stron

�wietnym pierwszym krokiem w przej�ciu na przetwarzanie w chmurze jest przeniesienie stron statycznych do chmury w taki sam spos�b, jak CDN obs�uguj� strony statyczne i zawarto�� statyczn� . Oczywi�cie wszystko, co dynamiczne lub jeszcze nie buforowane, musi by� podawane bezpo�rednio od �r�d�a. Odpowiedzi HTTP, bez wzgl�du na to, czy typ odpowiedzi to HTML, XML, JSON, czy inny format, dzia�aj� w ten sam spos�b, z t� r�nic�, �e tre�� mo�e si� r�ni� w zale�no�ci od kilku czynnik�w:

• Czy klient jest zalogowany
• Przegl�darka internetowa / agent u�ytkownika
• Fizyczna lokalizacja (cz�sto dok�adna do zip + 4 w USA lub kod pocztowy poza USA)
• Szybko�� po��czenia internetowego
• Ustawienia regionalne
• System operacyjny

Pod warunkiem, �e mo�esz zidentyfikowa� zmienne wp�ywaj�ce na odpowiedzi HTTP i odpowiednio r�nicowa� odpowiedzi HTTP, to podej�cie dzia�a bardzo dobrze w przypadku odci��ania wi�kszo�ci twoich ��da� HTTP. Buforowanie tego rodzaju jest powszechnie stosowane, szczeg�lnie przed du�ymi ruchami, na przyk�ad przed wakacjami lub podczas specjalnych wydarze�, takich jak Superbowl. U�yj tego podej�cia, aby zoptymalizowa� istniej�c� witryn� e-commerce, niezale�nie od tego, czy jest zgodna z zasadami architektury omnichannel. Jest szybki i �atwy do zrobienia i dzia�a najlepiej na stronach, kt�re nie zmieniaj� si� tak bardzo. Strony g��wne, kategorie stron docelowych i najlepiej sprawdzaj� si� strony ze szczeg�ami produktu. Aby to zrobi�, potrzebujesz oprogramowania, kt�re wykonuje nast�puj�ce czynno�ci:

• Siedzi mi�dzy klientem a punktem ko�cowym (zazwyczaj serwerem aplikacji). Serwery proxy i us�ugi r�wnowa�enia obci��enia zwykle spe�niaj� t� potrzeb�.
• Mo�e zbada� ka�de ��danie HTTP. W stosie OSI odnosi si� to do warstwy 7. Na przyk�ad oprogramowanie powinno by� w stanie spojrze� na nag��wek ��dania HTTP agenta u�ytkownika.
• Mo�e akceptowa� regu�y czarnej listy dotycz�ce tego, czego nie nale�y buforowa�. Na przyk�ad powiniene� by� w stanie zdefiniowa� regu��, kt�ra m�wi, �e wszystko w / checkout powinno by� natychmiast przekazywane z powrotem do �r�d�a.
• Rozumie zmienne wp�ywaj�ce na odpowied�. Na przyk�ad mo�esz zmienia� odpowied� w zale�no�ci od tego, czy klient jest zalogowany, czym jest agent u�ytkownika i fizyczn� lokalizacj�. Ka�dy z tych atrybut�w po��czy�by si�, tworz�c unikalny klucz. Je�li istnieje buforowana kopia, powiedzmy, XML odpowiadaj�ca temu kluczowi, powinna by� zwracane. Je�li nie, ��danie nale�y przekaza� z powrotem do �r�d�a z odpowiedzi� �r�d�o generuje buforowane.
• Mo�e szybko i skutecznie przechowywa� i pobiera� gigabajty danych w pami�ci podr�cznej.
• Mo�e szybko opr�nia� pami�ci podr�czne po aktualizacjach bazowych danych.

Kluczem jest identyfikacja zmiennych, kt�re powoduj�, �e wyj�cie ka�dego adresu URL zmienia swoj� odpowied�. Po ich zidentyfikowaniu mo�esz zbuforowa� wi�kszo�� da� HTTP. Po�rednicy wszelkiego rodzaju s� w stanie to zrobi�. R�wnowa�niki obci��enia i serwery proxy s� typowymi przyk�adami, ale nawet wiele serwer�w WWW jest w stanie to zrobi�. Ta funkcja jest wbudowana w sieci CDN, kt�re mog� s�u�y� jako odwrotne serwery proxy, ale mo�na tak�e wdra�a� wybrane oprogramowanie w publicznych chmurach IaaS. Generalnie najlepiej jest polega� na sieciach CDN, aby zapewni� t� funkcjonalno��, poniewa� maj� one t� zalet�, �e wypychaj� strony z pami�ci podr�cznej do ka�dego z dziesi�tek, a nawet setek centr�w danych na ca�ym �wiecie. Klienci prawdopodobnie nie znajd� si� w odleg�o�ci wi�kszej ni� kilka milisekund od punktu ko�cowego, co oznacza, �e wi�kszo�� da� HTTP mo�e by� obs�ugiwana praktycznie bez op�nie� i bez oczekiwania na wygenerowanie odpowiedzi. Opr�cz wydajno�ci CDN-y udost�pniaj� t� funkcjonalno�� jako SaaS, kt�ra uwalnia ci� do koncentrowania energii na wy�szym poziomie �a�cucha warto�ci. Jedynym przypadkiem zrobienia tego w publicznej chmurze Infrastruktura jako us�uga jest to, �e jest to Twoja pierwsza pr�ba bardziej merytorycznego przetwarzania w chmurze i chcesz to zrobi� jako �wiczenie edukacyjne. Jest to do�� atwe do zrobienia, ale zapewnia znaczne korzy�ci. Je�li nie jeste� jeszcze sprzedawany w chmurach publicznych, mo�esz to zrobi� w swoich istniej�cych centrach danych. Modu� r�wnowa�enia obci��enia, kt�rego u�ywasz dzisiaj, prawdopodobnie ma t� funkcj�. Chocia� jest to doskona�e podej�cie dla u�amka ruchu, aby buforowa� wi�cej, musisz spojrze� na nast�pne podej�cie.

Nak�adanie HTML na buforowane strony

Chocia� wiele ��da� HTTP mo�e by� obs�ugiwanych bezpo�rednio z pami�ci podr�cznej, niekt�re nie. Na przyk�ad klienci przegl�daj�cy stron� ze szczeg�ami produktu cz�sto widz� list� produkt�w zalecanych na podstawie historii przegl�dania lub historii zakup�w. S� to tak zwane produkty You Might Like Like, w skr�cie YMAL. Gdy wi�kszo�� danej strony jest taka sama, ale zmienia si� tylko niewielka cz��, mo�esz buforowa� ca�� stron� w po�redniku zgodnie z poprzednim podej�ciem, ale nast�pnie dynamicznie nak�ada� kilka fragment�w tre�ci, kt�re faktycznie zmieniaj� si� po stronie klienta. Mo�esz �atwo zastosowa� t� technik� do:

• Oceny i recenzje
• W�zki na zakupy
• Bu�ka tarta
• Banery "Cze��, !" W nag��wku

Oto bardzo prosty przyk�ad tego, jak powinien wygl�da� kod:

< head >
< script src = "http://www.website.com/app/jquery/jquery.min.js" >
< /script >
< script >
$ .ajax ({url: "http://backend.website.com/app/RetrieveYMALs?
productId = 12345 i customerId = 54321 ",
sukces: funkcja (wynik) {
$ ("# YMALs"). Html (wynik);
}});
< /script >
< /head >
< body >
< ! - Szczeg�y produktu … - >
< div id = "YMALs"> < /div >
… reszta strony internetowej
< /body >

Aby to zadzia�a�o, asynchroniczne ��danie HTTP musi zosta� zwr�cone tak szybko, jak to mo�liwe. Je�li b�dziesz czeka� zbyt d�ugo, aby wykona� ��danie asynchroniczne, klient zobaczy stron� w pe�ni renderowan�, ale bez nak�adki. W przyk�adzie YMAL klient zobaczy odmalowanie ekranu lub, co gorsza, bia�e znaki, gdzie produkty powinny by� wymienione. Aby to zrobi�, wykonaj asynchroniczne wywo�anie tak wcze�nie, jak to mo�liwe podczas �adowania strony g��wnej, aby r�wnolegle jak najwi�cej za�adowa�. Umie�� po��czenie u g�ry nag��wka. Upewnij si� r�wnie�, �e czas reakcji us�ugi dostarczaj�cej tre�� odpowiada tak szybko, jak to mo�liwe. Odpowied� powinna zaj�� kilka milisekund, aby unikn�� "przeskakiwania" strony podczas malowania r�nych cz�ci strony. Musisz tak�e zaprojektowa� interfejs u�ytkownika na wypadek awarii. Je�li ��danie asynchroniczne nie dzia�a, klient nigdy nie powinien wiedzie�. Innymi s�owy, nie powinno by� dziury, w kt�rej powinna znajdowa� si� tre�� adowana asynchronicznie. Na koniec zaprojektuj interfejs u�ytkownika, aby zapewni� p�ynne wycofanie. Je�li klient nie obs�uguje JavaScript, ca�kowicie pomi� tre�� dynamiczn� lub wr�� do �r�d�a, aby wy�wietli� dynamiczn� wersj� strony. Na przyk�ad wi�kszo�� bot�w wyszukiwarek nie obs�uguje JavaScript. Chcesz, aby ca�a strona by�a indeksowana. Po pe�nym i prawid�owym wdro�eniu technika ta mo�e znacznie zmniejszy� obci��enie, kt�re uderza w backend. Im wi�cej podajesz z interfejsu w chmurze, tym mniej musisz z niego obs�ugiwa�.

Korzystanie z sieci dostarczania tre�ci do wstawiania HTML

Zamiast nak�ada� dynamiczne fragmenty po stronie klienta, tak jak w poprzednim podej�ciu, mo�na nak�ada� je na CDN lub r�wnowa�ny po�rednik. Nie robi�c nic po stronie klienta, nie musisz si� martwi� o wdzi�czne cofni�cie si�, je�li klient nie obs�uguje JavaScript lub innych problem�w, kt�re pojawiaj� si�, gdy pr�bujesz zbudowa� stron� przez asynchroniczne �adowanie HTML z gdzie� indziej. Inn� zalet� jest to, �e nie musisz na si�� oddziela� nak�adki od zaplecza, co om�wimy w nast�pnym podej�ciu. Je�li chcesz zwi�kszy� liczb� stron, kt�re mo�esz wy�wietla� z pami�ci podr�cznej i nie chcesz przepisa� aplikacji, to jest twoje podej�cie. Podobnie jak w przypadku nak�adki po stronie klienta, technologia jej wdra�ania nie ma a� tak wielkiego znaczenia. Liczy si� to, �e mo�esz wyra�nie okre�li�, gdzie chcesz wstawi� dynamiczn� tre�� i z jakiego �r�d�a. Najpopularniejszym frameworkiem jest Edge Side Includes (ESI). ESI to prosty j�zyk znacznik�w, kt�ry �ci�le na�laduje mo�liwo�ci po stronie serwera, o czym om�wimy w dalszej cz�ci. Oto przyk�ad, jak m�g�by wygl�da� kod:

< body >
< ! - Szczeg�y produktu … - >
< div id = "YMALs" >
< esi: include
src = "http://backend.website.com/app/
Pobiera� YMAL? ProductId = 12345 i customerId = 54321 "/ >
< /div >
…reszta strony internetowej
< /body >

Wi�kszo�� g��wnych sieci CDN obs�uguje ESI, podobnie jak niekt�re us�ugi r�wnowa�enia obci��enia i odwrotne proxy. Chocia� najlepiej jest stosowa� t� technik� w sieciach CDN ze wzgl�du na ich zdolno�� do buforowania zawarto�ci i wypychania jej do kraw�dzi, z pewno�ci� mo�na u�ywa� r�wnowa�enia obci��enia i odwrotnych serwer�w proxy. Tutaj kod jest o wiele �atwiejszy do napisania, poniewa� nie musisz si� martwi� cokolwiek asynchronicznie lub wynikaj�ce z tego problemy. Wystarczy wstawi� dynamiczne fragmenty strony i zwr�ci� klientowi ca�y dokument HTML, gdy b�dzie gotowy. Niekt�re frameworki umo�liwiaj� nawet asynchroniczne �adowanie ka�dego z do��cze�, a ca�a strona nie jest zwracana do klienta, dop�ki nie zostanie zwr�cone ostatnie do��czenie. Poprawia to wydajno��, szczeg�lnie je�li masz wiele r�nych opcji. Ponownie, to podej�cie jest �wietnym po�rednikiem, kt�ry pozwoli ci buforowa� znacznie wi�cej ni� w innym przypadku, ale bez konieczno�ci przepisywania aplikacji.

Nak�adanie HTML po stronie serwera

To nast�pne podej�cie polega na tym, �e frontend dla Twojej witryny jest niezale�nie obs�ugiwany z chmury, a dynamiczna tre�� z twojego backendu jest wpleciona w stron� wygenerowan� przez twoj� stron�. Jest to zasadniczo inne podej�cie ni� korzystanie z CDN lub klienta do nak�adania fragment�w, poniewa� w tym modelu faktycznie obs�ugujesz frontend niezale�nie od backendu. Dziel�c frontend z backendu, pobierasz tylko ma�e, dynamiczne fragmenty z backendu. Twoja nak�adka mo�e by� nast�pnie uruchomiona w dowolnym miejscu, tak jak w chmurze publicznej. Frontend, kt�ry obs�uguje wi�kszo�� ruchu, mo�e nast�pnie dynamicznie skalowa� w g�r� i w d�, w razie potrzeby pobieraj�c dynamiczne fragmenty z backendu. Tw�j backend mo�e by� wtedy znacznie mniejszy i hostowany tradycyjnie. Mo�liwo�ci wstawiania zawarto�ci dynamicznej do istniej�cej strony istnia�y od pierwszych dni Internetu, poczynaj�c od wersji serwerowych, kt�re s� nadal u�ywane. Wszystkie biblioteki znacznik�w skryptowych r�wnie� obs�uguj� to poprzez importowanie lub do��czanie znacznik�w. Oto przyk�ad, jak m�g�by wygl�da� kod:

< body >
< ! - Szczeg�y produktu … - >
< div id = "YMALs" >
< ! - # obejmuj�
virtual = "http://backend.website.com/app/
Pobiera� YMAL? ProductId = 12345 i customerId = 54321 "- > < /div >
… reszta strony internetowej
< /body >

Chocia� technologia jest do�� prosta, wdro�enia architektoniczne s� ogromne. Zamiast po prostu podawa� statyczny dokument HTML, a nast�pnie nak�ada� dynamiczne fragmenty, tak naprawd� generujesz dynamiczn� stron� dla ka�dego klienta w chmurze i po prostu w tym dynamiczne fragmenty, kt�rych potrzebujesz z backendu, je�li to konieczne. To �wietny spos�b na przeniesienie du�ej cz�ci obci��enia do dynamicznej chmury. W tym modelu backend jest wy��cznie odpowiedzialny za dostarczenie niewielkiej ilo�ci tre�ci, a frontend jest odpowiedzialny za dostarczenie du�ej cz�ci rzeczywistej zawarto�ci. To du�a r�nica, cho� techniczne podstawy istniej� od dziesi�cioleci.

W pe�ni odsprz�one frontendy i backendy

We wszystkich dotychczas udokumentowanych podej�ciach przyj�to, �e tre��, kt�ra zostanie na�o�ona, to HTML. Ale jak pami�tacie z wcze�niejszej cz�ci ksi��ki, kana� internetowy, w kt�rym u�ywany jest HTML, jest szybko marginalizowany na korzy�� kana��w mobilnych i innych. Tylko przegl�darki internetowe u�ywaj� HTML. Ka�dy inny kana� zu�ywa jak�� form� XML lub JSON pochodz�c� z twojego �r�d�a, co powoduje, �e wszystkie dotychczasowe podej�cia nie maj� znaczenia dla kana��w nie-internetowych. Dzi�ki takiemu podej�ciu frontend znajduje si� w chmurze i w razie potrzeby pobiera ma�e fragmenty dynamicznej zawarto�ci z backendu. R�nica mi�dzy tym a poprzednim podej�ciem polega na tym, �e odpowiedzi� backendu powinien by� XML lub JSON zamiast HTML. Odpowiedzi w HTML s� z pewno�ci� �atwiejsze, poniewa� nie musisz tak bardzo zmienia� kodu. Problem polega jednak na tym, �e uniemo�liwia to ponowne wykorzystanie us�ug zaplecza w r�nych kana�ach, poniewa� �aden z pozosta�ych kana��w nie mo�e u�ywa� HTML. W tym modelu konstruujesz strony HTML przy u�yciu danych z zaplecza, ale nie z prezentacji. Jest to czysty rozdzia� mi�dzy prezentacj� a logik� biznesow�. Oto przyk�ad, jak m�g�by wygl�da� kod:

< body >
< ! - Szczeg�y produktu … - >
< div id = "YMALs" >
< c: import url = "http://backend.website.com/app/
Odzyska� YMAL? ProductId = 12345 i customerId = 54321 "
var = "ymals" / >
< h2 > < c: out value = "$ {ymals.displayText}" > < /h2 >
< c: forEach items = "$ {ymals.products}" var = "product" >
< jsp: include page = "/ app / productDetailYMAL.jsp" >
< jsp: param name = "product" value = "$ {product}" / >
< / jsp: include >
< / c: forEach >
< /div >
… reszta strony internetowej
< /body >

Ponownie jest to fundamentalne odchylenie od liczby dzisiejszych stron internetowych, a backend zapewnia tylko uporz�dkowane dane. Najlepsze w tym podej�ciu jest to, �e us�ugi udost�pniane przez backend (np. http://backend.website.com/app/RetrieveYMALs) mo�na ponownie wykorzysta� we wszystkich kana�ach, poniewa� ujawniasz tylko surowe dane. To jest przysz�o�� architektury e-commerce, niezale�nie od tego, gdzie wdro�ysz swoje interfejsy i backendy. Takie podej�cie wymaga znacznych zmian w kodzie i architekturze, ale d�ugoterminowe korzy�ci s� transformacyjne w stosunku do sposobu prowadzenia dzia�alno�ci.

Wszystko opr�cz bazy danych w chmurze

Najbardziej ekstremaln� form� przetwarzania hybrydowego jest umieszczanie wszystkiego w chmurze publicznej opr�cz bazy danych. Tw�j frontend jest ca�kowicie podzielony z backendu, aby przestrzega� zasad architektury omnichannel, ale wdra�asz obie warstwy w chmurze, a komunikacja frontend-backend odbywa si� ca�kowicie w chmurze. Tylko Twoja baza danych znajduje si� poza chmur�, Poniewa� op�nienie jest tak wa�ne, nale�y stosowa� to podej�cie w po��czeniu z bezpo�rednim po��czeniem z "��czenia z chmur�", w kt�rym hostujesz baz� danych w systemie colo, kt�ry ma bezpo�rednie fizyczne po��czenie z chmur�, z kt�rej korzystasz. Wyci�gni�cie jednego produktu z bazy danych mo�e spowodowa� dziesi�tki zapyta� SQL, poniewa� dane mog� by� roz�o�one na dziesi�tki tabel. Gdy potencjalnie wykonanych jest kilkadziesi�t szeregowych instrukcji SQL na ��danie HTTP, op�nienie szybko zabija wydajno��. W przypadku bezpo�redniego po��czenia czas oczekiwania powinien wynosi� co najmniej milisekund�, sprawiaj�c, �e nie jest to ju� problemem. Bazy danych mo�na wdra�a� w chmurze, ale mo�e by� �atwiej wdro�y� je w colo pod��czonym do chmury, poniewa� bazy danych maj� rygorystyczne wymagania dotycz�ce oprogramowania, sprz�tu, sieci, pami�ci i bezpiecze�stwa, kt�re mog� nie by� w pe�ni oferowane przez baz� danych w Chmura. Zastosowanie monolityczne z nierozdzielnymi frontendami i backendami r�wnie� mo�e skorzysta� z tego podej�cia.

e-Commerce w ChmurzeHandel

Chmura hybrydowa