W jednym z projektów realizowanych w Onwelo dla Vodeno, w pełni cyfrowej platformy bankowej opartej o chmurę Google, jako programista z pięcioletnim doświadczeniem w Javie i C#, otrzymałem propozycję pisania w języku Go (Golang). Wydała mi się ona wtedy mało interesująca. Dlaczego? Ze względu na dużą popularność platformy Java czy .NET i skupienie się środowiska IT na tych konkretnych technologiach. Za tym idzie często rezygnacja z nauki kolejnego języka. Taki trend poparty jest przekonaniem, że lepiej znać dobrze dwie technologie niż pięć, ale w mniejszym stopniu. Co więc przyniósł mi udział w tym projekcie i czy przekonałem się do języka Go?   

Dlaczego postawiliśmy na Go?

Go nie jest idealnym językiem, ma swoje wady i zalety. Wymaga zmiany nawyków z usystematyzowanego programowania deklaratywnego na bardziej imperatywne. Programowanie w Go jest jednak przyjemne, co stwierdziłem po jakimś czasie. Zainteresowani porównaniem tego języka do Javy mogą zgłębić temat, korzystając z licznych źródeł w Internecie. Ciekawym artykułem może być np. „Comparison between Java, Go, and Rust”. O moich doświadczeniach z tym językiem przeczytacie poniżej.

Aplikacje napisane w Go są szybkie, dedykowane do niedużych serwisów oraz do współbieżnego procesowania. Skompilowana aplikacja napisana w Go zużywa znacznie mniej pamięci w stosunku do np. aplikacji napisanej w Javie (mowa tu o rzędach wielkości). Z racji ogromnych potrzeb skalowalności aplikacji oraz zapotrzebowania na zasoby chmurowe zapadła decyzja o  wyborze właśnie tego języka dla silnika nowoczesnego banku.

Przykładowo – jeśli pomyślimy o jednej z wielu instancji aplikacji systemu centralnego, różnica w chwilowym zużyciu 100 MB nie ma znaczenia. Zwiększając skalę, możemy sobie wyobrazić nawet 10 000 instancji. Zasoby chmurowe, takie jak zużycie procesora lub pamięci pomnożone przez liczbę instancji oraz przez kwotę, jaką należy zapłacić dostawcy chmury, dają duże sumy pieniężne ponoszone za korzystanie z zasobów. Optymalizacja kosztów i efektywność złożyły się więc na decyzję o wyborze Golanga.

Początek VCP (Vodeno Cloud Platform)

Wraz z kolegami z zespołu otrzymałem pierwsze z wymagań funkcjonalnych dla systemu centralnego tj. stworzenie prostego systemu księgowego przechowującego historię wszystkich wpisów w księdze, z możliwością dojścia do salda w dowolnym punkcie tej księgi dla danego konta. Jednym z kluczowych wymagań był też popularny mechanizm blockchaina zapewniający wiarygodność i zabezpieczający transakcyjność w systemie. Znając te oczekiwania, rozpoczęliśmy tworzenie systemu bankowego, a dokładnie mówiąc, jego centralnej części.

Bank as a Service

Mamy więc platformę opartą o chmurę Google Cloud Platform z możliwością rozproszenia danych na regiony. Rozwiązanie typu BaaS niczym building blocks umożliwia klientom tworzenie od zera systemu księgowego lub nawet banku. Jako zespół odpowiedzialny za centralną część systemu utrzymujemy szereg mikroserwisów, które odpowiadają za orkiestrację środowisk inwestorów. Stworzyliśmy silnik uruchamiania procesów biznesowych z dedykowanym językiem i funkcjami.

Wspomniana wyżej funkcjonalność wydaje się być doskonałym narzędziem z punktu  widzenia właściciela produktu i zarządzania kwalifikacjami osób pracujących przy projekcie. Utworzonych zostało w ten sposób 150 procesów biznesowych obsługiwanych przez system centralny. Tempo rozwoju silnika i architektury, które udało nam się uzyskać, byłoby niemożliwe do osiągnięcia, gdyby każdy z tych elementów miał być zaimplementowany przez nasz zespół deweloperski odpowiedzialny również za funkcjonalności stricte techniczne. Położenie więc nacisku na „napisanie” silnika umożliwiło oddelegowanie tworzenia procesów biznesowych, bez pośrednictwa programistów nieznających dobrze domeny biznesowej, do specjalistów znających ją perfekcyjnie. Dzięki temu jako zespół deweloperski mogliśmy skupić się na rozwoju architektury, monitoringu  czy problemach technicznych.

Jestem odpowiedzialny nie tylko za sam silnik i dane, ale również za np. serwis przechowujący dane o klientach lub generujący numery rachunków IBAN. Równolegle pracuję nad utrzymaniem i automatyzacją procesu zakończenia dnia bankowego, za który czuję się odpowiedzialny. Chociaż ww. proces EoD (End of Day) działa produkcyjnie, wciąż jest pole do poprawy, na którym obecnie działam, wprowadzając optymalizacje.

Dlaczego więc polubiłem Go?

Warto zauważyć, że jeśli istnieją potencjalne optymalizacje i zapada decyzja o ich wprowadzeniu, bo nie zawsze ma to miejsce w firmach, to znaczy, że ludzie, z którymi pracujemy, dbają o jakość tego, co tworzą.

Jako zespół przeżyliśmy wszystkie fazy modelu Bruce’a Tuckmana (forming – storming – norming – performing). Dzięki niemu zrozumiałem, że efektywną współpracę w zespole trzeba wypracować. Dołączając do jakiegokolwiek zespołu nierzadko wchodzimy w znormalizowany schemat współpracy – strukturę. U nas było inaczej. Owszem, były etykiety, przypisanie, kto, jaką rolę pełni w zespole, ale przeszliśmy również przez wszystkie fazy wyżej wymienionego modelu i dało nam to bardzo dużo. To dobra droga, pełna wyzwań i satysfakcji czerpanej z jej pokonania. Doświadczenia moje i kolegów, duży nacisk na code review oraz rzetelność osób w zespole mają ogromny wpływ na polepszanie zarówno kompetencji deweloperskich, jak i aspektów biznesowych.

Go jest bardzo zyskującym na popularności, rozwojowym z punktu widzenia GCP, językiem, radzącym sobie z paradygmatem OOP, ale wymagającym zmiany przyzwyczajeń. Przejrzysta składnia umożliwia zwracanie wielu obiektów z dowolnej funkcji, współbieżność i chyba najważniejsze – wydajność. Wymienione cechy to kilka z wielu zalet, których jest dziesiątki. Jeśli ktoś zmierza do bycia inżynierem systemowym, język programowania wydaje się być tylko narzędziem do osiągnięcia zamierzonego celu. Dziś piszę w języku Go, bo jest dobry i rozwojowy, jak będzie to wyglądać za kilka lat? Czas pokaże.

Warto pamiętać, że to, nad czym pracujemy i to, jakimi narzędziami się posługujemy, jest równie ważne, jak ludzie, z którymi dążymy do uzyskania zamierzonego celu. Nierzadko to właśnie efektywna współpraca zespołowa i atmosfera mają wpływ na ogół wrażeń z nabytych doświadczeń projektowych i oddziałują na naszą opinię na temat całego projektu – tworzonych rozwiązań czy wykorzystywanych technologii. Wszystkie te czynniki mają wpływ na osobistą satysfakcję, którą, mogę to powiedzieć po dwóch latach pracy, w pełni czerpię z udziału w opisanym projekcie realizowanym dla Vodeno.

Przemysław Bagiński – software developer, zwolennik Agile, amator angielskiego humoru i koszykówki.