2. Do strony sklepu wstawiamy odpowiednie tagi script w nagłówku oraz wskazujemy Fablo gdzie jest:

- pole „Szukaj”:

$(‘#szukaj’).fabloSearchInput({resultDivId: ‘wynikiFablo’});

- miejsce, gdzie mają „rozwinąć się” wyniki wyszukiwania, czyli nawigacja po wynikach:

<div id=”wynikiFablo”></div> <p>

3. Jeśli trzeba, zmieniamy szablon produktu, dodając tam link do naszego koszyka, lub inne elementy. Przykładowo, aby przy każdym produkcie dodać informację o promocji:

‘<% if(attributes.Promowany) { %> PROMOCJA! <% } %>’

Od tej pory wpisanie czegokolwiek w pole „Szukaj” powoduje rozwinięcie nawigacji po wynikach wyszukiwania i włączenie instant search. Wygląd interfejsu można modyfikować albo zmieniając CSS, albo korzystając z narzędzia jQuery UI Themeroller. Można też konfigurować układ Fablo dodając opcje Javascript i korzystając z Panelu Klienta.

AWS jest podzielone na pięć regionów geograficznych. Awarie miały miejsce w regionie US-EAST-1 (Virginia), gdzie mamy naszą instalację testową. Nasze serwery produkcyjne obsługujące klientów są uruchomione w regionie EU-WEST-1 (Irlandia), niedawne problemy więc naszych klientów w żaden sposób nie dotknęły.

Dodatkowo, w każdym z regionów istnieje kilka tzw. „stref dostępności”, z których każda jest fizycznie odrębną instalacją. Przykładowo, w US-EAST-1 są cztery takie strefy. Nawet wydarzenia takie jak pożar, awaria zasilania, czy odcięcie łączności powinny dotykać tylko jednej ze stref dostępności, nigdy wszystkich. Ostatnie awarie dotyczyły tylko dwóch z czterech stref dostępności.

Niedawne problemy były związane głównie z usługą EBS (Elastic Block Store), którą zawsze uważaliśmy za problematyczną. Fablo nigdy nie używało i nie używa EBS do niczego istotnego. Awaria dotknęła za to wielu popularnych serwisów sieciowych opartych na bazach SQL — które najwygodniej się instaluje właśnie na wolumenach EBS. Nasze systemy są projektowane tak, by nie korzystać z bazy SQL.

Awarie w Amazon AWS zdarzają się bardzo rzadko, ale w praktyce w każdym odpowiednio dużym systemie muszą się takowe wydarzyć. Dlatego mamy na takie okazje przygotowane procedury. Całą instalację produkcyjną Fablo jesteśmy w stanie odtworzyć automatycznie. W ten właśnie sposób jest budowana i stawiana instalacja testowa — automatycznie od zera do działającej infrastruktury. Jesteśmy więc gotowi, w razie poważniejszych awarii, uruchomić całą produkcyjną infrastrukturę w dowolnym regionie (i dowolnej strefie dostępności) Amazon AWS i przekierować tam obsługę zapytań. Operacja taka trwa około godziny, co jest wyjątkowo krótkim czasem — nieosiągalnym w przypadku poważniejszych awarii własnych serwerowni.

Dla najbardziej wymagających klientów jesteśmy w stanie zaoferować obsługę z pełną redundancją — równocześnie w dwóch strefach dostępności lub nawet w dwóch regionach geograficznych.

Jesteśmy zdania, że dla oprogramowania zaprojektowanego do pracy w „chmurze” (jak nasze) można oferować znacznie lepsze warunki niezawodności niż dla tradycyjnych rozwiązań.

Dlaczego uważamy, że świadczenie „usługi wyszukiwania” ma sens? Powodów jest kilka:

• Skalowalność. Gdy w TVN CNBC powiesz o swoim sklepie, możemy w ciągu pojedynczych minut uruchomić kolejne serwery API, by zapewnić obsługę nawału zapytań. Tysiące zapytań na sekundę nie będą dla nas problemem. A jak szybko możesz uruchomić dodatkowe serwery w swoim sklepie?

• Niezawodność. Zindeksowane dane trzymamy w Amazon S3. Każdy plik zapisywany jest w co najmniej trzech kopiach, na trzech różnych dyskach, w różnych maszynach. W ilu kopiach trzymane są dane Twojego sklepu? Do tego jesteśmy w stanie zapewnić niezawodną obsługę zapytań przez uruchomienie dowolnej ilości równolegle i niezależnie pracujących serwerów API, w kilku różnych fizycznych serwerowniach (a czy Twoje serwery są odporne na awarię zasilania lub pożar jednej serwerowni?).

• Niskie koszty. Utrzymanie własnych serwerów jest drogie. Często się tego nie zauważa, bo nie uwzględnia się wszystkich kosztów — takich jak chociażby koszt zapewnienia gotowości zapasowych serwerów na wypadek awarii, koszt administratorów i serwisantów koniecznych do szybkiego reagowania na problemy, koszt wymiany sprzętu, który po 2-3 latach staje się przestarzały, czy koszt przeszkolenia personelu co do instalowanego oprogramowania. Na pozór wydaje się, że można zapewnić infrastrukturę taniej niż Amazon — ale jest to złudzenie. Tylko w skali dziesiątek i setek tysięcy serwerów można zapewniać usługi tak tanio.

• Łatwość aktualizacji oprogramowania. W modelu SaaS to my odpowiadamy za aktualizacje, możemy je robić sprawnie i przewidywalnie. Możemy łatwo uruchomić zapasowe serwery do obsługi zapytań w trakcie procedury upgrade.

• Odpowiedzialność. W modelu SaaS dokładnie wiadomo kto za co odpowiada. Zadaniem Fablo jest takie utrzymanie usługi, by odpowiadać na zapytania. W każdym innym modelu to klient martwi się zapewnieniem niezawodności serwerów i poprawnym uruchomieniem oprogramowania.