Kamil Mrzygłód o rozwiązaniach chmurowych

Dzisiaj porozmawiamy o rozwiązaniach chmurowych, o zastosowaniach chmury, jej kosztach. Kamil, zacznijmy od tego, abyś się przedstawił, powiedział parę słów o sobie, o tym, czym się zajmujesz.

Mam na imię Kamil. Pracuję w Warszawie przy rondzie ONZ w firmie Demant Technology Centre. Zajmujemy się tam tworzeniem aplikacji czy też szeroko pojętego software’u, który pomaga osobom mającym problemy ze słuchem. Tematyka aparatów słuchowych, przetwarzania danych w tego typu hardwarze jak najbardziej się pojawia. Co więcej, jestem Microsoft Azure MVP, czyli osobą utytułowaną przez Microsoft w zakresie bycia liderem w społeczności. Tu konkretnie mówimy o chmurze Azure. Jestem także trenerem w Sages, współpracujemy od czasu do czasu. Prowadzę także „Stację IT”, kiedy tylko mam okazję. Od czasu do czasu pojawiam się na różnego rodzaju prelekcjach, konferencjach, żeby podzielić się troszkę swoją wiedzą, podyskutować na temat chmury, zarówno w Polsce, jak i na świecie.

Mówisz dużo o chmurze na różnego rodzaju szkoleniach. Jak oceniasz poziom wiedzy w Polsce na temat tego, czym jest chmura, gdzie można ją zastosować?

Temat chmury współcześnie wygląda trochę inaczej niż kilka lat temu. Nie jestem w Azurze od samego początku, chociaż Azure sam w sobie nie jest starą technologią. Pamiętam, że parę lat temu wyglądało to całkowicie inaczej. Mało kto wiedział, jak z tej chmury skorzystać albo jak wejść. Myślę, że teraz, na początku 2019 r., sprawy mają się trochę inaczej – choć nadal jest duże pole, które wymaga nauczania i rozmawiania o tym, w jaki sposób to organizować. Patrząc jednak na społeczności, nawet w Polsce, widać rosnące zainteresowanie. Na przykład w tym momencie na grupie facebookowej, azure’owej mamy już ponad 3 tys. aktywnych członków, na meet-upach pojawia się coraz więcej osób. Widać, że zainteresowanie rośnie. Niemniej należy rozróżnić takie stricte społecznościowe zainteresowanie od komercyjnego zainteresowania firm. Patrząc po moich doświadczeniach i doświadczeniu znajomych z branży, widać, że edukacja nadal musi się odbywać i wiele osób podejmuje błędne decyzje. Podejrzewam, że nie do końca rozumieją, w jaki sposób powinni z chmurą pracować.

Zacznijmy od podstaw. Cloud to różnego rodzaju zastosowania, ale jeśli mówimy „chmura”, to co tak naprawdę mamy na myśli?

Chmura ma szerokie spektrum zastosowań, jak chociażby przez osoby korzystające z różnych social mediów. U nich ta chmura się pojawia. Czy korzysta się z Apple’a czy z Google’a, urządzeń mobilnych, chmura dla takiego statystycznego Kowalskiego też jest, ale niekoniecznie niesie jakąkolwiek wartość poza tym, że użytkownik wie, że ma kilka gigabajtów, na których może przechowywać swoje zdjęcie, i to wszystko. Definicja chmury jest znacznie bardziej rozbudowana, ale nie ma co jej nie wiadomo jak upiększać, bo chmura obliczeniowa sama w sobie nie jest niczym nowym. W najprostszej definicji można uznać ją za skończoną pod względem mocy obliczeniowej data center, z której można skorzystać i w której dostawca – niezależnie od tego, czy to będzie Amazon, Microsoft, Google czy inny, np. polski – udostępnia nam część tej mocy obliczeniowej na odpowiednich zasadach, z odpowiednim porozumieniem i za cenę, którą można oczywiście negocjować. Ale generalnie kończy się to na tym, że my, używając chmury, przenosimy tę data center, te komputery i serwery, które jeszcze parę czy paręnaście lat temu pewnie każda firma miała, do zewnętrznego dostawcy. To oczywiście wiąże się z różnicami na poziomie odpowiedzialności, z tym, kto na samym końcu jest za co odpowiedzialny.

To jest ta główna korzyść, czyli że zdejmuje z nas konieczność zajmowania się infrastrukturą – myśleniem o tym, jakiej ma być wielkości – administracją i, co najważniejsze, odpowiedzialność, że to będzie działać z jakąś dostępnością. Czyli płacimy firmom zewnętrznym za to, że to one odpowiadają, żeby to było dostępne 24 godziny na dobę.

Warto zaznaczyć jedną ważną rzecz: poziom odpowiedzialności jest zależny troszkę od modelu, z jakiego chcemy skorzystać, wchodząc do chmur. Jak się chodzi na konferencje związane z tematyką chmury, bardzo często pojawiają się pewne czteroliterowe skróty i jeden termin on-premises, którymi cały czas ludzie żonglują. Myślę, że ważne zaznaczenia jest to, jakie są różnice. Bo kiedy mówimy o on-premises, to mamy na myśli właśnie te nasze onsite’owe serwerownie, które są zarządzane przez nas, są naszą odpowiedzialnością – nasze w sensie mnie jako firmy – które mają bądź nie mają kontaktu ze światem zewnętrznym. Gdy wchodzi się w chmurę, pojawiają się jeszcze dodatkowe terminy, czyli tzw. IAAS, czyli Infrastructure as a Service, w którym to, co pozyskujemy, to – w bardzo ogólnym znaczeniu – wirtualne maszyny. W tym momencie odpowiedzialność dostawcy sprowadza się do tego, żeby zapewnić nam infrastrukturę fizyczną, infrastrukturę sieciową, podłączenie do internetu, do prądu, czyli bardziej te fizyczne aspekty. Na nas ciąży odpowiedzialność za zarządzanie tą wirtualną maszyną.

Później jest PaaS – Platform as a Service, w którym tą wirtualną maszyną nie zarządzamy. De facto to, co musimy wnieść do tego rozwiązania chmurowego, to jest nasz framework, nasza platforma – czy javowa, czy dotnetowa, czy javascriptowa, nie ma tak naprawdę znaczenia. Chodzi o to, że my na końcu dostarczamy, wdrażamy naszą aplikację np. internetowo, ale w przeciwieństwie do tych starszych rozwiązań, gdzie musieliśmy skonfigurować serwer webowy, porty, firewalla na serwerze, tutaj jest już wszystko poza nami. Dostarczamy wyłącznie naszą aplikację i nią zarządzamy.

Później ten poziom abstrakcji rośnie. Pojawia się serverless, gdzie dostarczamy wyłącznie kawałki kodu, nie całą platformę, albo cały temat kontyneryzacji, w który można także wejść – to, co jest na nas, to często nawet nie jest orkiestracja tych kontenerów, tylko znów wdrożenie i do chmury, a jakaś usługa chmurowa zarządza tym wszystkim za nas. Myślę, że zrozumienie, jak różnią się te modele i jak odpowiedzialność po stronie dostawcy rośnie, a maleje po naszej stronie, w momencie kiedy poziom abstrakcji wzrasta, też jest kluczowe do zrozumienia, czym chmura jest na samym końcu.

Czyli obecnie mamy bardzo duży wybór odpowiedzialności, którą chcemy wziąć na siebie. Możemy wziąć większą odpowiedzialność, budując własną chmurę on-premises, możemy wziąć chmurę jako infrastrukturę od dostawców i jako platformę czy wręcz kawałki kodu. To daje duże możliwości dopasowania do własnego biznesu – robimy to, co jest naszym biznesem, a nie zajmujemy się tym, co jest bardziej z boku. Czy w sytuacji, kiedy budujemy chmurę samodzielnie, jest jakaś różnica w stosunku do podejść stosowanych dawniej? Czy słowo „chmura” coś nam dodaje – taka własna chmura budowana na własnym sprzęcie w stosunku do tego, co funkcjonowało 10 lat temu, czyli własne serwery? Czy to jest coś ekstra, czy to jest to samo, ale pod nową nazwą?

Myślę, że jeśli nie dokładamy do tego elementu hybrydowego, czyli kiedy mamy łączone nasze on-premises z chmurą od wybranego dostawcy, to pewnie nie ma co za bardzo mówić, że teraz my robimy chmurę. OK, pewnie część ludzi bardzo chętnie by to w tym momencie nazwała. Oni dziś, w 2019 r., robią chmurę, a 10 lat temu robili serwerownię. Myślę, że na samym końcu to jest jedno i to samo w tym sensie, że chmura pod spodem to są tylko i wyłącznie fizyczne maszyny i fizyczna serwerownia, która jest zarządzana przez jakąś grupę ludzi. Czy to dziś, czy 10–15 lat temu, problemy z tym związane są bardzo podobne. Moim zdaniem na samym końcu robimy cały czas to samo. Jedyne, co się w tym momencie zmienia, to świadomość tego, co trzeba wnieść ze swojej strony, żeby uzyskać jakiś zysk po stronie firmy.

Po drugie ludzie zaczynają rozumieć, że budowanie po stronie swojej firmy wszystkich kompetencji wymaganych, żeby te on-premises, które ludzie usiłują zbudować, odzwierciedlało taką biznesową wartość pod kątem wydajności, zarządzania i bezpieczeństwa, może być bardzo kosztowne. Jest to jedna z zalet chmury i powodów, dla których coraz więcej firm decyduje się na chmurę. Bo zbudowanie kompetencji, zespołu, który będzie zarządzał taką infrastrukturą – jeżeli ta infrastruktura to nie są trzy serwery gdzieś tam pod biurkiem, tylko to są naprawdę konkretne szafy, raki, w których mamy wysokiej klasy sprzęt – to są grube tysiące złotych. Jeżeli nałożymy do tego jeszcze dynamikę, z jaką całe to środowisko się zmienia, związaną z tym, jak wyglądają wszystkie ryzyka związane z bezpieczeństwem, to może okazać się, że to jest trywialne i koszt wymagany do tego, aby stworzyć taką infrastrukturę po swojej stronie, niemalże przewyższa realny zysk albo zwrot z tej inwestycji nastąpi dopiero po wielu, wielu latach. Z tego powodu coraz więcej firm, także tych największych, decyduje się jednak wejść w chmurę.

Przejdźmy teraz do strony biznesowej. W jakich zastosowaniach się to opłaca? Wydaje się, że opłaca się to właśnie tym biznesom, które dopiero startują i dla których technologia nie jest kluczowa. Tu chmura wydaje się mieć największe znaczenie. Bo jeśli jestem firmą odzieżową, która chce mieć własne rozwiązania informatyczne, czy to do sprzedaży, czy do jakichś wewnętrznych procesów, to fakt, że nie muszę wchodzić w technologie związane z obsługą moich danych, jest ogromną korzyścią. Wyobrażam sobie tu firmy, które zajmują się softwarem czy IT od wielu lat, więc one mogą sobie to wyważać, czy bardziej opłaca im się to czy to. Natomiast dla firmy, która zajmuje się zupełnie czymś innym, czy dla start-upu, to jest ogromna korzyść. Zastanówmy się teraz nad takimi obszarami biznesu, które najbardziej mogą skorzystać z chmury. Jakie są najbardziej typowe zastosowania chmury?

Zacznę, odpowiadając troszkę przewrotnie. Udział chmury w rynku, jeśli chodzi o software development, zmienia się dość mocno, chociażby w zależności od kraju. Wiemy, że w tym momencie kraje skandynawskie przodują w technologiach chmurowych. Tam duży procent firm korzysta z chmury. To nie jest nic dziwnego. Finlandia, Norwegia i Dania widzą korzyści z tego płynące. Na przykład olbrzymia duńska firma Maersk korzysta z tej chmury.

W przełożeniu na polskie realia to wygląda już inaczej. Bardzo powoli przekonujemy się do chmury, i to niezależnie od sektora. Bo z jednej strony można by było powiedzieć, że sektor publiczny niekoniecznie chciałby mieć chmurę, bo chmura ma taką specyfikę, że nie zawsze te dane mogą być przechowywane na terenie danego kraju, nie my jesteśmy właścicielem tej całej infrastruktury. Ktoś może „zapalić lampkę” i powiedzieć, że nie do końca ufa dostawcy. Z drugiej strony to też nie do końca prawda, ponieważ największe chmury, najwięksi dostawcy – jak wspominałem, Amazon, Google czy Microsoft – mają olbrzymi zestaw odpowiednich certyfikatów, które poświadczają to, że są zgodni z normami, wymaganiami i regulacjami danego kraju. Z punktu widzenia dostawcy chmurowego oczywiście to też jest wartość dodana. Im zależy na tym, żeby maksymalizować zysk po swojej stronie, a więc zachęcać także sektor publiczny, bankowy do tego, żeby wchodził w chmurę. Na naszym polskim podwórku to się powoli zmienia. Jest coraz więcej instytucji finansowych, jak i publicznych, które wchodzą w usługi chmurowe. Pewnie na przestrzeni najbliższych lat nadal ten trend będzie rósł. Na pewno problem tkwi w edukacji, jeżeli chodzi o to, w jaki sposób te rozwiązania chmurowe robić.

Ale wracając do twojego pytania o to, które konkretnie obszary głównie z tego korzystają, to zgodzę się z tym, że wśród software house’ów, które specjalizują się w budowie software’u, ten wybór, jeśli chodzi o to, gdzie tę chmurę wsadzić, jest dość prosty i naturalny. Bo oni doskonale wiedzą, jaka technologia daje im profit. Ale z punktu widzenia firm, które nie są software housem, ale wytwarzają oprogramowanie po swojej stronie, ich decyzja może być troszkę trudniejsza.

Posłużę się przykładami. Mam swojego klienta, który jest jednoosobową działalnością zajmującą się produkcją i instalacją urządzeń, które zliczają wejścia, wyjścia sklepu. One są rozsiane, dystrybuowane w całym kraju. Aplikacja wcześniej była zbudowana w taki sposób, że działała tradycyjnie na wirtualnej maszynie, tam wszystko było wpakowane w jedno. Jeżeli jakikolwiek problem się pojawił, to cała firma w tym momencie stawała. Z punktu widzenia jednoosobowej działalności gospodarczej to może być dość duży problem, gdy przez tydzień nie działa. Może się okazać, że odpłynie 30% klientów, a 30% klientów to dla domowego budżetu poważny cios. Zdecydowaliśmy się na wejście w chmurę, ponieważ zauważyliśmy wiele korzyści, zarówno pod kątem maksymalizacji kosztów, optymalizacji zarządzania, jak i możliwości skalowania i zwiększenia dynamiki tego produktu. Bo główną bolączką tej aplikacji było to, że była ciężka do rozbudowy. Jeżeli chcielibyśmy w tym momencie rozszerzyć ofertę na sąsiednie kraje, to okazuje się, że duplikacja tej całej architektury sprawiała olbrzymie problemy i generowała spore koszty. Mówię to po to, aby z jednej strony pokazać, że nawet jednoosobowa działalność może z tego korzystać, a z drugiej – żeby zauważyć to, że jeżeli chodzi o koszty związane z tym, po co nam chmura, to jest troszkę inaczej w zależności od tego, kto de facto jest beneficjentem tego, co ona daje.

W mojej obecnej firmie, Demant Technology Centre, mamy coraz więcej produktów chmurowych. To jest firma, która ma tysiące pracowników i olbrzymi market. Poziom finansów firmy i tego, jak wygląda finansowanie tych projektów software’owych, jest całkowicie inny. Tam z jednej strony olbrzymim benefitem chmury jest to, że cały proces wytwarzania i dostarczania oprogramowania na produkt jest znacznie prostszy, pomimo że jesteśmy obarczeni znacznie prostszymi regulacjami związanymi z tym, że na samym końcu wytwarzamy urządzenia medyczne. Z drugiej strony firma tę chmurę widzi z jednej strony jako trend, a z drugiej – jako multum możliwości pod kątem tego, w którą stronę firma chce się kierować. Jeżeli mówimy o takim kierunku, że coraz więcej firm chce zbierać i przetwarzać dane, to okazuje się, że dla dużych firm jak np. moja obecna, jest to olbrzymia wartość. Nie musimy zastanawiać się nad tym, skąd weźmiemy zasoby, żeby przechowywać terabajty danych, które zostaną zebrane w ciągu najbliższych lat. Nie musimy się zastanawiać i planować, jak sfinansować zakup tego całego hardware’u, dysków, maszyn i budowania skillsetu, żeby ludzie byli w stanie tym zarządzać.

Jeśli chodzi o część naszych rozwiązań – bo nie mówię, że nie mamy takich on-premisesowych rozwiązań – które nie zostały wepchnięte w nasze serwerownie, to my de facto nie musimy utrzymywać całego zespołu ludzi, którzy będą przepinać kabelki i konfigurować to wszystko. Mówię to z pewnym przekąsem, bo nie chciałbym sugerować, że odpowiedzialnością osób zarządzających serwerownią jest przepinanie kabelków. Niemniej jednak z naszej perspektywy to olbrzymia wartość dodana, że możemy skupić się de facto na developmencie i researchu, a nie na takich mocno fizycznych, przyziemnych rzeczach. Wydaje mi się, że inne duże firmy, które w chmurę wchodzą, też widzą tę wartość. Nie muszą się przejmować, skąd wziąć miejsce na nowe serwery, co robić z tymi, które się zepsuły, nie muszą budować skillsetu związanego z obsługą czy wirtualizacją. Mogą raczej poświęcić budżet na szkolenia, na zatrudnienie ludzi, którzy wprowadzą ich w ten nowoczesny trend związany z nauczaniem maszynowym, z przetwarzaniem danych, z reagowaniem na opinie czy też reakcje klientów niemalże w czasie rzeczywistym, żeby z jednej strony klientom dostarczyć najwyższą możliwą jakość, a z drugiej – obniżyć koszty operacyjne, które być może mogą być poświęcone na ten element researchu i badań w firmie, na który być może wcześniej nie było finansów.

Ten element finansów i kosztów pewnie w tym wszystkim jest ważny. O kosztach chmury porozmawiamy za chwilę. Natomiast ciekawe jest to, że duże firmy technologiczne, takie jak Spotify – był taki głośny przypadek przejścia z własnej infrastruktury na tę chmurową – też decydują się na to, że przestają utrzymywać działy związane z infrastrukturą i całkowicie to delegują. Bo w małej firmie czy działalności jednoosobowej trudno samodzielnie się tym zajmować, natomiast ci duzi gracze najwyraźniej widzą w tym korzyść.

To nie tylko Spotify, ale też Netflix. Dzięki temu, że Netflix wszedł w chmurę z takim podejściem, w którym zrozumiał benefity płynące z posiadania chmury i z tego, w jaki sposób ona jest elastyczna, to z racji tego, że Netflix jest generalnie oparty o ten stack Amazonowy, to kiedyś swego czasu był problem z Amazonem w poprzednim roku. Była dosyć mocna awaria, gdzie duża część internetu miała przez chwilę czkawkę. Natomiast okazało się, że Netflix wcale tej czkawki nie ma na samym końcu, bo to wynika ze specyfiki implementacji w chmurze. Netflix to są w ogóle początki inżynierii chaosu związane z developmentem software’u w chmurze. Pokazuje to, że dla tak dużej firmy to był gigantyczny benefit. Oni musieli zainwestować ze swojej strony odpowiednie zasoby, ludzkie i finansowe, żeby w to wszystko wejść. Mieli odwagę, żeby przenieść cały swój stack technologiczny do chmury i tam operować w Amazonie. Ale na samym końcu rachunek jest na plus. Bo w przeciwieństwie do wielu innych dostawców oni byli w stanie funkcjonować. Pewnie posiadając swoją serwerownię, niekoniecznie by im się to udało.

Co więcej, patrząc ostatnio na problem T-Mobile’a, okazało się, że niestety, jeżeli chodzi o redundancję tych właśnie serwerów czy ogólnie całego naszego stosu technologicznego, który gdzieś tam mamy, to posiadanie tego lokalnie pewnie jest fajne i być może optymalizuje koszty, ale z drugiej strony trzeba zrobić to w taki sposób, żeby tego biznesu nie zabić na samym końcu. A pewnie tego typu problematyka jest znacznie łatwiejsza, kiedy takie pytania zadaje sobie nasz dostawca. To nie znaczy, że my jako klient nie musimy sobie zadawać pytania, w jaki sposób nasza architektura powinna być wysoko dostępna. Niemniej jednak jest to pewnie znacznie prostsze. Nie wymaga zatrudniania ekip, które nam wybudują teraz w Poznaniu kolejne data center. To sprowadza się na samym końcu do dobrego zaplanowania jednego kliknięcia, które zrobi replikę naszej architektury w innym regionie.

Padło już tu kilka nazw firm – Amazon i Microsoft, Google – w kontekście dostawców chmury. Porozmawiajmy chwilę o tym, skąd tę chmurę wziąć. Jak dokonać wyboru? Czy są jeszcze inni gracze oprócz tej wielkiej trójki? Jak przygotować się do tego, żeby podjąć decyzję i z której oferty skorzystać?

Jeśli chodzi o wybór, to z jednej strony jest to proste, a z drugiej ciężkie. Myślę, że głównym kryterium na samym końcu będzie to, z czego korzystamy, jeśli chodzi o technologię. Bo z jednej strony każdy z tych dostawców, przynajmniej tych największych – Microsoft, Amazon, Google – chce być konkurencyjny głównie wobec siebie, chociaż pojawiają się nowi dostawcy, np. Chiny zaczynają proponować swoje rozwiązania. Wybór zależny jest od tego, na czym chcemy te aplikacje mieć. Mimo że wszyscy starają się wspierać wszystko, to zawsze jest główna platforma, która będzie wspierana w 100%, a reszta w 75%. To się zmienia w czasie i wsparcie wygląda różnie. Niemniej jednak po swoim doświadczeniu widzę, że taki stack technologiczny, microsoftowy zwykle najbliżej jest Azure’a. A jeżeli mamy bardziej javowy stack, to ludzie operują wokół Amazona. Jeśli chodzi o inne technologie i kontenery, wydaje się, że Google jest jak na razie z przodu. To nie znaczy, że czegoś nie da się zrobić u kogoś. Na samym końcu można wziąć wirtualną maszynę i na niej postawić to, co chcemy. Niemniej jednak ja bym w pierwszym kroku zastanowił się, jaki ja mam stack technologiczny i co chcę najbardziej wynieść z tego wszystkiego.

A druga rzecz jest taka, że często ten wybór podyktowany jest już wcześniejszymi zobowiązaniami. Bo np. jeżeli mam Office’a 365, to pewnie znacznie łatwiej mi wejść w Azure’a, bo mam już jedną technologię, która de facto jest tą chmurową. Jestem bliżej tego Microsoftu. Jeżeli mój stack technologiczny to są te kontenery, to mimo że Microsoft ma swojego Kubernetesa – Azure Kubernetes Service – to patrząc na to, jak obecnie społeczność boksuje się dosyć mocno z tą usługą, może się okazać, że może jednak poczekajmy jeszcze chwilę, wybierzmy na ten moment lepiej Google, a może jeszcze kogoś innego. Bo są jeszcze mniejsze firmy, które oferują rozwiązania chmurowe w mniejszym lub większym zakresie. Często jest tak, że niestety albo wachlarz dostępnych usług jest bardzo wąski, albo gwarancje związane z dostępnością tych usług nie są na wysokim poziomie. Głównie chodzi o te finansowe aspekty i to, ile jaki dostawca może zaoferować ze swojej strony. Microsoft może na pewno łatwiej budować data center niż jakiś mały dostawca z polskiego podwórka.

Dochodzą tu jeszcze tematy chmury hybrydowej, np. polski Beyond, który oferuje usługę chmury hybrydowej opartej na Azure Stack. Dalej wybór jest troszkę zależny od tego, jaka jest charakterystyka biznesu. Nasza charakterystyka wygląda w ten sposób, że my tę chmurę chcemy, ale mimo wszystko mamy część rzeczy, których nie możemy do niej wsadzić, bo regulacje prawne nam zabraniają, więc bardzo często wyborem będzie chmura hybrydowa, która pozwala mieć część rzeczy u siebie, oparta chociażby na Azure Stack, który jest pewną wersją Azure’a dostosowaną do tego, żeby była hostowana on-premises, na odpowiednio wyspecyfikowanym sprzęcie. Wtedy możemy mieć subskrypcje już w chmurze publicznej i możemy prowadzić wymianę informacji. Z punktu widzenia firmy, która ma np. jakieś kontenerowce, ma na swoim pokładzie data center, bo go potrzebuje, może się okazać, że chmura hybrydowa w tego typu biznesie jest jak najbardziej OK, bo pozwala synchronizować się w momencie, kiedy kontenerowiec dopływa do portu, synchronizuje się z chmurą publiczną, np. z jakimiś systemami korporacyjnymi. Mamy jakieś dane dotyczące dostaw, tego asortymentu, który przypłynął, w momencie kiedy wypływa, to lokalnie na tej swojej chmurze, która jest na pokładzie, przetwarza te dane. Myślę, że to w Polsce będzie się coraz bardziej zmieniać, coraz więcej firm będzie wchodzić w tę chmurę. Ale kiedy to się zdarzy, ciężko powiedzieć, bo to zależy od tego, ile sukcesywnie wdrożeń będzie na samym końcu.

Czy ci dostawcy różnią się też sposobem płatności i rozliczania naszej firmy?

Modele płatnicze bardzo często sprowadzają się do odpowiedniej umowy pomiędzy dostawcą a firmą. Znam to najbardziej z punktu widzenia Microsoft Azure. Tych modeli jest kilka. Generalnie można to przełożyć także na innych dostawców. Najprostszy model jest wtedy, gdy podpinamy kartę płatniczą i dostajemy subskrypcję, deployemy nasze aplikacje, wytwarzamy serwisy, płacimy na sam koniec tyle, ile nas to kosztowało. W takim modelu pewnie nie ma dużej elastyczności, jeśli chodzi o zniżki, dodatkowe dostępy czy o usługi preview. Z chmury można także skorzystać za pośrednictwem partnera. Jeżeli nie chcemy zajmować się bezpośrednio komunikacją z Microsoftem czy ogólnie z dostawcą chmurowym, nie chcemy zajmować się aspektem finansowym, tym, w jaki sposób opłacać subskrypcje, w jaki sposób rozmawiać z naszym dostawcą, aby uzyskiwać jakieś benefity, to możemy wybrać model z partnerem. Wtedy to partner jest naszą pierwszą linią supportu, to on wspiera nas w rozwoju technologii i to jemu zależy na tym, żebyśmy usługi chmurowe wykorzystywali w jak najbardziej optymalny sposób.

Kolejnym modelem, który można brać pod uwagę, są wszelkie umowy pomiędzy firmą a dostawcą, taki enterprise agreement. Na podstawie commitmentu finansowego decydujemy się, że w danym roku kalendarzowym użyjemy usług na pół miliona dolarów. Mając taki commitment z naszej strony, dostawca wie, że jesteśmy zobowiązani do użycia takiej ilości zasobów, do wydania takiej ilości pieniędzy. Ale w zamian od razu jesteśmy spersonalizowanym klientem dla dostawcy. Możemy uzyskiwać różnego rodzaju zniżki, pozyskiwać dostępy do usług, które są jeszcze całkowicie prywatne i nie są dostępne, żeby robić wszelkiego rodzaju proof of concept naszych rozwiązań, zanim jeszcze dana usługa pojawi się publicznie. To też jest wartość dodana. Bo jeśli mamy u siebie w firmie departament zajmujący się rozwojem i badaniami, może się okazać, że jesteśmy w stanie pół roku wcześniej przetestować i zacząć realizować usługę, która będzie konkurencyjna w stosunku do innych na rynku. Nie musimy czekać paru miesięcy, aż ta usługa będzie publiczna, i dopiero wtedy zastanawiać się, czy możemy jej użyć. Nie, jesteśmy wtedy bardziej do przodu. Można to także przenieść na odpowiednie wyniki finansowe.

Tych modeli i możliwości jest więc kilka. Im jesteśmy większym klientem, tym oczywiście łatwiej jest zdecydować i uzyskać fajne benefity. Niemniej jednak, nawet będąc mniejszym klientem, można za pośrednictwem partnera uzyskać odpowiedni poziom wsparcia, szczególnie że dostawcy chmur są generalnie bardzo chętni, żeby na podstawie odpowiednich ustaleń dostarczać jakieś tam parę dolarów, po to żebyśmy mogli przygotować koncept dużego rozwiązania. Jeżeli jesteśmy start-upem i robimy coś innowacyjnego, pewnie jest możliwość dogadania się z dostawcą chmurowym na kredyt tudzież na dostarczenie subskrypcji, która ma jakiś zasób pieniężny dodany, aby dostarczyć rozwiązanie w zamian za to, że np. będzie ono reklamowane tym, że używamy Amazona.

Jednym z kryteriów wyboru dostawcy chmury mogą być usługi dodane, które dostawcy oferują. W ostatnich latach obserwujemy, że coraz więcej jest gotowych usług na tych platformach. Kiedyś był goły sprzęt, infrastruktura, więc teraz mamy różnego rodzaju usługi, np. związane z przetwarzaniem danych czy wręcz takie jak analiza obrazu czy rozpoznawanie głosu. Dostawcy prześcigają się w rozwiązaniach dających konkretne narzędzia, których możemy użyć jako klocki do zmontowania własnej aplikacji, ale z takich bardzo zaawansowanych narzędzi. Wydaje mi się więc, że jest między nimi wyścig, który ma uatrakcyjnić tę ofertę.

To jest naturalne w konkurencji pomiędzy nimi, bo przekłada się na samym końcu na koszty chmury. Nie powiemy, że one maleją, ale są generalnie zrównywane. Gdy dostawcy mają podobne koszty, to albo muszą być tańsi, albo muszą oferować lepszą jakość. Z punktu widzenia klienta jest to na pewno na plus. Bo ja dostaję coraz lepszą jakość, a wybieram na samym końcu to, co uważam za wartościowe z mojej perspektywy. Tych wszystkich SaaS-owych usług jest coraz więcej w chmurze, coraz bardziej są oparte na zaawansowanych narzędziach. Mamy narzędzia enterprise’owe, jak chociażby wspomniany Office 365, którego tematyka związana jest z pakietami biurowymi, które firma musi mieć na samym końcu. Zintegrowane chmury to są dodatkowe plusy, bo dzięki temu możemy np. integrować nasze konta z innymi usługami chmurowymi. Co więcej, jest taka tendencja, że coraz częściej dostawcy chmurowi kupują jakieś rozwiązania po to, żeby je osadzić w chmurze na własnych zasadach. Bo normalnie koszt licencyjny pewnie znacznie by przewyższał to, co oni by chcieli. A bardzo często kończy się tak, że oni te rozwiązania wykupują i te rozwiązania są potem dostosowywane, dostępne jako takie klocuszki, które można sobie potem zdeployować, wdrożyć do własnej chmury i korzystać z nich bez wykupywania licencji, bez konieczności setupowania całego stacku sieciowego hardware’owego. Czasem wiąże się to z jakimiś obostrzeniami, czasem z troszkę większą problematyką rozwiązań, bo jednak ten produkt musiał zostać dostosowany.

Wspominałeś już wcześniej o różnego rodzaju obawach firm w kwestii wykorzystania chmury, np. to, że udostępniamy swoje dane w pierwszej chwili nie do końca wiadomo gdzie. Czy widzisz inne obawy, które pojawiają się u firm, i jak można na nie odpowiedzieć? Jakie są realne zagrożenia, o których musimy myśleć, kiedy planujemy przeniesienie naszych danych czy naszej aplikacji do infrastruktury chmurowej?

Pewnie jeśli chodzi o przechowywanie samych danych, to jest już kwestia regulacji. Bo jeżeli mamy jasno powiedziane, że dane nie mogą być przechowywane poza granicami kraju, to jeżeli data center nie jest w danym kraju, to pewnie to jest niezbyt możliwe. Dostawcy chmurowi często dostarczają specjalne regiony, które są de facto przeznaczone dla rządów poszczególnych krajów i one są na odpowiednio innych zasadach, już potem hostowane i obsługiwane.

Widzę ryzyka związane może nie tyle stricte z chmurą, a raczej z tym, w jaki sposób można ją wykorzystać, kiedy projektujemy, wytwarzamy jakieś aplikacje oparte o nią. Bardzo często można naciąć się na to, że zakładamy, że dostawca wszystko robi za nas. A tak jak wspominałem na samym początku, to troszkę zależy, po pierwsze, od modelu, a po drugie to nie zwalnia nas z czytania dokumentacji. Dokumentacja zawiera bardzo dużo wiedzy na temat tego, co powinniśmy zrobić po naszej stronie, żeby to było wspierane. Większość ludzi tej dokumentacji nie czyta. I nie mówię tu o osobach, które to projektują, czy tych w marketingu biznesowym, ale widzę też po sobie, że często czegoś nie doczytam i potem muszę do tego wracać. Niestety ta niewiedza, czy właśnie ta częściowa wiedza, może powodować, że w pewnym momencie nasze rozwiązanie nie do końca będzie spełniać nasze oczekiwania. Bo jeżeli nasz biznes jest oparty na tym, że rozwiązanie musi być wysoko dostępne, na tym, że musimy być w stanie w określonym czasie podnieść to rozwiązanie, to jeśli dojdzie do awarii, to to, że mamy chmurę, nic nie zmieni. Każda usługa ma odpowiednie recovery point objective, który czasem jest mniej lub bardziej jasny. Dostawca chmurowy daje nam tylko service level agreement, mówiący o tym, że oni starają się przez 99,99% czasu całkowitego w miesiącu mieć pewność, że ta usługa działa, np. zawsze zostaje ta jedna setna procenta i jak stworzymy skomplikowaną architekturę i połączymy te wszystkie SLA, to może się okazać, że z tego 0,01% robi się 0,1%. W przeliczeniu na czas całego roku może się okazać, że aplikacja nie działa parę dni, a my nie będziemy wymagać niczego od dostawcy chmurowego, bo zgodziliśmy się na to z uwagi na agreement, który jest pomiędzy nami.

Minusem chmury publicznej jest to, że niestety ten recovery point objective, który mówi, jaki jest planowany czy też przetestowany czas potrzebny do tego, żeby podnieść usługę w momencie awarii, często albo nie jest dostępny, albo nie jest wystarczająco zagwarantowany. To jest tylko jakiś tam cel. Ale jeśli okaże się, że tak się nie stało, to nie mamy narzędzi, żeby dostawcę chmurowego pociągnąć do odpowiedzialności.

A jaka jest ta odpowiedzialność? Czy ona jest realna, że możemy domagać się jakichś finansowych rekompensat, jeśli to SLA jest przekroczone?

Tak. Z racji tego, że jest umowa pomiędzy nami a dostawcą, to jeżeli SLA zostanie przekroczone, to w tym momencie procentowo – w zależności od tego, ile zostało przekroczone – mamy zwracane pieniądze za usługę. Ale umówmy się tu do jednej rzeczy: jeżeli usługa kosztuje nas 50 dolarów, to może niech nam zwrócą 25 dolarów, tylko że problem był taki, że na usłudze kosztującej 50 dolarów mieliśmy system, który nas kosztuje np. za jedną godzinę tysiąc dolarów, jeśli działa. I OK, dostawca wywiąże się z tego, że nie dopełni swojej części umowy, ale to my nie zabezpieczyliśmy się przed down time naszej aplikacji. Głównym problemem jest jednak koszt związany z tym, że aplikacja musi być odpowiednio zaprojektowana. Jeżeli tak nie jest, to bardzo często słychać oburzenie pod kątem dostawców, ale praktycznie dziewięć na dziesięć przypadków jest takich, że to błąd po stronie klienta, który nie przewidział tego scenariusza i nie zaimplementował odpowiednio czy to failovera czy dostępności swojej aplikacji.

Korzystanie z chmury nie zwalnia nas z tego, że musimy myśleć, co się stanie, jeśli chmura przestanie działać.

Tak. Korzystanie z jakiejkolwiek technologii nie zwalnia nas z odpowiedzialności. Tu pojawia się temat tzw. vendor lock-inu, czyli jakby okazało się, że Microsoft zwija swój biznes dzisiaj, to co stanie się z naszym biznesem? Pewnie większość firm nie ma tego problemu, to jest raczej nierealne, niemniej jednak są praktyki, które mówią o tym, że niezależnie od tego, co by się stało, musimy mieć możliwość w ciągu jednej, trzech czy pięciu godzin – w zależności, jak ten cel zostanie wyznaczony – przeniesienia całości rozwiązania do innego dostawcy chmurowego albo do siebie do serwerowni.

Porozmawiajmy w końcu o kosztach tego rozwiązania. Czy jeśli korzystamy z chmury, to będziemy płacić więcej czy mniej, niż gdybyśmy mieli tę infrastrukturę u siebie? Jak to wygląda w przeliczeniu na realne pieniądze?

Wiele osób wchodzących w chmurę zapomina o jednej rzeczy. Są dostępne kalkulatory, które mówią o tzw. TCO, czyli total cost of ownership. Pokazuje ono, ile realnie takie rozwiązanie by nas kosztowało. Pewnie te rozwiązania chmurowe potrafią być droższe niż na fakturce, która mówi nam, ile za to zapłaciliśmy. Ale to, czego zwykle nie widać, to koszty ludzkie. Jeśli kupno serwera wyniosło ok. 10 tys. zł, a rozwiązanie chmurowe kosztuje nas w tym momencie np. 700 dolarów miesięcznie, to w przeliczeniu rocznym będzie zdecydowanie więcej. Tylko że my nie bierzemy pod uwagę licencji, które muszą być opłacane, i tego, że serwer musi być zarządzany. Jeżeli w tym momencie specjalista od infrastruktury bierze 10 tys. zł miesięcznie, to rachunek albo jest równy, albo gdzieś będzie znak większości. Z mojej perspektywy zwykle na samym końcu chmura i tak przeważa z racji tego, że ja, mając chmurę, nie przejmuję się tym, że jest jakiś fizyczny budynek, który może być zarządzany. Tam jest nie tylko kwestia zarządzania, tego, że mamy jednego specjalistę, który chodzi po tej serwerowni i ją obsługuje, ale tam jest ochrona, tam są systemy przeciwpożarowe, systemy związane z redundancją, jeśli chodzi o sieć energetyczną i internetową. Tych kosztów zwykle nie bierzemy pod uwagę w tym rachunku przy aplikacjach, które mamy on-premises. Albo robimy to w taki sposób, że troszkę sami siebie oszukujemy, że to na samym końcu kosztowo wychodzi lepiej.

Jeśli więc chodzi o koszty w chmurze, to wszystko zależy od tego, co chcemy zrobić i w jaki sposób to zrealizujemy. Bo np. te popularne rozwiązania jak serverless, które zwykle oparte są na modelu płatniczym, w którym płacimy tylko za wykorzystanie, to przy odpowiednim zaprojektowaniu aplikacji czasem można zejść do zera, jeżeli chodzi o obsługę, albo blisko zera, albo zminimalizować koszty obsługi aplikacji do ułamka.

Z drugiej strony wirtualne maszyny w chmurach są dosyć drogie. Jakiś czas temu miałem okazję porównać je, ponieważ miałem rozmowę, czy kupić serwer u jednego dostawcy, ale niechmurowego, tylko dostawcy wirtualnych maszyn, czy wybrać Azure. Okazało się, że cenowo Azure wychodzi drożej. Z drugiej strony, jak dołożyliśmy to, że np. jest wymaganie, żeby ta wirtualna maszyna była replikowana, żeby system cały czas działał, nawet jeśli coś by się stało, to się okazało, że z punktu widzenia drugiego dostawcy, niebędącego dostawcą chmurowym, nie dało się tego zrobić. On nie miał możliwości zapewnienia wysokiej dostępności. W tym momencie to nas zabiło pod kątem wymagań, pomimo że tam były grube tysiące. Mówimy o grubych tysiącach za wirtualne maszyny, bo to były naprawdę sensowne wirtualne maszyny, parę rdzeni, dość dużo pamięci RAM.

Rozwiązania oparte na wirtualnej maszynie potrafią sporo kosztować, nawet w wydaniu chmurowym. Za jedną taką maszynkę możemy zapłacić 700 dolarów. Jeśli mamy kilkadziesiąt takich maszyn, to koszt sięga kilkudziesięciu tysięcy dolarów miesięcznie. Pewnie to jest na samym końcu porównywalne z kosztem, jaki kiedyś był ponoszony. Pewnie na samym końcu wrócimy do tego, że do wirtualnych maszyn będziemy mieć jednego człowieka, i to będzie jego odpowiedzialność. Ale nie będziemy mieć tu armii ludzi, którzy oprócz tego, że zarządzają wirtualnymi maszynami, to zarządzają też całą serwerownią. Z drugiej strony te PaaS-owe usługi na pierwszy rzut oka potrafią być tańsze. I np. żeby hostować aplikację webową, możemy zapłacić kwotę rzędu 150–200 zł miesięcznie za produkcyjny workflow, który ma włączone odpowiednie feature’y zapewniające to, by aplikacja spełniała swoją funkcję. Okazuje się, że w tych PaaS-owych rozwiązaniach ten koszt potrafi się zwielokrotnić w momencie, kiedy np. trzeba wyskalować rozwiązanie albo zapewnić jego wysoką dostępność, backupy, łatwość tworzenia całej infrastruktury. Z racji tego, że poziom abstrakcji jest dość wysoki, trzeba się sporo nagimnastykować, aby to miało sens.

I co więcej, kiedy mamy wirtualną maszynę, to mamy wirtualną maszynę i tam koszt jest stały. Mogę to teraz odnieść do jednego z naszych projektów. Jeśli wiemy, że potrzebujemy pięciu wirtualnych maszyn, ale na tych wirtualnych maszynach będziemy hostować kilkanaście, kilkadziesiąt małych serwisików, to koszt jest stały niezależnie od tego, ile jest serwisów. Utylizacja tych kosztów jest znacznie lepsza. Jeżelibyśmy wzięli te same serwisy i przenieśli na PaaS-ową usługę w Azurze, to okazuje się, że ten koszt jest parę razy większy, dlatego że tam utylizacja kosztów jest znacznie trudniejsza, bo nie da się w ramach jednego serwisu hostować parę produkcyjnych serwisów, każdy de facto musi być oddzielną instancją. Jak każdy jest oddzielną instancją, to musi wykombinować, w jaki sposób to podpinać na poziomie domen, SSL-a, DNS-a. Poziom skomplikowania tej infrastruktury rośnie, pomimo że teoretycznie PaaS jest prostszy do zarządzania – tak jest przynajmniej z punktu widzenia wdrożeń. Koszt jest więc naprawdę płynny.

Widzę, że w chmurze jesteśmy w stanie zarówno zrobić rozwiązania na poziomie parunastu dolarów miesięcznie, co przy takich on-premisesowych rozwiązaniach jest raczej nierealne, a przynajmniej nie na pierwszy rzut oka – trzeba by to było odpowiednio przekalkulować. Z drugiej strony w chmurze bardzo łatwo stworzyć rozwiązanie za paręnaście tysięcy dolarów, które będzie kompletnie nieoptymalne i kompletnie się nie sprawdzi, a co więcej jeszcze będzie bardzo mocno zubażać portfel. Myślę, że wyważenie kosztów w chmurze i zaplanowanie architektury w taki sposób, żeby ona była kosztowo efektywna, jest trudne. W takim wypadku bardzo często lepiej zainwestować w porządnego konsultanta chmurowego, który za ułamek tej całej kwoty sprawdzi i przetestuje dane rozwiązanie – powie nam, że albo to jest coś, co warto zrobić, albo nie – niż usilnie starać się zrobić coś po swojemu. Z tego wynika niezrozumienie i czasem pretensje do chmury, że to jest niby tak proste i bardzo prosto ten suwaczek z kosztami wywindować w górę, a potem okazuje się, że bardzo trudno jest zjechać w dół.

Zatoczyliśmy koło, bo pewną korzyścią rozwiązań chmurowych było to, że nie potrzeba ludzi do zajmowania się infrastrukturą, a teraz okazuje się, że musimy się znać, bo te chmury stały się na tyle skomplikowane, tyle mamy tych różnych opcji do wyboru, że tu jest spory know-how do zdobycia, albo jednak potrzebujemy specjalisty od chmury, żeby nam pomógł.

To nie jest tak, że chmura niweluje kompletnie ten element, że tu trzeba pomyśleć i się zastanowić. Pewnie w jakimś stopniu przenosi ciężar tych kosztów z jednego miejsca w drugie. Tak jak mówiliśmy, pewnie przy odpowiednim zaplanowaniu pozwala nam się skupić na takim elemencie developmentu i rozwoju, a nie utrzymywania tego wszystkiego, co mamy.

Bardzo ciekawe informacje i sporo wartościowego know-how. Dzięki, Kamil, za rozmowę. Mam nadzieję, że do zobaczenia w „Stacji IT”!

Dzięki!