Deweloperzy powinni koncentrować się na problemach biznesowych

O nowej roli deweloperów; możliwych podejściach do zmiany systemów monolitycznych w rozwiązaniach opartych na architekturach zwinnych; błędach popełnianych podczas tworzenia środowisk kontenerowych i mikroserwisowych; koncepcji BizDevOps w praktyce, a także o efektach kompleksowego wykorzystania narzędzi do monitoringu mówi Andreas Grabner, aktywista DevOps, architekt Cloud i programista zawodowo związany z Dynatrace.

Dlaczego mikroserwisy, kontenery i koncepcje zwinne są tak ważne w kontekście dzisiejszych procesów rozwoju oprogramowania?

Nowe koncepcje i architektury rozwoju oprogramowania dają deweloperom większą swobodę działania, która przekłada się na większą elastyczność oprogramowania z perspektywy użytkowników biznesowych. Zwinne metodyki rozwoju aplikacji, architektury mikroserwisowe czy środowiska kontenerowe przyczyniają się też do zmian w istniejących systemach – także tych o krytycznym znaczeniu. Kluczem jest tu ponownie wyższa elastyczność. W przypadku rozwiązań działających na zasadzie monolitu każda linia kodu wymaga ponownego przekompilowania i wdrożenia całościowej aplikacji. Sprawia to, że nawet prosta pomyłka może mieć kluczowy wpływ na działanie systemu i wielu procesów biznesowych. W efekcie proces wdrażania zmian funkcjonalnych do systemów opartych na klasycznych architekturach jest obarczony dużo wyższym ryzykiem niż ingerencja w pojedynczy, samodzielny komponent oprogramowania zbudowanego w nowej architekturze.

Rozmawiałem niedawno z przedstawicielami dużej instytucji finansowej z Austrii. Do niedawna w ich organizacji nawet pojedyncza zmiana funkcjonalna potrzebna użytkownikom z jednego działu biznesowego mogła mieć ogromny wpływ na dostępność funkcji krytycznych dla wielu procesów biznesowych. Każdej, nawet najdrobniejszej zmianie wdrażanej w systemie towarzyszyło ogromne ryzyko biznesowe, co w naturalny sposób powodowało niechęć przed wdrażaniem zmian, które nie były niezbędne. Aby to zmienić, zdecydowano o przejściu na nową architekturę, by rozbić monolit. Dziś każdy dział biznesowy, każdy zespół deweloperów odpowiada za pojedyncze moduły. Dzięki temu wdrażanie nawet punktowych zmian jest dużo łatwiejsze.

Nowe podejście pozwala też wdrożyć nowe metody pracy zespołów odpowiedzialnych za rozwój, testowanie i funkcjonowanie systemów biznesowych. Nowe koncepcje, jak Blue Green Deployments czy Canary Releases, świetnie sprawdzają się w dzisiejszych realiach. Przykładowo można łatwo uruchomić równolegle dwie wersje rozwiązania i porównać ich efektywność w różnych obszarach funkcjonalnych czy kontekstach użycia.

Czy łatwo jest przenieść istniejące oprogramowanie monolityczne do rozproszonej i zwinnej architektury?

Zdecydowanie nie jest to zadanie łatwe. Niezbędna jest bowiem zmiana fundamentów architektury takiego oprogramowania i przejścia na zupełnie inne podejście do tworzenia aplikacji. W tego rodzaju projektach wykorzystywane są różne podejścia. I tak, Martin Fowler, znany specjalista z dziedziny architektury oprogramowania, mówi np. o sposobach pozwalających wydobyć poszczególne funkcjonalności z rozwiązania monolitycznego, aby potem łatwo zaimplementować je za pośrednictwem mikroserwisów.

Alternatywne podejście zakłada wykorzystanie funkcji realizowanych przez system monolityczny poprzez dostępne interfejsy API i na potrzeby rozwoju nowych funkcjonalności przy użyciu mikroserwisów. W instytucji finansowej, o której wspominałem wcześniej, zdecydowano się właśnie na taką drogę. Wybrane funkcje systemu opartego na architekturze monolitu udostępniono mikroserwisom poprzez API. Budowane odtąd funkcjonalności wykorzystują mechanizmy monolitu, ale pozostają niezależnymi komponentami. Takie podejście pozwala na współistnienie nowych rozwiązań z tymi bardziej klasycznymi. Łatwiej jest też testować różne ścieżki rozwoju. Plany zakładają oczywiście, że miejsce funkcji realizowanych przez monolityczny system centralny zajmą nowe rozwiązania mikroserwisowe. Wówczas monolit będzie stopniowo tracił na znaczeniu i potencjalnie kiedyś będzie mógł zostać wyłączony. Jest to podejście bezpieczne, ale nie tak łatwe do przeprowadzenia, jak mogłoby się wydawać.

W jaki sposób nowe architektury aplikacyjne zmieniają zadania stawiane deweloperom?

Przede wszystkim, od programistów wymaga się dziś ciągłego rozwoju, obserwowania zarówno kierunku rozwoju technologii, jak i metod tworzenia aplikacji oraz narzędzi wspierających ten proces. Nie chodzi tylko o tworzenie bardziej rozproszonych aplikacji. Zmienia się też podejście do testowania i wdrażania zmian; powszechne stają się, przykładowo, praktyki Ciągłej Integracji i Ciągłego Dostarczania (CI/CD).

Powinien również zmienić się zakres odpowiedzialności za oprogramowanie. Deweloperzy powinni przejmować odpowiedzialność nie tylko za tworzony przez nich kod, ale także za środowisko produkcyjne. Takie podejście stosujemy w Dynatrace. Zespoły programistyczne odpowiadają za tworzenie kodu, testowanie, ale też utrzymanie i planowanie rozwoju aplikacji. Dzięki temu deweloperzy nie funkcjonują w oderwaniu od faktycznych potrzeb organizacji, która korzysta z tworzonego przez nich oprogramowania.

Im mniejsze są aplikacje lub komponenty aplikacyjne, za które odpowiada dany zespół, tym łatwiejszy staje się ich dynamiczny rozwój. Oczywiście potrzebny jest tu fundament w postaci architektury całego rozwiązania aplikacyjnego, która będzie w stanie sprostać ewentualnym błędom w działaniu poszczególnych komponentów i efektywnie zadziałać w trybie awaryjnym. Odejście od statycznego podziału na zespoły deweloperskie, testowe i operacyjne pozwala uelastycznić całą organizację odpowiedzialną za oprogramowanie. Stanowi też pierwszy krok w kierunku koncepcji „self-driving IT”, czyli budowy środowisk działających w sposób wielowymiarowo zautomatyzowany.

Czyli nowoczesna architektura aplikacyjna powinna zachowywać się podobnie jak rozwiązania sprzętowe…

Dokładnie tak. Mając 100 mikroserwisów zamiast jednego monolitu, musimy być gotowi na awarię każdego z nich. Jeśli nam się to nie uda, wracamy do koncepcji monolitycznej, w której błąd na poziomie pojedynczej linii kodu mógł zaburzyć działanie całego środowiska biznesowego. Zapewnienie możliwości poprawnej pracy systemu, pomimo występowania usterek, to jedno z największych wyzwań związanych z architekturą mikroserwisową, ale też i źródło bardzo wymiernych korzyści dla użytkowników i deweloperów.

Aplikacje tworzone w oparciu o zwinne architektury często, wbrew oczekiwaniom, nie skalują się tak dobrze, jak powinny. Dlaczego?

Najczęściej powodem takiego stanu rzeczy są właśnie błędy na poziomie całościowej architektury oprogramowania. Źle zbudowane API, mnożenie ilości zapytań aplikacyjnych czy nieefektywne buforowanie danych to tylko niektóre z przykładów. Efektywne wykorzystanie mikroserwisów wymaga od deweloperów zmiany myślenia. O ile bowiem np. stosowanie rekursywnych odwołań do funkcji może mieć sens w systemach monolitycznych, to w środowisku mikroserwisowym może prowadzić do szybkiego przeciążenia całego systemu. Niezbędna jest ciągła optymalizacja relacji pomiędzy poszczególnymi komponentami środowiska aplikacyjnego. Należy myśleć o tym, jakie są funkcje biznesowe i transakcje biznesowe cenne dla użytkownika i pod tym kątem planować przepływ danych w systemie.

Czyli deweloperzy powinni postawić się w roli użytkownika końcowego…

Właśnie! Sprawne tworzenie systemów biznesowych opartych na najnowszych koncepcjach rozwoju oprogramowania wymaga zrozumienia oczekiwań użytkowników, istoty funkcji biznesowych i zdolności przełożenia tej wiedzy na kod. Zacierają się więc granice pomiędzy różnymi zespołami. Dochodzimy do praktycznej realizacji koncepcji BizDevOps. Wbrew pozorom, projekty cyfrowej transformacji nie opierają się tylko na technologii. Co więcej, wyzwania technologiczne to tylko niewielka część problemów towarzyszących tego typu projektom. Pozostała część to wyzwania związane z kulturą i strukturą organizacyjną.

I tak, aby deweloperzy mogli wykonywać pracę w zgodzie z nowymi regułami, powinni dysponować jak najbardziej zautomatyzowanymi narzędziami i środowiskami. Znów wracamy tu do koncepcji „self-driving IT (lepiej: it)”. Bieżący monitoring wielu aspektów działania takich środowisk pełni rolę swoistej nawigacji. Dostarcza wytycznych pozwalających na automatyczne dostosowywanie się środowisk do występujących zdarzeń biznesowych lub technologicznych. W Dynatrace stosujemy podobne podejście, powszechnie korzystamy też oczywiście z naszego oprogramowania. Dzięki temu udaje nam się podnosić jakość tworzonego kodu, a deweloperzy ‒ wyposażeni w proaktywne, zautomatyzowane narzędzia do testów samodzielnie wykrywają dziś 90% błędów.

Czy można powiedzieć, że architektura mikroserwisowa jest dziś najlepszym podejściem do rozwoju oprogramowania?

Mikroserwisy nie są uniwersalną odpowiedzią na wszystkie problemy. Z takiego założenia wychodzimy, rozwijając oprogramowanie Dynatrace. Mikroserwisy i kontenery to tylko dwie z całego szeregu możliwych opcji. W niektórych przypadkach może okazać się, że tradycyjny monolit będzie lepszym rozwiązaniem. Czasem lepsze będzie podejście mikroserwisowe lub wręcz wykorzystanie gotowych funkcji. Nierzadko okazuje się, że nie warto tworzyć własnego rozwiązania, bo na rynku dostępne są gotowe usługi SaaS.

Nasza praktyka pokazuje, że deweloperzy powinni skoncentrować się na problemach biznesowych, które mają rozwiązać, a nie skupiać się na tym, co będzie dla nich najwygodniejsze, najłatwiejsze lub najbardziej ambitne. Czasem warto rozejrzeć się na rynku i odpowiednio połączyć dostępne rozwiązania. Jeśli 80% istoty problemu biznesowego można zrealizować za pomocą gotowych narzędzi, to zaoszczędzony w ten sposób czas warto poświęcić na dopracowanie rozwiązania dla pozostałych 20%.

Jakie narzędzia mają dziś szczególne znaczenie w kontekście procesów związanych z rozwojem, utrzymaniem i doskonaleniem aplikacji?

W kontekście nowoczesnych architektur aplikacyjnych dla osób odpowiedzialnych za rozwój, testowanie i operacje IT ogromnego znaczenia nabiera możliwość ciągłego, zautomatyzowanego monitorowania działania środowiska. Monitoring na poziomie procesu CI/CD zapewnia system ostrzegający deweloperów przed ewentualnymi skutkami wprowadzanych zmian we wszystkich możliwych wymiarach. Co więcej, kompleksowy monitoring powinien obejmować cały cykl życia oprogramowania, aby sprawnie informować wszystkie zaangażowane zespoły o bieżących zdarzeniach istotnych dla funkcjonowania aplikacji i opartego na nich biznesu. Takie podejście oferujemy w narzędziach Dynatrace. Dodatkowo, ułatwiamy operacjonalizację monitoringu za sprawą integracji z popularnymi systemami wspierającymi zarządzanie incydentami, czy utrzymanie środowisk aplikacyjnych. Możliwe jest np. wykorzystanie oprogramowania Dynatrace za pośrednictwem chatbota.

Co jednak ważniejsze, nasze oprogramowanie może być łatwo włączone w cały proces rozwoju i utrzymania oprogramowania. Automatyczne wykrywanie zależności pomiędzy komponentami aplikacyjnymi, a także wąskich gardeł wydajnościowych, błędów w kodzie oprogramowania czy problemów sieciowych to tylko niektóre z możliwości nowoczesnego monitoringu oprogramowania Dynatrace. Ich wykorzystanie w pełni wymaga jednak zmiany dotychczasowych przyzwyczajeń wielu osób zaangażowanych w tworzenie i utrzymywanie aplikacji. Aby w pełni wykorzystać nowe możliwości monitoringu, deweloperzy będą musieli spojrzeć na firmowe systemy nie z perspektywy kodu aplikacyjnego, ale tak, jakby sami mieli z nich korzystać. To deweloper będzie osobą, która zdecyduje, jakie środki lub KPI powinny być brane pod uwagę w zakresie potrzeb dotyczących informowania o potencjalnych efektach zmian wdrażanych w systemach IT. Deweloper zdecyduje, które wskaźniki będą świadczyć o wystąpieniu problemu.

Tu dochodzimy do sedna koncepcji zakładającej wykorzystanie funkcji monitoringu z poziomu kodu. Analogicznie ma to miejsce w przypadku infrastruktury definiowanej aplikacyjnie lub programowalnych środowisk testowych. Dziś istnieje możliwość nie tylko zdefiniowania za pomocą kodu aplikacyjnego dostępnych dla aplikacji zasobów i procedur testowych, ale też miar służących ocenie efektywności aplikacji. Różnego rodzaju sygnatury wydajnościowe czy miary zależności będą sprzyjać szybkiej ocenie jakości oprogramowania. Będą też ułatwiać prowadzenie analiz biznesowych dotyczących firmowych środowisk IT.

Czy takie analizy to bardziej domena działów IT, czy może działów biznesowych?

I jednych, i drugich. Biznes i IT pracują wspólnie i na rzecz jednego celu, choć wymagają najczęściej różnych miar oceny efektywności. Dotyczy to także oprogramowania. Odpowiednie dopasowanie wskaźników do roli użytkowników daje możliwość nawiązania dwustronnej współpracy zmierzającej do polepszenia efektywności oprogramowania w wymiarze technicznym, użytkowym, ale też w codziennej praktyce biznesowej. O ile więc, opierając się na twardych KPI, użytkownicy biznesowi będą np. oczekiwać od zespołu deweloperów poprawy sprawności wykorzystania zasobów, tak specjaliści IT będą w stanie łatwo przekonać biznes do zaniechania rozwoju nieużywanych funkcji, aby uwolnić zasoby.

Czym nowa platforma Dynatrace różni się od Państwa środowiska monitorującego poprzedniej generacji?

Poprzednia generacja naszych rozwiązań monitorujących – Appmon – była zbudowana na potrzeby monitorowania klasycznych architektur aplikacyjnych. Wraz z nową odsłoną Dynatrace proponujemy rozwiązanie zbudowane pod kątem skutecznego monitorowania nowoczesnych środowisk IT, w tym także zwinnych i dynamicznych aplikacji biznesowych. Wychodzimy z założenia, że nowoczesny monitoring musi skupiać się na usługach, a niekoniecznie na poszczególnych elementach wykorzystywanych do ich świadczenia. Nie zawsze bowiem fakt wygaszenia kontenera lub mikroserwisu jest dowodem awarii. Może być to naturalny element cyklu życia danej usługi aplikacyjnej czy strategii rozwoju oprogramowania. Z drugiej strony, zdajemy sobie sprawę, że nie we wszystkich organizacjach nastąpi szybkie i całościowe przejście na nowe architektury. Dlatego Dynatrace wspiera migrację do środowisk zwinnych, ale też całkowicie klasyczne rozwiązania.

Nasze rozwiązanie wyróżnia też fakt, że platforma Dynatrace wspiera cały stos technologii. Dzięki temu możemy monitorować działanie aplikacji z perspektywy użytkowników końcowych, ale też konkretnych usług, procesów, hostów, komponentów sieciowych oraz logów i to niezależnie od technologii na jakiej są oparte. Jednocześnie pomimo rozbudowanych możliwości nasza platforma jest prosta w użyciu. Zautomatyzowane procesy pozyskiwania informacji o środowisku aplikacyjnym umożliwiają szybkie dotarcie do sedna problemu, niezależnie od tego, czy dotyczy on sieci, architektury czy linii kodu.

Co ważne, w naszym systemie gromadzone są szczegółowe informacje na temat wszystkich transakcji. Nie używamy agregatów. Dzięki temu platforma Dynatrace dostarcza użytkownikom bardzo szczegółowe informacje na temat funkcjonowania środowiska aplikacyjnego, a nawet na temat jednostkowych interakcji oraz doświadczeń indywidualnych użytkowników. Nie chodzi tu jednak wyłącznie o sam fakt posiadania szczegółowych danych, ale o możliwość łatwego prowadzenia analiz przyczynowo-skutkowych w zakresie wszystkich transakcji realizowanych w danym środowisku aplikacyjnym. Dzięki temu platforma Dynatrace staje się źródłem cennej wiedzy dla deweloperów, ale także dla użytkowników.

Artykuł ukazał się na łamach Magazynu ITwiz nr. 6-7/2018. Szczegóły dotyczące publikacji wraz z formularzem dla osób zainteresowanych zakupem wydania dostępne są na stronie: https://itwiz.pl/kiosk