Czasami inspirację do kolejnych tematów na blogu dostarcza samo życie, w tym kontakty z osobami spoza branży IT. Zwykle takie rozmowy są bardzo wartościowe, szczególnie ze względu na poznawanie różnych perspektyw i punktów widzenia na pewne sprawy osób z "zewnątrz". Naturalne jest też to, że ludzie nieznający tworzenia aplikacji od podszewki mogą mieć problem z niektórymi terminami - czasami ich nigdy nie poznali i próbują opisać swoją koncepcję w sposób, który niekiedy może mylić się z zupełnie inną technologią. Zauważyłem, że tak często dzieje się ze skalowaniem - niektórzy klienci tym pojęciem opisują zdolność interfejsu do bycia czytelnym zarówno na laptopie, jak i smartfonie. A to zupełnie nie tak i to słowo w IT oznacza zupełnie coś innego. Postaram się to dzisiaj wyjaśnić.
Czym jest responsywność?
Tutaj tak naprawdę funkcjonują dwa znaczenia, jednak jedno z nich jest znacznie częściej używane. A jest nim wspomniana wcześniej "elastyczność" ekranu.
Ściślej ujmując temat, wiemy doskonale, że od dłuższego czasu równie wiele (a może i więcej) osób przegląda strony internetowe na swoich smartfonach lub tabletach, które z natury mają mniejsze ekrany. Także na laptopach rozdzielczość nie jest taka "pewna", gdyż niby może być to Full HD (1920 x 1080 pikseli), ale tak spora grupa ma włączone przybliżenie w Windowsie (przez co rozdzielczość jest niższa), niektórzy po prostu ją zmniejszają, inni mają dodatkowe, bardzo szerokie monitory... Krótko mówiąc, ekrany mogą mieć naprawdę różną wielkość i proporcje, a użytkownicy w dzisiejszych czasach oczekują, że na każdym (lub prawie każdym) aplikacje będą wyglądały satysfakcjonująco.
Mówimy wtedy, że aplikacja jest responsywna - to jest to słowo, którego używa się, gdy chcemy powiedzieć, że strona ma wyglądać dobrze zarówno na m.in. laptopie, jak i smartfonie. Owszem, oznacza to, że elementy w interfejsie niejako skalują się do dostępnej powierzchni, ale w świecie IT nie mówi się o tym w ten sposób. Czasami rozumie się przez to też to, że strona bdzie wyglądać zupełnie inaczej na różnych ekranach i zmienia się wręcz układ menu, zachowanie przycisków, niektóre elementy są ukrywane, a inne rozciągane na całą szerokość, gdyż w ten sposób wygląda to lepiej. Wprowadzanie responsywności do strony nie oznacza zatem wyłącznie zmniejszenie pewnych komponentów lub ich poprzestawianie, ale często jest znacznie bardziej złożonym procesem i powinno być planowane od początku, aby można było przyjąć odpowiednie założenia. W zamian jednak dostajemy nowoczesną, spełniającą wymogi dzisiejszych czasów aplikację webową, nierzadko "załatwiając" w ten sposób kwestię aplikacji mobilnej. W tym miejscu warto wspomnieć, że responsywny projekt webowy (RWD) nie jest tym samym, co progresywna aplikacja (PWA) - to drugie oznacza aplikację webową zachowującą się podobnie do natywnej, co warunkuje wiele mechanizmów wewnątrz strony i używaną technologię.
Wspomniałem jednak o tym, że istnieje drugie znaczenie responsywności, które jest trochę rzadziej używane, choć również odnosi się do interfejsu. Otóż, nikt z nas nie lubi długo czekać na odpowiedź aplikacji czy odświeżenie strony internetowej. Jednak jeszcze gorsza jest sytuacja, gdy przy dłuższym czasie odpowiedzi aplikacja w żaden sposób (graficzny lub tekstowy) nie informuje użytkownika, że aplikacja nie zawiesiła się, tylko dalej wykonuje operację i po prostu trzeba chwilę zaczekać. Dlatego pojawiają się te wszystkie spinnery pokazujące, że coś ładuje się w danym miejscu, paski postępu, zmiana stylowania przycisków po kliknięciu i tym podobne techniki, które poprawiają odbiór interfejsu w oczach użytkownika. Metody informujące o działaniu strony oraz odpowiednio krótki czas odpowiedzi też razem pozwalają nazwać stronę "responsywną", jednak w tym przypadku częściej mówi się, że oprogramowanie jest po prostu szybkie, płynne, zostawiając termin "responsywny" dla kwestii związanej z ekranami o różnych wymiarach.
Czym jest skalowanie?
W przypadku skalowania zdecydowanie odchodzimy od tematu interfejsu i przechodzimy do kwestii bardziej sprzętowych. Ten termin oznacza bowiem zdolność aplikacji (a właściwie całych systemów i infrastruktury, na której funkcjonują) do działania w odpowiedni sposób przy rosnącym obciążeniu bądź rozmiarze danych. Zresztą, o skalowaniu możemy mówić nie tylko w kontekście oprogramowania - skalować się może też m.in. firma, aby odpowiednio obsługiwać coraz większą pulę klientów (a przyczynić się do tego może odpowiednia aplikacja, którą możemy Ci przygotować). Wróćmy jednak do kwestii software'owej.
Istnieją dwie metody skalowania zaplecza serwerowego. Pierwsza z nich, to skalowanie pionowe lub w górę (ang. scale up), które polega na zwiększeniu możliwości pojedynczej maszyny, która obsługuje oprogramowanie. Można to różnie rozumieć - od zwiększenia pamięci do zamontowania dodatkowego procesora lub po prostu zmianę komputera na mocniejszy. Idea polega na zwiększenie mocy tak, aby aplikacja działała szybciej lub mogła przechowywać więcej plików. Jest to rodzaj skalowania, które wymaga mniej przygotowania przy tworzeniu oprogramowania i wydaje się "naturalny", jednak związanym z nim jest kilka problemów. Po pierwsze, zazwyczaj zwiększenie mocy maszyny wiąże się z jej chwilowym zatrzymaniem oraz fizycznym przeniesieniem danych na inny komputer. Po drugie, każdy serwer ma swój limit i niekiedy nie jest już możliwe zwiększenie parametrów. Po trzecie - koszt takiej lepszej maszyny może być naprawdę duży i stać się nieopłacalny w stosunku do drugiego typu skalowania.
A jest nim skalowanie poziome lub w bok (ang. scale out), które polega na dostawianiu kolejnych serwerów, na których może pracować aplikacja. W tym przypadku należy wiedzieć, że oprogramowanie musi być odpowiednio przygotowane do takiej infrastruktury i warto założyć taką ewentualność od początku. W krąg zagadnień, które tutaj mają znaczenie, można wymienić m.in. bezstanowość, architekturę opartą o usługi, wyrównywanie obciążenia (ang. load balancing) czy replikację bazy danych. Nie wszystko musi być gotowe od razu, ale jeśli mamy choć cień szansy, że oprogramowanie może generować (nawet tymczasowo) duży ruch, warto od razu przyjąć bezstanowość i obecność usług sieciowych (ang. web services). Wówczas kopie aplikacji lub jej części (frontend/backend) znajdują się na różnych serwerach, z których każdy ma równe "uprawnienia" do obsługi użytkownika i odciąża inne serwery. To oznacza również, że niekoniecznie muszą to być równe i potężne maszyny (load balancer może kierować ruchem z pewnym prawdopodobieństwem), aczkolwiek im "szersza" staje się infrastruktura, tym bardziej trzeba ją przemyśleć, gdyż za tym musi iść dobra administracja i konfiguracja maszyn - dlatego jest to rozwiązanie dla większych biznesów, które mogą zapewnić dostateczne wsparcie.
To właśnie przez ideę skalowania poziomego bardzo popularne stały się usługi chmurowe, które pozwalają na "naturalne" skalowanie poprzez dostarczanie klientowi nie jednego, ale farmy serwerów. Co więcej chmury potrafią same czasowo zwiększać swoje możliwości w przypadku wykrycia szczególnie dużego ruchu i w ten sposób dostosowywać się do aktualnie panujących warunków - w końcu nie zawsze nasz system jest równie obciążony. Niestety, wadą chmur jest ich koszt, większy niż w przypadku innych "normalnych" usług serwerowych. O niektórych z nich mogliście już wcześniej przeczytać na blogu.
Biorąc to wszystko pod uwagę, warto przeanalizować, z jakim ruchem nasza aplikacja może się zetknąć w przyszłości. Jeśli będzie to mała strona dla lokalnego rynku, to być może temat skalowania nie będzie nas interesował aż tak. Z drugiej strony, warto przemyśleć, czy nie opłaca się (o ile jest to możliwe) od początku postawić na bezstanową architekturę, dzięki której będziemy mieli większe pole manewru w przyszłości. Nie warto natomiast od początku kupować wielu serwerów obsługujących naszą aplikację (chyba że mówimy o chmurze) - skalowanie ma to do siebie, że jest odpowiedzią na rosnące zapotrzebowanie, a zatem pozwala na dokupowanie zasobów już w trakcie "życia" naszego oprogramowania.
Podsumowanie
Jak widać, w teorii pojęcia, które mogłyby oznaczać podobne rzeczy, w IT dotyczą zupełnie różnych spraw. Responsywność jest ściśle związana z interfejsem i możliwością wygodnego korzystania z niego na różnych ekranach, natomiast skalowanie dotyczy zdolności naszej infrastruktury do normalnego działania w przypadku większego obciążenia. Jedno nie ma związku z drugim, jednak w dobie rosnącego zapotrzebowania na usługi sieciowe i ciągle rozwijający się biznes w sferze IT, warto przyswoić sobie te terminy i wziąć je pod uwagę przy projektowaniu nowego oprogramowania.
Pozdrawiam i dziękuję - Jakub Rojek.