Aplikacje w chmurze publicznej

Krzysztof Kempiński
May 4 · 16 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Mateuszem Grzechocińskim o tworzeniu, uruchamianiu i utrzymaniu aplikacji w chmurze publicznej.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

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.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-113-aplikacje-w-chmurze-publicznej/

kkempin’s dev blog

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.