Jak jest naprawdę z tą chmurą?

Jak jest naprawdę z tą chmurą? Z mojego doświadczenia można to najkrócej podsumować, że chmura to jedno wielkie „ale” i „to zależy”. Patrząc na szereg przypadków z którymi się spotkałem, tych „ale” i „to zależy” potrafi być w dużej ilości przypadków mniej niż w lokalnej infrastrukturze, pod warunkiem, że nasze działy bezpieczeństwa i compliance nie uważają się za najważniejsze w firmie i nie mają przerostu formy nad treścią, aniżeli to normy i przepisy wymagają.

Po paru latach pracy, zaczyna mi się klarować jasne stanowisko do czego się nadaje w mojej opinii. Takie obdarte z marketingu, sprzedawców marzeń i pięknego prostego świata, bez ochów i achów. Proste inżynierskie podejście. Mianowicie: chmura ma dużą przewagę zeswoim Time to market, TCO oraz globalną dostępnością i zgodnością, „ale”.

Część wpisu jest ogólna, a część kierowana na smaczki związane z Azure, na których chyba zjadłem zęby przez parę ostatnich lat.

enterprise – a dokładniej podejście czy też mentalność enterprise IT, będzie się przewijało we wpisie. Jego sens dobrze obrazuje post Tomka Onyszko - Kij w mrowisko – enterprise IT i poniższy rysunek, który jest niby żartem.

Time to market

Tutaj chmura z gotowymi komponentami wygrywa. Szczególnie Azure jest trudny do przebicia w tej materii. Nawet zaawansowane scenariusze można budować jak z klocków lego, skupiając się na integracji i logice jak coś ma działać. Narzędzia do budowy poważnej analityki, narzędzia do integracji różnych usług chmurowych czy komponenty do budowy dużych części aplikacji - to wszystko jest z pudełka. Usługi takie jak LogicApps, Functions, Azure Search, Data Factory, Cognitive Services czy Cosmos DB pozawalają na to. Popierając to przykładami, warto zobaczyć JFK Files, czyli wgrane wszystkie dokumenty ze śledztwa na temat zabójstwa Kennedy’ego, przetworzone przez Azure Serach i jego integrację z Cognitive Services. To bardzo dobrze pokazuje, jak niewiele kodu potrzeba do budowy takiej usługi. Drugim przykładem jest projekt wykonany przez Predica i prezentowany przez Tomka Onyszko na jednym z meetupów. Naprawdę życiowo pokazuje, jak można dostarczyć wartościowy projekt od zera, w bardzo krótkim czasie.

I w tym momencie pojawia się „ale”. Cały PaaS jest świetny do momentu, kiedy prototypujesz, nie robisz dużych aplikacji, ale raczej takie duże smart apps/crud, chcesz sprawdzić czy MVP ( minimum viable product) zadziała. Kiedy aplikacja zaczyna być, tak zwana, krytyczna (jeśli 15 min przestoju zaczyna generować straty to jest to krytyczna, straty to też niezarobione pieniądze) albo masz narzucone rygorystyczne SLA, to trzeba się zastanowić, czy PaaS ma sens. Często w tych przypadkach potrzeba kontroli nad środowiskiem, a nie czekania aż RAjesz obsłuży nasze zgłoszenie.

Innym scenariuszem jest ten, kiedy budujemy szeroko dostępną usługę, która ma być naszym produktem, czy jak kto woli IP. Często po początkowym zachwycie, okazuje się, że trzeba i tak zbudować coś samodzielnie albo złożyć dostępne klocki na rynku, żeby spełnić nasze wymagania.

Kolejny przykładem, kiedy własne rozwiązania i IaaS wygrywają, jest przelicznik wydajności na dolara. Zazwyczaj PaaS przegrywa, ale tylko wtedy, kiedy potrzebujemy skali i chcemy wyciskać siódme poty z infrastruktury chmurowego dostawcy. Przy mniejszych aplikacjach, zazwyczaj wystarczy po prostu poprawa kodu/architektury.

Jedną bardzo istotną cechą chmury, którą trzeba zaakceptować, to sposób jej działania. Można to przyrównać do dogmatów wiary albo do pojęć pierwotnych. Usługi tego typu są tworzone przez ekspertów computer science i sposób ich działania wynika ze skali w jakiej są dostarczane, zapewniając do tego dostawcy odpowiednie zyski.

Oprócz akceptacji działania, żeby dobrze zrozumieć i projektować aplikacje dla PaaS, należy poznać, jak PaaS działa pod spodem i skąd się bierze to czy inne działanie.

Największe kłamstwo związane z PaaS (tak sam z niego korzystam często) to - Nieważne co tam jest pod spodem, nie trzeba wiedzieć i tym zarządzać, ma coś dostarczać. To jest jako usługa i mnie nie interesuje.

W enterprise IT nawet ma to sens, ale kiedy zaczniemy mieć problemy, często okazuje się, że można było ich uniknąć już na samym początku. Dla przykładu okropny czas dostępu do dysku w Azure App Service ;-)

TCO

Wszyscy mówią i porównują, że chmura jest tańsza od wszystkiego. Czy tak jest? To zależy. Od tego kto liczy, co ma wyjść z wyliczeń. Pewnikiem jest, że dla enterprise IT, które korzysta z outsourcingu w Azji Południowej czy usług firmy mającej piękną historię współpracy z trzecią rzeszą, będzie to prawdą. Dla innych – to zależy. Wiem, że w naszym kraju jest dużo wyznawców podejścia dwa dedyki w ovh zbawią cały świat, ale to pozostawmy w spokoju. Rzeczą, której nie opłaca się robić to na pewno lift and shit (tak shit, a nie shift). Prawie zawsze wyjdzie drożej i będzie polegać na przenoszeniu kupy w inne miejsce. Często przyczyną takiego stanu jest odgórne polecenie migracji, żeby być zgodnym z aktualnymi trendami i modą. Innym światem jest tworzenie aplikacji natywnych dla chmury. Robiąc to świadomie, szczególnie dla mniejszych rzeczy, możemy uzyskać naprawdę ciekawe efekty i wytworzyć aplikacje taniej, szybciej, w porównaniu do tradycyjnego podejścia.

Inna rzeczą przy kosztach jest mit, że nie potrzeba administratora. Prawdą jest, że administrator może utrzymywać większą ilość usług, ale za to pojawia się masa nowego typu problemów, które w klasycznym lokalnym podejściu nie występują. Jeśli ktoś myśli poważnie o podejściu NoOps… :-) No cóż, Ops i tak będzie potrzebne. Jednym z przykładów są nieśmiertelne problemy z siecią… NoOps to zmiana mentalności i podejścia do utrzymania, a nie pozbycie się Ops. Moje zrozumienie tego pojęcia bliskie jest w tej bardzo fajnej prezentacji.

Globalną dostępnością i zgodnością

Rozwiązanie takie jak Azure daje globalną dostępność usług. Koniec i kropka. Z gwiazdką. „ale” w tym temacie - nie wszędzie dostępne są wszystkie usługi. Czasem dostępne są w jednym regionie na obszar geopolityczny, czyli na przykład usługa dostępna jest w EU, ale tylko West Europe. Drugą rzeczą jest oddzielenie Azure od instancji dedykowanych typu Azure Gov, China czy German, gdzie usługi pojawiają się często z dużym opóźnieniem i z ograniczeniami. Mimo tych drobnych niedogodności, naprawdę łatwo jest wykorzystać geo replikowanego po całym globie w Azure SQL Database czy Azure Cosmos DB. Dostępne jest to od paru kliknięć, ale na przykład przy takim Azure Cosmos DB należy pamiętać o dobrym partycjonowaniu ;-)

Zgodnością - podobnie jak z globalną dostępnością jest drobne „ale”. Microsoft, na stan mojej wiedzy, posiada najwyższą ilość certyfikacji i zgodności z regulacjami na świecie. Jedynym problem jest to, że nie wszystkie usługi są certyfikowane. Dobrym przykładem jest tutaj PCI-DSS, który wymaga certyfikacji poszczególnych usług. Recertyfikacje/certyfikacje wykonywane są w różnych okresach – kwartalnie, półrocznie albo rocznie i nie zawsze dana usługa załapie się na certyfikacje. Trzeba o tym pamiętać. Z drugiej strony na plus można zaliczyć otwartość Microsoft w dostępie do informacji z audytów i certyfikacji po podpisaniu NDA, co jest bardzo standardowym procesem u nich.

Inspiracją do dzisiejszego wpisu były ciągnące się wieczorami rozmowy z Marcinem, kawa z Łukaszem, fajny lunch z Grzegorzem z WDC oraz klika asyst przy rozwiązywaniu problemów z PaaSem :-)