Demistyfikacja chmury. Dla kogo będzie ona dobrym rozwiązaniem?

Chmura. Jeszcze do niedawna, z perspektywy osoby urodzonej przed upadkiem Związku Radzieckiego, słowo to oznaczało jedynie skupisko pary wodnej, wolniej lub szybciej przesuwające się po niebie oraz czasem przypominające znajome kształty – naszego psa, kota, babcię czy smoka. Dzisiaj nawet przeciętny Kowalski oraz jego żona Grażyna wiedzą, że w chmurze są ich zdjęcia z wakacji all-inclusive na Majorce razem z ich wszystkimi kontaktami i kopią zapasową ich telefonów. Niestety, wiele ich aspektów techniczno-biznesowych nadal pozostaje owianych tajemnicą znaną tylko mitycznym posiadaczom certyfikatów, które niczym glejt rycerski poświadczają znajomość oraz umiejętności pracy z danym skupiskiem wilgoci (chmurą). Z tego samego powodu nawet w branży IT pokutują do dzisiaj stereotypy o poziomie skomplikowania wdrażania i pracy z technologiami chmurowymi. Z drugiej strony jest też w użyciu powiedzenie, że „chmura to tylko czyjś komputer”, któremu, według mnie, pomimo strasznego uproszczenia omawianej problematyki, mimo wszystko bliżej do prawdy. Czym zatem jest chmura tak naprawdę i jaki wpływ na procesy rozwoju oprogramowanie ma jej wdrażanie? O tym właśnie chciałbym opowiedzieć w tym artykule. 

Definicja

Chmura to zdalne rozwiązanie infrastrukturalne przykryte warstwą abstrakcji. Interfejs użytkownika umożliwia zarządzanie nim bez potrzeby fizycznego kontaktu ze sprzętem – urządzeniami sieciowymi czy serwerami. W jeszcze większym skrócie: jest to hosting internetowy na sterydach. Może się to wydawać strasznym uproszczeniem, ale w praktyce jest to faktycznie tylko kwestia semantyki, ponieważ elementy składowe w obydwu przypadkach są takie same, a różnica polega głównie na wyżej opisanej formule usługi. W przypadku chmury, w odróżnieniu od tradycyjnego hostingu, w którym wynajmujemy faktyczne serwery, płacimy za konsumpcję zasobów takich, jak moc obliczeniowa, pamięć, przestrzeń dyskowa czy ilość zapytań. Niemniej jednak, mimo różnicy modelu usługowego, jest to nadal fizyczna infrastruktura, którą jako klient po prostu wynajmujemy, a którą moglibyśmy zbudować sobie lokalnie. Tylko po co? No i tu właśnie chciałbym omówić rzeczywiste benefity rozwiązań chmurowych w kontekście budowania infrastruktury pod dostarczanie produktów cyfrowych. 

Zastrzeżenie

Zanim wejdziemy głębiej w poszczególne aspekty pracy z chmurą, chciałbym zaznaczyć, iż mimo mojego sceptycyzmu w stosunku do ewangelizującej postawy części środowiska do tego oraz innych tematów z branży IT, jestem wielkim zwolennikiem wysokopoziomowych oraz abstrakcyjnych rozwiązań technologicznych. Tyczy się to nie tylko rozwiązań infrastrukturalnych, ale także języków programowania czy narzędzi wykorzystywanych w procesach tworzenia oprogramowania. Powód ku temu jest prosty oraz bardzo przyziemny: budując coś na już istniejących fundamentach, dostarczymy produkt końcowy szybciej oraz w większości wypadków prościej niż zaczynając od zera. Mając powyższe na uwadze, omówmy poszczególne aspekty chmury wraz z bilansem zysków i strat oraz związanym z tym ryzykiem.

Finanse

Jednym z najłatwiej mierzalnych parametrów infrastrukturalnych jest koszt. Pierwszym oczywistym benefitem chmury jest prosty fakt braku potrzeby inwestowania mniejszych lub większych środków na budowę fizycznej serwerowni, czyli zakup i konfigurację sprzętu. Drugim – elastyczność planów finansowych, pozwalająca na dopasowanie usługi do naszych potrzeb oraz budżetu, co z kolei oznacza, że w zdecydowanej większości przypadków, choć nie zawsze, będzie to rozwiązanie tańsze od tradycyjnej infrastruktury. Niestety, jest pewien haczyk: aby chmura była bardziej opłacalna, musi być odpowiednio zaprojektowana, zbudowana oraz skonfigurowana. Wyklikując na ślepo serwery oraz kontenery wirtualne, możemy się obudzić z gorzkim do przełknięcia rachunkiem, dlatego tak ważne jest dogłębne zrozumienie warunków wykorzystywanych usług. Ten aspekt optymalizacji całego projektu ma także wpływ na architekturę samej aplikacji lub serwisu dostarczanego na omawianej infrastrukturze, ale o tym za chwilę, ponieważ najpierw chciałbym omówić inny element tej układanki – aspekt ludzki.

Siła robocza

Firmy borykają się aktualnie z problemem zatrudniania niszowych specjalistów, a jednym z najrzadziej spotykanych profili na rynku jest m.in. specjalista od mainframe’ów. Często te duże firmy, które korzystają z archaicznej wewnętrznej infrastruktury, zmuszone są płacić kosmiczne stawki, ponieważ przespały okienko migracyjne lub świadomie pozostały przy wdrożonych lata lub nawet dekady temu rozwiązaniach, pomimo ogromnego ryzyka. Przykładem są pewne linie lotnicze, dla których pracowałem jako konsultant, budując nową warstwę mikroserwisów. Otóż wszystkie nowe systemy musiały, przechodząc przez kolejne poziomy coraz to bardziej archaicznych nakładek, połączyć się poprzez wiersz poleceń (CLI) z systemami, które nigdy nie zostały zmigrowane i zostały napisane w latach 70-tych. Był to swoisty koszmar dla wszystkich zaangażowanych w projekt stron, spowodowany ogromnymi inwestycjami w istniejącą infrastrukturę, spotęgowany potrzebą wstecznej kompatybilności oraz faktem, że większość specjalistów znających te technologie odeszła już na emeryturę. Ten niejako ekstremalny przykład może się wydawać niezwiązany z tematem, ale obrazuje on dokładne przeciwieństwo wszystkiego, czym obecnie jest chmura, do której konfiguracji i zarządzania często wystarczy ekwiwalent jednej osoby w zespole projektowym lub devopsowo rozproszonej w nim odpowiedzialności. Dodatkowo, ze względu na standaryzację chmury jako popularnego rozwiązania infrastrukturalnego, na rynku pracy raczej nie brakuje wykwalifikowanych specjalistów, oczywiście za odpowiednią cenę. Pozwala to zatem w większości przypadków (wyjątki omówimy w dalszej części artykułu) na drastyczną redukcję stałych kosztów związanych z wdrożeniem i bieżącym utrzymaniem infrastruktury, nie wspominając już o kolejnym aspekcie tego zagadnienia, czyli elastyczności.

Skalowalność

Kolejnym benefitem rozwiązań chmurowych jest możliwość dynamicznego i wręcz natychmiastowego reagowania na zmieniające się potrzeby. Rozszerzenie infrastruktury sprowadza się do kilku kliknięć lub zautomatyzowanych reguł skalowania, co oczywiście byłoby wykonalne także na wewnętrznej infrastrukturze, ale z fizycznym ograniczeniem dostępnego sprzętu i wcześniej omówionych wysokich kosztów inwestycji. Jak to wygląda w praktyce? Ano tak, że w przypadku jednorazowego skoku zapotrzebowania na moc obliczeniową lub przepustowość sieciową chmura pozwala na uruchomienie dodatkowych jednostek (czy to fizycznych, czy wirtualnych) oraz późniejsze ich zabicie po zaniknięciu wzmożonych potrzeb. Aby przeprowadzić podobną operację na tradycyjnej infrastrukturze musielibyśmy nabyć nowy sprzęt i ponieść ryzyko jego bezużyteczności po ustabilizowaniu się obciążenia. Niestety, omawiana skalowalność niesie ze sobą pewne ryzyko finansowe. O ile dostawcy rozwiązań chmurowych dostarczają nam rozwiązania bardzo elastyczne, o tyle na przykład taki atak DDOS (infekowanie ofiary/komputera z wielu miejsc jednocześnie) lub nawet gwałtowny wzrost liczby autentycznych użytkowników naszej aplikacji może, przy nieodpowiednio skonfigurowanej lub zabezpieczonej chmurze, puścić nas z torbami. Brak limitów skalowalności lub ustalonych budżetów może skutkować automatycznym wykorzystaniem ogromnej ilości zasobów chmurowych w celu zaspokojenia potencjalnie kosmicznego zapotrzebowania na moc obliczeniową lub ilość ruchu sieciowego. To z kolei sprowadza nas do kolejnego zagadnienia związanego z pracą w chmurze: optymalizacji kosztów i idących za tym ograniczeń architektonicznych.

Model rozliczeniowy

W obliczu powyżej opisanych benefitów decyzja o wyborze chmury może wydawać się oczywista, ale niestety także i ona ma swoje ciemne strony. Usługi te niosą za sobą konkretne i często niemałe koszty, dlatego też bardzo ważna jest optymalizacja wydajnościowa pod kątem danej infrastruktury. Niezwykle krytyczna w tej kwestii jest też analiza architektoniczna naszej aplikacji w odniesieniu do wcześniej wspomnianego sposobu fakturowania poszczególnych zasobów wykorzystywanej chmury. 

Architektura aplikacji kontra optymalizacja kosztów

W niektórych przypadkach zmiany wymuszane przez modele bilingowe konkretnych dostawców rozwiązań chmurowych często stoją w opozycji do poprawnych wzorców projektowych. Najczęstszym przykładem jest scalanie w monolityczne serwisy całych bloków aplikacji, w celu ograniczenia liczby zapytań pomiędzy indywidualnymi komponentami. Problem polega na tym, że – dla przykładu – poprawnie zbudowany katalog mikroserwisów składa się, jak sama nazwa wskazuje, z indywidualnych wyspecjalizowanych elementów, pełniących bardzo konkretne funkcje. W sytuacji, gdy taki zbiór funkcyjny znajduje się na jednym fizycznym urządzeniu, nie występuje problem przepustowości łącza czy liczby zapytań sieciowych. Niestety, w chmurze nie zawsze mamy możliwość odpowiedniego wdrożenia takiego rozwiązania i może się okazać, że w sytuacji opłacania nie tylko mocy obliczeniowej, ale także liczby wspomnianych zapytań nasze mikroserwisy będą najzwyczajniej w świecie zbyt kosztowne i będziemy zmuszeni zrefaktorować (zedytować) nasz kod, aby je ograniczyć. Innymi słowy: będziemy musieli scalić poszczególne elementy w monolityczne twory, co samo w sobie przeczy wszystkim współczesnym wzorcom programistycznym, oraz – o zgrozo – być może nawet zduplikować niektóre partie kodu. Czy wymuszanie na programistach podobnych kompromisów może zatem dyskwalifikować chmurę jako rozwiązanie infrastrukturalne? W obliczu wymiernych korzyści finansowych odpowiedź na to pytanie będzie zazwyczaj negatywna, ale czy są sytuacje, w których chmura będzie wyborem niewłaściwym? Oczywiście, że tak.

Uniwersalność chmury

Ideały to domena fikcji. W świecie rzeczywistym mało jest rzeczy jednostronnie pozytywnych i nie inaczej jest w przypadku chmury. Mimo ogromu zalet, istnieją sytuacje, w których będzie ona opcją nieopłacalną, niespełniającą wymagań czy najzwyczajniej w świecie niepraktyczną i chciałbym omówić kilka z głównych problemów.

Aspekt prawny

W niektórych sektorach (takich, jak finansowy czy rządowy) dużym problemem mogą być kwestie bezpieczeństwa oraz dostępu do przechowywanych w chmurze danych. Czasami sam wymóg formalny, określający to, kto może mieć do nich dostęp, może uniemożliwiać korzystanie z rozwiązań chmurowych. Nawet sam fakt hipotetycznej możliwości wglądu w poufne informacje osób trzecich, na przykład pracowników firmy dostarczyciela chmury, może blokować jej wdrożenie. Podobnie jest w niektórych krajach, które wymagają, aby serwery przechowujące owe dane znajdowały się fizycznie w kraju, do którego się one odnoszą. Co nie zawsze jest możliwe nawet w przypadku najpopularniejszych dostawców chmury.

Bezpieczeństwo danych

Równie ważnym aspektem jest poziom zabezpieczeń, chroniących nasze dane przed lepkimi rękami hakerów. W obecnych czasach praktycznie nie ma tygodnia, w którym nie przeczytalibyśmy o jakimś wycieku poufnych informacji – czy to prywatnych zdjęć, czy to tajnych dokumentów rządowych, czy nawet danych kart kredytowych klientów bankowych. Mając to na uwadze, warto poważnie zastanowić się nad tym elementem ryzyka, gdyż w przypadku przechowywania chmury wiele aspektów bezpieczeństwa naszych danych jest kompletnie poza naszą kontrolą.

Praca z chmurą

Kolejną kwestią, którą należy wziąć pod uwagę, jest praktyczność oraz opłacalność pracy zespołu deweloperskiego z chmurą. Może się bowiem okazać, że będzie to znacznym ograniczeniem jego codziennej produktywności. Ograniczona przepustowość łącza lub opóźnienia komunikacyjne, obciążenie infrastruktury ciągłymi zapytaniami, wykorzystanie zasobów na środowiska przedprodukcyjne – wszystko to wiąże się z pośrednimi lub bezpośrednimi kosztami. Przykładem mogą być środowiska testerskie lub integracyjne, na których zazwyczaj wykonuje się codziennie dość dużo operacji. Jaki będzie koszt uruchomienia wielowarstwowych testów zautomatyzowanych lub integracji roboczych gałęzi naszego kodu w przygotowaniu wdrożenia produkcyjnego? Może się okazać, że zbyt duży, zwłaszcza przy bardzo rozległych lub skomplikowanych architektonicznie projektach. Tak samo może być w przypadku przetwarzania bardzo dużych ilości informacji, czego przykładem może być jakże popularny Netflix, który w chmurze trzyma zaledwie swój interfejs, a sam streaming odbywa się już z jego wewnętrznych serwerów CDN (wysoce rozproszonej sieci serwerów). Kolejną problematyczną sytuacją może być migracja do chmury wdrożonego już środowiska produkcyjnego projektu. Biorąc pod uwagę omówioną powyżej specyfikę konkretnych rozwiązań chmurowych, istnieje możliwość, że koszt przygotowania aplikacji do wejścia na chmurę, czy to w kwestii optymalizacji kosztów, czy też adaptacji architekturalnej, będzie przewyższał potencjalne oszczędności, a dodatkowo związane z tym zburzenie statusu quo wypracowanej stabilności może odbić się na jakości wdrożonego rozwiązania.

Próg opłacalności

Ostatecznie należy też wziąć pod uwagę nie do końca prosty rachunek ekonomiczny. Może bowiem się okazać, że w przypadku wyjątkowo dużego zapotrzebowania na poszczególne zasoby takie, jak chociażby ruch sieciowy, wynajmowanie chmury będzie najzwyczajniej w świecie droższe niż budowa własnej infrastruktury. Mowa tutaj już, oczywiście, o największych graczach w branży IT, posiadających niezliczone rzesze aktywnych użytkowników – takich, jak na przykład polskie portale internetowe lub aukcyjne, portale społecznościowe czy wyżej wspomniane aplikacje streamingowe. W tych przypadkach, ze względu na wcześniej omówione modele bilingowe, koszt operowania w chmurze wielokrotnie przewyższałby koszt utworzenia i administrowania własnym centrum danych. Przesyłane informacje oraz ruch sieciowy to zatem dwa główne ograniczniki opłacalności chmury.

Na koniec chciałbym jeszcze raz powtórzyć, że jestem ogromnym zwolennikiem chmury, aczkolwiek nie uważam, że jest ona alfą i omegą, odpowiedzią na każdy problem czy potrzebę infrastrukturalną. Jej wdrożenie zawsze powinno być poprzedzone dogłębną analizą wymagań oraz kosztów, nie tylko obecnych, ale także długoterminowych. Podobnie, jak w przypadku różnych dogmatycznych metodologii, nawołuję do kierowania się argumentami merytorycznymi, a nie ideologicznymi, oraz ze zrozumieniem, że chmura nie jest żadnym mitycznym stworem czy przeskokiem ewolucyjnym, a zaledwie alternatywną opcją, która ma swoje wady i zalety, a przez to określony (jakkolwiek szeroki) zakres zastosowań. Tak samo nie jest ona nieodgadnioną enigmą, ale współczesną interpretacją teorii sieci, ubraną w warstwę abstrakcji, ułatwiającej administrowanie nią za pomocą przejrzystego i przyjaznego użytkownikowi interfejsu.