RegułyChaosu

Do tego, że składową przekazu dotyczącego Cloud Computing  jest marketingowo wzmacniany hype nie trzeba chyba przekonywać. O krytycznym spojrzeniu na skalę hype w komunikacji zagadnień chmurowych, na przykład w odniesieniu do uzasadnień finansowych usług chmurowych, napisano już wiele. Rzecz jasna, nie tak wiele, jak marketingu w tej sprawie. Dodałem także kilka groszy od siebie do tej publicznie prowadzonej dyskusji. Jednym z warunków urzeczywistniania tak fantastycznych business case jest zdolność do prowadzenia skutecznych procesów zakupowych. Czy kontekst zakupów chmurowych coś tu namiesza?

Nie przedstawię tu, rzecz jasna, kompletnej recepty na prowadzenie procesów zakupowych dla usług chmurowych. Świadczę takie usługi, więc – dla konkretnej organizacji i planów zakupowych – chętnie pomogę kompleksowo. Pokażę jednak kilka przykładów, jak bardzo kupowanie usług chmurowych miesza w praktykach zakupowych.

Procesy zakupowe mają kilka aspektów, ale – na potrzeby niniejszego skrótu zagadnienia – skupię się na dwóch z nich: optymalizacji zakupów (działania o charakterze negocjacji, grupowanie zakupów dla zwiększenia skali, przesuwanie w czasie do „lepszego okresu” itp.) oraz weryfikacja realizacji umowy (czy wydatki podążają za sporządzanymi ich planami, będącymi podstawą dla osiągnięcia korzyści z optymalizacji).

Optymalizacja, jak każde działanie „parawojenne”, jest skuteczna, jeśli jest prowadzona na własnych warunkach, a nie narzuconych sytuacją. Aby zyskać, trzeba wiedzieć coś więcej i to wcześniej. Negocjacje w warunkach postawienia pod ścianą nie są najczęściej skuteczną formą optymalizacji. Tym bardziej, że dla większości podmiotów korzystających z usług chmurowych – w konsekwencji porównania wielkości ich biznesu do wielkości biznesu usługodawcy chmurowego – cennik usług jest zwykle cennikiem detalicznym i nie jest raczej obszarem poddawanym znaczącym negocjacjom.

Kontrola wydatków, będąca podstawą weryfikacji realizacji umowy z perspektywy zakupowej, ma sens na etapie zaciągania zobowiązań. Na tej samej zasadzie controlling i rachunkowość zarządcza są czymś innym, niż księgowość. Praktyka pokazuje jednak, że często kontroli podlegają dopiero wydatki, co jest znaczącym ograniczeniem dla egzekwowania założeń optymalizacji. Usługi chmurowe, z perspektywy zaciągania zobowiązań, to najczęściej formy przedpłacone (subskrypcja, czy budżet do wykorzystania), co poddaj w wątpliwość wszelkie możliwości optymalizacji opartej wyłącznie na mechanizmach zakupowych.

Przydałby się jakiś przykład, więc dla przykładu podam przykład. Uzasadnienia biznesowe dla wyboru usług chmurowych w miejsce innych form wykorzystania infrastruktury (własne Data Centre, kolokacja, hosting) obejmują zwykle możliwości szerokiego wykorzystania mechanizmów skutkujących obniżaniem opłat. Takie mechanizmy to działania ściśle techniczne, np. administracyjne wyłączanie maszyn IaaS na czas braku ich utylizacji (np. na zakończenie każdego dnia pracy), downsizing kontenerów serwujących aplikacje (o ile upsize zwykle nie niesie sprzeciwu developerów, o tyle automatyka downsize wymaga wyrafinowania w konstrukcji), przyjmowanie schematów opłat rozliczania wyłącznie zużytych zasobów SaaS. Każdy taki model skutkuje – rzecz jasna jedynie na poziomie kontrolingu – przyjęciem jakiegoś budżetu (np. na użytkowanie IaaS) i koniecznością weryfikacji efektywności realizacji założonych działań (np. osiągniętego obniżenia użycia zasobów, redukcji liczby licencji czy skuteczności ich konwersji do tańszych). I tu ujawnia się „tempo chmury”, w którym zachodzące zdarzenia skutkują konsekwencjami finansowymi w czasie krótszym o rząd wielkości (lub nawet kilka rzędów), niż w przypadku rozwiązań on-premises. Drugim kluczowym elementem zmieniającym podejście do procesów zakupowych usług chmurowych jest realne ważenie wydatków oczekiwanym poziomem jakości (QoS / SLA). Podkreślam realne, nie zaś roszczeniowe – realne, czyli oparte o dowody uzasadniające godziny dostępności usług, czasy niedostępności, czasy przywracania w oparciu o finansowe mierniki wartości biznesowej „utraconego czasu”. Ma znaczenie zarówno w wymiarze świadomego obniżenia oczekiwań dla umożliwienia obniżenia kosztów, jak i w wymiarze skuteczności monitorowania realizacji SLA wpływających nie tylko na abstrakcyjne umowy, ale na rozliczenia finansowe. Krótko mówiąc, zagadnienia jakości stanowić mogą nawet większościowy udział w kosztach przedsięwzięcia i ma to sens, jeśli są uzasadnione. QoS/SLA everywhere oraz wbudowanie zdolności egzekwowania w działania operacyjne, bo w przypadku usług chmurowych ryzyko przekroczenia budżetu jest w całości przeniesione na kupującego.

Gdyby do zagadnień zakupowych z „tempem chmury” przyłożyć obecne praktyki zespołów source’ingowych (wymagania, dokumentacja, akceptacje, postępowania przetargowe, negocjacje, zamówienia do umów ramowych), kompletny paraliż ich działań nastąpiłby najpóźniej po kwartale. Pomijając nawet zagadnienie – wtedy już absurdalnych – kosztów takiej działalności. „Tempo chmury” wymaga przemyślenia także praktyk zakupowych. Na ich kształt trzeba bowiem spojrzeć – tak samo, jak w przypadku praktyk zarządzania technologią – nie z punktu widzenia poprawy stosowanych obecnie rozwiązań organizacyjnych, ale od podstaw, od celów i uwarunkowań, od definicji, kwestionując każde „wierzenie” i „wieloletnią praktykę”. Stosowanie dotychczasowych praktyk w świecie „tempa chmury” oznacza działanie zawsze reaktywne, postawione pod ścianą, więc widoki osiągnięcia poziomów KPI definiowanych dla zespołów zakupowych byłyby raczej marne.

Jeśli więc naprawdę chodzi o optymalizację zakupów, „tempo chmury” narzuca włączenie procesów zakupowych w działalność operacyjną, splątanie ich w działaniami ściśle technicznymi, z monitoringiem dopasowanym do wymogów śledzenia zmiennych umowy wpływających na cenę, a także na wywieranie skutecznego wpływu optymalizacyjnego. Najważniejszą jednak różnicą jest prosta konstatacja, że optymalizacja oznacza skierowanie działań do wnętrza firmy, a nie w kierunku dostawcy – zakupy stają się więc przede wszystkim jednostką kontrolną dla organizacji, a nie jej dostawców.

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ś?

Temat zarządzania procesowego jest częstym tematem moich architektonicznych poszukiwań. Stąd i częstość powrotów tego tematu w formule mojego bloga. W dzisiejszych warunkach zarządzanie operacyjne (nie mylić z obrazem analityka biznesowego i nadzorczym, szczegóły rozróżniające we wcześniejszym wpisie) na bazie procesu end-to-end stało się już zbyt kosztowne, a zarządzać operacyjnie trzeba. Nawet zakładając, że są jeszcze jakieś firmy, które twierdzą, że funkcjonują w oparciu o procesy end-to-end, to bez hipokryzji – powszechna sytuacja wygląda tak, że istnieje „dział od procesów” żyjący w innym świecie, niż operacyjnie działająca firma.

Jak pisałem ostatnio, rozważając metody zarządzania procesowego trzeba stawiać na zdarzenia (w oparciu o architekturę EDA, Event-Driven Architecture) i regułową organizację działań (w oparciu o rozwiązania klasy BRM, Business Rules Management). Takie są bowiem na dziś uwarunkowania organizacji współczesnego biznesu. Na tym jednak nie kończą się możliwości oferowane przez koncepcję zdarzeń ani siła wyrazu zdarzeń.

Historycznie rzecz ujmując, koncepcja zdarzeń nie jest ani nowa, ani szczególnie odkrywcza. Nawet w oparciu o dość pobieżny przegląd stosowanych wzorców projektowych widać powszechność spojrzenia zdarzeniowego:

• sprzęt – w tej sferze w zasadzie nie ma innego trybu współpracy, każda komunikacja opiera się o sygnały i zdarzenia;
• model programowania systemowego – wszystkie systemy na najniższym poziomie, np. systemy operacyjne, aplikacje w środowiskach graficznych, działają na zasadzie odpowiedzi na zachodzące zdarzenia;
• modne obecnie metodyki projektowania rozwiązań – dla przykładu Domain-Driven Design i jego podstawa, czyli Event Storming, traktują zdarzenia jako fundament modelowania domeny biznesowej, a najczęstszym wzorcem implementacyjnym jest zapisywanie zachodzących zdarzeń z których odtwarza się stan obiektu (choć nie tylko to);
• obserwowanie zmian w danych – w sferze operacyjnej zdarzenia identyfikowane na podstawie stanu danych i korelacji zmian w danych (wraz z technologią dla tego celu, Complex Event Processing), w sferze analitycznej fundamentem jest identyfikacja zmian w danych obiektów pomiędzy cyklami zasilania hurtowni.

Takich przykładów jest więcej, ale taka ich porcja chyba już wystarczy. Dlaczego zdarzenia? Bo to jest naturalny sposób działania człowieka. Na najbardziej podstawowym poziomie wcale nie jesteśmy ani procesowi, ani racjonalni – na najbardziej naturalnym poziomie reagujemy na bodźce w określonym kontekście. Opis świata sformułowany w taki sposób rozumiemy instynktownie i potrafimy się w nim szybko odnaleźć. Takie właśnie, instynktowne zrozumienie przenosimy na różne sfery świadomego działania, między innymi zarówno na grunt tworzenia jak i użytkowania rozwiązań informatycznych.

Zdarzenia, zarówno ze względu na spójność z naturalnym sposobem postrzegania jak i z powodu efektywności obsługi „w systemach” stanowią wspólny mianownik na wszystkich poziomach abstrakcji architektury. To na nich należy budować fundamentalne pryncypia architektury korporacyjnej, rozwiązań i oprogramowania. Uproszczenia i spójność to najlepsza strategia i recepta na sukces.

„Cloud, czy on-premises” wchodzi już na stałe do kanonu procesów decyzyjnych o sposobie realizacji przedsięwzięć informatycznych. Na szczęście mamy już za sobą czasy naiwnego rachunku kosztów i dysponujemy doświadczeniem pozwalającym na znacznie głębsze zrozumienie mechanizmów związanych z ekonomiką rozwiązań chmurowych i skutkujących racjonalizacją kosztów posiadania informatyki.

W prostych skojarzeniach, zarządzanie procesowe = BPMS, wydawałoby się, temat znany i ograny. Wydawałoby się. Wpadłem ostatnio w środek dość już „nabrzmiałego wyzwaniami” projektu wyboru „platformy BPMS”. Projekt przeprowadził RFI, RFP i nadal nie było wiadomo, co wybrać. Pierwsza diagnoza polegała na tym, że pomylone zostały pakiety komercyjnych środowisk z BPMS w nazwie, z koncepcjami narzędzi zarządzania procesowego. To pomieszanie doprowadziło do serii nieporozumień, kilku awantur i braku decyzji. Ale udało się wyprostować, a przepis na to poniżej.

Włam do szpitala może mieć wiele twarzy. To może być wyciek bardzo wrażliwych danych, ale może także doprowadzić do paraliżu placówki (ransomware). Przed takimi zdarzeniami trzeba umieć się zabezpieczyć. Włam do szpitala może jednak nieść także potencjał działań terrorystycznych, na przykład podawania pacjentom leków dla nich szkodliwych. Przerażające, prawda?

Duch startup’owy zachwyca możliwościami. Zero cynizmu, naprawdę. Skuteczność działań prowadzonych w ten sposób, choć oceniana jedynie po przedsięwzięciach „z sukcesem”, przekonuje duże firmy do realizacji przedsięwzięć w taki sposób. Jak więc powstają „systemy z garażu”? Opowiem o doświadczeniach na przykładzie dwóch przedsięwzięć, jakie oglądam z bliska.