Transformując firmę w kierunku posiadania kompetencji Big Data stajemy przed podstawowym, bardzo popularnym problemem: jak zbudować naszą infrastrukturę? Zapraszam na skrótowe zestawienie różnic obu podejść.

Temat ten dotyczy zresztą nie tylko firm raczkujących w Big Data – powraca on przed budową każdego nowego systemu Big Data. Dzisiaj dołożę starań, by pomóc w uproszczeniu tego dylematu;-).

Struktura będzie następująca:

1. Na początku powiemy sobie czym w ogóle jest on-premise oraz cloud.
2. Dla niecierpliwych – powiemy w skrócie czym się różnią oba podejścia.
3. Podsumowanie – kilka słów będących punktem wyjściowym do dalszej analizy.

Po skończeniu lektury warto usiąść także do poszerzonej analizy tego samego tematu. Trochę faktów, trochę moich własnych opinii, ale przede wszystkim z myślą o głębszym zajrzeniu w temat.

Rodzaje infrastruktury Big Data

Postanowiłeś, że Twoja firma zacznie korzystać z dobrodziejstw młodej branży Big Data. Świetnie! Być może zacząłeś już kompletować zespół, a przynajmniej znalazłeś architekta, który zaczął projektować rozwiązanie dedykowane dla waszej sytuacji.

Powstaje podstawowe pytanie: na czym ów system miałby działać? Na tym etapie warto wiedzieć, że wybór infrastruktury technologicznej – w przeciwieństwie np. do postawienia strony-wizytówki, czy nawet sporej aplikacji webowej – to naprawdę duże i ważne wyzwanie. Nie rób tego w pośpiechu czy “po łebkach”, nawet jeśli nie wydaje się to najciekawszym etapem modernizacji firmy.

Zacznijmy od uproszczonego wyjaśnienia, które jakoś nas ukierunkuje. Potem przejdziemy do głębszego spojrzenia. Zacznijmy od najprostszego rozróżnienia na dwa typy infrastruktury serwerowej:

1. Własna infrastruktura (On-Premise, często skrótowo po prostu “on-prem”) – komputery, które fizycznie do nas należą, są przechowywane gdzieś “na naszym terytorium”. Samodzielnie łączymy je siecią, instalujemy tam odpowiednie oprogramowanie, synchronizujemy itd. Specjalnie do tego typu infrastruktury stworzona została m.in. popularna platforma Big Data Apache Hadoop. Stawiając on-premise musimy zadbać o samodzielną obsługę całości, natomiast koszt związany z zasobami jest “jednorazowy” w momencie zakupu sprzętu (potem oczywiście jeśli chcemy ją rozbudować).
2. Chmura (Cloud) – czyli instalacja odpowiedniego oprogramowania na komputerach (serwerach) udostępnionych przez zewnętrzną firmę. Taka firma (np. Microsoft ze swoją chmurą Azure) ma centra danych (data center) w różnych miejscach na świecie. Komputery te są ze sobą powiązane odpowiednimi sieciami i zabezpieczeniami. Szczegóły technologiczne na ten moment sobie darujmy (prawda jest taka, że to na tyle złożone tematy, że… z poszczególnych chmur (np. Azure czy AWS) robi się powszechnie uznawane certyfikaty – sam zresztą nawet jednym dysponuję;-)). Za chwilę odrobinę dokładniej opowiemy sobie jakie mamy dostępne możliwości wykorzystując chmurę. Teraz jednak to co trzeba zrozumieć, to że rezygnujemy z ręcznej obsługi zasobów. Oddajemy całość administracyjną fachowcom z konkretnej firmy. Gdy korzystamy z takich usług, nie wiemy na jakim dokładnie komputerze (komputerach, bardzo wielu) lądują nasze dane. Tak więc sporo “zabawy” nam odchodzi. Oczywiście coś za coś, natomiast o plusach i minusach porozmawiamy za chwilę.

Ostatnie lata to co prawda bardzo duży “hype” na chmurę (pardon… “na clouda”). Warto jednak nie poddawać się bezrefleksyjnej modzie, tym bardziej jeśli w dużej mierze jej nie rozumiemy;-). Wszystkim tym, którzy uważają, że utworzenie systemu na chmurze jest lepsze z samego faktu, że jest na chmurze… cóż, dedykuję mema – dla otrzeźwienia.

Cloud vs. On-Premise – uproszczone porównanie

1. Koszt zasobów:
   • On Prem: na początku, duży wydatek.
   • Cloud: w zależności od wykorzystania przez cały czas (brak jednorazowej dużej inwestycji).
2. Koszt obsługi:
   • On Prem: Wysoki, należy zatrudnić dev-opsów
   • Cloud: Konieczność zakupienia subskrypcji, jednak samodzielnie nie przejmujemy się tym jak co działa. Jeśli coś nie działa – możemy napisać do supportu i dostać (lub nie) odpowiedź.
3. Jakość obsługi:
   • On Prem: Uzależniona od tego jakich fachowców (adminów/devopsów) zatrudnimy. Firma ma w związku z tym bardzo duży wpływ na ten aspekt.
   • Cloud: Jakość obsługi (support) jest bardzo różna, często losowa. Zależy to od dwóch rzeczy: wykupionego przez nas pakietu oraz “wylosowanego” przedstawiciela chmury. Często pomoc ta jest niestety niesatysfakcjonująca. Z mojego doświadczenia mogę jedynie dodać, że czasami support wiedział mniej, niż ja po paru dniach prób rozwiązania problemu;-).
4.  Stabilność kosztów:
   • On Prem: Duża stabilność, można to dość dokładnie wyliczyć. Należy tu wliczyć koszt zakupu, zużycia prądu oraz koszt zatrdunienia fachowców.
   • Cloud: W przypadku chmury stabilność kosztów jest skrajnie mała. Wielokrotnie zależą od wielu czynników, które nie są ani łatwe/możliwe do obliczenia, ani nie są znane. Dotyczy to szczególnie mocno wielkich dostawców. Nigdy nie możemy być pewni ile zapłacimy pieniędzy po danym miesiącu. Co więcej – jesteśmy mocno uzależnieni od platformy, która może dowolnie podnosić ceny (oczywiście w ramach pewnych granic).
5. Gdzie przechowywane są dane:
   • On Prem: na naszych komputerach, możemy dojść których dokładnie.
   • Cloud: U zewnętrznej firmy. Nigdy nie wiadomo dokładnie gdzie, choć często mamy możliwość wybrania data-center, np. obszar Europy Zachodniej.
6. Z jakich technologii można korzystać?
   • On Prem: Tylko z ogólnie dostępnych, które są udostępniane (za darmo lub za pieniądze).
   • Cloud: Największe chmury poza przestrzenią serwerową, udostępniają także swoje własne technologie dedykowane do rozwiązania konkretnego problemu.
7. Łatwość skalowalności:
   • On Prem: jeśli zabraknie nam zasobów/przestrzeni na dysku – musimy dokupić nowy fizyczny sprzęt, co pochłania zasoby i czas.
   • Cloud: W przypadku chmury jest łatwiej. Jeśli potrzebujemy większy klaster, po prostu możemy zmienić ustawienia.
8. Dostęp do danych w kontekście prywatności:
   • On Prem: Mamy gwarancję, że dostęp do danych mamy jedynie my (pomijamy tu kwestię włamań)
   • Cloud: Nie możemy stwierdzić gdzie dokładnie są dane ani nie mamy dostępu administracyjnego i developerskiego do serwisów obsługujących te dane, co za tym idzie – nie możemy być pewni, że jedynie my z nich korzystamy. W większości przypadków punkt ten nie ma dużego znaczenia, są jednak podmioty (tak prywatne jak i publiczne oraz rządowe), które kładą ekstremalnie duży nacisk na ochronę danych i przejrzystość dostępu.

Podsumowanie

No więc który rodzaj infrastruktury wybrać? I teraz najważniejsze – to zależy. Aby dobrze wybrać, należy znać specyfikę swojego projektu oraz swojej organizacji. Moim zdaniem to właśnie specyfika jest słowem-klucz. Musimy rozważyć bardzo wiele aspektów, nasze priorytety oraz to na ile umiemy przewidzieć rozwój projektu (np. przyrost danych czy budżet).

Aby zgłębić ten temat już teraz zapraszam do kolejnego artykułu, w którym analizuję całe zagadnienie. Jest to hybryda wiedzy oraz moich (i nie tylko moich;-)) doświadczeń. Liczę, że pozwoli rzucić nieco inne światło na wybór infrastruktury w oparciu o rzetelną wiedzę, pomijając cały owczy pęd.

Na koniec – zapraszam do naszego newslettera. Dołączając, pozostajesz w kontakcie z RDF, jedynym takim miejscem na temat Big Data/AI w polskim internecie;-).