Kiedy rozważyć wdrożenie chmury prywatnej?

Pomysł uruchamiania chmury prywatnej, hostowanej lub lokalnej, dla jednej firmy szybko staje się czymś powszechnym. Coraz więcej firm dowiaduje się o cloud computingu i dostrzega, że prowadzenie własnej platformy chmurowej jest zarówno wykonalne, jak i potencjalnie wartościowe dla biznesu. Jednak z powodu ogólnego braku wiedzy o chmurze coraz częściej chmury są rekomendowane tam, gdzie wcale nie odpowiadają potrzebom firmy, będąc mylone z tradycyjnymi systemami zarządzania wirtualizacją.

Chmura to szczególny rodzaj platformy wirtualizacyjnej i wypełnia unikalną niszę. Cloud computing bierze tradycyjną wirtualizację i nakłada na nią zautomatyzowane skalowanie i provisionowanie, co umożliwia szybkie, poziome skalowanie aplikacji. Nie jest to typowa potrzeba biznesowa. Chmura sprzyja również samoobsłudze w zakresie provisionowania zasobów i często jest z nią powiązana, ale samo to nie sprawia, że coś jest chmurą ani nie uzasadnia przejścia na platformę chmurową, choć może być dodatkową zachętą. To, co czyni chmurę interesującą, to możliwość udostępniania portali samoobsługowych użytkownikom końcowym oraz zdolność aplikacji do samodzielnego provisionowania. To właśnie te cechy odróżniają platformę chmurową od tradycyjnej wirtualizacji.

Chmura nie implikuje takich funkcji jak uproszczone zarządzanie całą domeną z jednego panelu, konsolidacja na dużą skalę, łatwa migracja między systemami sprzętowymi, szybkie provisionowanie nowych systemów, wirtualizacja, wysoka dostępność, nadmierne przydzielanie zasobów itp. Funkcje te są dostępne w inny sposób, przede wszystkim za pośrednictwem lub na podstawie standardowej wirtualizacji platformowej (VMware vSphere, Microsoft HyperV, Xen i inne). Nie oznacza to, że tych funkcji nie można udostępnić w chmurze prywatnej, ale nie są one aspektami chmury, lecz bazowej platformy wirtualizacyjnej. Warstwa chmurowa jest ponad nimi i po prostu przekazuje korzyści z warstw niższych.

Często do chmury podchodzi się z powodu błędnego przekonania, że wiele funkcji powszechnie kojarzonych z chmurami prywatnymi nie jest dostępnych w innej, prostszej formie. Rzadko tak jest w rzeczywistości. Normalne platformy wirtualizacyjne, najczęściej VMware vSphere i Microsoft HyperV, oferują wszystkie te opcje. Można je wykorzystać do tworzenia rozbudowanych klastrów serwerów fizycznych, zarządzanych z jednego interfejsu, o niezwykle wysokiej niezawodności i szybkim provisionowaniu nowych systemów, wymagających minimalnej specjalistycznej wiedzy ze strony działu IT, przy jednoczesnym zachowaniu tradycyjnych procesów biznesowych. W większości przypadków, gdy rozmawiam z firmami, które uważają, że mogą być zainteresowane posiadaniem własnej chmury, funkcje, które naprawdę chcą uzyskać, wcale nie są funkcjami chmurowymi.

Termin „chmura” stał się ostatnio tak popularny, że ludzie zaczęli zakładać, że ważne funkcje dla prawie wszystkich muszą być mu przypisane, aby wyjaśnić nagły wzrost jego znaczenia, ale po prostu tak nie jest. Chmura pozostaje i pozostanie rozwiązaniem niszowym, odpowiednim tylko dla bardzo małej liczby firm, które chcą ją posiadać. Korzystanie z chmur publicznych lub usług hostowanych dostarczanych z platform chmurowych stało się, i rzeczywiście już stało się, niemal powszechne. Ale posiadanie chmury prywatnej do użytku jednej firmy jest daleko od bycia potrzebą biznesową dla większości firm lub jednostek biznesowych i w wielu przypadkach, podejrzewam, nigdy taką nie będzie.

Chmury prywatne wyróżniają się w dwóch kluczowych obszarach. Pierwszym jest firma, która regularnie potrzebuje dużej liczby tymczasowych lub ad hoc systemów „uruchamianych” na żądanie. Często zdarza się to w dużych zespołach deweloperskich i grupach testujących aplikacje, szczególnie jeśli te grupy obsługują wiele systemów operacyjnych. Zdolność do szybkiego provisionowania tymczasowych systemów testowych lub laboratoryjnych może być bardzo korzystna, a naturalne dla cloud computingu łatwe udostępnianie narzędzi provisionowania, pozwalających klientom biznesowym tworzyć, zarządzać i usuwać własne instancje systemów, z wbudowanymi mechanizmami obciążenia zwrotnego, może być bardzo korzystne dla efektywności korporacyjnej, ponieważ interakcja między działem IT a użytkownikami końcowymi staje się niemal bezproblemowa w przypadku tej transakcji. Odpowiedzialność za utrzymanie chmury jako całości można łatwo oddzielić od odpowiedzialności za utrzymanie poszczególnych systemów. Rzadko stosowana w ten sposób w przypadku obciążeń produkcyjnych, podejście to umożliwia samoobsługę, której wiele jednostek biznesowych desperacko poszukuje dzisiaj. Niepraktyczne na małą skalę ze względu na koszty tworzenia i utrzymania samej platformy chmurowej, ale na dużą skalę może być ogromnie produktywne. Poza technicznymi zaletami, ten aspekt cloud computingu może służyć jako model myślenia o IT jako o wewnętrznym dostawcy usług, a o działach jako o klientach. Od dawna mówimy o IT i innych jednostkach biznesowych w tych kategoriach, ale rzadko naprawdę tak o nich myślimy.

Drugi obszar, w którym cloud computing naprawdę się sprawdza i dla którego koncepcja ta została pierwotnie opracowana, to obsługa automatycznego provisionowania dla poziomo skalujących się aplikacji. Czyli obciążeń aplikacyjnych zdolnych do zwiększania wydajności poprzez tworzenie nowych instancji dla siebie. Na małą skalę wiele aplikacji webowych, ze względu na ich bezstanowy charakter, robi to w ramach jednego systemu poprzez tworzenie nowych wątków roboczych do obsługi dodatkowych połączeń. Serwer webowy Apache może zaczynać z ośmioma listenerami gotowymi do obsługi żądań, ale gdy te wątki się wyczerpują, automatycznie uruchamia nowe wątki do obsługi dodatkowych połączeń przychodzących, dzięki czemu jest w stanie skalować się w granicach jednego serwera. Rozwijając tę koncepcję w zastosowaniu do cloud computingu, ta sama aplikacja wyczuwająca zbliżające się wyczerpanie wątków na poziomie całego systemu (lub na podstawie innych metryk, takich jak brak wolnej pamięci lub utrata wydajności) użyłaby API udostępnianego przez platformę chmurową, aby zasygnalizować systemowi zarządzania chmurą konieczność provisionowania nowej kopii systemu, który ją wywołał – zasadniczo klonując siebie w locie. W ciągu kilku sekund nowy wirtualny serwer, identyczny z pierwszym, byłby uruchomiony i dołączał do swojego rodzica w obsłudze przychodzących żądań. Ten podrzędny lub klonowany system również tworzyłby nowe wątki wewnętrznie, w razie potrzeby, a następnie, jeśli on też wyczułby wyczerpanie, wywołałby platformę chmurową w celu stworzenia kolejnego nowego systemu do obsługi jeszcze większej liczby wątków. W ten sposób aplikacja może rosnąć niemal w nieskończoność (w granicach sprzętowych całej platformy chmurowej) w razie potrzeby, w locie, automatycznie. Następnie, gdy poszczególne systemy stają się bezczynne, obciążenia maleją, jeden po drugim system może zasygnalizować platformie zarządzania chmurą, że nie jest już potrzebny, a system zostanie wyłączony i zniszczony, gdyż był jedynie bezstanowym klonem, zwalniając pojemność systemową dla innych aplikacji i obciążeń, które mogą chcieć skorzystać z wolnej pojemności.

Jak widzimy, cloud computing jest niezwykle potężny, szczególnie biorąc pod uwagę, że większość dzisiejszych aplikacji publicznych i korporacyjnych jest pisana w sposób bezstanowy, aby wykorzystać protokoły webowe i interfejsy użytkownika końcowego. Aplikacje webowe są szczególnie biegłe w wykorzystywaniu modelu skalowalności cloud computingu i większość dużych aplikacji webowych korzysta dzisiaj z tego elastycznego rozszerzania i kurczenia pojemności. Wiele nowych modeli NoSQL zaczyna się pojawiać, sygnalizując, że bazy danych, oprócz węzłów przetwarzania front-end aplikacji, mogą wkrótce korzystać z podobnych modeli na dużą skalę. Z pewnością można to wykorzystać zarówno dla aplikacji wewnętrznych, jak i publicznych, jednak aplikacje wewnętrzne rzadko muszą skalować się poza pojedynczy system, więc znalezienie chmur prywatnych wykorzystywanych w ten sposób jest dość rzadkie.

Zagrożenia związane z cloud computingiem mają postać dodatkowej złożoności wykraczającej poza normalną wirtualizację. Istnieje potencjał złożonej przestrzeni dyskowej potrzebnej do obsługi platformy i więcej warstw do nauczenia się i utrzymania. Zdolność cloud computingu do szybkiego tworzenia i niszczenia systemów może skusić użytkowników do próby używania zasobów chmurowych tak, jakby były systemami trwałymi, czym mogą być, co może skutkować utratą danych przez użytkowników otrzymujących zachowanie bardzo różne od tradycyjnego i oczekiwanego. Być może największą obawą związaną z chmurą jest kwestia ludzka – zwiększone prawdopodobieństwo doświadczenia niekontrolowanego rozrostu systemów, gdy użytkownicy końcowi tworzą coraz więcej nowych systemów, które, ponieważ są tworzone przez użytkowników końcowych, a nie przez IT, prawdopodobnie nie są ściśle kontrolowane i monitorowane, pozostawiając systemy w stanie nieautoryzowanym i często zapomnianym. Może to prowadzić do koszmaru związanego z utrzymaniem i bezpieczeństwem, ponieważ systemy pozostają bez aktualizacji i opieki, zwiększając ryzyko i pochłaniając zasoby. I najbardziej niepokojąca jest możliwość tworzenia i zapominania systemów, które potencjalnie mogą istnieć bez odpowiedniego licencjonowania. Śledzenie i raportowanie automatycznie provisionowanych systemów wiąże się z ryzykiem procesowym spowodowanym ogromną zmianą sposobu tworzenia systemów. Działy IT są przyzwyczajone do ciężkich procesów licencjonowania niezbędnych do zachowania zgodności, ale w przypadku cloud computingu istnieje potencjał, że proces ten zostanie wystawiony na jednostki biznesowe w sposób, do obsługi którego nie są one w ogóle przygotowane. Istnieją rozwiązania dla potrzeb licencjonowania w cloud computingu, ale jest to dodatkowa złożoność i zarządzanie, którymi należy się zająć. Pozwolenie na istnienie systemów bez bezpośredniego nadzoru działu IT wyraźnie niesie ryzyko o potencjalnie nieprzewidywalnym charakterze.

Posiadanie chmury prywatnej niesie ze sobą wiele ekscytujących możliwości, ale jest oczywiste, że te korzyści i możliwości nie są dla wszystkich. Odpowiadają one większym firmom, tym z dobrą kontrolą procesów, firmom prowadzącym szczególnie zaadaptowane aplikacje zdolne do korzystania z elastyczności zasobów na poziomie systemu oraz tym potrzebującym tworzenia i niszczenia systemów ad hoc na dużą skalę, dostarczanego jako usługa, dla użytkowników końcowych do samodzielnego provisionowania. Większość dużych przedsiębiorstw znajdzie ograniczone zastosowanie dla cloud computingu we własnej infrastrukturze. Mniejsze organizacje rzadko kiedy znajdą cloud computing korzystny w najbliższej przyszłości, jeśli w ogóle.