Jak przenieść firmę do chmury?

Subskrybuj nas: | |

Streszczenie odcinka:

⚫️ Przedstawienie Gościa
⚫️ Czym zajmuje się Twoja firma?
⚫️ Jak firma powstała?
⚫️ Dlaczego występujecie na konferencjach i organizujecie warsztaty? Czy jest to forma reklamy?
⚫️ Gdzie jeszcze można Cię spotkać?
⚫️ Dlaczego właśnie chmura? Co rozwiązania chmurowe mogą dać organizacji, która ją wdraża?
⚫️ Z jakimi firmami – co do wielkości/branży – pracujecie?
⚫️ Kiedy wdrożenie chmury w firmie jest opłacalne?
⚫️ Co trzeba przewidzieć w takim procesie?
⚫️ Czy wdrożenie rozwiązań chmurowych jest tożsame z transformacją cyfrową?
⚫️ Na co jeszcze trzeba zwrócić uwagę, aby wdrożenie chmury zakończyło się sukcesem?

Transkrypcja odcinka:

Cześć! Witam Was w kolejnym odcinku podcastu Stacja IT. Z tej strony Łukasz Kobyliński. Dzisiaj porozmawiamy z Wojciechem Gawrońskim, prezesem firmy Pattern Match, o tym, jak zrobić firmę, która zajmuje się wdrażaniem i utrzymywaniem usług w chmurze publicznej. Powiemy też o tym, czym jest chmura publiczna i dlaczego warto ją wdrożyć, a także kiedy warto to zrobić.

Cześć, Wojtek. Dzięki za znalezienie chwili, żeby z nami porozmawiać. Na początek powiedz, proszę, kilka słów o sobie.

Cześć. Nazywam się Wojciech Gawroński, jestem architektem rozwiązań chmurowych oraz współwłaścicielem firmy Pattern Match. Tematyką chmury zajmuję się od 2015 r.

Czy zajmuje się firma Pattern Mach?

Specjalizujemy się w projektowaniu, implementacji, wdrażaniu oraz doradztwie dotyczącym chmury publicznej i takiego pojęcia, które dość szeroko określa się mianem architektury cloud native.

Pomagacie firmom wdrażać chmurę czy zajmujecie się utrzymaniem rozwiązań już istniejących u klientów? Co jest przeważającym zadaniem w waszej firmie?

Na ten moment większość z tych rzeczy, którymi się zajmujemy, to implementacja. Doradzamy też oczywiście przy tematach migracyjnych, implementacyjnych. Projektujemy i pomagamy projektować. Wszystko krąży wokół tematyki cloud native, czyli budowy rozwiązań, które są projektowane i budowane z myślą o chmurze. Czyli nie jest to tylko migracja i tematy migracyjne, ale już takie, w ramach których projektujemy konkretne rozwiązania i chcemy, żeby one były osadzone od pierwszego dnia właśnie w ramach chmury publicznej.

Czy to są specyficzne projekty związane z przetwarzaniem dużej ilości danych albo wymagające dużej infrastruktury? Jak należy rozumieć to hasło cloud native? Kiedy ono się najczęściej pojawia?

To jest bardzo ciekawe pytanie, bo w zasadzie nie ma jakichś specyficznych ograniczeń czy rekomendacji, kiedy stosować i kiedy podchodzić do tego tematu. Oczywiście są pewne domeny czy problemy biznesowe, które lepiej aplikują się do tej tematyki, natomiast generalnie nia ma żadnych ograniczeń ani obostrzeń na temat tego, kiedy powinniśmy się tym tematem zajmować i kiedy go stosować. Najlepiej porównać to z tym, w jaki sposób kiedyś podchodziliśmy do tematu projektowania aplikacji. Wtedy na samym starcie myślało się o tym, gdzie znajdziemy serwery, czy powinniśmy mieć fizyczną infrastrukturę, może jakąś kolokację, hosting. Podobnie jest teraz, tyle że ukierunkowujemy się na wykorzystanie chmury publicznej i na to portfolio, które oferują nam dostawcy chmury, tak żeby od pierwszego dnia najlepiej wykorzystać to, co mamy dostępne, i jednocześnie w efektywny sposób wykorzystywać w dalszym rozwoju i utrzymaniu tej aplikacji.

Jeśli ktoś zastanawia się, czy jego projekt powinien być cloud native czy jednak chce skorzystać z bardziej klasycznych rozwiązań, to na jakiej podstawie powinien podjąć decyzję? Czy to wynika z jakichś decyzji biznesowych polegających na kalkulacji kosztów czy kalkulacji dodatkowych kosztów związanych z utrzymaniem własnej infrastruktury, problemów z tym związanych? Krótko mówiąc, skąd wiem, że chcę, żeby mój najbliższy projekt był cloud native, a nie klasyczny?

Generalnie tutaj jest kilka różnych motywacji. Najczęściej pojawiają się dość typowe uzasadnienia, jeżeli chodzi w ogóle o temat chmury publicznej, czyli elastyczność. Mamy możliwość wykorzystania szerokiego portfolio oraz szerokich możliwości tego, co dają nam dostawcy chmury publicznej. Mamy oczywiście skalowalność, czyli nieskończone zasoby, które bardzo często są reklamowane w ramach tego, co dostawcy nam oferują. Mamy zwinność i możliwość zmiany pewnych podejść i odłożenia decyzji architektonicznych w czasie, bo to jest chyba najważniejsza cecha tej zwinności. Też optymalizacja kosztów i w ogóle – zmiana sposobu myślenia o kosztach, bo chmura dość mocno zmienia ten aspekt w ramach tego, jak organizacje z tym pracują.

Inną motywacją, która coraz częściej się pojawia, jest to, że dostawcy chmury dość kompleksowo atakują temat związany z wdrażaniem innowacji i wykorzystaniem innowacyjnych rozwiązań. Część organizacji podchodzi do tego na zasadzie mody i tzw. presji konkurencji albo tzw. dowodu społecznego, czyli: wszyscy mają, to my też będziemy mieli. Część organizacji podchodzi do tego bardzo świadomie pod kątem postępu technologicznego. Często określa się to stwierdzeniem „żabiego skoku” – te firmy starają się przeskoczyć pewne ograniczenia, które miały do tej pory, i jednocześnie wraz z tym skokiem zaatakować nowe podejście czy nowe paradygmaty, nowe rozwiązania wykorzystywać w swojej organizacji. To wszystko wiąże się z tym, jak chmura jest definiowana i jakie cechy ze sobą dostarcza. Najczęściej tego typu motywacje się pojawiają.

Natomiast do nas zgłaszają się firmy praktycznie z każdej branży, np. z e-commerce’u, IoT, sektora usługowego, branży finansowej, travel & hospitality – nie tylko z każdej branży, ale też pod kątem każdego rozmiaru. Mamy tu do czynienia z rodzącymi się biznesami, ze średnimi, tzw. SMB, aż do olbrzymich, międzynarodowych korporacji. Niezależnie od tego, o czym tu mówimy i w którym temacie się obracamy, te firmy wykorzystują chmurę w taki sposób, żeby jedna z tych motywacji, o których mówiłem, była dla nich na pierwszym miejscu.

Dlaczego zdecydowaliście się zajmować projektami cloud native, a nie transformacjami istniejących projektów? Powiedz przy okazji w kilku słowach o genezie powstania firmy i dlaczego akurat taki produkt, a nie inny.

Zaczęliśmy w 2018 r. Pracowaliśmy wtedy nad dużymi wdrożeniami. W tamtym czasie pracowaliśmy nad wdrożeniami dotyczącymi przenosin, nie migracji, natomiast zauważyliśmy, że długofalowo te nowe aplikacje i rozwiązania narodzą się właśnie w chmurze i będą ją traktowały jako pierwsze i docelowe środowisko. Temat migracji jest sam z siebie dość skomplikowany i wymaga i specyficznych umiejętności, ale też świetnej znajomości środowiska, które próbujemy zmigrować. Bardzo często tego typu projekty same z siebie stawiają dodatkowe wymagania i problemy, a jednocześnie zawsze są jakieś ograniczenia, czy to związane z architekturą, czy z tym, jak organizacji wykorzystuje daną chmurę. Zauważyliśmy, że w momencie kiedy mamy tego typu ograniczenia, obostrzenia, dużo większe wyzwanie stanowi wykorzystanie tej chmury w stu procentach, tak żeby organizacja miała z tego jak największy zysk czy wartość biznesową. Z drugiej strony, jeżeli do pewnych tematów podejdziemy natywnie, naturalnie od strony chmury publicznej, to mogą nieść ze sobą dużo większy zwrot z inwestycji. Dlatego postanowiliśmy skupić się właśnie na architekturze cloud native i na tematyce związanej z już docelowym myśleniem o chmurze jako takiej pierwszej platformie.

Przyglądając się temu, co robicie, zauważyłem, że jesteście aktywni w środowisku konferencyjnym, że jesteście proagentami. Zastanawia mnie, czy jest to świadoma polityka firmy czy sposób na reklamę, pokazanie się indywidualnych osób, co swoją drogą też jest mi bliskie, ponieważ w Sagesie zawsze staraliśmy się być aktywni w środowisku konferencyjnym. Jak to wygląda z waszej strony?

Skłamałbym, gdybym powiedział, że nie liczymy na reklamę. Oczywiście, że tak. Natomiast z drugiej strony czujemy i wiemy, że posiadamy unikalną wiedzę w tym temacie i chcemy to podkreślać. Stąd nasza obecność na konferencjach, w organizowaniu warsztatów i webinarów. Temat reklamy staramy się traktować jako taki skutek uboczny. Nasza załoga jest bardzo doświadczona i ma taką wewnętrzną chęć dzielenia się wiedzą. Oprócz tego, co widać na konferencjach i warsztatach, w naszej organizacji spotykamy się przynajmniej raz w tygodniu na takich wewnętrznych prezentacjach i wymianie wiedzy, gdzie uczymy się od siebie nawzajem.

Kolejna rzecz to sposób naszej pracy. Dla nas bardzo ważny jest aspekt komunikacyjny i ludzki. Jesteśmy przede wszystkim inżynierami i komunikacja z tą samą grupą ludzi idzie nam sprawnie, natomiast wdrażanie zmian w organizacji i praca z takimi tematami jak chmura publiczna to niewątpliwie tematyka, która zahacza o klarowną komunikację z wieloma grupami, o umiejętności sprzedania i komunikowania tych pomysłów w odpowiedni sposób. Więc dzięki tego typu prezentacjom, warsztatom i tym podobnym mechanizmom możemy pracować nad sposobami komunikowania się i nad tym, czy to jest na tyle klarowne i wartościowe, żeby można było z tego później skorzystać. Więc staram się tu połączyć kilka różnych aspektów. I pewnie gdzieś na samym końcu ważne jest dla nas, żebyśmy byli postrzegani jako eksperci w branży, bo jest to pewnego rodzaju nagroda na sam koniec.

Powiedz kilka słów o składzie firmy, bo powiedziałeś, że są to osoby doświadczone, które lubią dzielić się wiedzą. Jak w ogóle doszło do powstania firmy? Jak to się stało, że obecny skład stanowi w tej chwili trzon tej firmy?

W tym momencie mamy 14 osób na pokładzie. Wszystkie mają co najmniej osiem lat doświadczenia w IT, natomiast większość ma powyżej 10, a są też osoby, które mają i 15. Poznaliśmy się w sześć osób jako współzałożyciele przy jednym z projektów, który wykonywaliśmy dla międzynarodowej korporacji. Jak zobaczyliśmy, w jaki sposób pracujemy, jakie wartości są dla nas ważne we współpracy ze sobą, to stwierdziliśmy, że warto by było z tego skorzystać i zbudować dookoła tego wspólny biznes, a potem zaczęliśmy zapraszać kolejne osoby, które tworzą naszą załogę i cały ten trzon.

Jesteśmy firmą relatywnie niewielką w porównaniu do dużych firm, zajmujących się konsultingiem czy doradztwem, ale też firmą złożoną w stu procentach z doświadczonych inżynierów. Staramy się kłaść spory nacisk na to, w jaki sposób się komunikujemy i pracujemy z klientami. To nie jest tak, że u nas pracuje się z dużą drabiną i hierarchią od strony Account Manager – mamy też te wszystkie tematy związane z business developmentem – my wszyscy zajmujemy się tym samodzielnie. Stosunkowo niedawno dołączył do nas Jakub, który zajmuje się tematem marketingowym. Dla niego nowością było to, jak firma może być zorganizowana wokół tak naprawdę tylko inżynierskiej braci. Oczywiście to nie niesie ze sobą wyłącznie samych zalet, natomiast widzimy tu dużą zaletę pod kątem wartości, o jakie nam chodzi, oraz sposobu, w jaki chcemy pracować z naszymi klientami.

Wspominaliśmy o konferencjach. Powiedz, jak to bezpośrednio u ciebie wygląda. Ubiegły rok był specyficzny z powodu pandemii, więc tych konferencji było mniej, ale gdyby ktoś chciał dowiedzieć się więcej o tematyce chmury, to gdzie ciebie może znaleźć w internecie lub na żywo?

Staram się chętnie dzielić wiedzą. Takim naturalnym miejscem są albo media społecznościowe – najaktywniejszy jestem na LinkedInie, na Twitterze i na Instagramie – oraz mój blog i kanał na YouTubie, czyli AWS Maniac. To jest takie miejsce, w którym dzielę się wiedzą w tematyce chmury publicznej Amazon Web Services. Oprócz tego są jeszcze dwie rzeczy, z których jestem szczególnie dumny. W tym roku pandemicznym, z racji tego, że czasu było więcej, udało się pomóc i przetłumaczyć książkę Gojko Adžicia Działaj z Serverless dla wydawnictwa PWN. Zostałem również kierownikiem studiów i wykładowcą na studiach podyplomowych na Akademii Leona Koźmińskiego na kierunku dotyczącym wykorzystania chmury publicznej w biznesie oraz wykładowcą na tej samej uczelni na kierunku związanym z tematyką big data i analizy danych.

Wróćmy do tematyki samej chmury i korzyści, które ona niesie. Zgłaszają się do was firmy z różnych branż i różnej wielkości, sporo się o tym ostatnio mówi. Co według ciebie jest kluczową wartością powodującą, że faktycznie warto inwestować w tę chmurę i nowe projekty na niej opierać, czy jak to określiłeś: stosować podejście cloud native w projektach?

Zacznę trochę od drugiej strony i powiem, czego uważam, że nie powinno się robić, i może z tej przekory wyjdzie coś ciekawego. Ja uważam, że w temacie chmury publicznej nie warto kierować się modą i tym, co mówi dowód społeczny albo co robi konkurencja. Temat chmury publicznej i w ogóle technologii powinien w pierwszej kolejności służyć biznesowi. Jeżeli my widzimy realne zalety i realne zyski z tego, że bylibyśmy w stanie z pomocą jakiejkolwiek technologii wspomóc wzrost naszego biznesu, wykorzystać dodatkowe źródła dochodu, zastanowić się, w jaki sposób pracować bardziej wydajnie i efektownie, to wtedy wdrożenie każdego rodzaju usprawnienia w tym kierunku, czy to technologicznego, czy związanego z transformacją cyfrową, może być pożyteczne. Odnośnie samej chmury, tego, co ona daje, to skupienie się w na tym, co krótkofalowo i długofalowo jesteśmy w stanie osiągnąć i jaki zwrot z inwestycji nas interesuje.

Bardzo często do tematu chmury podchodzi się właśnie od strony motywacji związanej z elastycznością, zwinnością i skalowalnością, ale w tej tematyce, kiedy próbujemy np. budować rozwiązania research & development albo staramy się rozpoznawać nowe rozwiązania w tej materii, dużo ważniejsze są tematy związane z time to market, czyli jak szybko będziemy w stanie dane rozwiązanie zwalidować i zweryfikować pod kątem bazy klientów, jak szybko będziemy w stanie pewne innowacyjne tematy dowieźć, nie mając do końca tak silnie zbudowanej kompetencji wewnątrz naszych zespołów. I dostawcy chmury publicznej pomagają w takim aspekcie, którego często używa się również w temacie innowacji. Jeżeli je mamy, to kolejne pytanie, które też warto sobie zadać w kontekście wdrożenia w oparciu o chmurę, brzmi: czy nie jesteśmy w stanie dość pragmatyczny podejść do tego tematu budowy kompetencji, wykorzystać to, co oferuje portfolio dostawców, i dzięki temu zbudować jakieś rozwiązanie szybciej lub oddelegować skomplikowane tematy, które niekoniecznie nas satysfakcjonują, bo nie są np. rdzeniem naszej działaności biznesowej, właśnie dostawcom i skorzystać z tego, co oni oferują.

Masz na myśli te dodatkowe usługi, które oferują chmury publiczne w zakresie sztucznej inteligencji, przetwarzania mowy, obrazu, które zasadniczo możemy wykorzystać jak gotowy produkt, płacąc tylko za moce wykorzystane w celu realizacji poszczególnych zadań?

Tak, jak najbardziej. Ja tylko wzbraniałbym się przed tym, żeby mówić, że to jest coś dodatkowego. Temat chmury i jej wykorzystania dość mocno zszedł na taką dyskusję pt. „Czy używamy rozwiązań?”. Kiedyś to była dyskusja na temat wirtualizacji, teraz to jest dyskusja na temat Kubernetesa czy rozwiązań klasy serverline. Cały czas zapomina się o tym, że chmura to bardzo duży zestaw usług na różnym poziomie konsumpcji. Mamy możliwości, żeby wykorzystywać pewne usługi na bardzo niskim poziomie abstrakcji, czyli np. projektować sieci wirtualne, używać wirtualizacji, korzystać z tych maszyn wirtualnych, jak to robiliśmy do tej pory, instalować rozwiązania platformowe, np. Kubernetes albo jakiekolwiek inne rozwiązania typu OpenShift, na tym stawiać dużo wyższe poziomy abstrakcji, ale mamy też cały szereg usług, które wspomagają to wszystko i dzięki temu, że mamy je dostępne w portfolio, możemy z nich skorzystać i budować w ich oparciu pewne innowacyjne rzeczy.

To wszystko jest wypadkową tego, co tak naprawdę organizacja chce osiągnąć i z jakiego problemu biznesowego wychodzimy. Bo jeżeli jesteśmy firmą technologiczną i rdzeniem naszej działaności biznesowej jest budowa technologii, z której będą korzystali inni konsumenci, nasi klienci, to w tym momencie warto się zastanowić, czy my nie jesteśmy jednym z takich dostawców. Z drugiej strony, jeżeli rdzeniem naszej działaności biznesowej jest konkretna domena, np. e-commerce, temat związany z rezerwacją miejsc hotelowych albo udostępnianiem i przetwarzaniem plików wideo, wtedy naszym naczelnym zadaniem jest dostarczenie konkretnej funkcjonalności klientom, a nie budowa platformy technologicznej. Ta budowa platformy technologicznej bardzo często sprowadza się do spędzania masy czasu na tym, co nie jest rdzeniem działaności biznesowej, nie jest w niej najważniejsze i nie przynosi nam bezpośredniego zysku. I bardzo często ten temat jest atakowany przez architekturę cloud native. Zastanówmy się nad tym, co jest rdzeniem naszej działaności biznesowej, jak zbudować to w oparciu o zestaw usług, które oferują nam dostawcy, w jaki sposób też jesteśmy w stanie to ryzyko zbalansować, bo mówimy tutaj o różnego rodzaju ryzykach, np. związanych z vendor lock-inem albo innymi problemami. Mając do dyspozycji tego typu wachlarz, jesteśmy w stanie do tego podejść dużo bardziej pragmatycznie, niekoniecznie budując technologie po to, żeby dostarczać wartość, tylko w pierwszej kolejności skupić się na tym, żeby tę wartość dostarczać.

Czy znasz przykłady takich rozwiązań, które uznałbyś za dobry sposób wykorzystania chmury, coś, co zajęłoby dużo czasu, gdyby to realizować samodzielnie, a z wykorzystaniem chmury publicznej taki time to market byłby dużo krótszy i korzyść biznesowa z tego wysoka?

Pracowaliśmy z jednym ze startupów amerykańskich, który wprowadzał na rynek nowy produkt z branży IoT, coś na kształt smart home automation. Wiadomo, że w takim przypadku rdzeniem tej działaności jest już samo urządzenie. Natomiast te urządzenia klasy smart rzadko kiedy działają w oderwaniu od wszystkiego innego. Jeżeli mamy do czynienia z internetem rzeczy, to wszystko jest w tym momencie podłączone już do internetu i komunikuje się aktywnie z jakimś backendem. Najważniejsze z perspektywy tamtej firmy było zwalidować pomysł i dostarczyć te urządzenia do klientów w jak najszybszy sposób, nie zapominając też o pewnych ważnych elementach, jak np. bezpieczeństwo, wydajność tego rozwiązania, zaadresować wymagania związane nie bezpośrednio ze sprzętem, ale bezpośrednio z obsługą tego, z czego ten sprzęt korzysta na samym końcu, czyli z tej platformy typowo backendowej, backoffice’owej. Wiadomo, że do tego jest jeszcze wymagana aplikacja mobilna, która też z tego backendu korzysta. I w tym momencie zaczynamy wracać do tego tematu time to market.

Z perspektywy firm najważniejsze jest to, żeby wypuścić dobre, jakościowe rozwiązanie, które jest oparte o sprzęt, nie zapominając o tym, że część tych środków i sił trzeba będzie też poświęcić na poprawne zbudowanie tej infrastruktury backendowej. Jeżeli budowaliby to bez pomocy dostawców lub takich firm jak nasza, to spędziliby nad tym wielokrotnie więcej czasu i pieniędzy, bo nie byliby tak naprawdę w stanie zaadresować tych podstawowych rzeczy, tylko musieliby budować to od podstaw, samodzielnie. Z drugiej strony, w momencie kiedy wykorzystują to, co oferują dostawcy na swoich platformach, skracają ten czas wypuszczenia, oszczędzając też pieniądze. Na samym początku te rozwiązania nie osiągają jakiejś kosmicznej skalowalności, więc nie musimy się też przejmować od początku tematem zużycia kosztów i tego, ile to rozwiązanie koniec końców nas kosztuje. Jeżeli jesteśmy w stanie ponieść jakąś inwestycję na początku, potem można to optymalizować i cały czas ograniczać, ale przesunęliśmy ten początkowy koszt dotyczący pracy typowo ludzkiej związanej z developmentem, troszeczkę oddaliśmy od tego kosztu dostawcy. Dzięki temu, że on miał przygotowane już jakiejś rozwiązania, pozwolił nam wypuścić to całe rozwiązanie szybciej, a my zaoszczędziliśmy i mogliśmy skupić się na budowie tego, co było najważniejsze, czyli tego rozwiązania sprzętowego.

Innym przykładem, który bardzo mocno dał nam do myślenia w kontekście tego, jak time to market może być krytyczny, był jeden z takich projektów, który wykonywaliśmy razem z naszym klientem w branży loss prevention. Razem z firmą DTiQ pracowaliśmy nad rozwiązaniem, które adresowało taki problem związany z pandemią COVID-19, czyli occupancy monitoring. DTiQ jako firma pracuje właśnie w temacie loss prevention, gdzie za pomocą swojego rozwiązania, które wpięte jest do infrastruktury kamer przemysłowych w wybranych lokacjach, np. w restauracjach szybkiej obsługi, punktach sklepowych, ma możliwość monitorowania i śledzenia ilości osób znajdujących się w danym obiekcie. I w momencie kiedy pojawiła się pandemia COVID-19, kiedy weszły obostrzenia i trzeba było zapewnić wymogi reżimu sanitarnego, ile osób jest w danej lokacji, podjęli oni decyzję, że chcieliby wypuścić w ciągu miesiąca produkt, który adresowałby tę konkretną potrzebę, czyli monitorowanie tego, ile osób jest na lokacji. Biznes przyszedł z konkretnym wymogiem do zespołu technicznego. Zespół techniczny powiedział: „Jesteśmy w stanie to dowieźć pod warunkiem, że będziemy korzystali z tych, tych i tych usług w ramach platformy dostawcy chmurowego, z którego korzystamy. W innym przypadku zajmie nam to trzykrotnie więcej czasu”. Biznes dał zielone światło i powiedział: „Zróbmy to w ten sposób”. Udało się to dowieźć w wymaganym czasie miesiąca, oczywiście z odpowiednim naciskiem na cięcie zakrętów, czyli np. tematy bezpieczeństwa nie mogły zostać pominięte, ale nie musieliśmy myśleć od początku nad stuprocentową skalowalnością tego rozwiązania ani przejmować się kosztami. Dzięki temu kupiliśmy sobie czas, dowieźliśmy to rozwiązanie, zwalidowaliśmy jego sens biznesowy, a potem dzięki temu, że byliśmy już na wdrożeniu, na produkcji, mogliśmy iterować z tym rozwiązaniem, cały czas je usprawniając i dowożąc. Gdybyśmy tego nie zrobili w przeciągu miesiąca, istniałoby spore ryzyko, że po pierwsze nie udałoby się tego pomysłu w ogóle zwalidować, a po drugie było takie ryzyko i taka szansa, że obostrzenia by minęły i temat nigdy by nie wrócił. A mamy teraz taką sytuację, że pandemia całe szczęście chyli się ku zachodowi i niedługo nie będziemy musieli się tym tematem przejmować. Klienci DTiQ zauważyli, że będą w stanie skorzystać z tego occupancy trackingu nie tylko w celu zapewniania wymogów reżimu sanitarnego, ale też do innych elementów, np. związanych z opłacalnością danej lokacji, z tym, czy powinno się tam znajdować tyle a tyle obsługi, punktów obsługowych itd., czyli z tematem analityki i optymalizacji. I to wszystko powstało dzięki temu, że byliśmy w stanie w ciągu miesiąca zwalidować pewien pomysł, przedstawić go rynkowi i na bazie feedbacku działać dalej.

W kontekście tego, o czym powiedziałeś odnośnie wyboru dostawcy usług chmurowych, to czy właśnie tym kryterium wyboru chmury publicznej coraz częściej jest ten zestaw usług, który nas interesuje, który jest nam potrzebny, żeby dowieść tę wartość biznesową, czy nadal patrzy się głównie na koszty? Jak to w tej chwili wg ciebie wygląda?

Podejrzewam, że to wszystko jest mocno zależne od tego, co chcemy osiągnąć. Mamy tu kilka różnych płaszczyzn, jedną z nich jest koszt, o którym wspomniałeś. I na pewno to będzie ważny temat w przypadku wielu organizacji. W przypadku wielu innych biznesów – temat bezpieczeństwa i tego, w jaki sposob ten sprzęg bezpieczeństwa z naszą infrastrukturą, którą posiadamy, będzie wykonany. I zaczynamy tutaj wchodzić w ten temat przewidywania, a to sugeruje, że istnieje złoty środek, szklana kula, która nam powie, jakie rozwiązanie jest właściwe. Ja jestem wielkim zwolennikiem tego, żeby podchodzić do tych tematów w oparciu o dane. Iterować, mierzyć i robić to ciągle. Jeżeli organizacja ma już konkretnego dostawcę, a tak się często zdarza, bo np. rozwiązania firmy Microsoft były dość mocno rozpowszechnione w konkretnej organizacji, czy to mówimy o Office 365, czy o SharePoincie, o kontrolerach domeny itd., to bardzo możliwe, że będzie nam łatwiej wejść w ekosystem tego konkretnego dostawcy z racji tego, że firma już z niego korzysta.

Z drugiej strony na pewno ważnym aspektem jest to, jakie portfolio usług jest dostępne u tego dostawcy. Bo jeżeli zależy nam na konkretnym rozwiązaniu i widzimy, że zupełnie inny dostawca oferuje to rozwiązanie, to myślę, że będziemy skłonni i tak wciągnąć tę technologię czy tego konkretnego dostawcę do naszej organizacji nawet kosztem tego, że będzie to coś nowego, jeżeli to będzie rozwiązywało nasz konkretny problem biznesowy i oszczędzało czas albo środki. Moim zdaniem to jest bardzo wielopłaszczyznowe. Nie chcę odpowiadać jak typowy, bezużyteczny konsultant „to zależy”, ale do tematu chmury publicznej, do tematu związanego z wdrożeniami najrozsądniej jest podejść od początku i od tej motywacji biznesowej, czyli jaki problem tak naprawdę chcemy rozwiązać, na czym nam najbardziej zależy, jakie są wymagania funkcjonalne i niefunkcjonalne, które musimy spełnić.

Jak w tej chwili wygląda kwestia szacowania kosztów wykorzystania tej infrastruktury? Czy jest to jakoś ułatwione w stosunku do tego, co działo się powiedzmy na wczesnym etapie wdrażania chmury, czy nadal oszacowanie tych kosztów jest to dosyć dużym wyzwaniem? Krótko mówiąc, jeśli przychodzi do was klient i mówi, że chce zrobić to i to, to czy możecie oszacować swój koszt pracy i powiedzieć, ile będziecie musieli poświęcić pracy osobowej, natomiast jeśli musicie doliczyć do tego koszty wykorzystania chmury, to czy jest to trudne zadanie czy nieszczególnie?

Tutaj są znowu dwa ważne elementy. Pierwszy z nich dotyczy tego, jak dobrze mamy sprecyzowany projekt, konkretne rozwiązanie do przygotowania. Jeżeli mamy dość precyzyjnie określone wymagania, np. funkcjonalne, niefunkcjonalne, związane z wydajnością, z ilością użytkowników, da się to wszystko przygotować i wyliczyć. Oczywiście nie z dokładnością co do centa, ale z dość dużym przybliżeniem, które daje nam odpowiednią dozę szacowania ryzyka, szacowania tym ryzykiem i ograniczenia tego ryzyka, że, mówiąc kolokwialnie, nie pójdziemy z torbami na samym końcu. Natomiast da się to zrobić i da się to w miarę precyzyjnie oszacować, jeżeli mamy dość precyzyjnie określony projekt.

Z drugiej strony są też projekty, które bardzo ciężko oszacować na samym początku i dość precyzyjnie powiedzieć, w co mierzymy. Oczywiście możemy się ograniczać i mówić, że w pierwszej fazie czy to w NVP będziemy usatysfakcjonowani, jeżeli zdobędziemy tyle a tyle użytkowników, tyle a tyle innych kluczowych elementów, które bezpośrednio wpływają na te koszty. Natomiast w takich rozwiązaniach najlepiej jest znowu narzucić sobie pewne ograniczenia i na ich bazie przyjąć pewien punkt odniesienia. Czyli starać się przygotować model kosztowy i w jego ramach operować i myśleć. Z reguły przygotowanie tego modelu kosztowego jest możliwe dla większości projektów, a jeżeli jest niemożliwe dla tego konkretnego projektu, to znaczy, że my też nie do końca dobrze biznesowo zwizualizowaliśmy obraz tego, co ten projekt powinien robić, czym to konkretne rozwiązanie powinno się zajmować. Można do tego podejść tak: jeżeli nie wiemy, jak to zmierzyć, to być może nie jest to do końca doprecyzowane od strony funkcjonalnej.

Kiedyś faktycznie było tak, że brakowało i narzędzi, i te cenniki też nie były do końca dobrze zrozumiałe, bo było to coś nowego. W czasach, kiedy w zasadzie każdy z nas ma model subskrypcyjny w domu podpięty do swojej karty kredytowej czy to w formie Netfliksa, czy jakichś innych rozwiązań, intuicyjnie czujemy, jak wygląda ten model subskrypcyjny płatności. Dużo lepiej jest to rozpowszechnione i nie ma problemu związanego z edukacją, który był dawniej. Natomiast od strony narzędziowej i tych tematów cennikowych de facto niewiele się zmieniło, jeżeli chodzi o te możliwości.

Jest jeszcze jedna płaszczyzna, mianowicie temat migracyjny i porównania tych kosztów w stosunku do tego, jak wygląda rozwiązanie oparte o chmurę publiczną, a jak wyglądałoby to rozwiązanie, jeżeli mielibyśmy je oparte o własną infrastrukturę. Pojawia się ciągle problem związany z tym, że porównujemy ze sobą zupełnie inny zestaw kosztów. Bo mamy do czynienia z tematem kosztów inwestycyjnych, tzw. CAPEX (ang. capital expenditures) oraz OPEX (ang. operarating expenditures). W obu przypadkach możemy porównywać jedno z drugim. I na pierwszy rzut oka chmura będzie miała dużo wyższe koszty operacyjne niż rozwiązanie własnej infrastruktury, bo cały czas płacimy za zużycie, ale z drugiej strony ciężko porównywać te dwie rzeczy ze sobą jeden do jeden bez pewnych założeń.

I najczęściej pojawia się tu temat, który nazywa się total cost of ownership, czyli staramy się wyliczyć całkowity koszt, który wynikałby nie tylko z posiadania naszej infrastruktury, tak jak to często się mierzy, czyli wlicza się te wydatki na sprzęt, ale oprócz tego doliczamy też wydatki związane z pracą ludzką, pracą administratorów, z utrzymaniem data centers, podtrzymaniem tego wszystkiego, co zostało wdrożone. I w tym konkretnym rozwiązaniu nawet dla niedużych projektów lub średnich chmura może zdecydowanie wygrywać, ponieważ dostawcy mają tę skalę dużo wyższą niż my. Oni się tym zajmują, specjalizują się w tym temacie, są też w stanie w odpowiedni sposób zindustrializować i zoptymalizować, że te koszty po ich stronie ponoszone są dużo mniejsze i na sam koniec oni są w stanie z tego więcej wyciągnąć niż my.

W naszej rozmowie często pojawia się kwestia przemyślenia projektów, celów biznesowych, stwierdzenia, o co nam tak naprawdę chodzi, żeby dobrze do danego projektu podejść i dobrze wybrać dostawcę. Jak wg ciebie wygląda taki idealny proces przygotowania się do projektu? Gdyby klient miał przyjść do was czy do innej firmy, żeby zgłosić zapotrzebowanie wykonania jakiegoś projektu, to jak powinien przygotować się wewnętrznie w organizacji do takiego wdrożenia pierwszego projektu chmurowego, tak żeby zrobić to z głową i efektywnie?

Jeżeli firma nie ma doświadczenia z tematem chmurowym i to jest pierwszy projekt, to sugerowałbym, żeby zacząć od małej rzeczy: postarać się zidentyfikować miejsce, w którym ten potencjalny zysk da się zmaksymalizować przy niewielkim nakładzie pracy. To wymaga świadomości i znajomości tego, o jakim rozwiązaniu mówimy. Po prostu staramy się szukać takich nisko wiszących owoców, jak to się po angielsku mówi. Jakiego rodzaju są to rozwiązania? Jeden z naszych klientów przyszedł do nas, poszukując rozwiązania, ponieważ obecnie wdrożone monolityczne rozwiązanie nie spełniało wymagań od strony utrzymywalności tego produktu – przygotowanie nowego wdrożenia trwało np. sześć miesięcy, a wymaganie biznesowe było takie, żeby było skrócone przynajmniej sześciokrotnie – do jednego miesiąca. Klient przyszedł do nas z takim konkretnym problemem biznesowym, czując gdzieś podskórnie, że architektura mikroserwisowa, cloud native, chmura publiczna będzie mogła tu pomóc. Dobrze zdefiniowany zestaw problemów i wyzwań, z którym też do nas przyszedł, bo tak naprawdę opisałem tylko wycinek tego, z czym do nas klient przyszedł, pomógł nam zaprojektować pierwszy warsztat i pierwsze spotkanie, podczas którego razem z ekspertami po stronie klienta, z architektami, z ekspertami domenowymi byliśmy w stanie przygotować konkretny plan i w ciągu sześciu miesięcy wydzielić elementy z tego monolitycznego rozwiązania, przenieść je na chmurę, spiąć z istniejącą infrastrukturą i dzięki temu skorzystać z elastyczności i zwinności modelu wdrożeniowego. Potem zaprojektowaliśmy kolejne kroki, zaczęliśmy wyciągać coraz więcej i więcej z tego rozwiązania. W tej sytuacji mieliśmy już istniejące rozwiązanie, dobrze zdefiniowany zestaw problemów – co często zdarza się w jednym i drugim przypadku – i mogliśmy to odpowiednio zaprojektować i przygotować.

Paradoksalnie troszeczkę ciężej jest z tymi rozwiązaniami, które istnieją na papierze jako pomysły, nie są jeszcze wdrożone i chcemy je zwalidować i zweryfikować. Bo tutaj mamy taki grunt, na którym ciężko jest dobrze zdefiniować problem, albo inaczej: trochę działamy po omacku. Znowu – tutaj lepiej zacząć od małego aspektu, starać się wydzielić z tej większej koncepcji mniejszy aspekt, zweryfikować go, zwalidować i iteracyjnym podejściem rozbijać go na mniejsze i przechodzić do przodu kawałeczek po kawałeczku. Więc ja bym się tu skupił po raz kolejny na analizie biznesowej i na wylistowaniu problemów, na których rozwiązaniu zależy nam najbardziej.

Ostatnio często pojawia się takie modne hasło „transformacja cyfrowa”. Jak ty to widzisz i jakie jest powiązanie transformacji cyfrowej z chmurą? Jak tu ta chmura może pomagać w transformacji cyfrowej?

Samo wdrożenie technologii nic nam nie da. Co więcej, bardzo wiele zależy od tego, co konkretnie wdrożymy. Jakiś czas temu przeczytałem taki raport pochodzący z jednej z instytucji europejskich dotyczący procentowej adopcji chmury publicznej w ramach Europejskiego Obszaru Gospodarczego. Czytając go, trochę się zezłościłem i włosy stanęły mi dęba, gdy zobaczyłem, że jednym z kryteriów wdrożenia chmury przez organizację i tego, że ten proces adopcji jest na określonym poziomie, było to, że wykorzystuje ona email i programy biurowe w chmurze. Nie mam nic do rozwiązań takich jak Office 365 czy Google Workspace, to są świetne rozwiązania, ale to nawet nie jest czubek góry lodowej, tylko to jest czubek czubka tej góry, o której mówimy w przypadku chmury publicznej. Ciężko mi sobie wyobrazić, że to jest uznawane za jeden z etapów wdrożenia technologii w ramach organizacji czy nawet można by to było to wyekstrapolować i powiedzieć, że to jest jeden z etapów transformacji cyfrowej. Ja jestem raczej sceptycznie do tego nastawiony i nie wiązałbym tych dwóch rzeczy. Chmura to jest jedno z rozwiązań, które pozwala nam przejść i transformować się do tego cyfrowego świata.

A znowu idąc w tę bardziej złośliwą stronę, bardzo często ten temat przewijał się przy okazji pandemii COVID-19, że to właśnie pandemia stała za transformacją cyfrową w konkretnych firmach, bo ona wymusiła pewne zachowania i pewne zmiany wewnątrz tych organizacji, np. przeniesienie komunikacji na typowo zdalną, możliwość uruchomienia zdalnych kanałów pracy itd. Chmura oczywiście tutaj mocno pomaga, natomiast uważam, że takie podstawowe aspekty typu email w chmurze, komunikacja w chmurze, programy biurowe w chmurze to jest naprawdę pierwszy krok i to nawet nie zaczyna dotykać tego tematu związanego z wdrożeniem chmury publicznej. Owszem mówimy tu o temacie transformacji cyfrowej, w jakimś kierunku to jest związane z transformacją cyfrową, natomiast temat wdrożenia chmury jest dużo bardziej skomplikowany. On nie dotyczy wyłącznie tych podstawowych środków pracy i narzędzi, z których korzystamy, ale też tego, w jaki sposób ludzie potem korzystają z tej chmury, budują kolejne rozwiązania czy pracują z nimi.

Czy w tym kontekście miałbyś jeszcze jakieś uwagi? Czy są jakieś kryteria takich wdrożeń, które kończą się sukcesem? Jakie są generalnie trendy w zakresie chmury publicznej? Na co zwracają uwagę klienci, którzy poszukują nowych rozwiązań? Jakie nowe usługi, które zmieniają jakoś rzeczywistość, ci dostawcy dostarczają?

Przede wszystkim w pierwszej kolejności zwróciłbym uwagę na aspekt ludzki i na zespół. Przejście przez zmianę jest ciężkie i to jest w miarę zrozumiały dla nas temat i dość popularny we wszelkiego rodzaju tematyce związanej z project managementem czy z tematem zarządzania ludźmi. Zawsze mówi się o tym, że przejście przez zmianę dzieli grupę na określone klastry, zawsze pojawiają się takie najbardziej oporowe jednostki, które będą przeciwne tej zmianie. I to jest bardzo ważny temat, o którym trzeba pamiętać przy wdrożeniu chmury publicznej. Aspekt ludzki w tym temacie jest często spłycany, a może pogrzebać nawet najlepszy plan i najlepsze rozwiązania technologiczne, np. dostawca będzie nam oferował bardzo szerokie portfolio, z którego będzie bardzo dumny, natomiast jeżeli po stronie naszej organizacji nastąpi opór i nastawienie do naszej zmiany będzie negatywne, to nic nam to rozwiązanie techniczne w zasadzie nie da, bo będziemy tak naprawdę blokowani.

Z czego ten opór najczęściej wynika? Z niechęci do stosowania nowych rozwiązań technologicznych, z działów technicznych, administracyjnych, które chcą mieć wszystko pod kontrolą i u siebie ten sprzęt, czy od osób decyzyjnych, które boją się kosztów?

Ze wszystkiego po kolei. Wydaje mi się, że każdy z tych aspektów, który wymieniłeś, można byłoby podać jako jeden z takich przykładów. Wydaje mi się, że one mają wspólny mianownik, mianowicie taki, że jeżeli my traktujmy temat technologii z nabożną czcią, zamiast zastanowić się, jakie problemy biznesowe nam to rozwiązuje, a zamiast tego stawiamy to na piedestale, mówiąc, że „od teraz mamy chmurę, która rozwiąże nam wszystkie problemy”, to tego typu postawienie sprawy raczej negatywnie wpłynie na całą resztę, która będzie bardziej sceptyczna niż na początku.

Podam tu konkretny przykład. Często w organizacjach pojawia się pomysł zbudowania tzw. cloud center od excellence, czyli zespołu kompetencyjnego, który powinien w założeniu wspomagać pozostałe zespoły w procesie adopcji chmury w ramach organizacji. To jest bardzo często grupa ekspertów, która świetnie sobie z tym tematem radzi, też najbardziej entuzjastyczne jednostki w organizacji, które zachęcają inne zespoły, inne osoby, żeby z tej chmury zacząć korzystać. I to jest dobre podejście pod warunkiem, że nie buduje się takiej kliki wewnątrz organizacji albo takiego „elitarnego klubu purpurowych szlafroków”, od tego momentu wszyscy członkowie tego klubu czują się elitarni, bardzo często zamykają się na inne głosy, tworzą sobie własną bańkę, w której pracują, nie są otwarci na kolektyw, na feedback i zamiast pomagać innym zespołom, to one je tylko sceptycznie nastawiają do całej zmiany, bo przychodzą i nam coś tu zmieniają, modyfikują, nie rozumieją naszego kontekstu, nie wiedzą, jak z nami pracować. Jednym z założeń takiego cloud center of excellence jest szerzenie tej wiedzy i wspieranie tych zespołów w procesie wdrażania rozwiązań opartych o chmurze. A jeżeli nam się to zdegeneruje w kierunku takiego oderwanego od rzeczywistości ciała doradczego, które świetnie radzi sobie w teorii, ale kompletnie nie ma odzwierciedlenia w praktyce, to do niczego dobrego to w organizacji nie doprowadzi. I potem trudno się dziwić, że osoby decyzyjne boją się, że to będzie zbyt drogie, że administratorzy nie czują tego, bo mieli do tej pory fizyczne rozwiązania, a teraz mają je gdzieś w chmurze rozrzucone. Trudno się dziwić, że takie opory się pojawiają, jeżeli my staramy się ewangelizować i przeprowadzać tę ewangelizację trochę na zasadzie takiego opowiadania wyłącznie o dobrych stronach i niepragmatycznego mówienia o tym, że „teraz to już będzie tylko lepiej”. Na pewno będzie inaczej. Trzeba sobie zdawać z tego sprawę i być świadomym tych ograniczeń, żeby to miało ręce i nogi. Dlatego ja uważam, że ten aspekt ludzki i podział na zespoły też jest ważny.

Nie bez znaczenia jest też temat nie tylko związany z aspektem przejścia przez zmianę, ale też tego, jak zespoły są zorganizowane w strukturze organizacyjnej. I prawo Conwaya działa w każdym aspekcie, nie tylko w aspekcie wdrożenia chmury publicznej, ale przede wszystkim w temacie wytwarzania oprogramowania. Prawo Conwaya mówi o tym, że struktura organizacyjna będzie odzwierciedlona tym, w jaki sposób budujemy rozwiązania IT, czyli jeżeli mamy kilka różnych działów, które komunikują się ze sobą w sposób asynchroniczny, to najprawdopodobniej w infrastrukturze albo w tym temacie związanym z wdrożeniem jakiegoś konkretnego systemu, będziemy mieli odzwierciedloną tę strukturę komunikacyjną w organizacji. Ten temat jest bardzo często widoczny. Jeżeli był dział IT, dział operation z działami administratorów w firmie, to bardzo często ten temat wdrożenia chmury zaczyna się od nich i zostawia się go im po wsze czasy. Izoluje się ich od całej reszty organizacji, dorzuca się im tylko dodatkowe rozwiązania, zamiast skupić się na tym, jak przekrojowo podejść do tego, jak zachęcić wszystkich w organizacji do przejścia przez ten proces zmian.

Często pojawiały się takie analogie, jak pojawiała się kultura DevOps w świecie IT. Że po to my robimy kulturę pracy DevOps, żeby nie przerzucać roboty przez mur. I rzeczywiście część organizacji poszła w tym kierunku, usprawniła swój proces, zaczęła słuchać, co mają administratorzy do powiedzenia, developerzy zaczęli współpracować ściśle z działem operations. Przyszedł temat chmury publicznej i nagle okazało się, że „OK, teraz tworzymy dział cloud center of excellence i oni będą zajmowali się tematem wdrożenia w chmurze”. I mamy kulturę DevOps, pojawiła się chmura i nagle okazuje się, że i tak tworzymy jakiś osoby dział, który od tego momentu zajmuje się chmurą w firmie. Więc te tematy są dość mocno powiązane i one dość mocno wpływają na siebie, a racji tego, że mamy tu do czynienia z aspektem ludzkim, to też nie do przecenienia, nie do pominięcia jest aspekt tego, że jeżeli na samym końcu nie będziemy w stanie jasno i klarownie powiedzieć, o co nam tak naprawdę chodzi i na czym chcemy się skupić, to wszelkiego rodzaju zmiana zostanie niezrozumiana i będzie też problematyczna przy wdrożeniu i wykorzystaniu.

Dziękuję za to spojrzenie od strony ludzkiej na ten cały proces. Jak myślimy „chmura”, „rozwiązanie cloudowe”, to raczej do głowy przychodzą nam wtedy kwestie technologiczne i problemy związane z tym, jak z tej chmury technicznie skorzystać, a ty ciekawie przedstawiłeś te problemy ludzkie. Dziękuję za rozmowę, za poświęcony czas. Wszystkich zainteresowanych zapraszamy do szukania ciebie w internecie w tych kanałach, o których na początku wspomniałeś, i do posłuchania ciebie na konferencjach i na studiach podyplomowych.

Dziękuję bardzo i do usłyszenia.