Jak zbudować swoją infrastrukturę Big Data? Wybrać rozwiązania chmurowe, czy on-premise (własną infrastrukturę)? Zapraszam do pogłębionej analizy.

Jeśli potrzebujesz skrótowego zestawienia co jest czym i jakie są różnice, zapraszam tutaj.

Cloud czy On-premise? Spójrzmy na to głębiej

Nadszedł czas na to, co obiecywałem w poprzednim artykule z tematyki cloud vs. on-premise. Gdy już poznaliśmy uproszczone porównanie chmury i rozwiązania “własnego”,  możemy zagłębić się, aby poznać sprawę nieco dokładniej.

Problem specyfiki

Przede wszystkim musimy znać dobrze swoją specyfikę. Wybór infrastruktury nie może być efektem wzięcia udziału w “owczym pędzie”, gdyż może to nieść za sobą olbrzymie koszty. Specyfika właśnie to moim zdaniem słowo-klucz w dobrym podejściu do tematu.

Musimy wziąć pod uwagę przynajmniej kilka aspektów:

1. Czy przewidujemy jak duży będzie system (w kontekście złożoności)?
2. Czy wiemy jak duże dane będą tam przetwarzane oraz jaki będzie ich przyrost?
3. Jak bardzo zależy nam na prywatności oraz bezpieczeństwie dostępu do danych?
4. Na ile chcemy zachować elastyczność rozwiązania?
5. Jaki mamy budżet oraz jak bardzo przewidywalny będzie budżet w przyszłości?
6. Czy mamy na pokładzie fachowców od administrowania systemami (devops/admin)?
7. Czy dysponujemy już gotową infrastrukturą?
8. Jakie doświadczenie ma obecny na pokładzie zespół Big Data Inżynierów?

Lista może być solidnie dłuższa – wszystko zależy od konkretnego przypadku. Warto po prostu zadać sobie pytanie o obecny oraz przyszły stan projektu(ów) oraz danych a także – przede wszystkim – o nasze priorytety.

Przejdźmy pokrótce przez wszystkie punkty, żeby naświetlić na czym polegają.

Czy przewidujemy jak duży będzie system (w kontekście złożoności)?

Czasami system składa się z jednej bazy danych oraz kilku prostych aplikacji, które razem tworzą uproszczony ETL. Innym razem to ogromny ekosystem, na który składają się systemy plików, bazy danych, aplikacje analityczne i szereg technologii do przetwarzania danych oraz schedulingu.

Duże znaczenie ma tutaj pytanie, czy projekt już istnieje, czy dopiero będzie rozpoczynany. Jeśli istnieje, to koszt przepisania go na alternatywną infrastrukturę może być zabójczy, co samo w sobie zabije wszelkie pomysły. Jeśli dopiero będzie tworzony, należy zadać sobie pytanie o to jakich technologii chcielibyśmy użyć do zrealizowania celu. Być może – na przykład – tylko specyficzna chmura oferuje satysfakcjonujące rozwiązania.

Czy wiemy jak duże dane będą tam przetwarzane oraz jaki będzie ich przyrost?

Zauważyłem, że zaskakująco mało uwagi przykłada się do tego aspektu. Tymczasem to właśnie gwałtowny przyrost danych może wpędzić organizację w problemy, jeśli nieumiejętnie wybierzemy infrastrukturę.

Spójrzmy na bardzo prosty przykład: organizacja rządowa, która dopiero rozpoczyna informatyzację pewnego obszaru swojego zainteresowania. Przybywa danych i istnieje potrzeba, żeby te dane przeanalizować. Póki co cały proces cyfryzacji jest pilotażowy i bierze w nim udział relatywnie niewielka liczba podmiotów. Jeśli zdecydujemy się na rozwiązania chmurowe i to z wykorzystaniem takich zasobów zbudujemy system, możemy się “mocno przejechać”.

Ilość danych będzie się bowiem w przyszłości gwałtownie zwiększać (gdy projekt wyjdzie z etapu testowego, a potem – organicznie). Będzie to stanowiło ogromny problem finansowy, ponieważ cenniki usług chmurowych często są niejasne i – dodajmy – nie są to tanie rzeczy.

Znajdziemy się więc w sytuacji, w której na co dzień korzystamy z niezbędnego do życia systemu, gdzie co miesiąc faktura jest coraz bardziej “tłusta”. Nie możemy zrezygnować z usługi, ciężko oszacować budżet, jesteśmy dodatkowo skazani na “widzimisię” korporacji, która świadczy daną usługę chmurową.

Co gorsza – w przypadku instytucji rządowych – wzrost danych nie będzie wiązał się ze wzrostem przychodów. W przypadku prywatnych firm prawdopodobnie większe dane będą powiązane z większymi przychodami. Tutaj – jedynie z większymi kosztami.

Jak bardzo zależy nam na prywatności oraz bezpieczeństwie dostępu do danych?

Budując system obsługujący duże ilości danych, zderzamy się z podstawowym problemem… ochrony tych danych. Żyjemy w świecie, w którym informacja jest największym kapitałem. Oczywiście dobra, rzetelna informacja. I w miarę możliwości – z ograniczonym dostępem. Samo to powoduje już, że chcemy dane które przetwarzamy chronić. Kolejną rzeczą jest kwestia tego, czyimi danymi dysponujemy.

Krótko mówiąc – może okazać się, że prywatność danych i bezpieczeństwo dostępu do nich będzie absolutnie priorytetową sprawą. Dla zobrazowania – tak powinno być m.in. w przypadku służb specjalnych. W takiej sytuacji znacznie bardziej naturalnym wyborem będzie własna, dobrze zabezpieczona infrastruktura (być może także w jakimś zakresie odizolowana od internetu).

Na ile chcemy zachować elastyczność rozwiązania?

Myśląc o architekturze systemu warto mieć na uwadze przyszłość. Czasami nie zdajemy sobie sprawy jak bardzo ważą na przyszłości technologie, jakie wybierzemy. W tym przypadku mamy z grubsza dwie grupy technologii: dostępne powszechnie (w dużej mierze także open source) oraz natywne technologie chmurowe.

O ile w przypadku pierwszej grupy możemy łatwiej migrować między infrastrukturami, o tyle jeśli mówimy o natywnych – musimy pogodzić się z tym, że będziemy do nich przywiązani po wsze czasy. Będziemy skazani na support konkretnej chmury oraz potencjalne zakończenie wsparcia dla danej technologii.

Jaki mamy budżet oraz jak bardzo przewidywalny będzie budżet w przyszłości?

Wybierając infrastrukturę on-premise ponosimy jednorazowy, duży wydatek. Dodatkowo musimy dysponować kimś, kto będzie tym systemem administrował. Taki klaster jest przewidywalny w kontekście kosztów, jakie ze sobą niesie.

Dokładnie odwrotnie jest w przypadku chmury – dylemat “cloud vs. on-premise” bardzo mocno uzależniony jest więc od budżetu jaki posiadamy (być może próg wejścia w on-premise jest zbyt duży?), ale także od tego jak bardzo możemy przewidzieć jego stan w przyszłości.

Czy mamy na pokładzie fachowców od administrowania systemami (devops/admin)?

Eksperci devops, szczególnie w Big Data, należą do najwyżej opłacanych, co czyni oczywiście koszty istotnie większymi. Pytanie więc, czy mamy już na pokładzie takich specjalistów? Jeśli tak – mamy nie tylko ich już wliczonych w budżet, ale także posiadamy istotną pomoc podczas projektowania systemu.

Czy dysponujemy już gotową infrastrukturą?

Bardzo często dylemat między naszą własną infrastrukturą a tą chmurową nie dotyczy firm, które dopiero eksplorują teren. Wielokrotnie problematyka dotyka organizacje, które budują kolejny system i zastanawiają się w którą stronę pójść. W takiej sytuacji posiadanie już działającego i sprawdzonego klastra w ramach swoich zasobów byłoby ogromnym argumentem na korzyść on-prema.

Jakie doświadczenie ma obecny na pokładzie zespół Big Data Inżynierów?

Zostawiłem to pytanie na koniec, ale to jest naprawdę kluczowa sprawa. Wszystkie argumenty mogą przemawiać za jednym czy drugim rozwiązaniem. Końcem końców – ktoś ten system musi napisać;-). Pytanie więc, czy ludzie niedoświadczeni w chmurze mają stawiać wszystko od podstaw na Azure?

Odpowiedź wcale nie musi być oczywista. Być może tak, jeśli projekt nie jest kluczowym elementem organizacji. Wtedy to znakomity moment, aby zdobyć pierwsze rany w boju;-).

Pamiętaj – jeśli Twój zespół nie ma jeszcze kompetencji w Big Data (lub są one niewielkie), nie znajdziesz lepszego miejsca, które zmieni ten stan rzeczy;-). Skontaktuj się z nami… i zacznij wreszcie oddychać pełnymi możliwościami Big Data.

Cloud jak on-premise, czyli nie tylko “technologie chmurowe”

Wszystko to o czym pisałem rozdział wyżej, musi zostać uzupełnione o pewne doprecyzowanie możliwości chmurowych. Jeśli już wszystko było jasne, pozwolę sobie nieco skomplikować;-). Oczywiście – jak zawsze – tylko po to, żeby finalnie wiedza była uporządkowana i w pełni zrozumiana.

Co myślimy przeważnie, gdy mówimy “system został napisany w chmurze”? Zwykle zamykamy w ramach takiego stwierdzenia dwie rzeczy:

1. Korzystamy z usług jednego z trzech dużych dostawców usługi (Azure od Microsoft, AWS od Amazon oraz GCP od Google).
2. Wykorzystujemy technologie natywne – a więc np.  Azure Machine Learning Studio do predykcji.

Nie chcę mówić że to źle – uproszczenia są nam potrzebne, aby szybciej się porozumiewać i móc sprawnie analizować rzeczywistość. Tutaj jednak rozszerzmy podejście do chmury.

W samym założeniu, w podstawie, chmura to po prostu usługa rozproszonego udostępniania miejsca oraz mocy obliczeniowej. I tyle – zamiast kupować sprzęt, możemy wypożyczyć przestrzeń i moc. Wszystkie dodatki w postaci technologii konkretnych dostawców to późniejsza konsekwencja rozwinięcia się tej branży.

Jest więc możliwość, że wynajmiemy jedynie… przestrzeń oraz moc. Aby to zrobić, musimy wykupić maszyny wirtualne, na których samodzielnie administrujemy. System co prawda bardzo często jest stawiany automatycznie, natomiast cała reszta wygląda dokładnie tak, jakbyśmy mieli fizyczny komputer u siebie pod biurkiem w serwerowni.

Zasadniczo wszystkie usługi chmurowe zgrupowane są w 4 sekcje, które odpowiednio rozkładają odpowiedzialność za administrowanie infrastrukturą między klienta a dostawcę chmurowego.

1. IaaS (Infrastructure as a Service) – w tym przypadku po stronie dostawcy leży jedynie wirtualizacja, udostępnienie przestrzeni, “userwerowienie” sprzętu oraz networking. To w tym zakresie leży właśnie utworzenie maszyn wirtualnych (VM). Co prawda system może być w takim przypadku ustawiony
2. PaaS (Platform as a Service) – w tym miejscu dochodzi już znacznie więcej odpowiedzialności po stronie dostawcy. My dostarczamy jedynie aplikację oraz dane. Przykładem PaaS może być Azure Spark Pool w Azure Synapse. Wszystko utrzymywane jest przez dostawcę chmurowego, natomiast do nas należy zapewnienie danych oraz aplikacji.
3. SaaS (Software as a Service) – tutaj mówimy o całościowym produkcie oferowanym przez dostawcę chmurowego. Przykładem SaaS może być np. wirtualny Microsoft Office, gdzie wszystko osadzone jest w chmurze.

I teraz ważna rzecz: tak jak 2 i 3 punkt kojarzą się z największymi dostawcami, tak dostarczać IaaS może znacznie większa liczba organizacji. Jeśli więc nie odpowiada nam korzystanie z usług wielkiej trójki chmurowej – zawsze możemy wynająć mniejszą firmę i korzystać z postawionych tam serwerów. Pozwoli to na zmniejszenie progu wejścia. Co więcej – w takiej sytuacji cennik staje się znacznie bardziej przewidywalny.

A może… hybryda?

Ostatnią już rzeczą, którą chciałbym tu poruszyć w kontekście technikaliów i rzeczy do rozważenia jest hybryda. Dotychczas rozważamy wybór między “cloud vs. on-premise”. Pamiętajmy jednak, że to nie jedyny wybór. Infrastruktura którą budujemy musi być do nas dopasowana. Nic nie stoi na przeszkodzie, aby część rzeczy była wykonywana na naszej infrastrukturze, a jedynie niektóre obliczenia były robione w chmurze.

Przykładem takiego podejścia może być sytuacja, w której dane użytkowników w czystej formie są trzymane w 100% na naszych serwerach. Do chmury idzie natomiast jedynie przetworzony i zaszyfrowany fragment danych, który pozwoli na sprawną analizę, odciążając tym samym nasze moce obliczeniowe.

Myślmy strategicznie

Skoro omówiliśmy już podstawowe elementy, chciałbym poruszyć jeszcze jeden, bardzo istotny aspekt. Tym wpisem chciałbym zachęcić Cię – jeśli jesteś osobą decyzyjną – do spojrzenia długofalowego, perspektywicznego. Jeśli “trzymasz w ręku pieniądze i decyzje”, to możesz uniknąć wielu błędów, takich jak wybranie technologii, które są nieświeże już w momencie wybierania.

Jak już napisałem na samym początku, najważniejsze w całej analizie jest to, jaka jest specyfika organizacji oraz projektu. Warto pociągnąć to dalej – dobra infrastruktura nie tylko realizuje cele tu i teraz, ale także pozwala rozwijać się firmie i realizować cele w przyszłości.

Jeśli chcesz podjąć dobrą decyzję, spróbuj zrobić coś piekielnie trudnego – spójrz na kilka lat do przodu. Nie chodzi o to, aby wszystko przewidzieć. Zachęcam jednak do tego, aby spróbować się zastanowić nad dwoma rzeczami:

1. Jakie rzeczy na pewno będą przydatne w rozwoju?
2. Jakie błędy mogą spowodować poważne, kryzysowe problemy?

Problemy

Być może drugi punkt jest jeszcze istotniejszy. Z jakiś powodów bowiem zapadła decyzja o pójście w stronę Big Data, więc potrzeby są najprawdopodobniej “wylistowane”. Ważne jednak, aby spróbować przewidzieć, jakie błędy mogą doprowadzić do pożaru rozmiarów biblijnych.

Gdy już będziemy świadomi problemów oraz “kamieni milowych”, które możemy zrealizować dzięki naszemu systemowi, zastanówmy się które rozwiązanie będzie najlepiej wspierać naszą specyfikę. Przemyślmy każdy element systemu, stwórzmy kilka propozycji, kilka architektur. Czy to będzie kosztować? Oczywiście – teraz. W przyszłości natomiast pozwoli zachować spokój i wydajność, a to przyczynia się do budowania stabilnej, zdrowej i silnej organizacji.

Aby mieć jakiś punkt odniesienia, zapraszam do przykładowej “listy kontrolnej” problemów, które mogą wpędzić nas w tarapaty.

1. Zbyt dynamiczny przyrost danych (on-premise – problem z miejscem oraz mocą; cloud – problem z budżetem)
2. Problemy z zachowaniem prywatności (on-premise – kwestia zabezpieczeń i personelu; cloud – mała elastyczność, dostęp do danych przez trzeci podmiot)
3. Problemy z błędami w infrastrukturze (on-premise – wykwalifikowany zespół, cloud – support)
4. Problem ze stabilnością kosztów (cloud – uzależnienie od dostawcy)
5. Przestarzałe technologie (on-premise – update klastra to trudny proces)
6. Zbyt duże uzależnienie się od dostawcy, co prowadzić może do konieczności nadwyrężenia budżetu lub decyzji o likwidacji systemu – to stricte w kontekście chmury. Przepisanie systemu może zająć od kilku tygodni, nawet do kilkunastu miesięcy – wszystko w zależności od tego jak bardzo złożony jest system. Powstanie więc dramatyczny wybór o decyzji między likwidacją, a potrzebą ogromnego dofinansowania (np. w przypadku zwiększenia stawek, zmiany sposobu liczenia opłat itd).

Liczy się nie tylko to co tu i teraz

Nie ukrywam, że szczególnie mocno zależy mi w tym miejscu na podmiotach z sektora rządowego. Miałem przyjemność oglądać z bliska (i nie tylko oglądać) proces automatyzacji niektórych procesów oraz przechodzenia na filozofię Big Data w publicznym sektorze. Zdaję sobie sprawę, że niekiedy pojawiają się “okazje”, które pomagają podjąć taką czy inną decyzję.

Moim zdaniem kierowanie się takim kryterium jest najgorszym pomysłem z możliwych. Zdaję sobie sprawę, że każdy z nas chce zaoszczędzić tu i teraz. Pamiętajmy jednak, że będzie to miało wpływ na wiele rzeczy przez kolejne lata, a może i dekady (wiemy dobrze, jak długo systemy IT potrafią się utrzymywać…;-)). Jeśli jesteś więc osobą decyzyjną w sektorze publicznym, państwowym, rządowym – odrzuć proszę pokusy doraźnego zysku. Jeśli chłodna, perspektywiczna analiza doprowadzi Cię to usługodawcy, który próbuje skusić lepszą ofertą, to nic tylko się cieszyć. Nie może jednak być to kryterium, które będzie decydować o wyborze ścieżki. Z raz wybranej ścieżki bardzo, bardzo trudno jest skręcić w inną. To zaś może okazać się dość mocno kosztowne.

Podsumowanie

Zdaję sobie sprawę, że ten artykuł wymagał znacznie więcej czasu, niż przeciętne treści w internecie. Liczę jednak, że taki pomysł pogłębionej analizy przyda Ci się przy okazji planowania infrastruktury Big Data w organizacji.

To co najważniejsze, to znać specyfikę oraz priorytety. Następnie należy wykonać dość nudną, ale niezwykle ważną robotę analityczną. Na końcu… cóż, po prostu trzeba zbudować klaster i ruszyć do budowy systemu;-). Jeśli ja lub ktoś inny z ekspertów RDF będziemy mogli pomóc – po prostu skontaktuj się. Z przyjemnością poznamy specyfikę firmy, zaproponujemy kilka dróg, przeszkolimy zespół.

Tymczasem zachęcam do pozostania w kontakcie przy pomocy naszego newslettera. Powodzenia!