To jest 113. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o aplikacjach w chmurze publicznej.

Przypominam, że w poprzednim odcinku rozmawiałem o tym, jak przejść na wyższy poziom w programowaniu.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/113.

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut.

Nazywam się Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast.

Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły.

Jednocześnie bardzo dziękuję moim obecnym patronom.

Teraz życzę Ci już miłego słuchania.

Odpalamy!

 

Cześć! Mój dzisiejszy gość to Head of Software Development w Chmurze Krajowej, Cloud Architect i certyfikowany inżynier Google Cloud Platform. Posiada szerokie doświadczenie w tworzeniu aplikacji mobilnych i zarządzaniu projektami. Mentor i prelegent. 

Moim i Waszym gościem jest Mateusz Grzechociński.

Cześć Mateusz! Miło mi gościć Cię w podcaście.

 

Cześć! Dzień dobry, mnie również jest miło. Dziękuję za zaproszenie.

 

Przyjemność po mojej stronie. Z Mateuszem będę rozmawiał dzisiaj o połączeniu dwóch światów: aplikacji i chmury publicznej. O tym, jak można tworzyć, wykorzystywać, utrzymywać i rozwijać aplikacje w chmurze publicznej.

Standardowo rozpoczynam odcinek podcastu od pytania do mojego gościa. Czy słuchasz, Mateusz, podcastów? Jeśli tak, czy masz jakieś ulubione, którymi możesz się podzielić?

 

U mnie, pewnie jak u większości słuchaczy, to przychodzi falami i zależy od tego, ile posiadam czasu. Ostatnio, nie ukrywam, mam go dosyć mało, więc trochę tę praktykę zarzuciłem. Faktycznie w przeszłości słuchałem bardzo dużo podcastów, głównie o tematyce mobilnej, bo tym się przez ostatnie długie lata zajmowałem. Więc takie podcasty jak Fragmented Podcast czy Android Developers Backstage to były podcasty, których musiałem przesłuchać każdy odcinek, bo były dla mnie bardzo ciekawe. 

Teraz z racji mojej ostatniej historii i niejako zmiany obszaru zainteresowań i działania, słucham głównie oficjalnego podcastu Google Clouda, jak też Google Kubernetes Podcast. To z takich anglojęzycznych. Również anglojęzyczny, aczkolwiek z polskiej sceny, bo prowadzony przez mojego dobrego kolegę z dawnych czasów zawodowych Tomka Nurkiewicza, jest bardzo fajny podcast W 256 sekund o różnych technologiach, buzzwordach ze świata IT. Fajna formuła, bo – jak sam mówi – podczas mycia zębów można posłuchać i on stara się to wytłumaczyć. Nie trzeba dużo czasu na to poświęcać, także polecam.

 

Dokładnie: krótko, zwięźle i na temat. Z tego co słyszę, podcasty odgrywają znaczną rolę, jeśli chodzi o zdobywanie przez Ciebie wiedzy. Słuchasz namiętnie, można powiedzieć.

 

Tak, zdecydowanie. Kiedyś miałem bardzo dużo kontaktu z konferencjami, występowałem, jeździłem, słuchałem, oglądałem. Stąd głównie czerpałem wiedzę, z kontaktów zdobytych na tych konferencjach, bo to jest główna wartość z uczestnictwa w nich. Natomiast teraz z wiadomych względów wszystko się trochę zatrzymało. Konferencje online’owe to nie jest już to samo w mojej ocenie. Faktycznie, trochę ten ruch i chęć zdobywania wiedzy przesunęły się w stronę podcastów, bądź videoblogów czy materiałów szkoleniowych, które są wrzucane na YouTube’a.

 

Ok, rozumiem. Kiedy Cię przedstawiałem, mówiłem, że prowadzisz dział Software Development w Chmurze Krajowej. Zastanawiam się, czy w takiej firmie, która działa w obszarze chmury, Dział Rozwoju Oprogramowania jest potrzebny, niezbędny? Jakiego typu projekty software’owe realizujecie? Czy tylko wewnętrzne, czy może uzupełniacie też w jakiś sposób usługi świadczone dla klientów zewnętrznych usługami software’owymi?

 

Tak, to jest dosyć ciekawa historia, my też tak sądziliśmy. Jak przychodziłem dwa lata temu do pracy, to przychodziłem jako Cloud Architect, który po prostu będzie pomagał klientom w transformacji ich biznesu do chmury. Wtedy nie mieliśmy jako takiego zespołu zajmującego się software developmentem. Szybko się okazało, że nasi klienci nie tylko potrzebują platformy i fachowej wiedzy, jak się na tę platformę przenieść, ale czasami przychodzą do nas z konkretnym pomysłem.

Nasz zespół i zmiana organizacyjna w firmie powstała tak naprawdę z realnej potrzeby. Przychodziły do nas zapytania ofertowe, przychodzili do nas klienci, którzy nie chcieli po prostu kupić dziesięć sztuk maszyn wirtualnych i iluś terabajtów storage’u, tylko chcieli zrealizować swój pomysł na biznes i potrzebowali zrobić to szybko. Potrzebowali szybko coś zwalidować, sprawdzić, zbudować coś, co będzie się dobrze skalować. Mówiąc wprost, wykorzystać wszystkie zalety chmury. 

W sierpniu zeszłego roku powołaliśmy nową jednostkę w firmie, która zajmuje się praktyką – bo tak to nazywamy – wytwarzania oprogramowania. Dzielimy się na różne praktyki, a ja mam przyjemność tę prowadzić. Razem z moim fantastycznym zespołem doświadczonych inżynierów zajmujemy się pisaniem, tworzeniem oprogramowania na zamówienie dla naszych klientów. Przy czym z definicji to oprogramowanie jest uruchamiane w chmurze. Naszym celem jest oczywiście zaspokojenie potrzeb klienta i zrealizowanie jego celu, ale droga do niego wiedzie przez chmurę, bo wierzymy, że to jest najbardziej optymalny model tworzenia i dostarczania oprogramowania.

 

Naszym celem jest oczywiście zaspokojenie potrzeb klienta i zrealizowanie jego celu, ale droga do niego wiedzie przez chmurę, bo wierzymy, że to jest najbardziej optymalny model tworzenia i dostarczania oprogramowania. 

 

Tworzymy też oczywiście własne produkty. Mamy pomysł, który teraz realizujemy, na nasz wewnętrzny system multicloud, czyli coś w rodzaju panelu dla klienta, w którym będzie mógł zarządzać swoimi usługami. To jest akurat nasz wewnętrzny projekt, który rozwijamy. Ja pracuję raczej przy większych projektach dla naszych klientów.

 

Porozmawiajmy chwilę o rozwoju oprogramowania, masz mocny background związany z software developmentem. Z drugiej strony, na Twoim LinkedInie znalazłem informacje o licznych certyfikatach, głównie Google Cloud. Zastawiam się, jak to się stało, że zainteresowałeś się obszarem chmury publicznej. Jak Tobie i Twojemu zespołowi pomaga wykorzystanie chmury publicznej w rozwijaniu oprogramowania i jego dostarczaniu?

 

Całe zawodowe życie, czyli około piętnaście lat, byłem programistą, kiedyś backendowym. Jak pojawiły się pierwsze aplikacje mobilne, to pociągnęła mnie ta myśl, że to co piszę i to co robię mogę nosić cały czas przy sobie i mieć to w telefonie. Zająłem się głównie aplikacjami mobilnymi. Z czasem, razem z moimi zespołami, zacząłem budować duże, rozpoznawalne w kraju produkty, jedną z topowych aplikacji bankowości mobilnej, czy aplikację mobilną dla jednego z większych e-commerców u nas w Polsce. 

Po niemal dziesięciu latach zdałem sobie sprawę i poszedłem za taką maksymą, że  – może to trochę nieskromnie zabrzmi – jeżeli jesteś najlepszy w pokoju, to najpewniej czas zmienić ten pokój. Dwa lata temu pojawiła się szansa na sporą zmianę, inwestycję w siebie, pójście za nową rewolucją, która wydaje się, że miała nadejść i nadchodzi, czyli przejście na stronę związaną z technologiami chmurowymi. Oczywiście miałem jakieś doświadczenia z tym związane i z samego Google Clouda też wcześniej korzystałem. Ale wiadomo, że jak chce się tę wiedzę zgłębić, to trzeba sobie znaleźć jakąś motywację. 

Dla mnie najlepszą drogą do nauki i motywacją były faktycznie certyfikacje i egzaminy. Materiałów szkoleniowych jest tak dużo i są tak łatwo dostępne, że przygotowanie do egzaminów, wchłonięcie teorii, a potem możliwość utrwalenia tej wiedzy w praktyce, na prawdziwych projektach z możliwością gratyfikacji w formie tytułu na dwa lata, jest czymś przyjemnym i dającym motywację.

Czemu Google Cloud akurat? Wiadomo, że na rynku jest trzech głównych graczy. Od czegoś trzeba zacząć. Jako Chmura Krajowa jesteśmy strategicznym partnerem Google’a i Microsoftu. Wyznaję taką zasadę, że lepiej uczyć się czegoś jednego na poziomie eksperckim i w tym się dobrze wyszkolić i dopiero poszerzać swoje horyzonty, niż, mówiąc kolokwialnie, łapać wszystkie sroki za ogon. Ja akurat w przeszłości zajmowałem się bardzo dużo androidem, też wyznając tę zasadę, że wolę być ekspertem od Androida niż po prostu programistą mobilnym, który zna oba systemy. Na Androidzie tak szybko i często się wszystko zmieniało, że ostatecznie nawet te dziesięć lat mi nie starczyło na to, żeby zająć się kiedykolwiek na poważnie IOS-em.

 

Wyznaję taką zasadę, że lepiej uczyć się czegoś jednego na poziomie eksperckim i w tym się dobrze wyszkolić i dopiero poszerzać swoje horyzonty, niż, mówiąc kolokwialnie, łapać wszystkie sroki za ogon. 

 

Obawiam się, że tutaj będzie podobnie, bo tempo rozwoju Google Clouda i tego jak się tam wszystko zmienia jest naprawdę imponujące. Ale bliżej mi było po prostu do technologii Google’owych. Wydaje mi się też, że Google Cloud jest bardzo przyjazny osobom o moim profilu, czyli programistom. Jest bardzo dobra dokumentacja, łatwo przyswajalna, mnóstwo materiałów szkoleniowych. Mamy coś, co się nazywa Qwiklabs, czyli platformę, gdzie możesz eksperymentować ze środowiskiem bez większych konsekwencji. Są gotowe scenariusze, które możesz sobie ćwiczyć, testować. Jest w tej platformie i w całym ekosystemie łatwość w przyswajaniu wiedzy. Może ciężko to określić, trzeba tego spróbować, ale jest to wciągające i mobilizujące, żeby poznawać to jeszcze głębiej.

 

Coś co daje frajdę automatycznie powoduje, że jesteśmy w to zaangażowani. Połączenie umiejętności, które ty masz, czyli z jednej strony background programistyczny, a z drugiej skille związane z chmurą, to jest mocna rzecz. Myśląc w duchu DevOpsowym, połączenie różnych działów powoduje, że jesteśmy w stanie dostarczać oprogramowanie kompleksowo. O tych dwóch wątkach, tym związanym z oprogramowaniem i tym związanym z chmurą, będę dzisiaj z Tobą rozmawiał.

Chciałbym zacząć od nie tak bardzo technologicznego tematu. Mianowicie, jak najczęściej to oprogramowanie w chmurze dla klientów biznesowych działa? Myślę tutaj o modelu SaaS, który jest bardzo powszechnym modelem na dziś. Czy w Twojej opinii to jest optymalny model? Zarówno dla firmy, czyli klienta korzystającego z oprogramowania, jak i jego dostawcy, który może w chmurze takie oprogramowanie rozwijać i dostarczać.

 

Jak sięgam wstecz dziesięć, dwanaście lat, gdy pisaliśmy aplikacje backendowe dla jednego z telekomów, to siedzieliśmy razem z kolegami i pisaliśmy aplikację w Java Enterprise Edition. Budowaliśmy z niej plik binarny, który przekazywaliśmy do klienta i nikt z nas się wtedy nie zastanawiał, co się z tym dalej dzieje. Jak to jest, że to potem gdzieś ląduje, na jakimś środowisku jest uruchomione, działa, jest skonfigurowane – wszystkie aspekty sieciowe, bezpieczeństwa, certyfikaty, bazy danych, które pod spodem były potrzebne. Przekazywaliśmy to do klienta, czasami się używa takiego określenia, że programiści przerzucają coś przez mur i inni operatorzy muszą sobie z tym poradzić i jakoś to utrzymywać.

Dzisiaj, po tylu latach, nie jestem sobie w stanie wyobrazić, jak można dalej w ten sposób rozwijać. O przewadze podejścia SaaSowego, czyli właśnie oprogramowania jako usługi, świadczy najlepiej fakt uświadomienia sobie, ile na co dzień takich usług używamy: Gmail, Google Docsy, Teamsy, Goolge Meet, przez którego teraz nagrywamy, Microsoft 365. 

Dobrym przykładem jest Jira, którą miałem w jednej z poprzednich firm, czyli dosyć popularny issue tracker, myślę że praktycznie każdy go zna. Mieliśmy go w wersji on-premise, czyli zainstalowanej na serwerach w ramach naszej organizacji. Tę Jirę trzeba było aktualizować, utrzymywać, zapewniać odpowiednią infrastrukturę, żeby ona działała wydajnie. 

Jednocześnie Atlassian, czyli producent Jiry, już od jakiegoś czasu oferuje albo model wdrażania w ich data center, albo model wdrażania w ogóle w cloudzie. Wtedy my po prostu płacimy subskrypcję, mamy takie oprogramowanie jako usługę i wszelkie problemy z nas są zdejmowane. O przewadze takiego podejścia świadczy w przypadku Atlassiana fakt, że oni już jakiś czas temu ogłosili koniec Jiry on-prem i narzędzi on-prem. Wszystkie te narzędzia będzie można uruchamiać albo w ich data center albo w cloudzie.

W SaaSie fajne jest to, że ten kto potrzebuje software, po prostu może skupić się na swoim pomyśle. On się świetnie będzie sprawdzał tam, gdzie mamy pomysł na biznes i chcemy zapłacić za to, żeby ktoś nam taką gotową usługę dostarczył. Nie chcemy inwestować w infrastrukturę, zespoły do utrzymywania tej infrastruktury i wszystkich usług, z których będziemy korzystać. 

Moim zdaniem SaaS idzie w zgodzie ze światowym trendem subskrypcji, jaki obserwujemy w życiu. Dzisiaj wszystko jest na subskrypcje: dieta pudełkowa, samochody (najem długoterminowy), mamy subskrypcję na wymianę telefonu komórkowego po iluś miesiącach używania. Płacisz i nic więcej ma cię nie interesować niż to, co ta usługa dla ciebie robi. Pod spodem jest zespół wyspecjalizowanych osób, które tę usługę w obszarze IT czy innym dostarczają.

Z drugiej strony, odpowiadając na tę część pytania dotyczącą perspektywy dostawcy, dla mnie jako osoby, która razem z zespołem dostarcza taki software w modelu SaaSowym, bo my głównie w takim modelu to dostarczamy, to jest też szereg zalet. Jeżeli my możemy wziąć odpowiedzialność za całość rozwiązania i posiadać wszelkie narzędzia do realizacji tej usługi, to jest dla nas bardziej efektywne, bardziej komfortowe i też zwyczajnie przynosi więcej satysfakcji ludziom, którzy to rozwijają. Traktują to trochę jako swoje dziecko, które cały czas rozwijają, utrzymują, pielęgnują, doglądają i patrzą, jak ono rośnie. A w takim modelu, gdzie my po prostu coś piszemy, przekazujemy, klient to sobie uruchamia, utrzymuje, wdraża, to jest takie trochę porzucenie tych zalet i czasami jest zwyczajnie przykro.

 

Jeżeli my możemy wziąć odpowiedzialność za całość rozwiązania i posiadać wszelkie narzędzia do realizacji tej usługi, to jest dla nas bardziej efektywne, bardziej komfortowe i też zwyczajnie przynosi więcej satysfakcji ludziom, którzy to rozwijają. Traktują to trochę jako swoje dziecko, które cały czas rozwijają, utrzymują, pielęgnują, doglądają i patrzą, jak ono rośnie. 

 

Oczywiście ten model SaaSowy nie zawsze jest możliwy, w szczególności, jeżeli rynek jest bardzo uregulowany i nie można w ten sposób działać, że software jest uruchomiony w chmurze. To się ostatnio na szczęście zmienia i moja organizacja powstała między innymi po to, żeby ten świat i to postrzeganie trochę odczarować. Nie zawsze wszystko tak różowo wygląda, że możemy każdy software w trybie SaaSowym dostarczyć. Aczkolwiek ja, podsumowując, widzę w tym bardzo dużo zalet z obu perspektyw.

 

Myślę sobie, że jest taki jeden doskonały wabik, zarówno dla biznesu, jak i działów rozwijających, utrzymujących oprogramowanie, mianowicie obietnica skalowalności, jeśli chodzi o chmurę i aplikacje w niej działające. W naszym dzisiejszym globalnym Internecie nigdy nie wiadomo, kiedy przyjdzie jakaś fala użytkowników, którzy będą chcieli z oprogramowania, które my rozwijamy, skorzystać. Popatrzmy na sklepy w modelu e-commerce czy portale rządowe. W związku z tym, chciałem Cię zapytać, jakie możliwości skalowania daje nam chmura, w szczególności Google Cloud?

 

Akurat te dwa obszary, które wymieniłeś, czyli e-commerce i portale rządowe, to są takie obszary, w których faktycznie mam praktyczne doświadczenie. W e-commerce jedną z najtrudniejszych dat jest zawsze tak zwany Black Friday, poza oczywiście okresem świątecznym, ale on jest ogólnie trudny. Black Friday to jest ten moment, kiedy wszyscy kupują, są promocje, a infrastruktura jest taka, jak przez cały rok. Trzeba sobie z tym poradzić i jakoś te systemy wyskalować.

W portalach rządowych dobrym przykładem są wybory, które odbywają się raz na kilka lat, a musi być jakaś infrastruktura do systemów informatycznych, która zapewni odpowiednią wydajność i przede wszystkim niezawodność. Zwłaszcza w krajach, w których głosowania odbywają się w trybie online, nie tradycyjnym. Drugim dobrym przykładem są też szczepienia, gdzie mamy uwalniane kolejne roczniki i każdego dnia jest potrzeba wyskalowania się na odpowiednią liczbę osób. Potem w ciągu dnia, czy przez jakiś czas, kiedy obywatele się już zarejestrują, potrzebna nam moc obliczeniowa znacząco spada.

Skalowalność to jest ogólnie taka cecha chmury, przez którą ciężko mi sobie wyobrazić, jak można to robić inaczej, w tradycyjny sposób. W chmurze można skalować samodzielnie zarówno moc obliczeniową, jak i bazy danych. Zarówno wertykalnie, czyli podwyższając parametry danej maszyny, która dostarcza usługę, jak i horyzontalnie, czyli po prostu zwiększając liczbę tych maszyn. 

Możesz też skorzystać z rozwiązań serverlessowych, gdzie skalowanie odbywa się automatycznie i zwykle, tak jak w przypadku na przykład usługi Google App Engine czy Cloud Run, odbywa się to skalowanie do zera. Czyli nie tylko skalujemy się według zwiększonych potrzeb, zwiększonego zainteresowania naszymi usługami, ale też całkowicie redukujemy koszty i infrastrukturę, która dostarcza naszą usługę do zera, jeżeli nikt z niej na przykład w nocy, albo przez weekend nie korzysta.

Jak już się tak obcuje z tymi systemami i patrzy się, jak one funkcjonują i realizują te potrzeby w prawdziwym świecie, to prawdziwa magia zaczyna się wtedy, gdy faktycznie te systemy skalują się automatycznie. Nie jest potrzebny żaden operator, który musi patrzeć w wykresy, albo przewidywać, że coś się za chwilę stanie i odpowiednio pokręcić którymiś gałkami i przesunąć niektóre suwaczki, żeby ta infrastruktura się przeskalowała.

Są takie narzędzia, jak choćby Google Kubernetes Engine, który automatycznie monitoruje obciążenie na poszczególnych kontenerach, na poszczególnych podach i odpowiednio je przeskalowuje, dokłada ich. Jeżeli brakuje maszyn wirtualnych, na których te kontenery są uruchomione, to przeskalowuje cały klaster, czyli dodaje te maszyny, albo je redukuje. 

Innym przykładem są procesy ITIL-owe, które przenoszą dane z jednego miejsca w drugie, czyli na przykład usługa Data flow, która też pod spodem sama skaluje się do potrzeb i określa ile maszyn wirtualnych będzie jej potrzebnych, żeby dany proces wykonać.

Skalowanie to jest taka integralna cecha chmury, chyba największa jej zaleta, zwłaszcza w połączeniu ze świadomością braku ograniczeń, jeżeli chodzi o moc obliczeniową. To jest naprawdę fantastyczne. Oczywiście mówi się, że nie ma czegoś takiego jak chmura, jest tylko czyjś komputer. Ta moc obliczeniowa, która jest zlokalizowana w jakimś regionie czy w jakiejś zonie, w jakimś data center jednego czy drugiego dostawcy, też jest zawsze fizycznie ograniczona. Natomiast są to takie liczby i takie wartości, że my z naszego punktu widzenia myślimy, że to jest praktycznie nieograniczone.

 

Rozumiem. Ja na co dzień pracuję ze startupami i tam bardzo ważny jest jeden z parametrów biznesowych, czyli time-to-market. Czas od pomysłu w głowie foundera do dostarczenia gotowego, działającego pomysłu na rynek. Chmura jest tu bardzo przydatna, bo umożliwia wykonywanie licznych eksperymentów, tak zwanych NVP, w łatwy sposób, bez zbędnych inwestycji, zaczynając powoli. Chcę Cię zapytać, jak z Twojego doświadczenia i doświadczeń Waszych klientów wynika, z czym i w jaki sposób możemy eksperymentować tworząc aplikacje i opierając je o chmurę?

 

Chmura z mojej perspektywy to jest zestaw klocków do budowania różnych rozwiązań, mniej lub bardziej zaawansowanych, na różnym poziomie abstrakcji. Niektóre z tych kloców, tych usług to są jakieś podstawowe komponenty infrastruktury sieciowej, czy mocy obliczeniowej. Inne to są gotowe usługi wysokiego poziomu do rozpoznawania obrazów, czy przetwarzania mowy na tekst. Jeżeli zaczynasz eksperymentować, to czujesz się trochę, jakbyś budował coś z klocków Lego. Cała umiejętność i cała trudność polega na tym, żeby mieć wiedzę, jak to wszystko ze sobą połączyć, co ze sobą zadziała, co nie zadziała, jakie będą koszty i jakie są poszczególne parametry tych usług.

 

Chmura z mojej perspektywy to jest zestaw klocków do budowania różnych rozwiązań, mniej lub bardziej zaawansowanych, na różnym poziomie abstrakcji. Niektóre z tych kloców, tych usług to są jakieś podstawowe komponenty infrastruktury sieciowej, czy mocy obliczeniowej. Inne to są gotowe usługi wysokiego poziomu do rozpoznawania obrazów, czy przetwarzania mowy na tekst. 

 

Najważniejsze jest to, że każda z tych usług w Google Cloudzie ma swoje określone SLA, jest dojrzała, stabilna i można na niej polegać. Jeżeli cokolwiek w Google Cloudzie nie jest opatrzone etykietą GA, czyli General Availability, to jest to bardzo jasno wskazane w dokumentacji. To jest projekt, usługa czy rozszerzenie istniejącej usługi (jakaś jej część, podfunkcja) w fazie beta i jasno to widać. W przypadku budowania jakichś poważniejszych rozwiązań warto o tym pamiętać i się na takie usługi nie decydować, bo istnieje szansa, że one mogą się w dowolnej chwili zmienić.

Jako przykład mogę podać projekt z kwietnia zeszłego roku, gdy w Polsce zaczynała się pandemia. Jak teraz sięgam pamięcią do tego czasu, to straż miejska i policja jeździła i mówiła, żeby nie wychodzić z domu, jakby były jakieś czasy wojny. Było to straszne i zrodziła się wtedy taka koncepcja, żeby zbudować bardzo szybko rozwiązanie e-wizyty. Czyli takie, które będzie łączyło lekarzy pracujących zdalnie przez taki system do wideokonferencji z jakiego teraz korzystamy, z pacjentami, którzy podejrzewają u siebie objawy zakażenia koronawirusem. Wypełnią odpowiedni formularz, wpadną do kolejki, lekarz podejmie pacjenta z kolejki, ten pacjent dostanie powiadomienie, porozmawiają, pomoże mu, wystawi receptę i tak dalej.

To był projekt, który powstał w trzy tygodnie, z ręką na sercu. To były bardzo intensywne trzy tygodnie, bez chmury na pewno byśmy sobie nie poradzili. Tak jak mówię, w chmurze jest bardzo dużo różnych usług, my na przykład wtedy skorzystaliśmy z gotowej usługi do uwierzytelniania użytkowników. Gdybyśmy musieli ją pisać sami, zajęłoby nam to pewnie kolejne dni, jeśli nie tygodnie. Tutaj mamy gotową usługę, która spełnia określone wymagania bezpieczeństwa, którą mogliśmy akurat w tym konkretnym projekcie użyć i użyliśmy. Dzięki temu mogliśmy skupić się na tym, co było core’em tego biznesu, a nie na tym, żeby po raz kolejny implementować mechanizm logowania do tego czy innego systemu.

 

Teraz chciałbym Cię zapytać o Twoje preferencje, bo wiem, że są przynajmniej dwie szkoły w tym temacie. Powiedzmy, że zaczynasz nowy projekt software’owy oparty o chmurę. Jakie podejście jest Ci bliższe: agnostyczne, jeśli chodzi o dostawców chmury, czy może skupiasz się na jednym konkretnym dostawcy i wykorzystujesz konkretne usługi tego providera? Które z tych podejść jest Tobie bliższe, które preferujesz, które według Ciebie jest lepsze?

 

My jako firma mamy dwóch strategicznych partnerów, którzy są dostawcami chmury publicznej, czyli Google Cloud i Microsoft Azure i większość projektów obecnie uruchamiamy akurat na tej pierwszej platformie, czyli na Google Cloudzie, bo ją aktualnie przy tym naszym młodym jeszcze zespole znamy lepiej, w związku z czym ten time-to-market jest najszybszy.

Są w firmie eksperci od tej drugiej chmury publicznej, z którymi wymieniamy się doświadczeniami. Jesteśmy dosyć młodym zespołem, z czasem na pewno któryś kolejny projekt, który będziemy realizować, uruchomimy też na Azurze. Ostatecznie usługi i providerzy są do siebie bardzo podobni, często to jest naprawdę kwestia nazwy danej usługi, czy jakichś tam konkretnych detali.

Oczywiście w kwestii samego modelu deploymentu pewnym standardem jest już konteneryzacja, która z założenia daje nam przenaszalność. Jeżeli uruchamiamy to na Kubernetesie, to staramy się używać takich właściwości Google Kubernetes Engine, które nie są bardzo specyficzne dla Google Clouda i pozwalają nam, przynajmniej teoretycznie, na migrację w krótkim czasie na inną konkretną platformę chmurową.

Z bazami danych jest trochę inaczej, zależy jakiej używamy. Jeżeli używamy serwera PostgreSQL czy MS SQL, to w zasadzie u obu tych dostawców ta usługa istnieje w formie PaaSa, czyli platformie jako usługi. Cloud Spanner na przykład jest usługą i bazą rozproszoną, bardzo wydajną, ale jest też specyficznym produktem Google’owym i migracja z tego Spannera nie jest czymś niemożliwym (przechodziliśmy to w jednym projekcie, była to kwestia kilku dni, żeby kilka zapytań dostosować i przepisać), ale też nie jest od tak do zrobienia w jeden dzień. Nie ma co się czarować.

 

Jasne, rozumiem. Tak sobie myślę, że dla tych działów, które zajmują się rozwijaniem oprogramowania, później też utrzymaniem, oprócz tych oczywistych zalet związanych z łatwością uruchomienia, skalowalnością, o czym już mówiłeś, istnieje też taka grupa zalet pod tytułem: ułatwienie pisania i testowania oprogramowania. Zacząłeś też chwilę o tym mówić. Jak w tych działach, w których pracujesz, którymi kierujesz wykorzystujecie chmurę w software developmencie?

 

Może zacznę od tego, że gdy rozwijamy jakieś oprogramowanie i dostarczamy je w chmurze, z definicji mamy nie tylko środowisko produkcyjne, czyli to, na którym faktycznie je dostarczamy do klienta, ale też środowisko testowe i deweloperskie. Zwykle to są trzy środowiska. Testowe jest przeznaczone dla klienta, jest już takie bardziej integracyjne, zwykle jest też wierną kopią konfiguracyjną środowiska produkcyjnego, żeby wykluczyć ewentualne problemy po wdrożeniu na produkcję. Środowisko deweloperskie jest bardziej dla nas do eksperymentowania, mniej stabilne. 

Co najważniejsze, co do zasady, wszystkie środowiska tworzymy z kodu. To jest taki mój osobisty konik, bardzo się w tym temacie lubię rozwijać i go zgłębiać. Świadomość, że mogę jedną komendą tu i teraz postawić ponad dwieście różnego rodzaju usług w danym projekcie w GCP, które stworzą mi po kilkunastu minutach w pełni działające, kompletne, gotowe do deploymentu aplikacji środowisko, to jest coś naprawdę fascynującego.

 

Świadomość, że mogę jedną komendą tu i teraz postawić ponad dwieście różnego rodzaju usług w danym projekcie w GCP, które stworzą mi po kilkunastu minutach w pełni działające, kompletne, gotowe do deploymentu aplikacji środowisko, to jest coś naprawdę fascynującego. 

 

Tworzenie takich środowisk z kodu zapewnia to, że możesz ich robić dużo, w zasadzie w nieograniczonej liczbie, jeżeli chodzi o zasoby chmury, tak jak już mówiliśmy. Dla mnie, co ważniejsze, zapewnia też niezaprzeczalność i homogeniczność tych środowisk. To znaczy jeśli one są tworzone dokładnie z tej samej definicji, dokładnie z tego samego kodu, to my praktycznie nie spotykamy się z takimi problemami, że błędy wynikają z tego, że load balancer jest źle skonfigurowany, na środowisku testowym inaczej niż na środowisku produkcyjnym i w związku z czym coś, co działało na teście nie działa na produkcji. 

To jest po prostu fizycznie niemożliwe, my tę infrastrukturę w kodzie wzmacniamy też podejściem GitOps, czyli wszelkie zmiany do infrastruktury traktujemy jako zmiany do prawdziwego kodu biznesowego naszej aplikacji. Podlegają one w praktyce code review, czyli ktoś przegląda tę zmianę, dyskutujemy o niej, wersjonujemy ją, podlega ona audytowi, wiemy co kiedy się zmieniło i w jakiej wersji. Możemy kontrolować propagacje tych zmian, czyli mieć część zmian wdrożonych już na środowisku deweloperskim, a część zmian jeszcze oczekujących i nie wdrożonych na środowisku testowym. To jest pierwsza rzecz, taka infrastruktura w kodzie na pewno się przydaje do rozwoju oprogramowania.

Druga rzecz to jest fakt, że w chmurze trzymamy też sam kod źródłowy, czyli znowu traktujemy Gita jako usługę, nie musimy go utrzymywać, rozwijać, upgrade’ować, tylko po prostu mamy do tego gotową usługę. W chmurze mamy też procesy CI/CD czyli Continuous Integration, Continuous Delivery czy Continuous Deployment. Nikt się nie przejmuje zbyt małą wydajnością serwera do budowania aplikacji. Po prostu powołujemy swojego runnera, maszynę, która jest o dowolnej, nieograniczonej mocy. Ograniczają nas jedynie koszty takiej maszyny i musimy to jakoś kontrolować. 

Także nie tylko to środowisko produkcyjne i już ten końcowy efekt, ale też zwykły warsztat programistyczny też bardzo dużo czerpie z tego, że aplikacja jest tworzona w środowisku chmurowym. 

 

Przypuszczam, że całe testowanie też odbywa się na tych środowiskach powoływanych za pomocą chociażby kodu opisującego infrastrukturę, tak jak powiedziałeś. 

Wcześniej mówiłeś o takich doświadczeniach, myślę że wielu słuchaczy też się pod tym podpisze, że kiedyś programiści skupiali się na tym, żeby faktycznie ten kod wyprodukować, natomiast mniej byli zainteresowani, mniej wiedzy mieli na temat, jak to się dzieje, że ten kod później na produkcji działa. Wydaje się oczywiste, że stworzenie aplikacji i uruchomienie jej to dopiero pierwszy krok. Później trzeba tę aplikację utrzymywać, trzeba w jakiś sposób ją monitorować, sprawdzać, czy nie ma incydentów bezpieczeństwa. Czy tutaj chmura też oferuje możliwości, jakieś rozwiązania? Czy w Google Cloud mamy coś, co ułatwia nam utrzymanie aplikacji?

 

Tak, jak najbardziej. Temat monitoringu i zapewnienia jakości i dostępności usług to jest mój kolejny konik, zaraz po infrastrukturze w kodzie. W tym obszarze Google Cloud, mam wrażenie, dosyć mocno błyszczy. W poprzedniej firmie miałem dział operatorów, u których w pokoju było więcej monitorów niż ich samych tam siedziało. Zawsze czułem jakąś ekscytację, kiedy wchodziłem do nich o czymś porozmawiać i widziałem na tych wykresach żywy organizm, nad którym każdego dnia dziesiątki ludzi z całego departamentu rozwoju oprogramowania pracowały. Oni widzieli na monitorach, kiedy ruch się zwiększa, kiedy spada, to jest naprawdę fajne zwieńczenie pracy, móc to na żywo obserwować.

Dziś w swoim zespole nie mam jako takich dedykowanych operatorów. Zgodnie z filozofią DevOps zasypujemy te podziały i każdy z nas, każdy z programistów, inżynierów, bo to już nawet ciężko się nazywać programistami, potrafi ten system monitorować, diagnozować problemy przy użyciu narzędzi, jakie chmura dostarcza. Jak sięgam pamięcią parę lat wstecz, to żeby zobaczyć logi produkcyjne musiałem iść do administratora, do drugiego pokoju i patrzeć przez jego ramię, na mały monitor, na którym przelatywały setki logów na sekundę, wszystkie w tym samym kolorze, w żaden sposób nie odseparowane i trzeba było umieć coś z tego wywnioskować.

Dzisiaj jest gotowa usługa Cloud Logging, akurat na Google’u, która po prostu agreguje logi ze wszystkich systemów i traktuje je jako ogromną bazę danych, zbiór, który można przeszukiwać pisząc dowolne zapytania. Na tych logach można potem robić metryki, czyli na przykład ile wystąpiło logów, które spełniły dane kryterium wyszukiwania w jednostce czasu. Albo jaka jest średnia wartość typu opóźnienie z jakiegoś loga, który się wyświetla. Możesz wyrażeniem regularnym wydobyć z loga tę wartość i ją monitorować. Na metrykach można potem zrobić wykresy i w usłudze Cloud Monitoring układać je w dashboardy i je prezentować.

Możesz też przy pomocy Cloud Monitoringu na metrykach zrobić dowolne alerty. Poza zwykłą, najbardziej domyślną i oczywistą formą reagowania na alert, czyli powiadomieniem na Slacku, e-mailowym czy SMS-owym, możesz też stworzyć, wyemitować zdarzenie i zapiąć się na tym zdarzeniu, dzięki czemu możesz stworzyć pewien mechanizm. Jeżeli baza danych, CPU na bazie danych wzrosło do jakiegoś poziomu i utrzymuje się przez jakiś czas na tym poziomie, to możesz wygenerować zdarzenie, które odbierze inna usługa i przez API tej bazy danych przeskaluje ją na większą wertykalnie, aby przez chwilę tę nadwyżkę ruchu obsłużyć i wartość CPU obniżyć.

Fascynujące jest to, że mamy dzisiaj do dyspozycji gotowe narzędzia, które umożliwiają nam rzeczy kilka lat temu dla zwykłego programisty będące abstrakcją. W ogóle się tym nie przejmowaliśmy, ufaliśmy, że ktoś o to zadba i że ktoś to zrobi, a w przypadku, gdy pojawiały się jakieś problemy, to następowała taka naturalna mini wojna: czyja to wina i kto jest odpowiedzialny za naprawę za jakiegoś problemu.

Incydenty bezpieczeństwa, bo o nie też pytałeś, monitoring bezpieczeństwa i w ogóle aspekt bezpieczeństwa, zwłaszcza tutaj w GCP, to jest chyba temat na osoby podcast. Moglibyśmy bez problemu zrobić osobny odcinek. Dość powiedzieć, że w naszej pracy standardem jest to, że wykonanie zapytania na produkcyjnej bazie danych, odczytanie jakichś sekretów z vaulta czy security managera lub uruchomienie maszyny wirtualnej na produkcji, jest natychmiast zgłaszane do odpowiedniego SIEM-a. Mamy taki dział operatorów w firmie po prostu, poza moim zespołem, który monitoruje tego SIEM-a i ci ludzie od razu weryfikują, czy nie są to działania niepożądane i musimy autoryzować takie dostępy. 

Dużo się o tym mówi, że dostawcy chmur publicznych nie mogą sobie pozwolić na to, żeby były jakiekolwiek incydenty bezpieczeństwa, bo to oznacza w zasadzie koniec danej platformy chmurowej. Ja osobiście, jako osoba, która na co dzień dużo z tej chmury korzysta, mogę powiedzieć wszystkim słuchaczom, którzy będą zaczynać tę przygodę, że to, że czasami coś nie działa, na dziewięćdziesiąt dziewięć procent wynika z tego, że nie ma uprawnień albo jest coś nie tak z rolami lub tego typu rzeczami. Nie pamiętam teraz konkretnej liczby, ale w Google Cloudzie jest bodajże trzy tysiące różnego rodzaju uprawnień do różnych rzeczy. Osobnym uprawnieniem jest uprawnienie do startu maszyny wirtualnej, a osobnym do jej zatrzymania. Te uprawnienia można agregować w role, role można przypisywać do konkretnych osób albo do konkretnych grup. Elastyczność tych rozwiązań jest tak duża, że moglibyśmy o tym jeszcze bardzo długo rozmawiać.

 

Wspomniałeś o pandemii, która wiele rzeczy wymusiła i przyspieszyła. Jedną z takich rzeczy było przejście wielu firm na działalność online, a nawet tylko online. Dla tych firm niedostępność w sieci jest czymś, co nie może się wydarzyć, bo to oznacza, że taka firma realnie nie działa. Czy w rozwiązaniach chmurowych, które znasz, mamy jakieś konkretne mechanizmy, które pozwalają nam na zwiększenie albo wręcz zagwarantowanie niezawodności aplikacji, które są uruchamiane w chmurze? Tak żeby to nie wymagało osobnego działu monitoringu, o którym mówiłeś, i osobnej grupy ludzi, która na bieżąco cały czas sprawdza stan aplikacji. 

 

Zacznijmy może od tego, że w Google Cloudzie każda usługa ma bardzo jasno określoną gwarancję swojej dostępności. Jest tylko jedna usługa, Cloud DNS, która posiada dostępność na poziomie sto procent. To znaczy Google określa, że jeżeli ta usługa nie będzie działać i zostaną spełnione określone warunki, to zgodnie z SLA, klient może upomnieć się o zadośćuczynienie finansowe, jeżeli ta usługa nie spełni tej dostępności. Inne usługi to są zwykle trzy dziewiątki, cztery dziewiątki, pięć dziewiątek i tak dalej. Więc zawsze istnieje jakieś ryzyko, że któryś z komponentów będzie niedostępny. Tak jak mówiliśmy, nie ma czegoś takiego, jak chmura, to też jest jakaś infrastruktura, od czegoś zależna. Ona jest zwykle redundantna, natomiast zawsze jakieś awarie mogą wystąpić.

Google bardzo transparentnie informuje o takich incydentach, zdarzały się nam one oczywiście czasami, widać je wtedy w konsoli. Zawsze jest dostępny support, można zakładać takie tickety z różnymi priorytetami, gdzie istnieje gwarancja odpowiedzi i podjęcia działań w określonym czasie. Z doświadczenia takiego kluczowego projektu, nad którym teraz pracujemy mogę powiedzieć, że nic szczególnego się przez te kilka miesięcy nie dzieje, żeby nie powiedzieć, że w ogóle nie mieliśmy żadnych problemów związanych z samą infrastrukturą chmurową. 

Kluczowa jest przede wszystkim odpowiednia architektura naszego rozwiązania. To jest właśnie powód, dla którego my polecamy swoje usługi klientom, dla których my w ogóle istniejemy.Wiemy jak ułożyć tę architekturę aplikacji i całego rozwiązania, aby była ona możliwie odporna na ewentualne awarie po stronie dostawcy. Usługi w zależności od typu są albo zonalne, czyli takie strefowe, albo regionalne czy nawet multiregionalne. 

 

Kluczowa jest przede wszystkim odpowiednia architektura naszego rozwiązania. To jest właśnie powód, dla którego my polecamy swoje usługi klientom, dla których my w ogóle istniejemy. Wiemy jak ułożyć tę architekturę aplikacji i całego rozwiązania, aby była ona możliwie odporna na ewentualne awarie po stronie dostawcy. 

 

Ze względu na lokalizację przyjmuje się, że zniknięcie danej strefy, danej zony jest możliwe wskutek katastrofy, wybuchu czy totalnego pożaru data center. Natomiast zniknięcie całego regionu, w skład którego wchodzą zwykle trzy albo nawet cztery zony, to jest coś, co musiałoby już oznaczać naprawdę potężny atak militarny czy ogromną katastrofę naturalną. 

Nawet wtedy zostają nam usługi multiregionalne, czyli redundantne względem regionów. Możemy mieć usługę, która jest powołana na przykład w nowym regionie w Warszawie, jakiś storage, ale równolegle ten sam storage i pliki, które się na nim znajdują są redundantne w innym regionie, na przykład w Holandii, Londynie czy w ogóle na innym kontynencie. 

Także ważna jest architektura, umiejętność dopasowania usług w zależności od tego jak bardzo ten system ma być dostępny, kluczowy jest również monitoring, wszelkie health checki, uptime checki, alerty. Nie tylko o braku zdarzeń niepożądanych, ale też alerty o tym, że nie ma zdarzeń pożądanych, czyli że w systemie nic się z jakiegoś powodu nie dzieje, nie ma żadnego ruchu – to niekoniecznie jest dobra oznaka. Dla przykładu brak odpowiedzi z health checka, który cyklicznie odpytuje usługę backendową na load balancerze, automatycznie przełącza ruch do innej usługi. To się dzieje całkowicie bezobsługowo, my nawet nie musimy tego jakoś szczególnie monitorować. To wszystko można tworzyć właśnie w usłudze Cloud Monitoring, o której wspominałem. 

 

Rozmawialiśmy o technikaliach, ale jeśli chodzi o działania aplikacji w chmurze, to jest też ta część finansowa. Coraz częściej pojawia się takie określenie jak FinOps, czyli różne optymalizacje, różne aspekty monitorowania tego, ile nas tak naprawdę ta chmura kosztuje. Doskonale zdajemy sobie sprawę, że rozwiązania chmurowe mogą nam znacząco obniżyć koszty, ale jeśli nie wiemy, co robimy, to może to zadziałać wręcz odwrotnie. Jak to wygląda w Google Cloud, czy są jakieś mechanizmy do tego, żeby trzymać koszty pod kontrolą?

 

Jak najbardziej tak. Koszty mogą oczywiście poszybować do niebotycznych rozmiarów i warto to kontrolować. Dla przykładu podstawowa maszyna w nowym regionie w Warszawie, która ma dwa procesory i około sześciu, siedmiu gigabajtów RAMu, kosztuje trzydzieści dwa dolary miesięcznie. Ale maszyna, która będzie miała osiemdziesiąt core’ów i będzie powołana nie w Warszawie, ale na przykład w regionie w Zurychu, w Szwajcarii, kosztuje już dwa i pół tysiąca dolarów za miesiąc.

Teraz wystarczy, że powołamy taką maszynę i zapomnimy ją wyłączyć na kilkanaście dni czy na cały miesiąc i faktycznie tę fakturę otrzymamy. To był tylko przykład z obszaru Google Compute Engine, czyli takiej najbardziej surowej infrastruktury maszyn wirtualnych i sieci. Z mojego doświadczenia widzę, że najbardziej, mówiąc kolokwialnie, można popłynąć w kosztach z narzędziami do machine learningu. Trenowanie modeli, hostowanie ich jest dosyć kosztowne, ale też warto podkreślić, że infrastruktura, która pod spodem jest wykorzystywana, jest naprawdę wyjątkowo potężna. To w jakim czasie te modele są przeliczane, jak szybko to wszystko działa powoduje, że musimy za to odpowiednio zapłacić. Są różne techniki, jak to optymalizować. Mamy u nas w firmie praktykę Data AI i tam koledzy się specjalizują w tych tematach.

Jak kontrolować koszty? Jest szereg narzędzi. Przede wszystkim dobrze jest umieć na początku oszacować, ile to wszystko będzie kosztować i bardzo fajna jest filozofia transparentności Google’a w tym obszarze. Istnieje ogólnodostępne w Internecie, darmowe narzędzie do tego, czyli Google Pricing Calculator. Możemy tam wyklikać całą naszą infrastrukturę, powiedzieć jakie będziemy mieli maszyny, jaką bazę danych, przez jaki czas, jaki klaster Kubernetesa, jak często używany, up engine i ile czasu będzie się skalował do zera, a ile instancji będzie żyło w jakim czasie. To wszystko jest zbierane, szereg parametrów jakie określimy.

Oczywiście jest to tylko estymacja, jakieś przybliżenie, natomiast daje taki ogólny pogląd na to, ile dana usługa będzie nas kosztować. Warto pamiętać o tym, że zwykle nie zamykamy się na jednym środowisku, tylko na kilku, więc trzeba sobie te koszty przemnożyć. Nie zawsze dokładnie tak samo, bo środowisko deweloperskie zwykle może być trochę mniejsze niż produkcyjne, ale testowe zawsze staramy się, żeby było takie samo jak produkcyjne. Warto umieć to oszacować.

Druga rzecz to umiejętność monitorowania. Do tego też są narzędzia, takie jak budżety. Możemy skonfigurować budżet na dany projekt albo na dany billing account, czyli takie konto, do którego są podłączone różne inne projekty i określać jaki maksymalny miesięczny budżet możemy wydać na projekty, które są do niego podłączone. Można stworzyć alerty, na przykład przy pięćdziesięcioprocentowym osiągnięciu tego budżetu, siedemdziesięcioprocentowym i tak dalej, progów możemy tworzyć dowolnie dużo.

Warto tylko pamiętać, że taki alert absolutnie nie powoduje, że ten spend, to wydawanie pieniędzy się zatrzymuje, to zależy od nas. Często jako przykład podaje się, że jeżeli budujemy jakiś startup, o którym tu wspomniałeś i ten startup nagle zacznie się cieszyć jakąś ogromną popularnością, kolejny Pokemon Go, to dostawca chmury nie może z racji tego, że ktoś zrobił budżet odciąć finansowania i zamknąć infrastruktury. Ryzyko jest przeniesione na stronę właściciela. Oczywiście istnieją narzędzia, my na przykład z czegoś takiego korzystamy, że można wyemitować zdarzenie, to zdarzenie gdzieś odebrać i napisać kawałek kodu, który obierze to zdarzenie i jednak odetnie projekty od billing accountu, żeby więcej tego spendu nie ograniczać.

Jeszcze dwa aspekty w kontekście budżetu. Pierwszy to są rekomendacje dla bardziej zaawansowanych klientów, którzy dłużej korzystają z chmury. Google zgodnie z transparentnością bardzo fajnie pokazuje, że na przykład ta maszyna wirtualna działała przez ostatnie kilka dni i była przeszacowana. To znaczy jest za mocna w stosunku do tego co realizuje, więc najprawdopodobniej możesz wziąć mniejszą, a co za tym idzie tańszą. 

Warto też wspomnieć o filozofii rabatów i naliczania sekundowego, czyli usługi które działają, na przykład maszyny wirtualne, są w naliczaniu sekundowym. Jeżeli ta maszyna działa i ją wyłączymy ją po pewnym czasie, to płacimy już tylko za to, ile sekund po tym czasie działała, a nie za kolejną minutę czy godzinę. Praktycznie każda usługa ma tak zwany free tier. Cloud Function na przykład, serverlessowa usługa do uruchamiania funkcji, ma taką opcję, że dajmy na to pierwsze dwa miliony wywołań funkcji jest za darmo, płacimy dopiero za kolejne. 

To wszystko widać potem na billingu, to jest bardzo jasno pokazane i nie jest tak, że przychodzi do nas faktura i łapiemy się za głowę, ponieważ nie wiemy z czego te koszty wynikają. Naprawdę jesteśmy w stanie zrobić taki drilldown do konkretnych usług albo nawet części tych usług, które wygenerowały koszty.

 

Myślę, że bardzo uczciwe i fair podejście. Jestem zdania, że najlepiej jest się uczyć na konkretnych przykładach, konkretnych wdrożeniach, dlatego chcę Cię teraz zapytać o system, który powstał z Waszym udziałem w bardzo krótkim czasie, z takim zadaniem obsłużenia większego ruchu, myślę tutaj o e-rejestracji. Chciałem Cię zapytać jak ten system powstał, z jakich komponentów murowych się składa? Jeśli jesteś w stanie coś powiedzieć, myślę że to dałoby jakieś przybliżenie, jakie są możliwości realizacji, szybkiego wdrożenia aplikacji z wykorzystaniem chmury.

 

Faktycznie pod koniec zeszłego roku, gdy pojawiły się pierwsze doniesienia medialne o zbliżającym się dopuszczeniu do użytku pierwszych szczepionek na świecie, dostaliśmy taką prośbę o pomoc w stworzeniu centralnego systemu, który miałby łączyć obywateli, którzy będą się chcieli szczepić i wziąć w ten sposób udział w Narodowym Programie Szczepień z kilkoma tysiącami punktów szczepień, jakie będą działały i kilkudziesięcioma pracownikami w tych punktach szczepień, którzy każdego dnia tworzą i obsługują swoje grafiki i cały proces szczepienia pacjentów.

Chmura, tak jak w przypadku e-wizyty, na pewno bardzo tutaj pomogła. Kluczowe były dla nas dwa aspekty, przede wszystkim bezpieczeństwo całego rozwiązania, bo jednak mówimy o bardzo dużej skali oraz time-to-market z oczywistych względów. Nikt nie zaakceptowałby faktu, że szczepionki są, przyjechały do Polski, ale system informatyczny będzie tworzony przez najbliższy rok i w zasadzie tych szczepionek nie można zużyć. Cały system powstał w kilka tygodni, w wyniku ogromnej tytanicznej wręcz pracy całego mojego zespołu. 

Nigdy nie powiem, że taki system powstaje dzięki chmurze, bo powstaje dzięki ludziom i dzięki ich zaangażowaniu i przede wszystkim ich wiedzy. Natomiast chmura jest tu narzędziem, elementem, którego trzeba odpowiednio użyć i narzędziem, które wyjątkowo dobrze nadaje się do użycia, akurat w tego typu przedsięwzięciu. Nie wyobrażam sobie stworzenia tego typu systemu, o tej skali i w takim czasie bez użycia chmury. System przetwarza w każdej sekundzie kilka tysięcy operacji bazodanowych.

Tak jak mówiłem, system obsługuje dziesiątki tysięcy pracowników punktów szczepień oraz obsługuje wszystkie kanały umawiania się, a jest ich kilka. Można umawiać się przez aplikację pacjenta, czyli samodzielnie, można się umawiać przez infolinię, gdzie jest bardzo duża grupa konsultantów, którzy odbierają telefony, a przed sobą mają tak naprawdę ten sam system. Jest kanał do umawiania się przez SMS-y i jest kanał do umawiania się przez IVR-a, czyli bota, który odbiera telefon i proponuje termin, a my wybierając z klawiatury numer, daną cyfrę, potwierdzamy, czy ten termin przyjmujemy, czy chcemy jakąś inną propozycję.

Oczywiście nie mogę mówić o szczegółach technicznych tego przedsięwzięcia, to fajne wyzwanie i bardzo się cieszę, że przypadł nam zaszczyt i możliwość rozwijania tego systemu, bo skala jest dla nas wszystkich bardzo imponująca i motywująca do tego, żeby przejść i przeprowadzić cały kraj przez program szczepień suchą stopą.

 

Bardzo potrzebna, niezbędna wręcz rzecz i stworzona w rekordowo krótkim czasie, więc to pokazuje możliwości narzędzi, które gdzieś pod spodem stoją. Co by nie było, to jednak jest praca, takie codzienne zaangażowanie w rozwój tych systemów. Tak jak stwierdziłeś, nie możemy powiedzieć, że to chmura coś za nas realizuje, to jest jak każde inne narzędzie i to od nas zależy, jak je wykorzystamy.

W takiej codziennej pracy albo w projektach, które realizujesz dla klientów, coś Cię szczególnie zaskoczyło, jeśli chodzi o Google Cloud, czegoś się nie spodziewałeś? Może jakieś szczególne zastosowania, które utkwiły Ci w pamięci?

 

Zaskoczyły mnie na pewno dwie rzeczy. Pierwsza to jest efekt skali, zwłaszcza kiedy opuściłem świat aplikacji mobilnych, który jednak jest trochę hermetyczny. Człowiek przez cały dzień patrzy się w telefon, klika po ekranie, testuje aplikacje, cieszy się nimi, ale trochę nie ma takiego bezpośredniego wrażenia, ile pod spodem jest tej backendowej infrastruktury, która wystawia wszystkie usługi dla tej aplikacji mobilnej. W Google Cloudzie, operując konsolą czy stawiając tę infrastrukturę w kodzie z Terraformem, na każdym kroku przekonujemy się, jak olbrzymia jest ta skala. 

Dla przykładu podam, że w ramach regionu istnieje domyślny limit dwudziestu czterech procesorów w maszynach wirtualnych, jakie powołujemy. Czyli możemy stworzyć dowolną konfigurację, ale nie możemy wyjść poza ten limit. Są to tak zwane quoty i je można zmieniać, wymagane jest złożenie takiego wniosku przez konsolę. W jednym z naszych projektów oczywiście potrzebowaliśmy więcej mocy obliczeniowej niż te dwadzieścia cztery core’y w ramach regionu, więc grzecznie kliknąłem, że chciałbym zmienić te quoty. Napisałem, może nie elaborat, ale dosyć długie uzasadnienie, że piszemy dosyć ważny system, będziemy potrzebowali więcej mocy obliczeniowej i jakby się dało, to grzecznie poprosimy. Z tych dwudziestu czterech core’ów poprosiłem o dwieście, czyli w zasadzie dziesięć razy więcej. Oczekiwałem, że jak kliknę submit, to zaraz ktoś zadzwoni, zapyta, czy ja to ja i tak dalej. Natomiast w zasadzie dokładnie w momencie, w którym kliknąłem submit, dostałem maila, że ta quota została mi przyznana i od teraz mogę zrobić maszyny, które w sumie mają dwieście core’ów. Więc pierwsza rzecz, to jest ten efekt skali i możliwości, jakie ta chmura daje.

Druga to jest pricing, już trochę o tym mówiliśmy, ale w sumie jestem zaskoczony, że jeżeli jest ta architektura jest robiona z głową, to koszty są dosyć niskie w stosunku do tego, ile tak naprawdę kosztuje prąd, klimatyzacja, serwery i ludzie. Często w rozmowach z klientami spotykamy się z takim naturalnym sposobem porównywania, że w tej chmurze będzie drogo, bo u nas jedna osoba siedzi, dogląda i to wszystko działa. Ale jakby zebrać wszystko razem, całą infrastrukturę i jej koszty, wynajęcia podłogi w serwerowni, zapłacenia rachunku za prąd, serwisu klimatyzacji i tak dalej, to się okazuje, że to nie są aż tak duże pieniądze. Fajna jest też taka zwykła uczciwość i transparentność. Mówiłem o tych rekomendacjach, w których Google pokazuje, że można coś robić taniej niż obecnie mamy to za setupowane. Także to tyle z rzeczy, które mnie zaskoczyły. 

Jeśli chodzi o nietypowe zastosowanie, bo też o to pytałeś, to chwilę o tym teraz myślałem i wydaje mi się, że taki rynek bardzo regulowany, na przykład finansowy w Polsce, gdzie wymagana jest zgodność z tak zwanym komunikatem KNF-u. Mam osobiste doświadczenia z wdrażania projektu, w którym dane musiały być szyfrowane kluczem dostarczanym z zewnątrz, w którym komunikacja między systemami musiała się odbywać bezpiecznym kanałem, w którym były pewne rygorystyczne wymogi bezpieczeństwa, a jednak udało się taki projekt wdrożyć. To nie powinno brzmieć jako coś nietypowego, jako nietypowe zastosowanie chmury, tylko wręcz typowe, mam nadzieję w ciągu najbliższych lat tak będzie. Na razie jest to mimo wszystko coś, co daje satysfakcję, że nie tylko taki otwarty rynek, startupowy może się migrować do chmury, ale też ten rynek taki bardziej regulowany.

 

Na koniec chciałbym Cię zapytać, jak oceniasz poziom adopcji chmury w Polsce, zwłaszcza w takim biznesowym zastosowaniu. Czy według Ciebie ten nowy region, o którym powiedziałeś, region Warszawa Google Cloud, jakoś tę sytuację poprawi, będziemy gonić Zachód, Stany?

 

Nie ukrywam, że wizja powstania regionu w Warszawie była jednym z dosyć kluczowych czynników, dla których zmieniłem kierunek swojej kariery, zająłem się tematyką chmurową i po dziesięciu latach odszedłem z zajmowania się aplikacjami mobilnymi i rozwojem tychże aplikacji. Z perspektywy dwóch lat pracy w chmurze i zajmowania się nią każdego dnia, zwłaszcza Google Cloudem, chciałbym teraz móc się cofnąć czasami do tych miejsc, w których byłem i pracowałem, ale być tam z moim obecnym doświadczeniem i wiedzą, aby wprowadzać praktyki używania tej chmury i stopniową migrację wszystkich rozwiązań, bo naprawdę widzę w tym bardzo dużo zalet, a jednocześnie znam problemy, jakie były w tych organizacjach, w których pracowałem. 

Dzisiaj nadal, gdy rozmawiamy z klientami, widzimy te problemy, które chmura mogłaby realnie i w miarę szybko rozwiązać. Choćby ta wspomniana już skalowalność,  Black Friday, o którym już rozmawialiśmy. Myślę, że nie ma odwrotu i rewolucja chmurowa, po tej rewolucji mobilnej, która się przetoczyła dobre kilka lat temu, to jest kolejna rewolucja i kolejna fala, która się przetoczy przez Polskę i świat. My oczywiście jesteśmy jako rynek, jako Polska troszeczkę z tyłu, aczkolwiek ostatnie wskaźniki pokazują, że to się rusza, że firmy coraz częściej przenoszą swoje workloady do chmury. Natomiast kluczowe jest, aby robić to z głową i ze wsparciem doświadczonych pasjonatów, inżynierów, osób, które zagwarantują odpowiednie podejście do tego i przeprowadzą takie transformacje. Osobiście bardzo na to liczę, nie mogę też powiedzieć nic innego, bo będę nieautentyczny. Moim zdaniem nie ma odwrotu, po prostu tak jest. 

 

Myślę, że nie ma odwrotu i rewolucja chmurowa, po tej rewolucji mobilnej, która się przetoczyła dobre kilka lat temu, to jest kolejna rewolucja i kolejna fala, która się przetoczy przez Polskę i świat.

 

Na koniec powiem tylko, że miałem w swoim życiu kilka takich sytuacji, że poznałem jakąś technologię i wydawało mi się, że ona była tak rewolucyjna, że nie rozumiałem, jak można było to w ogóle robić inaczej. Trochę tak miałem z Gitem, z systemem do kontroli wersji. Jak go poznałem, zgłębiłem i mnie zafascynował, to też sobie zacząłem przypominać, jak w ogóle można było rozwijać oprogramowanie bez Gita na innych systemach kontroli wersji. I teraz trochę tak czuję, że zbliżam się do takiego wniosku z chmurą. Każdy kolejny projekt, który działa, który możemy monitorować, który możemy skalować, który możemy dowolnie dostosowywać do naszych potrzeb i do potrzeb przede wszystkim naszych klientów, doprowadza mnie chyba do takiego podobnego wniosku i podobnego stwierdzenia, że nie ma odwrotu.

 

Tym optymistycznym akcentem zakończymy.

Dzięki Mateusz za tą ciekawą rozmowę, za pokazanie możliwości chmury w kontekście rozwoju, utrzymania, uruchamiania aplikacji. Przed naszą rozmową powiedziałeś, że nie masz zbyt wielu doświadczeń, jeśli chodzi o występowanie w podcastach. Muszę Ci powiedzieć, że tego w ogóle nie było słychać, także wielkie dzięki za ten poświęcony czas.

 

Dzięki!

 

Powiedz jeszcze na koniec, gdzie Cię można znaleźć w Internecie, jak się można z Tobą skontaktować?

 

Zachęcam oczywiście do kontaktu, ja mam wizytówkę swoją na swojej stronie witrynie grzechocinski.com. Mam też oczywiście Twittera, LinkedIna, zwykle nie ukrywam się pod jakimiś aliasami, po prostu po imieniu i nazwisku na pewno w Google’u mnie znajdziecie. Zapraszam do kontaktu, zapraszam też do pracy. My zawsze szukamy wsparcia, szukamy fajnych, nowych, energicznych osób, które chcą się rozwijać, programistów, którzy chcą poszerzać swoje horyzonty i być inżynierami od rozwoju oprogramowania, którzy zgodnie z tą filozofią DevOpsową będą się też zajmowali czymś więcej niż tylko produkcją kodu. To jak najbardziej zawsze chętnie  można się do mnie odzywać, zapraszam, pokieruję co dalej można robić.

 

Świetnie, oczywiście wszystkie linki jak zawsze będą w notatce do tego odcinka.

Z mojej strony Mateusz jeszcze raz bardzo dziękuję i do usłyszenia. Cześć!

 

Dziękuję bardzo, cześć!

 

I to na tyle z tego co przygotowałem dla Ciebie na dzisiaj. Chmura obliczeniowa daje wiele możliwości, jeśli chodzi o tworzenie, testowanie jak i utrzymanie oraz skalowanie aplikacji. Umożliwia szybkie uruchomienie nawet złożonych projektów z opcją monitorowania stanu i kosztów.

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach. Jeśli masz jakie pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Nazywam się Krzysztof Kempiński a to był odcinek podcastu Porozmawiajmy o IT o aplikacjach w chmurze publicznej.

Zapraszam do kolejnego odcinka już za tydzień. 

 

Cześć!