Aplikacja Pokémon Go stała się nie tylko ogromnym sukcesem, ale także ogromnie frustrującym doświadczeniem dla wielu osób. Zwłaszcza dla rodziców podekscytowanych dzieci i nastolatków, chcących natychmiast wyjść i szukać aplikacyjnych stworków. Niestety nie wszyscy mogli to uczynić, bo podczas tworzenia konta, aplikacja chwilowo się zawieszała, a następnie działała wolno z powodu przeciążenia serwera.
Szybko zareagował Werner Vogels, CTO Amazona, który zaproponował pomoc w rozwiązaniu problemów. Autorzy Pokémon Go stwierdzili, że “nie mogli od razu stworzyć aplikacji w chmurze”. A to okazuje się być powodem zaistniałych problemów. Zgodnie z informacjami podanymi na Wikipedii aplikacja przetwarza “ponad 200 milionów działań dziennie podczas interakcji z rzeczywistymi i wirtualnymi obiektami.” Wszelkie przestoje kwituje się frazą “problemy serwera”, ale wszyscy wiemy, że “serwer” to techniczny żargon na określenie “15 różnych komponentów aplikacji i infrastruktury sieciowej”.
Lekcją z tej sytuacji powinno być to, że chmura nie zawsze jest lepsza w radzeniu sobie z niespodziewanym sukcesem. Oczywiście może taką być, ale nie dlatego że jest chmurą samą w sobie, ale dlatego, że stanowi miejsce, gdzie
usługa może zostać wyskalowana.
Ciężko ocenić dlaczego Niantic Labs nie do końca poradził sobie z zapotrzebowaniem. Być może powodem były zbyt niska wydolność
serwerów – w tej sytuacji chmura byłaby
najlepszym wyborem. Drugim powodem mógłby być fakt, że aplikacja (lub infrastruktura) nie została zaprojektowana by się łatwo skalować – w tym wypadku umieszczenie aplikacji w chmurze by nie pomogło.
Ważne, by bazując na przykładzie Niantic Labs, inne
organizacje były równie dobrze przygotowane na sukces, jak i na porażkę. I to nie na stopniowy, powolny
wzrost, ale na natychmiastowy sukces, jaki obserwujemy w przypadku Pokémon Go.
Jednym z problemów związanych ze skalowalnością są problemy ze źródłami danych. Długoletni
użytkownicy Twittera z pewnością pamiętają wczesne lata social media, gdy dotykał ich problem słabej skalowalności baz
danych. PayPal był jednym z najgłośniejszych rzeczników architektury Shard.
Firma musiała poradzić sobie z ogromną liczbą użytkowników, a technika jaką zastosowali została uznana za uniwersalną, stosowaną w bazach danych, usługach i aplikacjach. Obecnie źródła danych NoSQL są uznawane za lepiej skalowalne niż tradycyjne bazy relacyjne.
Inne źródło problemów skalowalności ma swoje źródło w infrastrukturze. Autoskalowanie w chmurze nie polega na zdolności automatycznego zwiększania
wydajności, ale na wzroście wydajności w punkcie styku aplikacji z użytkownikiem. Jakakolwiek architektura, która wymaga skalowalności w pewnym momencie spotka się z problemem równoważenia obciążenia. Oznacza to konieczność korzystania z API i skryptów, odpowiedniej automatyzacji i orkiestracji infrastruktury. Te komponenty powinny znaleźć się w infrastrukturze jeszcze przed tym, gdy będą potrzebne – w innym wypadku pojawią się opóźnienia wymagające z konieczności natychmiastowego zwiększenia wydajności.
Korzystanie z usług równoważenia obciążenia w jakiejkolwiek architekturze aplikacyjnej powinno być wymogiem. Równoważenie obciążenia wspiera skalowalność – cechę konieczną do osiągnięcia sukcesu. Ale nie myślmy o równoważeniu obciążenia jedynie w szczątkowej formie. Ważne by pomyśleć o automatyzacji (skryptach) i orkiestracji (procesach), które pomogą w auto-skalowaniu
popytu na aplikację. Ważne by przygotować architekturę zawczasu, by uprzedzić potencjalne przestoje.
Szczerze mówiąc Niantic Labs świetnie sobie poradził z
zarządzaniem kryzysowym. Problemy z wydajnością były przedstawiane w formie zabawnych
informacji. Były one łatwe do zrozumienia nawet przez dzieci. Być może jednak Niantic Labs nie byli przygotowani na tak duży sukces. Warto więc wdrożyć
strategię skalowalności w
proces budowania aplikacji.
Ireneusz Wiśniewski, Dyrektor Zarządzający w F5 Networks