DevOps, Tech Talk

5 powodów, dlaczego publiczne rozwiązania chmurowe nie zawsze są dobrym wyborem

rozmowa w biurze

Pojęcie chmury obliczeniowej w ostatnich latach mocno się spopularyzowało i jest powszechnie znane w społeczeństwie. Dalej jest to głównie domena specjalistów IT, którzy zanim zaczną korzystać z tego typu rozwiązań, muszą być świadomi dostępnych możliwości.

Czym jest chmura obliczeniowa i jakie są jej rodzaje? Dlaczego firmy wybierają chmury publiczne? Kiedy chmura publiczna ogranicza rozwój produktu i co może dać rezygnacja z niej? Odpowiedzi na te pytania znajdziecie w artykule.

Chmury i ich rodzaje

Chmura obliczeniowa to model dostarczania usług IT na żądanie, który umożliwia dostęp do zasobów informatycznych za pośrednictwem internetu. Istnieją trzy główne typy “cloud computingu”:

  • Chmura publiczna (Public Cloud) to rodzaj chmury dostępnej dla ogółu klientów i zarządzanej przez dostawcę usług chmurowych. Zasoby są współdzielone między różnymi organizacjami, co pozwala na elastyczne skalowanie i obniżenie kosztów, bez konieczności posiadania fizycznie żadnego sprzętu. Przykłady dostawców to Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), czy mniej popularne jak IBM Cloud oraz Oracle Cloud Infrastructure (OCI).
  • Chmura prywatna (Private Cloud) jest używana wyłącznie przez jedną firmę. Może być zarządzana przez dostawcę usług chmurowych lub lokalnie przez organizację. Zapewnia większą kontrolę nad zasobami i bezpieczeństwem danych, ale w zależności od wielkości organizacji może być bardziej kosztowna w porównaniu do chmury publicznej.
  • Chmura hybrydowa (Hybrid Cloud) to połączenie chmury publicznej i prywatnej, umożliwiające organizacjom elastyczne dostosowanie zasobów do potrzeb. Pozwala na przenoszenie danych i aplikacji między różnymi środowiskami, w zależności od wymagań bezpieczeństwa, wydajności i kosztów.

Dlaczego firmy wybierają chmury publiczne?

Wiele organizacji, szczególnie w początkowej fazie rozwoju produktu, stawia na którąś z chmur publicznych. Przy tworzeniu MVP (Minimum Viable Product) takie podejście jest szczególnie istotne, gdyż umożliwia skupienie się na wartości dodanej, którą jest logika biznesowa, upraszczając aspekty infrastruktury. Również korporacje decydują się na szeroką współpracę z dostawcami chmurowymi, czego przykładem jest partnerstwo UBS z Microsoft dotyczące migracji zasobów UBS do chmury Azure.

Kiedy podejście chmurowe ma sens?

Przy tworzeniu aplikacji, której szybki rozwój jest ciężki do przewidzenia, chmura publiczna umożliwia prawie nielimitowane zasoby, które czekają tylko na polecenie uruchomienia. Podobnie przydatną sytuacją jest czasowy wzmożony ruch, który przy dobrze przygotowanej aplikacji można w łatwy sposób obsłużyć poprzez odpowiednie przeskalowanie środowiska. Po chwilowej, bądź sezonowej aktywności, przychodzi dla takich aplikacji spokojniejszy czas, kiedy w przypadku chmury publicznej wystarczy wyłączyć dodatkowe zasoby, tak aby za nie nie płacić. Nie byłoby to możliwe w przypadku własnej infrastruktury, gdzie nawet wyłączony serwer generuje koszty amortyzacyjne oraz zajmuje miejsce w serwerowni.

Gdy mamy do czynienia z nieprzewidywalnością biznesu, zwłaszcza w mniejszej organizacji, posiadanie własnej infrastruktury prowadzi często do nieoptymalnego wykorzystania zasobów. Nie da się w takiej sytuacji dołożyć tylko niewielkich zasobów, a zasoby z zakupu nawet jednego serwera dla takich projektów często się nie wypełnią przez długie miesiące.

Kiedy chmury publiczne ograniczają rozwój produktu?

W zupełnie innej sytuacji są większe organizacje zatrudniające setki czy tysiące specjalistów, posiadające w swoim portfolio różnorodne produkty. Często produkty te mają stabilną sytuację, gdzie atuty, które oferują chmury publiczne niekoniecznie są istotne, a zaczynają ciążyć stałe, niedające się ograniczyć koszty. W jakich przypadkach warto zastanowić się nad migracją projektu do chmury prywatnej czy hybrydowej?

1. Mamy bardzo dużo danych

Projekty zajmujące się wszelkiego rodzaju przechowywaniem i wykorzystywaniem sporej ilości danych to jeden z przykładów, w którym z pozoru tania usługa, jak S3 od AWS, może negatywnie wpłynąć na rentowność danego projektu. O ile w przypadku dziesiątek czy setek GB, koszt takiej usługi jest znikomy na tle innych składowych, tak w przypadku projektów, w których przechowywanych danych może być nawet wiele eksabajtów (EB), koszt ich przechowywania można liczyć w milionach dolarów miesięcznie, i to już po odpowiedniej optymalizacji.

2. Inwestujemy we własną infrastrukturę

Jeśli firma nie chce inwestować we własną serwerownię, bądź proces jest w trakcie, a zasoby są potrzebne znacznie wcześniej, istnieje wiele firm będących w stanie zaoferować miejsce w swojej serwerowni. Wówczas w zależności od wyspecjalizowania pracowników w organizacji, można w różnym stopniu oddelegować część prac przy przygotowaniu tego typu infrastruktury. W przypadku globalnych projektów nie jest możliwe szybkie przygotowanie nowej serwerowni ze względu na złożoność procesu. W tego typu sytuacjach wykorzystanie firm zewnętrznych może być traktowane jako etap przejściowy, gdzie po przygotowaniu własnej infrastruktury nastąpi migracja do własnych zasobów. Proces ten powinien być bardziej efektywny przy wykorzystaniu analogicznego sprzętu niż chmury publicznej.

3. Nie chcemy być zależni od dostawcy

Kolejnym argumentem przeciwko publicznym chmurom może być zbyt mocne przywiązanie do danego dostawcy. Rozwiązania SaaS przygotowywane przez dostawców rozwiązań chmurowych w założeniu mają pomóc w szybszym rozwoju aplikacji. I owszem, jest wiele sytuacji, gdzie to jest prawdą, jednak jednocześnie taki dostawca uzależnia od siebie daną organizację. Migracja na inne rozwiązania jest zdecydowanie trudniejsza niż przy klasycznym modelu. Powstało nawet dedykowane zagadnienie vendor lock-in, które opisuje sytuację, gdzie koszt zmiany na innego dostawcę jest tak wysoki, że klient jest właściwie skazany na wykorzystanie obecnego rozwiązania. Jakiekolwiek oszczędności wynikające z doboru tańszej opcji bledną przy kosztach migracji.

4. Kluczowe są dla nas kwestie bezpieczeństwa

W niektórych sytuacjach wykorzystanie własnej infrastruktury jest koniecznością, kiedy ze względu na rządowe regulacje dostawca oprogramowania jest zobligowany na zagwarantowanie najwyższego bezpieczeństwa danych – najczęściej są to dane obywateli wykorzystywane do cyfrowej administracji w państwie. Dobrym przykładem są tutaj szwajcarskie banki, które gwarantują swoim klientom, że ich dane nie wyciekną poza granice kraju. W ich przypadku powoli to podejście się zmienia, jednak minie jeszcze wiele czasu zanim publiczne chmury będą przez instytucje rządowe traktowane na równi z prywatnymi zasobami.

5. Chcemy mieć pełną kontrolę nad usługą

Ostatnim argumentem, o którym warto wspomnieć jest dostępność zasobów, a raczej złudne poczucie nieograniczonych możliwości. O ile podczas korzystania z rozwiązań chmurowych zasoby takie jak RAM, CPU, czy pojemność dysków jesteśmy w stanie w pełni kontrolować, tak nie mamy wpływu na to jaki hardware znajdzie się pod spodem. W przypadku specjalistycznych rozwiązań to może mieć znaczenie dla wydajności aplikacji i generować dodatkowe problemy. Tak samo w przypadku adapterów sieciowych niekoniecznie to, co oferuje nam AWS czy GCP jest w stanie sprostać wymaganiom, z którymi mierzy się nasza aplikacja.

Co może dać rezygnacja z chmury publicznej? Przykład Basecamp’a

Tyle suchej teorii, ale co robić w sytuacji, w której organizacja jest obsługiwana przez jedną z publicznych chmur i chciałaby to zmienić? Jest wiele przykładów pokazujących, że takie podejście może przynieść spore oszczędności. Jednym z bardziej wyrazistych jest Basecamp. Firma ta prowadziła biznes w oparciu tylko o AWS oraz GCP bez wykorzystania własnej infrastruktury. Po wielu latach, w których oczekiwali na obiecywane oszczędności, postanowili zrezygnować z usługi. Efekt? Zamiast ponad 3 milionów dolarów rocznie wydawanych dla Microsoftu i Google, operują obecnie za niewiele ponad 800 tysięcy, czyli prawie czterokrotnie mniej!

Nawet, jeśli przy okazji tej migracji ponieśli dodatkowe koszty, a do tego przy własnej infrastrukturze spotkają ich niespodziewane problemy, skala oszczędności o której tu mówimy jest ogromna i ciężko w ich sytuacji byłoby obronić trzymanie się współpracy z dostawcami chmurowymi.

Własna infrastruktura niesie za sobą oczywiście pewne ryzyka i trzeba mieć ich znajomość. Istotne jest jednak świadome podjęcie decyzji, dlatego warto przeanalizować to, w jaki sposób nasz produkt docelowo będzie wyglądał. Może się okazać, że w naszym przypadku operowanie na publicznej chmurze nie będzie najlepszą drogą i warto poświęcić czas na odpowiednie przygotowanie własnej infrastruktury.


Zdjęcie główne artykułu pochodzi z Envato.

DevOps Team Lead w Kaseya

Od ponad 9 lat zajmuje się wdrażaniem projektów, zajmując się głównie konfiguracją środowisk, CI/CD oraz monitoringiem. Fan automatyzacji, nie tylko zawodowo, wolny czas najchętniej spędza poza domem, na rowerze, squashu bądź z dziećmi.

Podobne artykuły