RegułyChaosu

O tym, że co innego kieruje architekturą systemu chmurowego już uprzejmie donosiłem. Siły ekonomiczne, choć najmocniej odczuwalne w praktyce działań z rozwiązaniami chmurowymi, nie są jednak jedynymi czynnikami wpływu. W kilku innych przypadkach trzeba się będzie najprawdopodobniej od nowa nauczyć obsługi codziennych zadań związanych z posiadaniem ICT.

Monitorowanie systemów IT, w porównaniu na przykład z monitorowaniem systemów telekomunikacyjnych, zawsze wypadało blado. Zwykle jest realizowane dla obsługi niskopoziomowych celów technicznych (utylizacja zasobów jak CPU, RAM, HDD) lub dla rozliczeń (KPI lub chargeback). Monitorowanie systemów chmurowych to zupełnie inna sprawa, co potraktuję jako przykład jednej ze sfer działalności IT wymagającej „wymyślenia od nowa”. Za „model referencyjny” przyjmę tu praktyki monitorowania systemów utrzymywanych w infrastrukturze własnej, czyli on-premises. Naturalny rozrost systemu (nie wynikający z tego, że aplikacja będzie słabo napisana, choć to potęguje efekt) zmienia warunki działania takiego systemu. W konsekwencji, system on-premises z czasem będzie po prostu działać wolniej. Spowolnienie to, jak wiadomo, ocena subiektywna – argument rutynowo zbijany przez praktykę ankiet „satysfakcji użytkownika”), bo przecież monitorujący system niezwykle rzadko są jego użytkownikami. Mimo tak postępującej degradacji, system działać będzie, bo konsekwencje degradacji nie dotyczą bezpośrednio nikogo – o ile problem nie stanie się naprawdę krytyczny.

Z systemami chmurowymi jest inaczej. Dostawcy chmur liczą każdy cykl CPU – ich modele cen usług przenoszą ryzyko na klientów. W konsekwencji mamy dwie klasy modeli wyceny usług chmurowych:

• Model kosztowy. W tym modelu wzrost zapotrzebowania na zasoby będzie zrównoważony ich automatycznym dostarczeniem, z kosztem uzależnionym od użycia zasobów. Nawet jeśli aplikacja będzie słabo napisana, to nie zwolni – będzie jednak kosztować więcej, niż się zakładało. Zważywszy jednak niewielkie tempo przyrostu zapotrzebowania na zasoby, trend może być przez długi czas ignorowany – to trochę tak, jak z powstawaniem znieczulicy u onkologów, czy w przypadku trzeciej z zasad manipulacji społeczeństwem, zmiany zachodzące stopniowo są przyjmowane znacznie łatwiej, niż zachodzące skokowo. Naturalnie, modele wycen usług chmurowych – nie zawsze przejrzyście przekładające użycie zasobów na cenę usługi – dodatkowo utrudniają wnioskowanie. Przez długi więc czas (np. roczny cykl budżetowy?) nikt się nie zorientuje w sytuacji, jednak kiedy już się zorientuje, to konstatacja ma szansę być naprawdę bolesna.
• Model z limitami. Ten model zapewnia stałość ceny za korzystanie z usługi, jednak określa (i egzekwuje!) limity użycia usługi. Limity są pochodną sposobu konstrukcji rozwiązania chmurowego i oceny ryzyka dostawcy takiej usługi, wcale nie są szczególnie czytelne i często agregują efekty działania procesów zachodzących w różnych częściach rozwiązania chmurowego. W praktyce więc, w efekcie naturalnego wzrostu lub kiepskiej konstrukcji aplikacji chmurowej, usługa nagle przestanie (częściowo…) działać w niepowtarzalnych okolicznościach i manifestując się w zaskakujący sposób. Nie będzie łatwo dociec post factum (o ile w ogóle), co było powodem takiej sytuacji, a jeszcze trudniej (znacznie, znacznie trudniej) ustalić, jak nie dopuścić do takich sytuacji w przyszłości.

W praktyce zwykle jest hybryda powyższych (np. limity rozszerzane w paczkach o wystarczająco zawiłej logice, aby nikt nie chciał się nad tym zastanawiać), co dodatkowo komplikuje sytuację.

W praktyce on-premises monitoring platformy i aplikacji, choć są to podstawy, są często traktowane po macoszemu, jako działalność wewnętrzna IT. W przypadku usług chmurowych mamy konieczność posiadania monitoringu wyprzedzającego zaskoczenia, działające zdecydowanie bardziej w trybie ex-ante, niż ex-post. Co więcej, w warunkach on-premises sprzężenie zwrotne między wzrostem zapotrzebowania na zasoby a ich dostarczeniem opiera się na procesach eksploatacji systemów i daje czas na refleksję, planowanie i optymalizację. W tych warunkach brak praktyk współpracy między inżynierem eksploatacji (patrz: stereotyp administratora systemu) a procesem zakupowym – działającym w warunkach i ograniczeniach czasu decyzji zgodnego z „tempem chmury” – stanowić może krytyczne ograniczenie.

Z tych wszystkich powodów dla użytkowania aplikacji chmurowych tak krytyczną staje się architektoniczna perspektywa Systems Engineering – określanie profilu obciążenia aplikacji, wytworzenie zdolności do śledzenia utylizacji w bardzo specjalizowanych aspektach, wyznaczanie i obserwowanie trendów, identyfikacja anomalii. Perspektywa ta musi być obowiązkowo, rutynowo uwzględniana w całym cyklu życia aplikacji chmurowej, w szczególności w jej procesie wytwórczym, eksploatacji rozwiązania jak i strategiach zakupowych. Co więcej, zarówno zbudowanie monitoringu pozwalającego zapanować nad systemami chmurowymi jak i wbudowanie w rozwiązanie chmurowe zdolności do bycia monitorowanym (sic!) to także znaczący wysiłek i koszt, zapewne nie uwzględniany ani w budżetach projektów, ani porównaniach rozwiązań on-premises i cloud.

Piszę o tym, bo to bardzo istotne zagadnienia, a dostrzegam problemy ujawniające się na tle tych zagadnień. Z moich obserwacji, sposób myślenia o używaniu aplikacji chmurowych jest „niebezpiecznie niekompletny”. W moim odczuciu panuje intelektualne „krótkie spięcie”, skróty myślowe skutkujące bezrefleksyjnym narzucaniem praktyk zarządzania technologią zbudowanych w czasach on-premises, mimo że aplikacja jest w chmurze. Taką praktyką jest monitorowanie, ale dla aplikacji w chmurze nie są obserwowane właściwe symptomy nadciągających kłopotów, a skoro nie są obserwowane, to z pewnością zaskoczą – brakiem ciągłości od razu lub rachunkiem po jakimś czasie. Chmura zmienia wszystko, ale praktyki zarządzania technologią chmurową są niedojrzałe. Jeśli wydaje się komuś, że istnieje sfera, która nie ulega zmianom w kontekście rozwiązań chmurowych, jestem gotów pokazać, że ulega – Challenge Accepted, dwa bez atu „w ciemno”. Ktoś coś?