Jak zbudować chmurę hybrydową

W świecie zdominowanym przez chmurę infrastruktura IT staje się niewidoczna dla użytkownika. W rzeczy samej, to jedno z założeń chmury – pule zasobów tworzące chmurę mogą znajdować się gdziekolwiek, są elastyczne i dynamicznie przydzielanie, w zależności od bieżących potrzeb aplikacji. Jednak w wielu przypadkach środowisko chmurowe jest ograniczone fizyczną lokalizacją, w której się znajduje. Dlatego przyszłość należy do chmury hybrydowej, w której wiele środowisk chmurowych jest ze sobą zintegrowanych.

Kiedy ludzie rozmawiają o chmurze, wyobrażają ją sobie jako kolekcję zasobów. Jednak chmura wcale nie musi być jedną, scentralizowaną pulą zasobów. Przeciwnie, może to być również pula obejmująca wiele mniejszych pul. Każda z tych pul może mieć różne właściwości. Przykładowo, chmura AWS oferuje bardzo szeroki zestaw funkcji, ale można się spodziewać, że Microsoft będzie argumentował, iż jego aplikacje działają najlepiej w chmurze Azure. Z kolei Google przekonuje, że Tensor Processing Units to wiodące rozwiązanie do zastosowań AI i uczenia maszynowego.

Rynek chmury jest bardzo zróżnicowany i ten stan rzeczy będzie się pogłębiać. Popularność chmury w przedsiębiorstwach rośnie i każda organizacja będzie koncentrowała się na tych aspektach, które są dla niej atrakcyjne. Jednocześnie bardzo niskie jest prawdopodobieństwo, że jakaś firma zdecyduje się na korzystanie wyłącznie z jednej chmury. Nawet jeśli określony dostawca będzie miał zróżnicowaną ofertę, należy się spodziewać, że przedsiębiorstwa przyjmą analogiczną strategię jak w przypadku producentów sprzętu i oprogramowania – będą unikały przywiązania do jednego dostawcy.

Zobacz również:

Zarządzanie wieloma chmurami

Przeniesienie zasobów IT do chmury nie zwalnia z obowiązku dbania o architekturę środowiska. Trzeba zadbać o możliwość jego monitorowania, zarządzania zmianami czy audytowania. Jak jednak opracować strategię zarządzania i orkiestracji, jeśli każda chmura stanowi niezależny byt? Jeśli chmura ma zapewniać elastyczny dostęp do zasobów, jak zarządzać aplikacjami, które miałyby przemieszczać się między chmurami? Odpowiedź brzmi, że nawet jeśli sama chmura będzie składać się z pojedynczych komponentów, to te komponenty trzeba ze sobą łączyć, aby utworzyć jednorodną chmurę hybrydową.

Podstawowym wymaganiem każdej strategii zarządzania są możliwości monitorowania środowiska. To oznacza, że przedsiębiorstwa zamierzając korzystać z zalet wielu chmur muszą samodzielnie zadbać o centralizację monitoringu i wizualizacji danych. Służące do tego narzędzia muszą obejmować fizyczne i wirtualne zasoby oraz chmurę prywatną i hybrydową.

Wszystkie narzędzia związane z orkiestracją i automatyzacją procesów będą dobierane na podstawie całościowej strategii monitoringu i wizualizacji. Nieudane zbudowanie spójnego, pełnego monitorowania różnych domen oznacza, że wszelkie plany wykorzystania zasobów z różnych chmur zostaną przekreślone. Praktyki operacyjne opierają się bowiem na spójnym spojrzeniu na podstawową infrastrukturę.

Ta zależność jest określana w kręgach deweloperów mianem prawa Conway’a. Zasadniczo, to jak zbudowane są produkty znajduje później odzwierciedlenie w tym, jak zorganizowane są zespoły ludzkie. Przekładając to na chmurę, sposób, w jaki użytkownicy będą korzystać z infrastruktury będzie odbiciem tego, jak infrastruktura jest zarządzana. Trudne zapewnić użytkownikom spójne doświadczenie, jeśli zespół operacyjny jest podzielony na segmenty odpowiadając poszczególnym lokalizacjom chmurowym.

Procesy i ludzie

Sukces nie jest wypadkową wyłącznie instrumentacji i przerzucania danych. W modelu wielu chmur trzeba też ująć procesy i ludzi. Z reguły firmy przydzielają zasoby w ramach pewnych ograniczonych granicami obszarów. Natomiast środowisko hybrydowe będzie dobrze działać tylko, jeśli ludzie i aplikacje będą mogli funkcjonować w ramach wielu obszarów.

Jeśli przedsiębiorstwo opiera się na procesach, które zaczynają się i kończą w obrębie pewnych granicach, wdrożenie nowych usług, które przekraczają tego granice, jest dużo trudniejsze.

Jeśli poszczególne zespoły zachowają kompletną autonomię, w naturalny sposób zablokują wdrożenie spójnych narzędzi i procesów, które umożliwią użytkownikom w sposób przejrzysty wykorzystanie zasobów niezależnie od miejsca pobytu.

Nie chodzi o to, żeby w przyszłość utworzyć płaską organizację bez granic, ale narzędzia i procesy, które te granice przekraczają, powinny być starannie skonstruowane z myślą o bezproblemowym działaniu chmury hybrydowej. Przykładowo, zespół zarządzający chmurą prywatną i zespół odpowiedzialny za chmurę AWS powinny być w stałym kontakcie, nawet jeśli funkcjonują niezależnie.

Sukces w widoczności

Na etapie planowania i wdrążania można koncentrować się wyłącznie na chmurze, ale sukces będzie zdeterminowanym tym, czy użytkownicy będą zadowoleni z końcowego efektu. Jeśli więc skupi się wyłącznie na zapewnieniu możliwości przenoszenia aplikacji między chmurami, cały włożony w to wysiłek przejdzie niezauważony dla użytkowników końcowych.

Przyszłość IT powinna naśladować obecne sieci energetyczne. Przykładowo, gdy wchodzi do pokoju konferencyjnego, światło może zapalić się automatycznie. Podobnie, kiedy użytkownik włącza aplikacje, automatycznie powinna mieć ona zapewnioną łączność sieciową i zasoby obliczeniowe. Oczywiście każdy kto pracuje przy sieciach energetycznych powie, że zrobienie czegoś, co jest niewidoczne, to bardzo trudne zadanie. Tak samo jest w przypadku IT – zrobienie takich rzeczy będzie wymagać znacznych nakładów.