Tworzenie oprogramowania, puszczone na żywioł kończy się zwykle tak samo

Z Pawłem Cynkarem, Chief Technology Innovation Officer, Enterprise Architect w ProService Finteco rozmawiamy o migracji do chmury obliczeniowej; tym, czy rozwiązania typu Cloud Native Applications są „lekiem na całe zło”; tym, jak zmienia się dziś produkcja oprogramowania i wykorzystywane technologie, narzędzia, frameworki oraz architektury; konieczności budowy środowiska pracy nastawionego na innowacje i rozwój; a także wpływie DevOps na sposób pracy.

Zbudowaliście chmurę prywatną, a teraz wchodzicie w usługi cloud computing. Czy to – po Waszej stronie – wymaga dostosowania do nowych środowisk opracowywanych aplikacji?

Cloud computing to bardzo szerokie pojęcie, ale w przypadku chmury prywatnej to – mówiąc kolokwialnie – nic innego, jak uruchamianie aplikacji na cudzym sprzęcie. Jest to oczywiście bardzo mocny skrót myślowy. W tym wariancie chmury, nic nie trzeba dostosowywać, wystarczy zainstalować aplikacje w nowym miejscu, przekierować domeny i tyle. Korzyści są jednak ogromne, bo skorzystanie z takiej opcji w zewnętrznym centrum danych daje bardzo dużo – specjalistów ds. bezpieczeństwa, dodatkowe zasoby infrastruktury IT uruchamiane w razie potrzeby, redundantne sieci, systemy zasilania, dostęp do centrum zapasowego itd. Chmura w obecnych czasach nie jest niczym nowym, ale należy pamiętać, że my jako ProService Finteco działamy na rynku regulowanym i przetwarzamy dane osobowe milionów Polaków. Tutaj nie ma miejsca na kompromisy.

Naszym zdaniem, warto iść zgodnie z ideą skupiania się na bazie biznesowej oddając innym to, na czym znają się lepiej, uzyskując jednocześnie efekt skali. Dzięki temu – pod względem infrastruktury IT – jest lepiej i taniej. Co warto podkreślić, wejście w chmurę prywatną nie wymagało od nas zmian w stosowanych aplikacjach, ale otwiera jednocześnie drzwi do znacznie większych możliwości. Nie musieliśmy wiele zmieniać, bo do tego modelu działania byliśmy przygotowani już wcześniej.

Jak – w kontekście rosnącej popularyzacji platform cloud computing – zmienia się dziś produkcja oprogramowania, technologie, narzędzia, wykorzystywane architektury?

To wszystko zmienia się z dnia na dzień. Nie ma jednak prostej odpowiedzi na pytanie co warto wybrać, bo rozwiązań jest bardzo dużo i trzeba je dobierać w taki sposób by przede wszystkim realizować potrzeby biznesu. Sposób produkcji oprogramowania zmienia się nie tylko w wymiarze technologicznym, ale przede wszystkim w wymiarze procesowym. Sztuką obecnie jest przede wszystkim przyciągać talenty i stworzyć im przyjazne środowisko pracy. Mówiąc przyjazne, myślę przede wszystkim o takim, które jest nastawione na innowacje i rozwój, ponieważ tego oczekują dziś pracownicy IT. Z pewnością warto iść w zgodzie z duchem czasów, bo bycie dobrym programistą czy architektem to przede wszystkim ciągła nauka i rozwój.

Ważna w produkcji oprogramowania jest odpowiednia struktura projektowa i takie ułożenie procesu, aby każdy zajmował się tym na czym najlepiej się zna i by każdy wiedział co do niego należy. W projekcie potrzebni są nie tylko programiści, ale również analitycy, testerzy, projektanci interfejsów, architekci, kierownicy projektów, graficy. Produkt finalnie ma nie tylko działać poprawnie, ale ma być również przyjazny dla użytkownika. Ważna w tym wszystkim jest oczywiście metodyka działania. Tutaj bardzo dobrze sprawdza się Scrum w połączeniu z mechanizmami jego skalowania w przypadku prac realizowanych równolegle w wielu zespołach. W naszym środowisku, współpraca wielu zespołów i równoległe zmiany wielu systemów są czymś normalnym, a potrzeba zapanowania nad tym jest oczywista.

Nie bez znaczenia są również narzędzia w procesie wytwórczym. W tym momencie nasuwają mi się na myśl takie hasła, jak: Ansible, Jenkins, Nexus Repository Manager, Azure DevOps, git, docker, Kubernetes, OpenShift, AWX, DevOps, Liquid-Base, Continuous Integration, Continuous Delivery, Jira, Confluence… Na co dzień korzystamy z wszystkich tych rozwiązań i nie wyobrażam sobie już pracy bez nich. Czasy utrzymywania kodu na wspólnym udziale sieciowym czy customowych skryptów do instalacji oprogramowania bezpowrotnie minęły. Teraz ścieżka jest inna: request > analiza > planowanie > development > commit > pull request > code review > automatic build > automatic deploy itd.

Z jakich narzędzi deweloperskich/systemowych dziś korzystacie?

W zasadzie główne narzędzie wymieniłem już wcześniej. Komunikację opieramy o rozwiązania Microsoft 365, do pracy zespołowej wykorzystujemy narzędzia Jira i Confluence, a edytory kodu to: Intelij, PHP Storm, Microsoft Visual Studio. Wykorzystujemy też analizę syntaktyczną podczas pisania kodu, co znacznie przyspiesza proces i poprawia jakość oprogramowania. Na pewno warto też skorzystać z frameworków takich, jak:

• Backend: Java, Spring,
• Automatic test for Backend: Rest-Assured,
• Database: PostgreSQL, Microsoft SQL
• Frontend: Angular,
• Automatic test for Frontend: Selenium,
• Load Balancer: HAProxy,
• Containerization: Docker,
• Deployment: Ansible.

Jakie są najważniejsze trendy w rozwoju oprogramowania? Czy Cloud Native Applications jest jednym z nich?

Tak, ale może wyjaśnijmy najpierw czym jest Cloud Native. W wielkim uproszczeniu jest to gotowość do działania w środowisku rozproszonym, nastawionym na mniejsze komponenty, które dostarczają konkretne zestawy funkcjonalne i które komunikują się z innymi komponentami systemu lub komponentami wielu systemów. Z założenia – budując nowe rozwiązania – należy więc zawsze starać się myśleć szerzej. O mikroserwisach głośno jest od dawna, ale teraz pora pójść krok dalej, pora skorzystać z tego, co dają z automatu nowoczesne rozwiązania chmurowe.

Trzeba jednak pamiętać, że Cloud Native to nie jest remedium na zło tego świata. Nieprzemyślane architektonicznie aplikacje tego typu staną się chmurą burzową, która na koniec przyniesie grad i dla nikogo to się dobrze nie skończy. Należy pamiętać, że tworzenie oprogramowania – czy to metodą klasyczną, czy to z użyciem najnowszych rozwiązań i trendów – puszczone na żywioł kończy się zwykle tak samo. Dlatego od zawsze w tworzeniu oprogramowania najważniejsze są:

• zaplanowanie,
• funkcjonalność i łatwość obsługi,
• bezpieczeństwo,
• łatwy rozwój,
• gotowość do skalowania,
• budowa komponentowa.

Nie bez znaczenia pozostają (oczywiście tam, gdzie zastosowanie jest możliwe i ma uzasadnienie):

• uczenie maszynowe i algorytmy sztucznej inteligencji, ale zdecydowanie te oferowane jak usługi w modelu cloud computing,
• Data Science,
• współpraca z czujnikami IoT i gotowymi rozwiązaniami jakie chmura daje do ich obsługi

Jak wiele zmienił DevOps w sposobie Waszej pracy?

DevOps to po prostu kierunek lub inaczej specjalizacja. DevOps to obecnie dość szerokie pojęcie, pod którym kryje się:

• Automatyzacja procesów budowania aplikacji, wykonywania testów, deploymentu na środowiska testowe czy to produkcyjne.
• Mocna standaryzacja środowiska.
• Zapewnienie ciągłości pracy operacyjnej środowisk produkcyjnych pomimo równoległego rozwoju i prac programistycznych.
• Nacisk na ścisłą współpracę i komunikację pomiędzy administratorami i programistami.

Coraz częściej pojawia się pojęcie DevSecOps. Jest to obszar działania, który skupia się na zapewnieniu bezpieczeństwa rozwiązań zarówno w warstwie aplikacyjnej, jak i w otoczeniu instalacyjnym, infrastrukturalnym. DevSecOps angażowany od początku projektu nie tylko pomoże wyznaczyć ścieżki architektoniczne, ale podpowie, jak wydzielić warstwy aplikacji dla zachowania jak najwyższych standardów bezpieczeństwa oraz – już na etapie wytwarzania oprogramowania – uruchomi zestaw narzędzi, które będą wykonywać badanie bezpieczeństwa rozwiązania. My wykorzystujemy do tego np. narzędzia Nessus czy Acunetix.

• Efektami zmiany podejścia na DevOps lub DevSecOps jest to, że:
• Programiści skupiają się na programowaniu, a nie zadaniach administracyjnych (każdy robi to co kocha), walczą z kodem, a nie z narzędziami
• Wprowadzenie rozwiązań, które dają możliwość skalowania dostępności oraz wydajności.
• Podstawowe błędy wykrywane są na wczesnym etapie rozwoju oprogramowania.
• Niższa bariera wejścia programisty w środowisko pracy (dzięki standaryzacji).
• Podwyższenie bezpieczeństwa budowanych rozwiązań.
• DevOps wymusza na Product Ownerze i programistach podwyższanie wersji, łatanie luk itp.
• Poprawa jakości wdrożeń oprogramowania.
• Częstsze udostępnianie nowych wersji oprogramowania.
• Lepszy wgląd w procesy i wymagania.
• Kulturowa zmiana współpracy.
• Lepsze reagowanie na potrzeby biznesowe.
• Bardziej zwinne wdrożenia.
• Bardziej zwinne zarządzanie zmianami.
• Poprawa jakości kodu.

Jak dziś wygląda System Development Life Cycle zwłaszcza w kontekście trendu Continuous Integration i Continuous Delivery?

O cyklu wytwarzania oprogramowania można mówić bardzo dużo. Wytwarzanie oprogramowania to po prostu proces, jak budowa domu czy montaż samochodu, ale produkcja oprogramowania jest czymś jeszcze mniej namacalnym. Dlatego wielu ludziom trudno to zrozumieć, a przecież tak oczywiste dla wszystkich jest, że budowę domu zaczynamy od projektu. Tutaj wszystko musi być poukładane od początku do końca, a jak nie jest, to proces po prostu nie działa i efekt końcowy jest marny. Statystyki projektowe na świecie pokazują wprost, że nie jest to łatwe. Wiemy, że większość projektów przekracza czas i budżet.

Proces wytwarzania oprogramowania to nie tylko praca programistów, to przede wszystkim praca z klientem, który ostatecznie jest odbiorcą zmian i to on nas ocenia przez pryzmat czasu, jakości i ceny. Z punktu widzenia organizacyjnego najważniejsze elementy to:

• zapewnienie współpracy klienta,
• bardzo dobra komunikacja w projekcie,
• zaangażowanie osób decyzyjnych.

Bardzo pomaga przy tym Scrum, pod warunkiem, że jest dobrze wprowadzony oraz uczestnicy projektu go rozumieją i chcą stosować. W dobrym wydaniu Scrum buduje zaangażowany zespół z jasnym celem do realizacji. Organizacja projektu to jedno, a drugie nie mniej istotne zagadnienie to automatyzacja i standaryzacja. Tutaj kłania nam się temat DevOps, bo to się ze sobą mocno wiąże. Z punktu widzenia jakości im częściej weryfikujemy kod oraz im mniejsze zmiany wprowadzamy, tym lepiej.

Jeśli zaś chodzi o Continuous Integration to jest z nami od dobrych kilku lat i polega właśnie na:

• automatycznym budowaniu aplikacji po wprowadzeniu zmiany w kodzie przy zaleceniu by programista przynajmniej raz dziennie wprowadzał efekty swojej pracy do repozytorium;
• automatycznym uruchomieniu testów jednostkowych;
• dzięki temu podejściu wcześniej wykrywamy błędy, zmniejszenia kosztów łączenia zmian przez inne osoby.

Natomiast Continuous Delivery oznacza ciągłe dostarczanie, to znaczy jako priorytet powinno traktować przede wszystkim zadowolenie klienta poprzez częste, powtarzalne i wiarygodne wdrażanie nowej wersji oprogramowania. Oznacza to, że „idziemy mniejszymi paczkami”. Potrzebne są też testy jednostkowe.

Coraz więcej mówi się też o tzw. rozwiązaniach Low Code czy No Code. Czy stosuje się je już w praktyce? Co o nich sądzisz?

Wszyscy doskonale wiemy, jak wygląda obecnie rynek pracy w obszarze IT. Programistów brakuje i mimo tego, że nowa kadra jest cały czas kształcona, to sytuacja wcale się nie poprawia. Zapotrzebowanie jest coraz większe. Sytuacja związana z pandemią tylko zwiększyła to zapotrzebowanie. Możemy sobie, wobec tego zadać trudne pytanie, kiedy to się zmieni? Kiedy programiści przestana być potrzebni? Stanie się to wówczas, kiedy powstaną programy, które będą pisać programy. Jest to dość przewrotne i wydaje się niemożliwe, ale kto wie, może za jakiś czas sztuczna inteligencja da takie możliwości. Teraz jesteśmy jednak na bardzo wczesnym etapie drogi w tym kierunku.

Kiedyś stworzenie prostej strony internetowej i opublikowanie jej w sieci wymagało sporych – jak na tamte czasy – umiejętności związanych z konfiguracją domeny, serwera, napisania kodu HTML itp. itd. Później powstał WordPress, w kolejnym kroku WordPress jako usługa, a następnie seria usług związanych z tą platformą. Dziś wybieramy domenę, szablon strony i skupiamy się już tylko na treści. Do tego nie potrzeba żadnych umiejętności IT i o to właśnie chodzi. Z tworzeniem aplikacji jest tak samo, tylko poprzeczka jest ustawiona znacznie wyżej. Mamy czasy, w których proste aplikacje możemy tworzyć w prosty sposób, niemalże jak z klocków Lego. Potrzebne są jednak do tego standardy i łatwość obsługi dzięki wykorzystaniu wizualnych narzędzi do tworzenia „kodu”. Przykładem rozwiązań Low Code są np. Microsoft Flow, Azure Logic Apps, Oracle Apex.

Jakich kompetencji poszukujecie do Waszych zespołów?

Firma to miejsce, w którym spędzamy sporo czasu, więc dla sprawnego działania, wszystko musi być na miejscu, a zakres obowiązków powinien być dostosowany do indywidualnych potrzeb i preferencji. Nie możemy przy tym tracić oczywiście z horyzontu celów biznesowych, jakie mamy zrealizować w ramach projektu. Staram się tak układać tematy, abym mógł z czystym sumieniem powiedzieć „chciałbym być programistą w swoim zespole”. Jestem inżynierem z krwi i kości i dlatego bycie programistą, ciągły rozwój jest dla mnie kluczowy. Nigdy nie interesowało mnie bycie po prostu managerem, to nie dla mnie.

Budujemy zespoły projektowe w taki sposób, aby mogły dostarczać produkt od początku do końca jako jeden, zgrany zespół. W zespole zbieramy kompetencje Project Managerów, analityków, programistów, testerów, DevOps-ów, a więc każdy, zainteresowany działaniami IT znajdzie dla siebie coś ciekawego. Szukamy ludzi, którzy będą chcieli zostać częścią zespołu, chcą się uczyć. Ponieważ jesteśmy sporą organizacją, to mamy też wiele systemów i rozbudowany stack technologiczny, w skład, którego wchodzą:

• warstwa systemowa – w zdecydowanej większości Linux/Unix, ale bywa też Windows,
• bazy danych – MS SQL, PostgreSQL, MongoDB, Ingres,
• języki programowania – Java, PHP, TypeScript, C#, 4GL,
• frameworki – Angular, Spring Framework (mvc, boot, cloud, security), Apache Cordova, Laravel,
• narzędzia DevOps – Jenkins, Ansible, AWX, Kibana, Gerrit.

Jesteśmy już sporą organizacją, ale nie jesteśmy jeszcze dużą korporacją. To nam daje unikalne możliwości budowania wielkich systemów bez narzuconych z góry ograniczeń technologicznych. Każdy głos, pomysł, idea brane są pod uwagę.