Pokemon GO - dlaczego aplikacja od samego początku nie działała tak, jak powinna?

Aplikacja Pokemon GO stała się nie tylko ogromnym sukcesem, ale także ogromnie frustrującym doświadczeniem dla wielu osób. 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 z Amazona, który zaproponował pomoc w rozwiązaniu problemów. Autorzy Pokemon GO stwierdzili, że “nie mogli od razu stworzyć aplikacji w chmurze”. A to okazuje się być powodem zaistniałych problemów. Aplikacja ma bowiem przetwarzać “ponad 20. 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 tak by łatwo się skalować – w tym wypadku umieszczenie aplikacji w chmurze by nie pomogło. Skalowanie aplikacji to łatwość w rozszerzaniu aplikacji lub jej architektury celem zwiększania wydajności.

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 Pokemon 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 (skrypty) i orkiestracji (procesy) 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 i orkiestracji, 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.

słk

WP / F5Networks