Chmura przez chwilę nie działa? Przyzwyczaj się, tak już będzie

Rozumiemy, w skrócie tekst mówi o tym, że przestoje w chmurze są zjawiskiem normalnym i nie przesłaniają korzyści zarówno dla konsumenta, jak i biznesu. Jeśli czujemy potrzebę szybkiego skomentowania bez czytania, można wybrać któryś z przygotowanych poniżej wpisów:

Co do zasady większość osób woli, kiedy rzeczy i usługi po prostu działają. Denerwujemy się na samochód, który odmawia posłuszeństwa, rozklejający się but, niedostarczoną na czas paczkę, młynek do kawy, który się pali podczas porannego rytuału parzenia ulubionego napoju. Kiedy przyjrzymy się bliżej rzeczywistości rzeczy i stanów, zauważymy, że w czasie obserwujemy w niej coraz więcej takich zdarzeń spontanicznych, często od nas niezależnych. Ta niezależność sprawia, że nasza wolność jest ograniczona w zasadzie do wyboru naszego stosunku do nich. I tak, możemy w idealistycznym szale wyrywać sobie włosy z głowy lub - decydując się na podejście stoickie - uznać, że taki jest obecnie stan entropii układu, w którym się znaleźliśmy. I tyle.

Kiedy popatrzymy na chmurę obliczeniową, nasz stosunek możemy ewokować na dwa sposoby. Pierwszym niech będzie podejście - nazwijmy je - niebiznesowe.

Kiedy słuchamy muzyki z Tidala, sięgamy po audiobooka zapisanego na Dropboksie czy też chcemy właśnie obejrzeć najnowszy odcinek serialu na Netfliksie, de facto łączymy się z zasobami chmury obliczeniowej (w tym wypadku AWS), która udostępnia nam na żądanie daną treść. W podejściu niebiznesowym nasze oczekiwania związane z niedostępnością zasobów nie są do końca ograniczone przez kontekst ewentualnej utraty przychodów, myślimy raczej o tym, że chcieliśmy się zrelaksować przy swojej ulubionej playliście, ale nie możemy. Towarzyszą temu zazwyczaj jakieś mało pozytywne emocje, ale raczej jesteśmy skłonni zaryzykować stwierdzenie, że nie rozsadzają nam one głowy. Innymi słowy, większość osób nie przekreśla w takich chwilach usług chmurowych. I choć możemy powiedzieć, że chwilowa niedostępność chmury w takim wypadku rodzi irytację, to już nazwanie takiej sytuacji ważną byłoby pewnie dość nieobiektywne.

W drugim podejściu - biznesowym - mamy do czynienia z sytuacją nieco bardziej skomplikowaną. Oto bowiem firma oczekuje, że jej platforma służąca do zarabiania pieniędzy będzie te pieniądze zarabiała przez cały czas. Można powiedzieć, że oczekuje słusznie. W takim wypadku śmiało stwierdzamy, że to ważne, by chmura nie miała przestojów. Ale czy na pewno? Na to pytanie spróbujemy sobie dziś odpowiedzieć.

Chmura czasem ma przestój (tzw. outage), ponieważ jest bardzo złożonym rozwiązaniem technologicznym, którego każdy element obciąża pewne prawdopodobieństwo wystąpienia niewłaściwego działania. Biorąc pod uwagę historię występowania niedostępności chmur obliczeniowych, możemy wyróżnić cztery główne przyczyny:

Wydaje się, że pierwsze trzy punkty są dość klarowne, otóż większość obecnie wykorzystywanych technologii obciążonych jest często bardzo precyzyjnie dookreślonym prawdopodobieństwem wystąpienia awarii. Osoby, które pracują w branży, na pewno spotkały się z takimi pojęciami jak:

Większość liczących się producentów urządzeń dla branży IT (urządzeń - dodajmy - kupowanych przez firmy, które traktują swój biznes na poważnie) dostarcza rozwiązania opisywane właśnie powyższymi parametrami. Pozwala to odbiorcom na takie planowanie infrastruktury, by przy uwzględnieniu jej ograniczeń móc planować architekturę o odpowiednim i zakładanym poziomie SLA. Innymi słowy, dostawcy chmury składają swoją platformę z urządzeń, które nie są doskonałe, ale starają się to robić w taki sposób, by SLA było najwyższe. Dla przykładu: kiedy w Oktawave dokładnie przeanalizowaliśmy ryzyko wystąpienia przestoju dla naszej chmury, mogliśmy zaoferować klientom SLA na poziomie 99,96%. Mówimy tym samym: drogi kliencie, gwarantujemy, że w naszej infrastrukturze komponenty infrastrukturalne, które pozwalają na utrzymywanie Twojego biznesu, będą działały przez 719 godzin i 42 minuty w miesiącu, który składa się z 720 godzin.

Być może warto nieco rozszerzyć kontekst rozumienia punktu dotyczącego skali. Otóż, jeśli wyobrazimy sobie, że mamy jedno urządzenie, którego producent zakłada, że w ciągu np. 100 dni istnieje 1% ryzyka wystąpienia awarii, to raczej śpimy spokojnie. Ale weźmy pod uwagę sytuację, w której takich urządzeń mamy 100. W takiej sytuacji musimy przyjąć już z całkowitą pewnością, że w przeciągu nieco powyżej kwartału będziemy mieli do czynienia z awarią. I w takiej sytuacji są właśnie dostawcy chmury: mają pod swoją kontrolą bardzo liczne pule urządzeń, a taka skala podwyższa ryzyko wystąpienia przestoju.

Skoro wiemy już, jak działa chmura obliczeniowa, to na pewno zaświtało też nam w głowie oczywiste pytanie: po co to wszystko? Szybka odpowiedź brzmi: aby dostarczyć użytkownikom maksymalną elastyczność przy akceptowalnej cenie.

Rozszerzając to podejście, spróbujmy wyobrazić sobie dostawcę chmury obliczeniowej jako firmę, która ma kompetencje do tego, by budować wysoko wydajne, odporne na awarie, redundantne, bezpieczne i skalowalne systemy IT za cenę, która jest akceptowalna dla rynku. Akceptowalna to znaczy taka, która pozwala na przyjęcie ewentualnych 18 minut przestoju w miesiącu. Bo czy jest możliwe stworzenie systemu, który jest całkowicie odporny na awarię? Wydaje się to dość idealistyczne, ale nawet jeśli założymy, że jest to możliwe, to musimy dodać (i to jest jedno z naszych najważniejszych stwierdzeń): taki system jest bardzo (naprawdę bardzo) drogi. I nie jest teraz ważne, czy budujemy go sami czy buduje go dostawca chmury - po prostu "idealna platforma sprzętowa" to niebotyczne koszty, które najzwyczajniej w świecie nie byłyby do zaakceptowania przez żaden biznes. I kiedy mówimy "żaden", to w istocie mamy na myśli takie firmy jak np. Netflix, które przeżyły już niejeden downtime w chmurze, ale jednak nie decydują się na budowę własnych DC, ponieważ jest to po prostu zbyt drogie.

Dodajmy do tego kolejny niezmiernie ważny kontekst: chmura oferuje użytkownikom funkcje, najczęściej niedostępne dla ich klasycznych modeli budowy IT przy akceptowalnych kosztach. Są to między innymi:

Jak to rozumieć? Spróbujmy stworzyć porównanie. Wyobraźmy sobie, że mamy tor wyścigowy, na którym musimy przejechać 100 000 okrążeń. Możemy to zrobić na wiele sposobów, np. wyciągnąć rower z piwnicy, założyć wrotki, kupić Skodę lub wynająć bolid F1. Nie będziemy się dziś zajmowali wrotkami i rowerem (niech w pamięci zostanie nam tylko, że to odpowiedniki tzw. shared hostingu i VPS-ów), ale decydujemy się na rozważenie zakupu Skody (rozwiązanie dedykowane) lub wynajem auta przeznaczonego do F1 (chmura).

Ok, więc najpierw kupujemy na raty Skodę. Będziemy za nią płacili dla przykładu 2000 zł miesięcznie przez trzy lata. Podstawiamy auto na tor i jedziemy - spokojnie ruszamy, przejeżdżamy kolejne zakręty, musimy dobrze dopasować prędkość, liczyć się z ramami sterowności, układu zawieszenia, przyczepnością opon etc. Okazuje się, że oczywiście da się po torze Skodą jeździć. Może nie za szybko, może niezbyt pewnie, ale autko jest nasze, mało pali i jesteśmy szczęśliwi. No dobrze, przy 12 000. okrążeniu musieliśmy na chwilę zjechać z toru i pojechać do Pana Zbyszka, żeby zmienił olej, ale po dwóch dniach znów jesteśmy na torze i ciśniemy, ile Mlada Boleslav dała. Pan Zbyszek wziął od nas tylko 500 zł. Przy 24 000. okrążeniu, wymieniamy opony, filtry, zepsuł się gaźnik i trzeba zmienić wahacze, ale co tam! To tylko 3000 zł i cztery dni poza torem. Można założyć, że wszyscy wiemy, jak ta historia się toczy dalej. Po trzech latach nasza Skoda już wcale taka nowa nie jest, z toru trzeba zjeżdżać coraz częściej, a okrążeń przed nami jeszcze wiele.

Tymczasem w modelu, w którym mamy do dyspozycji bolid F1, po prostu rejestrujemy się na stronie "dostawcy", zamawiamy odpowiednie parametry naszego auta (powiedzmy, że za 2,91 PLN za godzinę), przychodzimy na tor, a tam czeka odpalony i gotowy do użycia sprzęt. Wsiadamy i jedziemy. Czy musimy opisywać wrażenia? Jak to auto wchodzi w zakręty, jak przyspiesza, jak hamuje, jaką daje nam kontrolę i ile razy już ominęliśmy Skodę? Ale to nie koniec, bo jeśli na naszym kokpicie zapali się lampka mówiąca o konieczności wymiany opon, po prostu zjedziemy sobie do pit-stopu i ktoś nam je wymieni w 7 sekund. Prawdziwa radość jednak zaczyna się w momencie, kiedy na 12 000. okrążeniu stwierdzimy, że potrzebujemy więcej koni mechanicznych. I tutaj mamy do czynienia z magią, bo okaże się, że w trakcie jazdy możemy sobie zmienić abonament, i już za 3,19 zł za godzinę możemy mieć np. o 300 koni mechanicznych więcej. Jak toczy się dalej ta historia? Otóż, nie przejmujemy się tym, czy nasz bolid się starzeje czy nie, czy się psuje i czy go ktoś po trzech latach będzie od nas chciał - tym musi się martwić jego właściciel. Kropka.

Skupmy się teraz tylko na modelu, który jest bardziej wrażliwy, a więc na modelu, w ramach którego do chmury przenosimy nasz biznes (w domyśle naszą aplikację). Kontekst ten wymaga od nas przyjęcia któregoś z założeń:

Pierwszy scenariusz już opisywaliśmy. W nim to możemy pisać sobie naszą aplikację, jak nam się żywnie podoba, nawet zlecając jej stworzenie do któregoś z naprawdę tanich software house'ów, ponieważ wydaliśmy gazylion dukatów na stworzenie infrastruktury, która nie istnieje, i która prędzej czy później i tak się zepsuje (choć liczymy oczywiście, że tak nie będzie). W drugim scenariuszu zakładamy, że urealniamy nasze działania i projektujemy aplikację, tak aby downtime był wewnętrzną cechą jej działania – tj. aby downtime jakiegoś zasobu chmury nie przeszkadzał w działaniu aplikacji. I to właśnie ten drugi scenariusz jest dziś stosowany przez większość największych dostawców usług na świecie, którzy jednocześnie nie wydają w nadmiarze swych środków na zaklinanie rzeczywistości.

Tak naprawdę to wypada jeszcze pogłębić nieco samo rozumienie słowa downtime i tego, jak powinniśmy myśleć o aplikacji z jego perspektywy. Otóż, powinniśmy rozróżnić różne architektury.

A czy wszystkie auta się psują? Generalnie możemy powiedzieć, że większość znanych dostawców zaliczyła dłuższy lub krótszy downtime. W mediach napisano o tym naprawdę wiele ciekawych artykułów:

Na koniec podkreślmy jeszcze jeden aspekt związany z przestojami w chmurze. Otóż, nie oznaczają one utraty danych! Często ten kontekst jest mylony i zupełnie bezpodstawnie oskarża się cloud computing o to, że gubi dane użytkowników. To jest po prostu statystyczna nieprawda. Chwilowy brak dostępu do danych nie oznacza wciągnięcia ich w Twilight Zone.

Tak. Chmura zapewnia Ci dziś najlepszą jakość w stosunku do ceny, pozwala na wykorzystywanie najnowocześniejszych narzędzi i skupieniu się na rozwoju swojego biznesu. Korzystają z niej największe firmy cyfrowej przestrzeni - Airbnb, AON, Netflix, Newseek czy SAP, a w Polsce LOT, Pracuj.pl czy TUI. No chyba że uważasz się za mądrzejszego. To wtedy nie.

Dariusz Nawojczyk, CMO, Oktawave. Chmury, która wszystko zmienia. Od dziesięciu lat buduje strategie marketingowe, biznesowe oraz komunikacyjne dla branży B2B: hostingowej oraz outsourcingu usług IT. Pasjonat nowych technologii i nowych mediów, a także sztucznej inteligencji i teorii komunikacji. Swoją przygodę z informatyką zaczął od programu rysującego choinkę napisanego w języku BASIC na ZX Spectrum z gumową klawiaturą. Napisz do mnie: @_nawojczyk.