Czym jest architektura serverless, w której skupiamy się tylko na funkcjach biznesowych?

Z Adamem Lejmanem, CEO Altkom Software & Consulting rozmawiamy o zmianach w sposobie tworzenia oprogramowania; nowych architekturach, technologiach i wykorzystywanych narzędziach; wykorzystaniu kontenerów i zaletach budowy rozwiązań serverless; podejściu do realizacji projektów deweloperskich i wykorzystywanych w nich narzędziach; a także kierunkach rozwoju kompetencji w zespołach.

Jakie – na przestrzeni ostatnich 20 lat – nastąpiły zmiany w podejściu do rozwijania kodu i korzystania z narzędzi developerskich?

Pod koniec lat 90-tych – gdy tworzyliśmy pierwsze systemy korporacyjne – zespoły programistyczne i ich praca wyglądała całkowicie inaczej. Nie było zarządzania kodem i kontroli wersji, ani praktyk Continuous Delivery / Continuous Integration. Tymczasem teraz tego typu narzędzia i metody dynamicznie się rozwijają. 20 lat temu mieliśmy jedynie katalog sieciowy z kodem, który się współdzieliło. Teraz korzystamy w pracy z bardzo zaawansowanych narzędzi pozwalających m.in. na analizę kodu, a także to, ile pracy poszczególni pracownicy włożyli w jego powstanie.

Co ważne, obecnie możemy też analizować, w których obszarach kodu pojawia się tzw. dług technologiczny. Z biegiem czasu, w wyniku rozwoju funkcjonalnego aplikacji, przyrastanie liczby linii kodu powoduje coraz większą złożoność rozwiązania i coraz większe nakłady pracy na wprowadzanie kolejnych zmian. Z czasem więc koszty modyfikacji kodu rosną. Warto zatem poświęcić część wysiłku developerów na mądrą spłatę długu technologicznego. Nie ma sensu go wkładać w te fragmenty kodu, które są stabilne i mało rozwijane, lepiej skupić się na refaktoryzacji modułów, które są często modyfikowane lub w których pojawiają się luki bezpieczeństwa. Warto na bieżąco robić analizę zadłużenia i w dużych rozwiązaniach, przeznaczać nawet do 20% czasu sprintu na aktualizację architektury, uaktualnienie frameworków, bibliotek lub stosowanych rozwiązań open source. Bez tego, każda, nowa funkcjonalność będzie kosztować coraz więcej.

Jakie są obecnie najważniejsze kierunki rozwoju oprogramowania, zwłaszcza pod kątem nowych architektur, technologii i wykorzystywanych narzędzi?

Jest to przede wszystkim zmiana z monolitu na mikroserwisy, ale także – dużo mniej jeszcze popularna – architektura serverless. Dzięki niej, tworząc nowe rozwiązania, możemy skupić się tylko na funkcjach biznesowych, a nie – jak dotąd – tworzeniu kodu infrastrukturalnego, który jest konieczny do uruchomienia danej funkcjonalności. Przykładem takiego podejścia są rozwiązania Cloud Native.

Przykładowo, dzięki rozwiązaniom dostępnym w ramach AWS Lambda czy Azure Functions płacimy jedynie za wywołanie danej funkcji. Może to początkowo przerażać, bo w jaki sposób – twórca aplikacji lub pion biznesowy, który z niej korzysta – ma wcześniej oszacować liczbę takich wywołań? Każde z nich jest przecież płatne, a chcemy znać koszty z góry. Z naszego doświadczenia, ale również z ogólnie dostępnych case study wynika, że dzięki takiemu podejściu stworzenie i eksploatacja aplikacji serverless w chmurze obliczeniowej jest nawet 5-7 razy tańsze niż podobnego rozwiązania opartego na kontenerach. Dodatkowo – dzięki możliwościom oferowanym przez dostawców usług cloud computing – dużo łatwiej się ono skaluje.

Trzeba też pamiętać, że rosnąca liczby wywołań funkcji serverless powinna być wynikiem rosnącej skali biznesu, a więc rosnącej liczby transakcji biznesowych i generowanych przez nie przychodów. Warto więc korzystać z rozwiązań serverless w takich zastosowaniach, które generują biznes, np. związanych z działalnością e-commerce. Architektura serverless wymusza zmianę sposobu myślenia o prowadzeniu projektów programistycznych, a także liczenia kosztów posiadanych rozwiązań biznesowych.

Serverless jest dalszym rozwinięciem – dokonujących się od kilku lat – zmian architektury. Początkowo odchodziliśmy od monolitu, na rzecz mikroserwisów, aby móc wielokrotnie wykorzystywać te same fragmenty kodu i lepiej dzielić pracę zespołów. Kontenery zastępowały tradycyjną wirtualizację, co pozwoliło uniezależnić się od platformy, na której działa dane rozwiązanie. Dziś zaś architektura serverless pozwala skoncentrować się wyłącznie na logice biznesowej. To także idealne rozwiązanie, gdy chcemy się przygotować na prognozowane, duże wzrosty ruchu.

Czy architektura serverless wymaga innych narzędzi programistycznych?

Nie. Stosuje się te same narzędzia, jak i dostępne platformy chmur publicznych. Od pewnego czasu istotnie zmniejszyły się opóźnienia związane z wywoływaniem funkcji w chmurze, więc nie ma już problemu z szybkością działania rozwiązań opartych o taką architekturę. Tego typu podejście sprawdza się szczególnie w aplikacjach mobilnych lub front-end’owych, bo dużo szybciej stawia się back-end w oparciu o architekturę serverless. Dużo oszczędniej też piszemy kod źródłowy. Lata temu stworzenie aplikacji, która wyświetlała komunikat typu „Hello World” wymagało zaledwie 3 linii kodu. Dedykowane temu celowi typowe dla aplikacji korporacyjnych złożone i rozproszone środowisko IT zestawia się już w… 3 dni. Serverless odwraca ten trend. Wysyłamy jedynie do chmury obliczeniowej odpowiedni komunikat: przelicz, zapisz, wyświetl… Nie martwimy się o to, w jaki sposób polecenia te są realizowane po stronie back-end.

Czy obecna, pandemiczna sytuacja zmienia sposób, w jaki należy budować zespoły deweloperskie i to, w jaki sposób zarządza się ich efektywnością pracy?

Dla nas pierwsze miesiące tego roku nie były wielką zmianą. Od dawna bowiem pracowaliśmy w zespołach rozproszonych w kilku miastach dla Klientów zlokalizowanych w jeszcze innym miejscu . Nawet korzystając z metodyk agile nie musieliśmy pracować w jednym budynku. Pandemia Covid-19 udowodniła, że w zwinnych podejściach można pracować w zespołach rozproszonych zachowując efektywność. Znam wiele firm programistycznych, które nigdy nie miały biura, ale pracowały przede wszystkim dla klientów zagranicznych. Miały więc ten styl pracy niejako wpisany w model biznesowy.

Warto też podkreślić, że dostępne dziś narzędzia i systemy komunikacji wspierają współdziałanie rozproszonych zespołów, a ich członkowie są do tego przyzwyczajeni. De facto znacznie szybciej można skomunikować się z kimś np. na platformie Teams czy Slack niż przejść się dwa pokoje dalej, aby coś uzgodnić. Warto pamiętać, że interakcje społeczne z osobami, których nie znamy wciąż są dla nas niezbyt komfortowe. Zwłaszcza dotyczy to Polski.

Jednocześnie okazało się również, że metody, takie jak Event Storming czy User Sory Mapping, używane dotychczas w sposób tradycyjny, równie dobrze sprawdzają się w pracy zdalnej. Pozwalają one lepiej poznać i uszeregować wymagania biznesowe. Nie trzeba już siedzieć w jednym pokoju z Product Ownerem. Tym bardziej, że zazwyczaj wiedza biznesowa i decyzyjność jest w rękach więcej niż jednej osoby. Korzystając z odpowiednio dobranych narzędzi łatwiej jest „pozbierać” potrzebne informacje.

Z jakich narzędzi korzystają Państwo w pracy nad tworzeniem oprogramowania?

Poza narzędziami komunikacyjnymi, a także repozytoriami takimi, jak Gitlab, staramy wspierać się w pracy komercyjnymi narzędziami do badania kodu i jego podatności na zagrożenia. Im wcześniej bowiem przeprowadzimy te analizy, tym lepsza jest jakość końcowego kodu, dotyczy to także jego bezpieczeństwa. Testy bezpieczeństwa przeprowadzamy już na etapie tworzenia kodu. Im wcześniej wykryjemy luki lub niezalecane wzorce kodowania, tym taniej poprawić kod.

Wykorzystujemy też narzędzia, które wskazują w kodzie przestarzałe konstrukcje lub nieaktualne biblioteki. Jedną z oferowanych przez nas usług jest właśnie badanie stopnia zadłużenia kodu źródłowego. W wynikach takich analiz zawsze podkreślamy wpływ takiego stanu rzeczy na biznes klienta. Argumenty te są potem podstawą w rozmowach biznesem, który lepiej rozumie sens inwestycji w refaktoryzację.

W jaki sposób rozwijają Państwo kompetencję zespołów developerskich? Czy faktycznie tak ważne teraz są kompetencje miękkie?

Nasi pracownicy mają średnio ok. 4 tygodni w roku na rozwój – poznanie nowych bibliotek lub technologii, których akurat nie wykorzystują w pracy, ale chcą zdobyć na ich temat wiedzę, aby nie odstawać od rynku.

Mamy też politykę inwestowania w wiedzę o technologiach, które uważamy za strategiczne. Dla nas są to przede wszystkim Java, .NET czy w pewnych zastosowaniach Python. Są to bowiem języki najbardziej popularne w korporacjach, dla których pracujemy. Dodatkowo rozwijamy kompetencje chmurowe. Wkrótce cloud computing stanie się podstawą każdego rozwiązania. To już dzieje się w Europie Zachodniej, a w Polsce ten trend także wkrótce się upowszechni. Tym bardziej, że aplikacje cloud native pozwalają osiągnąć cele biznesowe mniejszymi nakładami pracy wykorzystując to, co jest już dostępne w chmurze publicznej.

Oczywiście ważny jest dla nas także – wspomniany w pytaniu – rozwój umiejętności miękkich, aby zespoły mogły udzielać sobie wzajemnie informacji zwrotnej. Budowanie kompetencji miękkich i myślenie poprzez cele jest równie ważne wśród kadry seniorsko-leaderskiej.