Ekonomiczna natura architektury rozwiązań chmurowych

Data: 2019-02-03
Autor: Sebastian Konkol
Ekonomiczna natura architektury rozwiązań chmurowych

Chmura obliczeniowa to – obok blockchain, IoT i sztucznej inteligencji – jeden z najszybciej rozwijanych obszarów technologicznych. To obszar z inwestycjami ogromnymi, nawet w skali działania branży IT, dużo się więc dzieje w sferze metod i wzorców wykorzystania chmury w budowie rozwiązań. Kwestia kosztów zawsze była istotnym czynnikiem wpływającym na konstrukcję rozwiązań informatycznych, jednak chyba po raz pierwszy w historii stała się czynnikiem determinującym architekturę rozwiązań korzystających z chmury.

Od czasów, kiedy sprzedawcy IT – naginając prawa fizyki – głosili taniość chmury, nastąpiła już racjonalizacja myślenia o wykorzystaniu chmurowych zasobów obliczeniowych. Nikt rozsądny nie traktuje SaaS jak coś innego, niż aplikację dostępną przez Internet. Każdy, kto potraktuje IaaS jak wynajmowany sprzęt, zmieni zdanie po otrzymaniu pierwszych faktur za taką usługę. Najwięcej jednak dzieje się w sferze określanej jako PaaS, czyli tam, gdzie można zbudować własna aplikację korzystając z szerokiego wachlarza dostępnych gotowych funkcji (obliczeniowych, komunikacyjnych, składowania danych). To w tym obszarze właśnie przejawia się podstawowy wyznacznik architektury rozwiązań chmurowych – ekonomia i optymalizacja kosztów.

Świadomi architekci zawsze kształtują tak architekturę rozwiązań, aby zachować równowagę między ponoszonymi kosztami i uzyskiwanymi korzyściami. Fundamentalna zasada obowiązująca w świecie PaaS, Billed for Consumption, stała się czynnikiem głównym i najważniejszym. Czy to dobrze? Za mały materiał, aby to obiektywnie ocenić. Warto jednak zwracać uwagę na konsekwencje ściśle ekonomicznych uwarunkowań kształtujących architekturę rozwiązań chmurowych.

Architektura rozwiązań chmurowych przeszła bardzo szybko zasadniczą ewolucję: od dedykowanego sprzętu, przez wirtualizację i konteneryzację, dochodząc do promowanych obecnie FaaS (Function as a Service) i serverless. O ile architektura microservices miała jeszcze głębsze uzasadnienie techniczne, o tyle Cloud Native jest architekturą podporządkowaną argumentom ekonomicznym, nie zaś technicznym. FaaS jest prostym efektem kompromisu między bogactwem funkcjonalnym gotowego do użycia komponentu a powszechnością jego użycia. Dostawcy tych komponentów konstruując je optymalizują swoją marżę podłapując każdy pozwalający na to trend (np. serverless), który pozwala na przerzucenie odpowiedzialności za spójność działania całości aplikacji na jej użytkownika. Przy okazji, jak to często bywa, ewolucja technologii zatoczyła koło, gdyż w myśl trendu Cloud Native aplikacja użytkownika musi być ciężką aplikacją (duży framework JavaScript, aplikacja mobilna), coraz większą część działań przerzucającą na sprzęt użytkownika. Z jakiegoś powodu jednak pokochaliśmy możliwość działania przez WWW rezygnując z grubych aplikacji klienckich w architekturze klient-serwer. Czy poza argumentami ekonomicznymi po stronie twórców komponentów jest więc głębsze uzasadnienie dla rozwiązań chmurowych?

OK, optymalizacja jest dobra. Jeśli wszyscy na tym zyskujemy, super. Tylko czy na pewno? Mimo wszelkich zapewnień, że w chmurze płaci się tylko za tyle, ile się używa, za potencjał skalowania do „być może wykorzystania” także trzeba zapłacić. W cenie użycia milisekundy mocy obliczeniowej ten potencjał został już wkalkulowany. To jednak nie koniec Przejście na podporządkowany ekonomii model wykorzystania chmury (FaaS) oznacza, że każdy z wykorzystywanych komponentów musiał zostać przygotowany do działania w chmurze. Musiał zostać zbudowany włączając mechanizmy autoskalowania i fault-tolerance. Żaden z tych mechanizmów nie wymusza poprawy jakości działania komponentu, ani sprawności jego działania (za to wszak płaci użytkownik, Billed for Consumption), a raczej wręcz przeciwnie – usypia czujność twórców komponentu (w razie czego wystartuje od nowa, luzik). Zgodność z tymi wszystkimi mechanizmami na pewno zwiększa zakres prac do wykonania dla każdego komponentu, a to kosztuje. Koszt ten jest następnie wkalkulowany w milisekundę mocy obliczeniowej wykorzystania tego konkretnego komponentu – w konsekwencji natury chmury, a nie wymagań aplikacji. Większe rozdrobnienie komponentów oznacza większe wykorzystanie mechanizmów integracji. Nawet jeśli są one tak proste, jak kolejki buforujące wywołania pomiędzy poszczególnymi komponentami w łańcuchu, każda z nich zwiększa utylizację mocy obliczeniowej, za którą trzeba zapłacić. I znów, nie w wyniku wymagań aplikacji, ale w konsekwencji natury chmury.

Charakterystyka chmury wymusza także dodatkowe cechy komponentów, które nie są zwykle obecne w rozwiązaniach powszechnie użytkowanych. Najważniejsze z nich to zarządzalność i bezpieczeństwo. Zdolność do zarządzania komponentem (zmiana parametrów w czasie działania, włączanie i wyłączanie, skalowanie) to akurat jedna z lepszych praktyk, jakie wymusza architektura rozwiązań chmurowych. W porównaniu architektury rozwiązań telekomunikacyjnych i informatycznych te drugie są po prostu niedorozwinięte w sferze zarządzania nimi. Wbudowanie zarządzalności komponentami i automatyzacji tej zdolności oznacza jednak kolejne podniesienie kosztów wytworzenia i utrzymania komponentu. Billed for Consumption, yeah. W sferze bezpieczeństwa architektura rozwiązań chmurowych to rewolucja u podstaw. W chmurze każdy komponent to oddzielna wyspa z użytkownikami, uprawnieniami, atakami, szyfrowaniem i całą masą spraw, które – w przypadku on-premise – załatwiane były przez zabezpieczenia na poziomie całej serwerowni. W chmurze każde z tych zagadnień trzeba rozwiązać na poziomie każdego (sic!) komponentu, a do tego pojawiają się inne sprawy (np. multitenancy). Każdy oficer wie, że perymetr powinien być jak najdalej – w chmurze perymetr to granica komponentu. Ktoś chce dodać coś o kosztach?

Są także takie wisienki na torcie, jak na przykład narzut organizacyjny na prowadzenie rozliczeń między dostawcami poszczególnych komponentów, z których budowane są usługi. Jak jest jeden lub dwóch, to luz, ale to oznacza Vendor Lock na poziomie dotychczas nieobserwowanym. Strategicznie koszmarny błąd. Dostawców komponentów będzie jednak po prostu więcej, bo do tego zmierza świat – duzi chmurowi będą tworzyć ekosystemy dla komponentów małych dostawców, tak samo, jak w przypadku aplikacji mobilnych czy dodatków do platform klasy Enterprise. A rozliczenia w takim ekosystemie będą złożone, przez co kosztowne.

Mimo tych wszystkich zastrzeżeń, istnieją badania dowodzące, że przechodząc z aplikacji monolitycznych na chmurowe (FaaS, serverless) można oszczędzić nawet 75% TCO. Czy to znaczy, że PaaS jest takie fantastyczne? Być może tak, ale w moim odczuciu znacznie bardziej świadczy o tym, jaki potencjał optymalizacji leży w posiadanych aplikacjach monolitycznych. Potencjał ten można częściowo zrealizować także bez przechodzenia do rozwiązań chmurowych. Zanim więc wzlecimy w chmury, może warto zrobić trochę porządku jeszcze u siebie. Wszak dla przejścia do aplikacji chmurowej i tak trzeba będzie zrobić to (i znacznie więcej), tylko ze znacznie większym rozmachem. Biorąc pod uwagę skalę kosztów, których dodanie wymuszane jest na architekturze rozwiązań chmurowych stawiam, że istnieje optimum optymalizacji architektury aplikacji (odejście od monolitu), które daje wyniki porównywalne z ekonomią chmury. Takimi działaniami ostatnio się zajmuję.

Pozostaw komentarz