Uzależnienia szkodzą, zwłaszcza małym serwisom – na przykładzie widgetów i map

Uzależnianie swojego biznesu od pojedynczego czynnika, który jeśli nawali to nawali też cały biznes, nigdy nie jest zdrowe. Czasami nie ma innego wyjścia bo wynika to ze specyfiki danego biznesu, ale wszędzie tam, gdzie jest to możliwe, należy takie sytuacje eliminować lub ograniczać ich możliwe skutki. Dwa najczęściej spotykane obszary uzależnień małych serwisów internetowych od większych, to uzależnienie od źródła użytkowników i/lub ruchu oraz uzależnienie od zewnętrznych funkcjonalności. W dzisiejszym webie, który coraz bardziej opiera się na widgetach oraz różnego rodzaju API, ta kwestia nabiera coraz większego znaczenia.

Zakręcanie kurka
Niedawny przykład MySpace vs. Photobucket bardzo dobrze pokazuje takie zależności. W sytuacji, gdy znaczący procent ruchu Photobucket generowany jest przez widgety umieszczone na MySpace, zablokowanie ich na stronach najpopularniejszego serwisu społecznościowego oznacza bardzo wymierne straty. MySpace zastosowało straszak – zablokowało jedynie widgety video, które jako stosunkowa nowość nie są znaczącą częścią popularności Photobucket, opierającym się głównie na widgetach ze zdjęciami. Było to więc dosyć nieszkodliwe, ale niosło wyraźne przesłanie: “widgety ze zdjęciami możemy zablokować równie łatwo, a wtedy będziecie mieli realny problem”.
Gdy kilka dni później okazało się, że MySpace kupił Photobucket za $250M, jasnym było, że blokada widgetów była nieprzypadkowa.

• Odstraszyła konkurentów, z którymi Photobucket równolegle negocjował, pokazując im, że wartość tej firmy w dużej mierze oparta jest na czymś tak mało przewidywalnym i mało pewnym jak kaprys MySpace.
• Pozwoliła zaoszczędzić kilkadziesiąt milionów dolarów – Photobucket początkowo wyceniał się na $300M, po czym bardzo szybko po blokadzie widgetów sprzedał się za $50M mniej.

Ta historia tak naprawdę zakończyła się happy endem, bo choć $50M piechotą nie chodzi to uzyskana cena wciąż jest sukcesem inwestorów i twórców Photobucketa, w którego stworzenie zainwestowano łącznie $15M – zatem inwestycja zwróciła się szesnastokrotnie w ciągu czterech lat od powstania firmy. Wiele innych historii jednak nie kończy się aż tak szczęśliwie.

Zabieranie narzędzi
O ile uzależnienie swojej popularności nie rujnuje całego serwisu, bo nigdy nie jest tak, że 100% ruchu pochodzi z jednego źródła, to uzależnienie swoich głównych funkcjonalności od zewnętrznych usług jest o tyle groźniejsze, że w przypadku ich blokady praktycznie cały serwis może przestać działać. Na własnej skórze poczuli to twórcy serwisu Statsaholic, prezentujący oraz pozwalający porównać dane dotyczące popularności witryn pochodzące z serwisu Alexa. Historia blokowania Statsaholic przez Alexę jest długa i powinna być przestrogą dla wszystkich, którzy rdzeń swoich funkcjonalności opierają na funkcjonalnościach zewnętrznych.

Jeśli mapy to… od Google
Tam gdzie można, należy unikać tego typu uzależnień jak ognia. Świetnym przykładem na takie silne uzależnienia, których skutki można jednak zminimalizować, jeśli odpowiednio wcześnie się o nich pomyśli, są wszelkiego rodzaju serwisy oparte o osadzane, zewnętrzne mapy. Każdy prawdopodobnie będzie w stanie wskazać wiele takich serwisów – w moich bookmarkach z racji szczególnego zainteresowania tematem znajduje się kilkadziesiąt, jeśli nie nawet ponad setka takowych. Niemalże wszystkie z nich korzystają z Google Maps, a z moich rozmów z programistami i projektantami serwisów wynika, że niemalże nikt nie myśli o ewentualności nagłej niedostępności Google Maps – na przykład poprzez indywidualne zablokowanie ich serwisu, ale powody tak naprawdę mogą być różne i nie są one w zasadzie istotne, istotny jest skutek.

Wszystkie te serwisy są bardzo mocno uzależnione od Google, które jest w stanie je zniszczyć w ciągu jednej sekundy, odcinając je od API. Na szczęście można się przed tym zabezpieczyć, problem w tym, że mało kto o tym myśli odpowiednio wcześnie.

Istnieje też świat poza Google
Google Maps to nie jedyny serwis oferujący mapy wraz z API. Porównywalną funkcjonalność oferują choćby Yahoo Maps czy Live Search Maps Microsoftu. Teoretycznie można więc przepiąć się z jednej mapy na inną i przywrócić zniszczoną funkcjonalność. W praktyce może to być bardzo łatwe albo bardzo trudne, w zależności od tego czy projektując serwis przewidzieliście taką możliwość.

Przepisanie dużego serwisu z Google Maps na Yahoo Maps może zająć wiele dni lub wręcz tygodni – jeśli zewnętrzna funkcjonalność wywoływana jest bezpośrednio w tych wszystkich miejscach, które jej używają – lub kilkanaście godzin, jeśli zastosowana była odpowiednia warstwa abstrakcji. Ta różnica w czasie przywrócenia działania podstawowych funkcjonalności serwisu może mieć krytyczne znaczenie dla funkcjonowania całego biznesu. Dlatego jeśli tworzycie serwis oparty na zewnętrznych funkcjonalnościach (dotyczy to wszystkiego, nie tylko map), twórzcie warstwy abstrakcji, dzięki którym zmiana dostawcy usług będzie możliwa w znacznie krótszym czasie.

Czym jest warstwa abstrakcji
Dla osób nie będących programistami lub architektami oprogramowania postaram się krótko i w uproszczeniu wyjaśnić tę ideę. Zamiast wywoływać zewnętrzną funkcjonalność w każdym miejscu aplikacji, która jej potrzebuje, stwórzcie warstwę abstrakcji, która będzie integralną częścią Waszego serwisu i to do niej kierowane będą wszystkie wywołania z każdego miejsca w aplikacji, które potrzebuje danej funkcjonalności. Będzie ona czymś w rodzaju wewnętrznego API, z którego korzystać będziecie zamiast bezpośrednio z zewnętrznego API – i dopiero ona wywoływać będzie właściwe, zewnętrzne API poprzez moduł/klasę implementującą. Cała integracja z zewnętrznym API polegać będzie właśnie na tym module implementującym, który obrazowo ujmując tłumaczył będzie wywołania Waszej klasy abstrakcji na wywołania rozumiane przez zewnętrzne API. Przepięcie się na innego dostawcę usług polegać będzie jedynie na napisaniu nowego modułu tłumacza, a wszystkie setki lub tysiące miejsc w Waszej aplikacji korzystające z tej funkcjonalności pozostaną bez zmian, wywoływać będą bowiem bezpośrednio tylko Waszą klasę abstrakcji, której interfejs pozostał niezmieniony.

Taka architektura pozwala skrócić czas niezbędny do zmiany dostawcy z liczonego w dniach na liczony w godzinach. Jeszcze większa różnica będzie, jeśli stare i nowe zewnętrzne API nie udostępniają dokładnie takiej samej funkcjonalności i trzeba zastosować całkiem nowe rozwiązania, żeby za pomocą nowego API uzyskać taką samą funkcjonalność naszej witryny jak poprzednio – wówczas czas przystosowania do nowego API serwisu nie korzystającego z warstwy abstrakcji może być liczony nawet w tygodniach. Dlatego istotnym jest też, żeby metody udostępniane przez Waszą warstwę abstrakcji nie były odwzorowaniem jeden-do-jeden metod udostępnianych przez zewnętrzne API, a odzwierciedleniem funkcjonalności potrzebnych w Waszej aplikacji. To moduł implementujący zewnętrzne API, czyli moduł “tłumacza”, powinien zatroszczyć się o rozwiązanie Waszych potrzeb odpowiednio stosując zewnętrzne API. Przy takim podejściu zmiana dostawcy wymagała będzie najmniej pracy oraz czasu.

Ta banalna i dla wielu oczywista prawda jest jakże często zapominana przez projektantów i twórców serwisów i ja sam widziałem na to całe mnóstwo przykładów – szczególnie w przypadku API obsługiwanych z poziomu JavaScript (czyli na przykład mapy).

Unikajcie uzależnień lub ograniczajcie ich skutki
Krótka lekcja do wyciągnięcia przez wszystkich twórców z doświadczeń Photobucket i Statsaholic oraz niniejszego artykułu jest taka: używajcie warstw abstrakcji wszędzie, gdzie polegacie na czymkolwiek pochodzącym z zewnątrz. Bardziej ogólnie: unikajcie uzależnień Waszego biznesu od niezależnych od Was firm, a tam, gdzie nie jest to możliwe, starajcie się ograniczyć jego skutki – na przykład przez wcześniejsze rozpoznanie możliwych alternatyw i takie zaprojektowanie Waszego biznesu, żeby ewentualna zmiana dostawcy kosztowała Was najmniej.