O ewolucji hostingu w ciągu ostatnich pięciu lat z Łukaszem Strzelcem, Global Infrastructure Management Tribe Leadem, rozmawiała Katarzyna Fulek-Szajkowska.
Jak wyglądał hosting pięć lat temu? Na co wtedy kładło się największy nacisk?
Hosting pięć lat temu w głównej mierze opierał się na utrzymywaniu własnych, prywatnych centrów danych. W ten sposób byliśmy zorganizowani i my, i wszyscy dookoła. Większość w tym czasie myślała, że to jest dobry kierunek. Nacisk kładło się przede wszystkim na to, żeby automatyzować zadania/operacje tzw. drugiego dnia oraz procesy instalacji usług w Data Center (DC). Rozwiązania chmur obliczeniowych stanowiły egzotykę, a większość organizacji zmagała się z pojęciem chmury prywatnej. My również byliśmy w tej grupie.
Czy to oznacza, że pięć lat temu chmura była takim rozwiązaniem docelowym?
No właśnie nie. Oczywiście ci, którzy byli tzw. early adapterami, ewangelistami, mówili, że chmura publiczna to przyszłość. Konserwatyści natomiast nadal kręcili się wokół prywatnych centrów danych. To wynikało głównie z aspektu kosztowego, jak również związanego z „legal & security”. Chmura prywatna oznacza posiadanie kontroli od A do Z oraz możliwości dowolnego wpływania na rozwój data center. Mieliśmy certyfikację, która potwierdzała, że wszystko jest bezpieczne. Zupełnie inaczej niż w chmurze publicznej, gdzie za warstwę niskopoziomowej infrastruktury odpowiada sam dostawca i procesy akredytacji takiego rozwiązania musiały zostać zaktualizowane do takich wymogów od nowa.
Które z tych przekonań prezentował wtedy Pan?
Ja byłem wśród tych biednych ewangelistów mówiących, że chmura publiczna to przyszłość. Mówiłem, że pierwszym krokiem do zmiany systemu hostingu jest zrezygnowanie z własnych data center na poczet tzw. chmury hybrydowej. Uważałem, że część rozwiązań powinno pozostać u dostawcy chmury publicznej, a część w naszym prywatnym data center. To był pierwszy krok ku temu, żeby zmienić cały hosting i przerzucić go w 100 proc. na chmurę publiczną.
Użył Pan sformułowania „biedny ewangelista”. Czy to oznacza, że był Pan w znaczącej mniejszości?
W tamtym czasie powiedzenie, że idzie się do chmury publicznej, było przyznaniem się, że wchodzi się w zupełnie egzotyczne rozwiązanie. Na tę decyzję wpływały także wymagania regulacyjne. Jako instytucja finansowa, mamy zobowiązania wobec regulatorów oraz przepisów. Sposoby przetwarzania danych w systemach informatycznych są jasno określone. W tym przypadku brak „odświeżenia” prawa tak, by móc świadczyć nasze usługi na platformie, jaką jest chmura publiczna to problem. Praca z regulatorami i przekonywanie ich powoli pozwala nam na uzyskanie wszystkich niezbędnych akredytacji. Wiele rzeczy trzeba zaadaptować, np. nasze wewnętrzne procesy. Chmura publiczna jest opłacalna tylko wtedy, gdy mądrze przejdziemy proces migracji do niej. Musimy zrezygnować ze złożoności naszych systemów na korzyść prostoty. Trzeba się zastanowić, co jest droższe: utrzymanie własnego data center, czy nasza obecność w 100 proc. w chmurze publicznej.
Jakie jest „niemądre” podejście?
Podejście „shift and lift” – przerzucenie wszystkiego, co mamy na lewej stronie na prawą bez znaczniej inwestycji w modernizacje obecnych rozwiązań. Efektem takiego działa będzie znaczny wzrost kosztów utrzymania platform w chmurze, jak również brak podstawowych benefitów, które z założenia powinniśmy uzyskać po takiej migracji.
Czym jest cloud native?
Kiedy wchodzimy do danego dostawcy chmury, to staramy się wykorzystywać jego usługi natywne. Jednak nasz hosting musi być odpowiednio do tego przygotowany. Oznacza to, że wszystko, co wędruje do publicznej chmury, nie może być staroświecką aplikacją monolitową. Aplikacja musi być gotowa, by wykorzystać natywne benefity danego dostawcy. Te korzyści to: skalowalność, elastyczność oraz wysoka dostępność. Zatem dobrze przygotowana do migracji aplikacja jest mikrousługowa, niezmienna (Immutable) oraz wspierająca tzw. potoki (Continuous integration / Continuous Delivery). Warto podkreślić minimalne wymagania dla naszych usług: „Everything-as-code”, „API first”, czyli mantra w postaci dostarczania rozwiązań opisanych tylko kodem w oparciu o ich instalacje za pomocą tzw. potoków. W przeciwnym wypadku jest pytanie o sens migracji, skoro własna infrastruktura nie jest na to gotowa.
Na jakim etapie jest ING Hubs Poland?
Śmiało możemy nazwać się ewangelistami, bo od dłuższego czasu promujemy podejście do nowoczesnego designu naszych aplikacji. Gloryfikujemy kulturę inżynieryjną stawiając nacisk na rozwój mikrousług, CI/CD oraz znaną wszystkim zasadę: „wszystko jako kod”. Za każdym razem, kiedy pomyślimy o rozwiązaniach dostawców chmur publicznych, staramy się pójść z taką aplikacją czy funkcjonalnością, która będzie korzystała ze wszystkich udogodnień chmury publicznej. Słowa klucze: mikrousługi, „wszystko” jako kod, kontenery i szeroko pojęte CI/CD (Continuous Integration and Continuous Delivery).
Jaki był punkt zwrotny, w którym ewangeliści zaczęli być w większości?
To jest bardzo dobre pytanie do tych, którzy 5 lat temu oponowali (śmiech). Jednak poważnie. Przede wszystkim technologia się zmieniła, po drugie koszty utrzymania data center nie są niskie, jest to dobry czas na ponowną analizę rozwiązań chmurowych. Dodatkowo mamy też 3 kluczowe aspekty rozwiązań chmurowych, które trzeba wziąć pod uwagę, a których na pewno nie mamy w tradycyjnym hostingu. To jest czas dostarczenia – nie możemy pokonać cloud providerów, jeżeli chodzi o dostęp do najnowszych technologii. Oni już je mają – są dostępne pod jednym kliknięciem myszy. Drugie to zasięg – jeżeli chcielibyśmy utworzyć bank w regionie APAC czy gdziekolwiek indziej na świecie, po prostu wyklikujemy nasze usługi w danej lokalizacji np. Australii. I trzecie, to sama elastyczność – jeżeli się mądrze podchodzi do swojego biznesu i chce się korzystać z chmury publicznej, to okazuje się, że można na tym naprawdę dobrze zaoszczędzić. Elastyczność rozwiązań chmurowych powoduje, że kiedy mamy potrzebę, to nasze środowisko może rosnąć, a kiedy nie ma, to może zostać zredukowane do minimum przy utrzymaniu pełnej operacyjności i jakości tych usług. Dodatkowo nowocześnie skrojona platforma w chmurze, daje nam szereg rozwiązań, które wbrew pozorom mogą znacznie wpłynąć na stopień naszego bezpieczeństwa. Dziś jest naprawdę ciężko nadążyć za nowymi technologiami, a co ważniejsze być o krok szybciej i zabezpieczyć się przed nowymi wektorami ataków na nasze platformy. Weźmy nasz ulubiony Ransomware. Dzięki elastyczności dostawców rozwiązań chmurowych oraz świadomego ich wykorzystania jesteśmy w stanie w lepszy sposób mitygować tego typu zagrożenia. Hosting musi się zmienić, bo to już nie jest wystawienie serwera do serwerowni – tutaj mamy do czynienia z infrastrukturą opisaną kodem, wysoko dostępnymi mikrousługami – totalnie zautomatyzowanym ekosystemem działającym bez interakcji użytkownika.
Skoro hosting od jakiegoś czasu się zmienia, to co będzie za kolejnych pięć lat?
Sądzę, że za kilka lat samo utworzenie nowego banku w dowolnym kraju będzie się odbywało w pełni w sposób automatyczny bez udziału człowieka, a sama infrastruktura, platformy, będą opisane całkowicie kodem. Podstawowe funkcjonalności będą od siebie zupełnie odseparowane, więc w przypadku jakiejkolwiek awarii jednej usługi nie będzie ona miała wpływu na działalność naszych klientów. Przeżyjemy większość zdarzeń, awarii, ataków, które mogą się zdarzyć. Uruchamianie banku będziemy liczyć w minutach, a nie w godzinach, a systemy wspomagane rozwiązaniami z grupy AI/ML znacznie podniosą bezpieczeństwo świadczonych usług.