Na styku chmury i mobile, czyli rynek aplikacji okiem Googlersa

Świetnie, że jesteś. Subskrybuj, aby być na bieżąco z kolejnymi odcinkami podcastu FlyTalks. Dzisiaj przed nami rozmowa z ekspertem w obszarze technologii chmurowych i aplikacji mobilnych, ale też kimś, kto na co dzień buduje mosty pomiędzy klientami a zespołami IT. Nasz dzisiejszy gość Customer Engineer w Google – Krzysztof Zalasa. Cześć.

Cześć. Witam serdecznie wszystkich słuchających.

Krzysiek albo dla zagranicznych klientów „Chris” jest po prostu osobą, którą dobrze spotkać, gdy szuka się rozwiązań dla swojego biznesu, rozwiązań chmurowych. Bo jesteś praktykiem, wiesz, co sprzedajesz i co proponujesz swoim klientom dzięki wieloletniemu doświadczeniu, portfolio i wielu wdrożeniem.

Tak. Myślę, że to doświadczenie z prawdziwych projektów, w których ja byłem trochę po tej drugiej stronie, czyli to ja wdrażałem, ja korzystałem z chmury, to było mega pomocne. Ja właśnie tak lubię opisywać się jako ktoś, kto jest pomiędzy i buduje ten most. Bo nasze teamy produktowe budują produkty, które są bardzo wysokiej jakości, ale mają jakąś swoją wizję tych produktów. A często ten feedback od użytkowników jest kluczowy. Więc moim zdaniem to jest właśnie rola customer engineera, żeby przekazać ten feedback, być trochę adwokatem wewnątrz organizacji tych potrzeb klienta. Ja myślę, że to są potrzeby szczególnie ważne w tej roli. Mimo tego, że w nazwie jest inżynier, ale ten przedrostek „customer” właśnie mówi o potrzebach, że to my jako inżynierowie staramy się zrozumieć tego klient czego tak naprawdę potrzebuje i rozwiązać jego problem. Nasza praca polega na tym, żeby znajdować rozwiązania tych wyznań, które w danym momencie są najważniejsze dla klienta.

Zanim to rozwiniemy, porozmawiamy o rynku mobile. Wiem, że to leży też w obszarze twoich zainteresowań. Zanim dowiemy się więcej o Google Cloud Platform Firebase, po co sięgnąć, budując swój biznes w oparciu o chmurę? Ale zanim to wszystko, rozgrzewkowo może bardziej przyziemne pytanie: jak po prostu wygląda twój typowy dzień pracy w Google, czym się zaczyna, czym kończy? Jak to wygląda?

Teraz wiadomo, że w czasie covidowym wygląda to trochę inaczej. W takim normalnym czasie to, co jakby cechuje nasze stanowisko pracy, to to, że dużo podróżujemy po świecie. Czyli to są jakieś konferencje, ale też po Polsce po prostu, żeby być blisko naszych klientów, żeby rozmawiać z zespołami developerskimi w pełnym kształcie, w pełnym zakresie, gdzieś tam na miejscu. Też oczywiście często gościliśmy naszych klientów w naszym warszawskim biurze. Teraz trochę się to zmieniło. Więcej tych spotkań w formie elektronicznej. Ja osobiście bardzo mocno stawiam na work-life balance, bo wychodzę z takiego założenia, że przez te 8 godzin każde takie półgodzinne spotkanie, na które czasami klient musi chwilę poczekać, chciałbym, żeby miał jak największą wartość z tego, żeby jego czas był dobrze zainwestowany. Dlatego ja osobiście staram się jak najbardziej trzymać tych 8 godzin. Oczywiście w sytuacji, kiedy jest jakaś sprawa, wymagająca natychmiastowej atencji, to po to jest telefon firmowy i laptop, żeby zareagować. Ale staram się jak najmocniej trzymać tego timeboksu. Ogólnie życie Googlera, tak jak wspomniałem, w normalnych czasach pełne podróży. Teraz jakby trochę mniej. Sporo spotkań, czyli bezpośrednich dyskusji z klientami o ich projektach od samego startu idei, czasami startupu, który jeszcze nawet nie ma nazwy i domeny firmowej do wdrożeń, do ruszenia na produkcję; sprawdzenia, czy wszystko jest zapięte na ostatni guzik. Wcześniej trzeba wybrać komponenty, architekturę, oszacować koszty, zapewnić, żeby wszystkie zasoby znalazły się tam, gdzie są potrzebne. Czasami w takich projektach, które są bardziej skomplikowane, na przykład brałem udział też w takich rutynach w pracy z powodu developerskiego Przegląd Sprintu. Gdy klient pracował w scrumie, wtedy na Sprint Review mogłem podpytać; zobaczyć, jak idzie progres; podpowiedzieć przy planingu, jakie komponenty, jakie środki GSP są najlepsze do tego, żeby osiągnąć skutek biznesowy, bo to jest jakby najważniejsze. Więc customer engineer to jest taka rola, która bardziej kojarzy się z działaniami na wstępnych etapach jakby współpracy z Google Cloud, natomiast tak naprawdę z niektórymi klientami pracuję już po 3 lata, odkąd tylko dołączyłem, i cały czas oni mają jakieś nowe potrzeby, nowe wyzwania, nowe projekty. To jest taka nieustanna praca i taka relacja, opierająca się na zaufaniu.

Ciekawe jest to, że na twoim koncie jest tak, że socjologia, psychologia, pomagają ci w pracy.

Tę socjologię to tylko liznąłem, bo tylko zacząłem. Natomiast psychologia jak najbardziej się przydaje. To jest trochę paradoksalne, ale żeby dobrze znaleźć rozwiązanie techniczne na konkretny problem klienta, to tam bardzo dużo jest o zrozumieniu potrzeb, o zrozumieniu biznesu, o zrozumieniu tego, co jest potrzebne, żeby dany biznes wzrósł. Po prostu zwykła rozmowa z ludźmi. Zrozumienie tej drugiej strony, a czasami przekonanie kogoś w organizacji do tego, żeby wesprzeć tę inicjatywę. Więc jako ciekawostkę mogę powiedzieć, że w naszej rodzinie Cloud-inżynierów w Polsce jest więcej psychologów niż tylko jeden, więc to nie jest tak, że customer inżynierowie to są osoby koniecznie, które skończyły studia techniczne. Oczywiście ja miałem wykształcenie techniczne na poziomie szkoły średniej, takiej elektronicznej, więc tam też było bardzo dużo nauk ścisłych, ale ogólnie jestem samoukiem. Myślę, że to jest też coś, co się bardzo przydaje w ogóle w Cloudzie, że do pewnego poziomu można przechodzić oficjalne ścieżki certyfikacyjne, można tam jakieś rozszerzone kursy i tak dalej, ale od pewnego momentu tak naprawdę najważniejsza jest taka samodyscyplina w tym, żeby się systematycznie uczyć, poznawać, eksperymentować. To jest taka najlepsza droga do tego, żeby z tymi super nowymi technologiami być up to date i z powodzeniem je wdrażać w swoich projektach.

To były cenne rady zawodowe, a żyjemy teraz w czasach, w których łatwiej być w pracy, nawet po pracy, także za sprawą urządzeń mobilnych. Wszyscy dobrze wiemy, jak to działa. Porozmawiajmy trochę o tym. Wiem, że to leży także w zakresie twojej wcześniejszej działalności. Czym jest mobile? Jak opisujesz ten rynek? To znaczy czym jest teraz, czym był kiedyś, bo wydaję mi się, że chyba obserwujesz go tak naprawdę od początku?

Chyba tak. Przynajmniej jeżeli chodzi o aplikacje mobilne. Masz rację, że pracowałem z tym znacznie wcześniej i dzięki temu trochę inaczej patrzę na te korzyści, które dostarczają obecnie rozwiązania, bo to jest trochę tak, że jeżeli tak jak moje dzieci, które są wychowywane w epoce Internetu, po prostu nie znają świata bez Internetu, tak samo jak wychowuje się w epoce, gdzie chmura już jest czymś właściwie codziennym, to nie wiesz, jak to wyglądało wcześniej, a ja akurat wiem. Pracując w poprzednich miejscach pracy, mieliśmy okazję robić różne projekty, aplikacje, które ułatwiały mieszkańcom miasta na przykład korzystanie z komunikacji miejskiej czy taki bardzo fajny projekt dofinansowany z Unii Europejskiej o grach edukacyjnych dla dzieci. Ale to były aplikacje mobilne, które trzeba było w jakiś sposób połączyć też z tym światem backendowym. Zdecydowanie teraz wygląda to zupełnie inaczej po tych kilkunastu latach, już teraz zestaw narzędzi, który jest, jest zdecydowanie bardziej rozbudowany. Urządzenia są znacznie lepszej jakości, mają lepsze parametry, można znacznie więcej na nich zrobić. Obecnie ten rynek mobile to trochę, nie chciałbym używać jakiegoś takiego pojęcia 2.0, które jest popularne czy X.0, 4.0, ale wydaję mi się, że trochę ostatnio wchodzimy w taki kolejny krok rozwoju. Właściwie każde duże przedsiębiorstwo czy tam średnie, jeżeli powinno mieć aplikację mobilną, to już ją ma. Ale teraz dużo takich projektów, które gdzieś tam prowadzimy, a akurat jeszcze nie możemy się nimi pochwalić, bo jeszcze są nieukończone; to są projekty odnośnie redesignu tych aplikacji. Czyli nawet duże takie przedsiębiorstwa tradycyjne, które mają już swoje aplikacje mobilne, są teraz na etapie takim, że OK, mamy, widzimy pewne niedoskonałości, niedociągnięcia i chcemy zrobić to tak, żeby nasze aplikacje były jeszcze lepsze. To jest to, że jeżeli te aplikacje powstawały już jakiś czas temu, to tak jak na przykład trochę odnośnie tego Firebase’a. Teraz, żeby dodać autentykację do aplikacji, to bierze się z DEK-a, konfiguruje i za kilka godzin, a może i szybciej w zależności od zespołu, ma się to wdrożone. A wtedy, kiedy kilkanaście lat temu ja coś takiego wdrażałem, to trzeba było przygotować API, zaprojektować je, zakodować. Tam gdzieś pod spodem była jakaś baza, jakieś serwery aplikacyjne. Skomunikować to ze sobą i dopiero wtedy taką funkcjonalność mogliśmy dostarczyć. Więc to był zupełnie inny proces i właśnie część tych aplikacji, które mają już swoje lata, powstawało w trochę innych realiach i one muszą być trochę dociągnięte do tego, co teraz jest na topie. Bo użytkownicy są przyzwyczajeni, że aplikacje działają bardzo responsywnie. Nikt nie chce czekać na to, żebyś się jakiś ekran 5 sekund w aplikacji załadował, bo to jest coś, czego się po prostu nie robi. Więc są te narzędzia, które pozwalają zrobić tę aplikację bardzo responsywną. Nie wiem, czy miałaś okazję obejrzeć Google'a I/O ostatnio, właśnie o tym, w jaki sposób zmienia się podejście do designu. Bardzo mi się to podoba, że on jest taki bardziej spersonalizowany per użytkownika. To nie jest tylko tak, że mamy aplikację danego przedsiębiorstwa i ona musi być taka sama dla wszystkich. Może to użytkownik powinien zdefiniować, jak ta aplikacja powinna pod względem na przykład kolorystyki działać, żeby po prostu dobrze się z nią czuł. Bo coraz częściej z tych aplikacji korzystamy. Ja sam robiąc teraz z racji warunków dużo zakupów internetowo i aplikacja do obsługi paczkomatu jest jedną pewnie z najczęściej używanych w moim telefonie. Ale być może mógłbym coś innego z tą aplikacją zrobić czy w ogóle do wykonania tych zakupów. Więc te aplikacje przechodzą taki redesign, który jest widoczny od strony użytkownika, ale tam pod spodem co się dzieje, to właśnie to, że już nie musimy tego wszystkiego wynajdować od nowa. Możemy skorzystać z bardzo dużego zestawu komponentów, które są predefiniowane w chmurze, są w jakiś sposób już wstępnie wybudowane i można je łatwo dołożyć do aplikacji. Na przykład bardzo lubię przykłady maschinenringowe, że bierzesz aplikację, robisz zdjęcie i na podstawie tego zdjęcia może sobie znaleźć produkt, który cię interesuje albo znaleźć odpowiedź na pytanie, które właśnie sfotografowałeś. Więc to jest znacznie więcej niż tylko takie proste przeklikanie i te aplikacje współczesne mogą znacznie bardziej poza to wykraczać. To mi się bardzo podoba i właśnie to też jest jakby widoczne na rynku, że i duże i małe firmy chcą robić te aplikacje, które są jak najbardziej innowacyjne i takie noszące wartość, żeby użytkownicy chcieli z nich korzystać, bo konkurencja też jest ogromna. Jeżeli ta aplikacja będzie w porównaniu do innych słabsza, to konkurencja prawdopodobnie wygra ten wyścig.

Niejednokrotnie aplikacje mobilne teraz oferują tak stabilne działanie, że nikt nie ma w ogóle problemu, by korzystać z bankowości mobilnej z poziomu telefonu. Coś, co pewnie kiedyś było nie do pomyślenia, by zamiast na stacjonarnym to robić w telefonie, podglądać, obracać swoimi środkami. Więc to na pewno kawał dobrej roboty i kodu ze strony środowiska programistów. Teraz pytanie właśnie, które się z tym wiąże, dotyczy trybu pracy. Czy kiedyś, pracując nad apką mobilną, trzeba było to tak trochę robić po godzinach po macoszemu? Czy faktycznie zmieniło się podejście do rozwijania jednego produktu webowego, działającego też na smartfonie, czy może zalecane jest tworzenie dwóch lub więcej produktów natywnych? Jakie jest to bardziej nowoczesne podejście z twojej perspektywy? Co się zmieniło?

Myślę, że to trochę wynika z tego, co użytkownicy mają w kieszeniach i jak korzystają z Internetu. Jak ja tak sobie spojrzę w mój domowy przykład, to moja żona zdecydowanie mniej korzysta z laptopa, więcej z telefonu. Ja pewnie gdzieś też jak nawet sobie jakieś filmiki oglądam z obszaru moich obecnych zainteresowań, to też właśnie bardzo często robię to na telefonie, nie uruchamiam laptopa. Więc od strony biznesowej jak na to spojrzysz, to e-commerce w wielu wypadkach sprzedają więcej przez mobile niż przez klasyczny web. To jest tak proste. Więc jeżeli sprzedajesz więcej za pomocą tego kanału, to jest to dosyć oczywiste, że dla przychodów Twojej firmy jest to ważny kanał i musisz trochę ten suwak przesunąć i dać więcej zasobów na rozwój tej technologii. Więc na pewno jakby ta technologia przez to, że smartfony są bardzo popularne, dobrze są zaadaptowane, że większość użytkowników ma dostęp do Internetu też w tych smartfonach i lubią z tego korzystać. A teraz jeszcze pamiętajmy, że jesteśmy w czasach pandemicznych. Ale jak wrócimy trochę do tych czasów takich, gdzie więcej będziemy podróżować, to pewnie kojarzysz z tych wszystkich środków komunikacji ludzi, którzy jednak korzystają z telefonów w pociągu, w metrze, w tramwaju, w autobusie. Myślę, że to będzie jeszcze bardziej widoczne. Ja mam takie poczucie, że przez to, że właśnie te zachowania się zmieniły, chociaż to oczywiście też zachowania się zmieniają, bo są coraz lepsze apki. To tak się jakby trochę samo napędza, ale też jakby poza potrzebami są lepsze narzędzia. Kilkanaście lat temu nie było takich narzędzi, żeby można było tak dużo funkcjonalności dołożyć w tak krótkim czasie. Teraz zapisać sobie jakieś proste informacje o użytkowniku wystarczy, że wrzucicie z DEK-a i tyle. I do pewnego progu odwiedzalności Twojej aplikacji nawet za to nie zapłacisz, bo to będzie darmowe, a alternatywnie kiedyś trzeba było te wszystkie kroki przejść, o których już trochę wspominałem. Przez ten design, stworzenie jakiegoś API, skomunikowanie tego, dogadanie się tych jednych developerów z drugimi. Myślę, że na jakość też trochę wpłynęły sposoby obecnego rozwoju tych aplikacji. Dawno temu ja miałem takie poczucie, że to było bardzo rozseparowane, że były zespoły mobile i były zespoły, które tworzyły jakiś backend do tego i to były zespoły, które słabo ze sobą współpracowały. Teraz to najczęściej jest jeden zespół, który ma w sobie wszystkie kompetencje. Miałem okazję pracować w takim składzie i efekty były bardzo fajne. My robiliśmy coś co aplikacje do OTT, do streamowania wideo, które musiały być zabezpieczone. To nie jest tak, że do takich aplikacji jest 1000 przykładów na Stack Overflow i właśnie to, że pracowaliśmy razem w takich cross funkcjonalnych zespołach, to powodowało, że szybko dodawaliśmy nowe funkcjonalności. Więc myślę, że wielkość rynku, liczba zasobów, też lepsze narzędzia i do tego jeszcze mamy zmienione trochę i udoskonalone metodyki pracy i to powoduje, że na koniec mamy dobre aplikacje. I to, co myślę, że też jest ważne, a nie do końca się też kojarzy wszystkim, którzy myślą o aplikacji mobilnej – dane. Twórcy aplikacji analizują, co się dzieje, co użytkownikowi się podoba, co się nie podoba; czy to działa sprawnie, czy nie. Czyli mają informacje o tym, jak to działa po tej drugiej strony i na podstawie tych informacji są w stanie reagować i reagują. Więc to jest też istotne, że ta pętla sprzężenia to nie jest tylko komentarz gdzieś tam w sklepie, ale są po prostu twarde dane mierzalne, które można sobie release po release porównać miesiąc do miesiąca i sprawdzić, czy jest progres czy nie. To jest coś, co powoduje, że te decyzje są nie tylko oparte na takiej intuicji, ale oparte są na danych i przez to są po prostu trafniejsze i lepsze dla użytkowników.

Zatem pytanie, czy rozwijać dwa produkty natywne lub większą liczbę w przypadku, gdy robimy to osobno na Androida i iOS-a, czy tworzyć jedną aplikacją webową, sprowadza się po prostu do kasy?

Ja zawsze do tego podchodzę w ten sposób, że trochę zależy use case’u, bo jeżeli nasza aplikacja będzie miała bardzo jakiś tam wąski skok, to faktycznie strona, która będzie dobrze wyglądała na telefonie i będzie w miarę funkcjonalna, to może nawet wystarczyć. To nie jest tak powiedziane, że koniecznie trzeba mieć aplikacje. Natomiast aplikacje pozwalają na zrobienie czegoś, co jest znacznie bardziej użyteczne niż tylko otwarcie strony na telefonie. Wtedy, kiedy mamy taki use case właśnie, tak jak już wspominałem, że robimy zdjęcie i wyskakuje nam odpowiedź czy produkt, który akurat byłby dla nas interesujący, to to jest dla mnie coś bardzo fajnego. Albo sterowanie głosem, czyli jedziesz samochodem, dojedziesz za pół godziny do domu i możesz za pomocą asystenta sobie zamówić pizzę, żeby już tam kurier za 5 minut po Twoim przyjeździe był z tym jedzeniem. Więc tego typu rzeczy powodują, że ta funkcjonalność tej aplikacji, ta aplikacja daje znacznie więcej niż tylko strona internetowa. Ja myślę, że tutaj jest ten balans. Bo to jest inwestycja, wiadomo, jak tworzenie dedykowanej aplikacji mobilnej. Ale jak będzie ta wartość, to dla użytkownika pewnie będzie to opłacalne.

Mamy wyszukiwanie głosowe, mamy wyszukiwanie graficzne wśród trendów na ten rok. Nowością może być także VR w telefonach i tutaj tę furtkę może stworzyć, a raczej otworzyć, wprowadzenie 5G. Jakie widzisz jeszcze możliwości rozwoju w aplikacjach mobilnych na ten rok i przyszłe lata?

Pamiętam, że prezentowałem na takim evencie i tam jeden z prezenterów przede mną miał właśnie 5G i po tym evencie sobie już w nieoficjalnych warunkach rozmawialiśmy na temat tego 5G. On mówi, że fajnie, że będzie szybciej, ale co mu to da jako Polakowi. On mówi: „ja mieszkam w Pekinie”. W tamtych jeszcze czasach, przedcovidowych, w godzinach pracy tam jest 50 milionów ludzi na terenie miasta. To jak sobie to policzysz, to jest znacznie więcej, bo prawie 1,5 razy tyle co mieszkańców w Polsce. No i tam obecna technologia nie daje rady, więc nie myśl też o 5G jako o czymś, co jest tylko lepszym Internetem, jak mieszkasz na peryferiach miasta, ale to jakby odblokowuje pewne rzeczy w miejscach, gdzie technologia była za słaba. Druga sprawa jest taka, że to 5G też tak jak w Google mamy Stadię – platformę do elektronicznej rozrywki. I na moim Internecie LTE grało mi się OK, ale musiałem być w tym samym pokoju co router. Mam taki dodatek, który mi pozwala trzymać wygodnie telefon i Pada, którym steruję na tym telefonie. Da się grać, ale pewnie lepszy experience byłby właśnie z 5G, czyli wchodzą też... dzięki temu 5G będziemy mieli możliwość do innego rodzaju rozrywki. To na przykład takie jak platforma Stadia, ale też ja bardzo lubię obszar, kiedy medycyna i technologia się spotykają, czyli jakaś operacja albo specjalista siedzi ileś tam kilometrów od miejsca, gdzie jest osoba, która potrzebuje pomocy, ale żeby ten specjalista mógł kilka takich osób zoperować, które są bardzo daleko od siebie w sensie fizycznym, to dla mnie to jest coś, co jest na pewno super US Case’em właśnie dla tej technologii, więc zdecydowanie widzę case’y. Jest jakieś tam grono sceptyków do tej technologii, ale ja raczej staram się dosyć szybko adaptować takie rzeczy, więc jak tylko będzie w moim miejscu zamieszkania dostępne, to na pewno sobie podłączę.

A gdy mówimy o aplikacjach i grach, to jaką rolę w ich rozwoju odgrywa chmura? To znaczy z jakimi wyzwaniami zwłaszcza jest w stanie sobie świetnie poradzić? Co jeszcze stanowiłoby spory problem te ładnych parę lat temu dla zespołu programistów?

Jasne. Jak tworzysz grę, to w sumie trochę nie wiesz, co cię może spotkać. Jest taka jedna z polskich firm, która tworzy gry, które w czasach niecovidowych miały zupełnie inną liczbę użytkowników i odsłon niż miały kilka miesięcy później. To po prostu potrafiło wzrosnąć w bardzo szybkim tempie ze względu na specyfikę tych gier. Teraz chmura pozwala Ci być na to przygotowanym. Bo tam są narzędzia, które pozwalają na przykład na analitykę w takich aplikacjach czy zbieranie informacji o zdarzeniach, czy wszystko to, co dostarcza platforma Firebase’a w zasadzie jest dobre i dla startupu i dla nawet studenta, który stworzył swoją pierwszą aplikację na zaliczenie, jak i dla dużych tradycyjnych przedsiębiorstw z grona największych na polskiej giełdzie. Dla każdego z nich któreś z tych komponentów będą przydatne, więc przede wszystkim skalowanie tego, jeżeli nasza aplikacja, gra, stanie się dobra. Możliwości analityczne, bo to jest szczególnie ważne przy aplikacji. Już trochę o tym wspominałem, że teraz bez dobrej analityki, bez zrozumienia tego, co robi użytkownik, w jaki sposób korzysta z aplikacji, to nie jest 2021 rok. My musimy mieć informacje, musimy je analizować, musimy reagować i dostosowywać, poprawiać. Na przykład z crashami aplikacji, teraz w zasadzie rzadko, nie mogę sobie przypomnieć, kiedy ostatni raz jakaś aplikacja mi się na telefonie scrashowała. Jeszcze kilka lat temu to było dosyć nagminne, ale właśnie dzięki rozwiązaniom między innymi chmurowym developerzy aplikacji mają informację o takim crashu w ciągu sekund i mogą zacząć proces debugu po kilkunastu minutach i wysłać do sklepu poprawioną wersję następnego dnia. Więc to jest coś, co znacznie zmieniłoby, podniosło jakość tych aplikacji. Właśnie to, co wcześniej też było trudne, czyli jakiś taki bardziej zaawansowany Maschinenring czy przesyłanie danych z telefonu w jakieś bezpieczne miejsce. To ciężko by było zrobić bez chmury. Szybkość ładowania się. Bo wyobraźmy sobie, że mamy aplikację, która służy do przeglądania jakichś na przykład zdjęć z katalogu mody, które muszą być super jakości, żeby nie stracić swoich walorów, ale też nie chcemy na nie czekać w nieskończoność. Więc tutaj chmura też pozwala, żeby te zdjęcia były podane w taki sposób, który będzie jak najbardziej przyjazny dla użytkownika, żeby to było szybko. Ja lubię właśnie opowiadać o tej platformy Firebase’owej, która jest trochę tak na styku chmury i mobile developmentu i tam są jakby takie 3 filary, które są istotne dla tej platformy. Jest taki filar, który kładzie nacisk i daje narzędzia do szybkiego rozwoju aplikacji. Czy tak jak wspomniałem — nie musisz wynajdować swojego sposobu zalogowania się, swojego sposobu na zbieranie danych, definiować API, budować go, bo możesz skorzystać z narzędzi, którymi zrobisz to samo znacznie szybciej, ktoś je za ciebie utrzyma, będziesz miał wysoką dostępność tego i zapłacisz tylko za zużycie. A na początku zmieścisz się we Free Tier. Druga rzecz to jest jakość, czyli właśnie analiza, jak szybko działa aplikacja, czy występują jakieś crashe, jak to przekazać do zespołu Q&A. Jak to przetestować na różnej gamie urządzeń. Ja to też pamiętam, jak w jednej z firm, w których pracowałem, jak chcieliśmy sprawdzić naszą aplikację na jakiejś tam reprezentatywnej próbie urządzeń, to tam taka kupka tych telefonów, tabletów, leżała. Teraz wystarczy napisać zautomatyzowany test i w chmurze te telefony i tablety, fizyczne urządzenia, mogą wykonać ten scenariusz testowy i dostaniesz z tego nagranie wideo i raport, czy to wszystko się udało, czy są jakieś tematy do poprawy. No i trzecia rzecz to jest właśnie to zaangażowanie użytkownika. Właśnie analiza tego, jak on się zachowuje w tej aplikacji. Ale też właśnie V-test, czyli na przykład nie wiemy, czy będzie czerwone czy zielone lepsze, więc zróbmy eksperyment. Nie zdawajmy się na intuicję. Sprawdźmy to po prostu. Możemy wysłać push-notyfikację i to też jest fajne, bo ja lubię dostać push-notyfikację, kiedy akurat jest 25 i wpływa wypłata na konto. Jest to coś, co zdecydowanie wzbogaca doświadczenie w tej aplikacji czy przewidywanie, że jakiś użytkownik nie jest zadowolony z naszej aplikacji, więc być może trzeba go jakoś zachęcić, skierować go na odpowiednie tory. Tutaj ja myślę, że to chodzi o to, że zestaw tych narzędzi jest znacznie bogatszy. Te problemy są już dosyć dobrze znane, dobrze zdefiniowane. I chmura przede wszystkim pozwala na zastosowanie jakiegoś takiego sprawdzonego sposobu. Oczywiście trzeba go zawsze sobie dostosować do swojego US Case’u bardziej precyzyjnie, ale jakby te wzorce są powtarzalne. Nie musimy się martwić, co będzie, jeżeli będzie klęska urodzaju. Jak dawno temu był taki portal Nasza klasa, który niedawno zakończył swoją działalność, ale w pewnym momencie z klęską urodzaju sobie nie poradził. A gdyby wtedy już twórcy korzystali i byłaby w ogóle taka możliwość jak dzisiaj z chmury, to być może ta historia byłaby inna. Może w Polsce byśmy o Facebooku nie słyszeli. Kto wie. Więc tutaj ta technologia powoduje, że jesteś gotowy na bardzo szybki wzrost. To moim zdaniem jest też szybkie. I teraz w czasach pandemii, kiedy zmieniają się restrykcje z dnia na dzień, to jeden z naszych klientów miał po jednym ogłoszeniu rządowym o kilkaset procent wzrost ruchu w porównaniu do największych pików wcześniej, bo wszyscy akurat zareagowali na to ogłoszenie. Bez chmury bardzo trudno byłoby takie scenariusze w ogóle obsłużyć.

Przypominam, Krzysztof Zalasa, Customer Engineer w Google, jest dzisiaj z nami w podcaście FlyTalks. Krzyśku, Firebase padło już kilkukrotnie. Czy możesz wytłumaczyć podstawy platformy Firebase, bo to jest osobny, a z drugiej strony bliźniaczy byt do Google Cloud Platform.

Firebase to jest taki zestaw narzędzi dla deweloperów aplikacji mobilnych. Takie było zamierzenie. Już trochę wspomniałem o tych 3 filarach, które wchodzą w skład. Natomiast każdy projekt Firebase’owy jest też jednocześnie projektem Google Cloud tak naprawdę. I to jest tak, że część z tych komponentów jest jakby taka sama czy bardzo podobna i tu i tu, czy też nawet współdziałają ze sobą. Taki przykład, że jeżeli napiszemy coś do Firestore’a, czyli do takiej bazy dokumentowej na urządzeniu mobilnym, to możemy równie dobrze odczytać z tej samej bazy z maszyny wirtualnej czy tam z Klastra Kubernetesa, który będzie zdiplojowany w Google Cloud. Więc to jest trochę tak, że część funkcjonalności Firebase’a korzysta pod spodem z Google Cloud. Ja bym to tak wytłumaczył, jeżeli o to chodzi. A Firebase to jest zestaw narzędzi, których jest w dużej mierze darmowy. Tam naprawdę sporo można zrobić bez dodatkowych opłat. Jest szczególnie fajny na początku dla jakiegoś star tupu, mniejszej firmy, która chciałaby tylko dostarczyć dosyć podstawowych funkcjonalności, ale funkcjonalności dla jakiegoś wąskiego grona odbiorców, które pozwala na właśnie szybsze wytwarzanie aplikacji z lepszą jakością, pozwala na analizowanie użytkowników i doskonalenie tej aplikacji. Więc trochę już wspomniałam, co tam się pod tym kryje w samym Firebasie, ale ja bym Google Cloud traktował w kontekście aplikacji mobilnej jako coś, co części tego Firebase’a, w tej części szczególnie odpowiedzialny za aplication development to jest platforma, z której też ten Firebase korzysta; ale też jest to miejsce, które najczęściej służy do rozszerzenia. Takim najpopularniejszym przykładem jest BIQR, czyli bardzo często jest tak, że dane odnośnie analityki, odnośnie crashy na przykład i odnośnie tych predukcji są eksportowane do BIQR i wtedy już analitycs łączy to dane. Bo jak się tak zastanowisz, jeżeli sprzedajesz przez aplikację i ta aplikacja ma jakieś problemy techniczne albo wydajnościowe, to możesz potem sobie policzyć, ile cię to kosztowało tak na dobrą sprawę. Czyli swoje revenue w takim czasie, kiedy wszystko jest OK; sprawdzasz swoje revenue wtedy, kiedy miałeś problemy; porównujesz te 2 wartości i widzisz, że ten błąd kosztował cię X czy Y. Czyli możesz nie tyle na podstawie jakby swojej intuicji ocenić jaki był wpływ tego, ale potem możesz to sprawdzić, jak to się ma do użytkowników, ich aktywności. Czyli wszystko możesz bardzo precyzyjnie sobie skorelować i to jest właśnie to, co jest bardzo częstym takim miejscem, gdzie podstawowe możliwości Firebase’a są rozszerzone przez Google Cloud. To jest tak najczęściej. No i oczywiście takie bardziej zaawansowane aplikacje najczęściej mimo wszystko mają gdzieś tam pod spodem core; jakieś API. Jest serwer aplikacji, są bazy danych. Czy jeżeli wejdziemy na chwilę do game’ingu, to w zależności oczywiście od segmentu gier, ale są takie gry, w których gracze grają ze sobą, czyli jest konieczna między nimi komunikacja, to zdecydowanie chmura może pomóc, żeby umożliwić stworzenie takiej platformy, gdzie ci użytkownicy, gracze, wymieniają się informacjami. Ja bym trochę w tę stronę poszedł. Jeżeli miałbym budować aplikację mobilną i nie mógłbym z tych wszystkich tematów korzystać, to powiem szczerze, że myślę, że byłoby to znacznie utrudnione. I to też jest chyba coś, co warto wziąć pod uwagę, że jeżeli nasi konkurenci korzystają ze stałego narzędzia, które znacznie ułatwia i przyspiesza pracę, jak my będziemy starać się robić to w taki sposób tradycyjny, bo na przykład boimy się innowacji, to nasz time to market będzie taki, że już tam będą 3 aplikacje, które będą robiły to, co my chcemy dowieść. Więc to jest dosyć istotne, żeby też rozumieć, że w aplikacjach szczególnie bardzo ważny jest time to market. Jest na przykład taki segment gier, gdzie żywotność aplikacji mierzy się w tygodniach. One są bardzo krótko żyjące, ale robi się ich bardzo dużo. To są jakieś na przykład proste gry, które są dosyć powtarzalne w innej oprawie graficznej, w innej oprawie muzycznej. Mechanika jest bardzo powtarzalna pomiędzy nimi, ale to dla tych twórców się sprawdza. I teraz bez takich narzędzi, które umożliwiają takie na przykład zaimplementowanie analityki w ustandaryzowany sposób, nie byliby w stanie tego robić. Jakby za każdym razem wymyślali koło od nowa.

Krzyśku, mamy teraz pytanie od słuchaczy. Pytanie brzmi: skąd wiecie jako Team Google w jakim kierunku rozwijać swoje produkty, jak mówimy GCP czy Firebase.

Nie ma na to takiej jednej odpowiedzi trochę. A może inaczej – jest odpowiedź, tylko ona jest bardzo złożona. Bo to nie jest tak, że jest tylko jeden czynnik, który o tym świadczy. Oczywiście analizujemy rynek, oczywiście zbieramy feedback od klientów; rozglądamy się, co jest dostępne i czego nam brakuje. Mamy też jakieś takie pomysły bardziej wizjonerskie, ale akurat w mobile to myślę, że Google trochę trudno przebić, jak tak sobie uświadomisz cały ekosystem. Przejdźmy trochę, bo myślę, że to dosyć ważne, istotne, żeby to zrozumieć. Czyli zacznijmy od Androida. System operacyjny, kilka miliardów deploymentów na całym świecie, dostępny w bardzo wielu, w każdej lokalizacji praktycznie. Więc my jak Google rozwijamy ten system. Potem, żeby zakodować aplikacje w tym Androidzie, można skorzystać z Fluttera, czyli język programowania, który też tworzy Google. Jeżeli chcesz dodać funkcjonalności takie właśnie jak już mówiłem, czyli tę analitykę, czy logowanie, czy zapisywanie jakichś informacji, to możesz skorzystać z Firebase’a, który dodaje Google. Jak chcesz rozszerzyć to na przykład o płatności, możesz skorzystać z Google Pay’a między innymi. Jeżeli na przykład Twoja aplikacja ma implementować jakieś płatności, jeżeli potrzebujesz funkcjonalności związanej z mapami, to znowu Google. Jak tak sobie spojrzysz na to z tej strony, że tam jeszcze później, żeby zhostować Twoje API, żeby dołożyć jakieś takie bardziej korporacyjne na przykład funkcjonalności, to też Google Cloud Ci może pomóc. No to naprawdę sporo produktów Google’owych możesz użyć, zobaczyć w jednej dużej rozbudowanej aplikacji. I dlatego mi się wydaje, że to trochę jest tak, że właśnie nawet jak na tym Google I/O, jeszcze o tym nie wspomniałem, o samym interfejsie, o tym Material Design, o tej idei, ale też właśnie o tym Material UI, że ten Material Design ma być dopasowany do użytkownika. To trochę Google definiuje, jak to ma wyglądać. Więc z jednej strony jest to bardzo takie wizjonerskie i patrzenie na to bardzo szeroko z perspektywy tych wszystkich różnych produktów Google’owych. A z drugiej strony sama struktura naszej firmy powoduje, że u nas jest oczywiście pewna hierarchia, ale bardzo duża autonomia poszczególnych zespołów. Jeżeli poszczególne zespoły Firebase i na przykładowym Cloudowy mają pomysł na rozwój jakiejś funkcjonalności, to pewnie się skomunikują i zaczną ją rozwijać. Czy będzie to w połączeniu razem, czy czasami niezależnie. Więc co to definiuje? Na pewno bardzo ważne jest feedback od użytkowników. To już nie jedną i nie dwie funkcjonalności, które jakby na podstawie feedbacku użytkowników widzę po prostu w naszych produktach. Czyli sam usłyszałem taki feedback; mówię, że faktycznie to ma sens; przekazałem do teamu produktowego; oni także zobaczyli, że tak – to jest coś, co jest ważne i inni klienci też tak uważają i wprowadzamy to. Więc myślę, że to też jest istotne, żeby się nie upierać, że zna się wszystkie odpowiedzi, bo to użytkownicy trochę mają zawsze inny use case, trochę inne spojrzenie; trochę coś, co mogło nam nie przyjść do głowy; i to bardzo mocno drive’uje produkty Google. Ale oczywiście analiza rynku, stricte biznesowe aspekty jak najbardziej też są tam istotne.

To na koniec przejdźmy do może konkretnych porad. Pojawiły się już konkrety dla wszystkich startujących w świecie IT ze startupami i szalonymi pomysłami, że część narzędzi jest po prostu darmowych i wystarczy po nie sięgnąć, dysponując oczywiście odpowiednim zapleczem, najlepiej certyfikowanym. Jakie jeszcze masz może rady dla biznesów, które obawiają się wejścia do chmury albo są zdecydowane, tylko nie wiedzą jeszcze, z czego skorzystać?

A ja myślę, że to, co bardzo często słyszę od klientów i dopiero potem musimy to trochę odczarować, to jest to, że chmura jest droższa niż na przykład rozwiązanie on-prem. Pierwsze, do czego bym gorąco zachęcał, to to, na zdrowy rozum, czy tak dużo byłoby klientów Cloudowych, jeżeli to by było faktycznie droższe. Coś muszą w tym wiedzieć. Nie robią tego tylko dlatego, że są jakie baswordy. Więc tak naprawdę ta ekonomia chmury, jak pracujesz prawie 3 lata w Google, to jeszcze ani razu mój klient nie policzył dobrze kosztów chmury. On-prem vs Chmura. Zawsze tam są jakieś takie niuanse, czynniki. Po prostu trzeba mieć pewne doświadczenie w świecie chmurowym. To są takie opłaty, które są nieoczywiste za ruch sieciowy, ale z drugiej strony te instancje nie działają 24/7. Jeżeli masz utylizację 20%, to po prostu dajesz instancję, która jest 4 razy mniejsza i masz nadal jakieś drobny zapas. Więc ekonomia chmury to jest coś, o czym zdecydowanie warto porozmawiać z kimś, kto ma doświadczenie w obszarze praktyczne. Bo najczęściej ta ekonomia chmury jest znacznie bardziej korzystna niż wygląda na pierwszy rzut oka. Więc tutaj czy z zespołem Google’owym, czy z naszymi partnerami, to zdecydowanie tutaj to jest taka pierwsza rada, żeby się nie sugerować, tak jak już wspomniałeś. I żeby w ogóle mieć takie pierwsze wrażenie, jak to działa, to zdecydowanie te Free Tier, te darmowe wersje, pozwalają na sprawdzenie tego. W Google Cloud dostaje się bodajże 300 $ na start i można sobie jakąś maszynę wirtualną uruchomić; zobaczyć, jak działa BIQR czy baza danych. Po prostu od strony funkcjonalnej. To nie jest coś, na czym postawimy jakiś duży projekt, ale to pozwoli nam w ogóle poczuć, jak to w ogóle działa. No i ja bym przede wszystkim zachęcał do tego, żeby się nie bać ekonomii, żeby eksperymentować i po prostu sprawdzić samemu, bo to jest to, co moim zdaniem jest ważne. Ja w jednej z firm, w której pracowałem, jak zmienił się nam zarząd i padł tam pomysł, że jednak wychodzimy z chmury, to po prostu już tam nie pracuję. To jest tak proste. Więc sprawa jest taka, że jeżeli chcecie w swoich organizacjach mieć osoby, które stawiają sobie za cel rozwój, które chcą piąć się po szczeblach kariery, uczyć się coraz lepszych rzeczy, lepszych technologii, to one nie będą chciały pracować na technologiach, które są outdated. Po prostu jeżeli chcecie mieć kogo zatrudniać, to musicie też się postarać o to, żeby to środowisko pracy nie tylko było fajne, żeby tam były owoce i odpowiednie wynagrodzenia, ale żeby też to, przy czym się pracuje, dawało pracownikom poczucie, że rzeczywiście robią to, co lubią. No i przede wszystkim bardzo ważne jest to, żeby rzeczywiście dawać swoim zespołem technicznym takie same narzędzia jak ma konkurencja. To jest trochę tak jakbyś był stolarzem i dostałbyś tylko ręczną piłę, a konkurencja miałaby profesjonalne narzędzia z wyrzynarkami i piłami tarczowymi włącznie. No to ciężko jest zrobić to po pierwsze z taką samą jakością, a po drugie w takim samym tempie. I bezpieczeństwo. Bardzo często nasi klienci się obawiają umieszczenia czegoś w chmurze, czują się znacznie bezpieczniej w jakiejś tam pojedynczej serwerowni, która jest blisko nich. Natomiast zdarzają się takie rzeczy jak ransomware, zdarzają się takie rzeczy jak pożar. Jak ja sobie przypominam, jak ja zgrywałem na płyty DVD i chowałem je w sejfie i wpisywałem do protokołu backup, bo takie były wtedy wymagania prawne, a teraz po prostu mógłbym to zautomatyzować i wrzucić to do dwóch regionów, które są kilkaset kilometrów oddalone w formie zszyfrowanej i po prostu ustalić to raz i tylko spojrzeć w logach, czy wszystko działa, to jest zupełnie inna kultura pracy. Czyli można te wymagania bezpieczeństwa jak najbardziej spełnić w chmurze. Mamy szereg tych certyfikatów, czy to w branży medycznej, czy w finansowej. Mamy bank w chmurze, stworzony przez zespół w Polsce w 100%. Więc na pewno jeżeli chodzi o bezpieczeństwo, to też jest coś, co śmiało można sprawdzić dla konkretnego jest US Case’u i gorąco zachęcam do eksperymentowania, do niepolegania tylko na jakichś obiegowych opiniach, tylko po prostu na sprawdzeniu w swoim własnym US Case. To jest moim zdaniem najlepsze, żeby nie wierzyć w prezentację, które się gdzieś tam widziało czy brać od razu na wiarę wszystko to, co się zobaczy na jakiejś konferencji, tylko po prostu przetestować. I większość klientów, która rzetelnie zrobiła test, podejmuje takie decyzje, że jednak chcą rozwijać swoje rozwiązania chmurowe.

Trudno o lepsze zakończenie, które wysyłamy w świat przedsiębiorców. Krzysztof Zalasa był naszym gościem. Customer Engineer w firmie Google. Mam nadzieję, że komuś będzie dane właśnie mieć styczność z tym człowiekiem na drodze rozwoju swojego produktu. Krzyśku, bardzo dziękuję Ci, że byłeś z nami i mogłeś podzielić się doświadczeniem i wiedzą na tym obszarze.

Konrad, bardzo Ci dziękuję za bardzo fajne pytania i dziękuję słuchaczom za uwagę.