Operations & Maintenance dla wielochmury hybrydowej

Data: 2021-02-24
Autor: Sebastian Konkol
Operations & Maintenance dla wielochmury hybrydowej

Skoro już prawie wiemy, że IT będzie z gniazdka (choć po prawdzie to w kilku gniazdek), trzeba zacząć się z tym oswajać. Skoro to nieuniknione, warto spojrzeć, co to zmienia w zakresie typowych obowiązków ludzi z informatyki. Moja ulubiona sfera takiej działalności to Operations & Maintenance (O&M) i to jest ciekawy przykład ilustrujący inną stronę złożonej chmurowości, czy też złożoności chmurowej.

Słuchałem niedawno kilku wypowiedzi przedstawicieli firm dostarczających składowe rozwiązań chmurowych. Odnosili się oni do narzędzi zarządzania rozwiązaniami w chmurze – monitoringu, bezpieczeństwa, konfiguracji. Często pojawia się w takich wypowiedziach motyw narzędzi zarządzania środowiskami multichmurowymi. Snute są przy tym wizje takiego zintegrowanego środowiska, umiejącego zrobić wszystko co trzeba na wszystkich chmurach. W tej wizji środowisko to miałoby unifikować kontrolę nad usługami w różnych chmurach, zapewniać możliwości konfiguracji usług, a nawet automatyzować przenoszenie usług z jednej chmury do drugiej dla optymalizacji kosztów. W mojej ocenie taki proces nie zajdzie, bo koszt wytworzenia – a przede wszystkim nadążenia w rozwoju – takiej platformy byłby absurdalny, a korzyści optymalizacji (nawet te już z pogranicza SciFi) nie uzasadniłyby takich wydatków. Wydaje się, że bardziej prawdopodobnym scenariuszem jest podtrzymanie oparcia o sporą porcję pracy ręcznej i patrzenia na koszty, żeby „załapać się” na lepsze oferty i trochę oszczędzić. W żadnym wypadku nie znaczy to jednak, że dążenie do spójnej kontroli i jednolitych mechanizmów O&M nie jest zasadne – wręcz przeciwnie.

Unifikację kontroli w heterogenicznych środowiskach chmurowych daje się także uzyskać innymi metodami. Wystarczy na przykład postawić granicę „infrastruktury” nieco dalej od maszyny wirtualnej, choćby ustanawiając konteneryzację i orkiestrację kontenerów za środowisko osadzania aplikacji. Kubernetes tworzy mikrokosmos rozwiązań opartych o konteneryzację. Już na dziś w ofercie każdego dostawcy chmury dostępne są zarządzalne usługi Kubernetes. Skoro z każdym z nich można „rozmawiać” przez kubectl i w dokładnie taki sam sposób (no, może prawie dokładnie) dostarczać aplikacje do węzłów klastra Kuberentes, to zagadnienie realizacji zadań O&M w różnych chmurach wykonane będzie dokładnie tak samo.

Z przenośnością usług PaaS i serverless nie jest już tak dobrze, a im dalej od infrastruktury, tym bardziej specyficzne dla dostawcy chmury. Skoro jednak nie wszystko można mieć, a ujednolicenie O&M dla warstwy aplikacji też ma swoją wartość, to choć o to można zadbać. Jeśli więc ktoś decyduje się na budowanie rozwiązań w oparciu o PaaS, to podjął już – świadomie lub nie, choć to inna sprawa – decyzję o uzależnieniu się od dostawcy chmury. Ze wszystkimi konsekwencjami tego faktu. W takim jednak wypadku z dużym prawdopodobieństwem całość rozwiązania będzie oparta o komponenty z jednej chmury, więc wykorzystanie narzędzi O&M z danej chmury będzie miało największy sens ekonomiczny.

Z innych opcji dostępnych widać tu co prawda elementy prób „najazdu” dostawców chmur na inne chmury (jak choćby ARC w Azure), ale one są także wymierzone w relatywnie jednolitą ofertę usługową (czyli raczej IaaS). Zawsze też pozostaje do dyspozycji „stare dobre” własne zarządzanie, z Zabbixem na przykład, choć tę możliwość rozpatruję raczej w kategoriach ślepej uliczki i stanu przejściowego, bo w zestawieniu z dostępnym standardowo środowiskiem monitoringu w każdej z chmur, przegrywa ono już na starcie w każdej kategorii, od funkcjonalności po koszty użytkowania.

Podchodząc do zagadnienia O&M usług chmurowych tradycyjnie, wpadamy w swoistą pułapkę. Musimy zdecydować o wielu aspektach zarządzania rozwiązaniami, które każda z chmur obsługuje fantastycznie, ale tylko w swoim zakresie (np. konfigurację, monitoring i zarządzanie, rozkładanie obciążenia, predykcja kosztów i optymalizacja). Myślimy wtedy, że trzeba określić „Strategię O&M”, która będzie dawać odpowiedzi na ważkie pytania i powie, jak to zrobić (np. coś pomiędzy musi być w pełni zintegrowane pomiędzy chmurami lub będziemy korzystać z tego, co mamy od poszczególnych chmur, a resztę „w Excelu”). Dlaczego to jest pułapka? Bo O&M w warunkach chmurowych wcale nie musi być jednym, zintegrowanym środowiskiem, uśmiercającym na samym początku zwinność, adaptacyjność i DevOps. Skoro już od pewnego czasu wiadomo, że chaosu rozwoju IT nie da się okiełznać, a jedyną sensowną metodą jest „dziel i zwyciężaj” (wszak o to chodzi w DevOps), to bądźmy konsekwentni. Każdy DevOps będzie miał takie O&M, na jakie zasłuży.

Czy warto się napinać i upierać przy ujednolicaniu? Moim zdaniem – nie. Warto powiązać główne zagadnienia (np. włączyć tworzenie IaC do CI/CD, czy zapewnić porównywalność akcji monitorowania), ale żeby dążyć do pełnego ujednolicenia, to nie – zdecydowanie się to nie obroni. Wszak, skoro równoczesne korzystanie z usług różnych chmur będzie rutyną (szczególnie usługi niszowe, krótkotrwale wykorzystywane, nie podlegające zmianom) uspójnianie tych wszystkich elementów zarządzania technologią chmurową byłoby barierą wejścia raczej nie do przeskoczenia.

Najbardziej spodziewam się samodzielnego budowania małych platform zarządzania skrojonych na miarę dla danego rozwiązania. Wszak daje się to robić w oparciu o otwarte API usług poszczególnych chmur – skoro są dostępne, to można je zintegrować, a zbudowanie O&M dla rozwiązania będzie po prostu elementem zakresu projektu. Muszę też z uznaniem przyznać, że control plane w świecie IT wreszcie staje się programowalne, podążając za tym, co świat telekomunikacji stosował rutynowo ćwierć wieku temu. Są dobre wzorce (TMN ze świata poważnych rozwiązań teleinformatycznych, SNMP od informatycznej strony sieci), więc może nie będziemy na to długo czekać.

Pozostaw komentarz