Jak przejść na architekturę typu composable?

Chcesz zastąpić swój dotychczasowy system i przejść w stronę architektury kompozytowej? 

Podejście to niesie ze sobą wiele korzyści, pozwalając na uzyskanie nowoczesnej architektury IT w pełni dostosowanej do Twoich potrzeb. Transformacja wiąże się jednak z pewnymi ograniczeniami, ponieważ wymaga również zmiany sposobu pracy. 

Aby przeprowadzić migrację do architektury kompozytowej, należy w pierwszej kolejności dokonać oceny obecnej architektury.

Następnie postępować zgodnie ze szczegółową metodologią, którą prezentujemy na przykładzie case study witryny e-commerce. Na koniec przedstawiamy najlepsze praktyki dotyczące wdrażania i zarządzania tego typu systemem..

Czym jest architektura composable? Korzyści i ograniczenia

Zrozumienie architektury composable

Przebudowa starego systemu (legacy) poprzez wybór architektury composable pozwala odejść od monolitycznej wizji narzędzi IT. Rzeczywiście, tradycyjny model monolityczny jest prezentowany jako blok łączący różne aplikacje biznesowe, zazwyczaj zintegrowane jako wtyczki (plug-ins). Choć pozwalają one na wykonywanie różnych funkcji biznesowych, ich integracja nie zawsze wystarcza, aby zaspokoić wszystkie potrzeby.

Architektura composable wygląda inaczej. Wykorzystuje funkcjonalności uosobione przez poszczególne komponenty, które działają niezależnie. Oferuje to większą elastyczność, ponieważ można pracować nad jednym komponentem naraz, nie wpływając na resztę architektury.

Platforma oferuje optymalne, płynne doświadczenie klienta. Rozwiązanie typu Backend for Frontend (BFF) łączy platformę z różnymi narzędziami biznesowymi, takimi jak CRM, PIM czy OMS, dostarczając niezbędne informacje we właściwym czasie.

Korzyści z architektury composable

Przejście na architekturę composable umożliwia:

• posiadanie narzędzi, które rzeczywiście odpowiadają Twoim potrzebom, bez konieczności korzystania z gotowych wtyczek. Stajesz się faktycznym właścicielem danych rozwiązań, a nie tylko dodatków uzupełniających system;
• tworzenie specyficznych rozwiązań (custom development) w oparciu o precyzyjne potrzeby;
• oferowanie płynnego doświadczenia klienta o wysokiej jakości.

Ograniczenia tego typu architektury

Adopcja tego typu architektury wymaga jednak adaptacji. Metody pracy znacząco różnią się od tych stosowanych w przypadku monolitu. Wiąże się to z poleganiem na chmurze w celu zapewnienia skalowalności platformy oraz pracą z narzędziami takimi jak :

• Docker/Kubernetes
• infrastruktura jako kod (IaC);
• automatyzacja wdrożeń;
• monitorowanie typu APM;
• scentralizowane logi.

Niezbędne jest podejście API-first, aby zachować zgodność z modelem headless, co wymaga:

• narzędzi do pracy lokalnej;
• kultury DevOps;
• krótszych cykli wdrażania;
• zarządzania zależnościami i kompatybilnością wsteczną;
• strategii testowania.

Ponadto należy przeprowadzić zmianę kulturową, która wymaga:

• zrozumienia technologii headless e-commerce;
• wiedzy, gdzie należy zastosować daną regułę biznesową;
• umiejętności rozwijania kompetencji niezbędnych do pracy z wdrożonymi narzędziami.
   

Analiza stanu Twojej architektury IT

Przed migracją do architektury typu composable niezbędne jest dokładne zrozumienie obecnej architektury IT.  Wiąże się to z precyzyjną wiedzą na temat tego, co robi Twój dotychczasowy system (legacy):

• bezpośrednie zależności systemów legacy: od jakich systemów są one zależne? Jak wyglądają przepływy danych i reguły biznesowe?
• istniejące niestandardowe zastosowania: w jaki sposób użytkownicy korzystają z systemów w oparciu o niepisane zasady? Jak istotne są te praktyki? Jakie są konsekwencje ich ewentualnego usunięcia?
• rzeczywiste reguły biznesowe: czy reguły te są udokumentowane? Jeśli tak, to czy zrobiono to w sposób precyzyjny?

Migracja do architektury composable: case study projektu e-commerce

Wyobraźmy sobie następujący scenariusz migracji witryny e-commerce opartej na monolicie typu „wszystko w jednym” (all-in-one). Firma ta łączy się z innym przedsiębiorstwem, które również posiada system typu legacy. Połączenie tych dwóch architektur jest niemożliwe. Zapada więc decyzja o migracji witryny e-commerce do architektury composable.

W procesie tej migracji niezbędne jest wykonanie poszczególnych kroków.

Dodanie Headless CMS

Przyzwyczajenie się do działania systemu Headless CMS może zająć trochę czasu. Rzeczywiście, różni się on znacząco od tradycyjnego CMS-a. Headless CMS nie posiada silnego powiązania z menu nawigacyjnym. Zarządzanie treścią jest niezależne od struktury drzewiastej. Poszczególne treści mogą być tytułami, obrazami lub tekstami, które można dowolnie które można dowolnie zestawiać.

Aby wyświetlić treść na stronie produktu, należy wykonać następujące czynności:

• w edycji artykułu w CMS skonfigurować pole „artykuły”, aby wprowadzić identyfikatory produktów.
• połączyć treść redakcyjną z danymi produktu na poziomie warstwy Backend for Frontend.
• ana poziomie frontendu, za pomocą wywołania GraphQL, wyraźnie zażądać pobrania treści redakcyjnej obok danych produktu.
• sformatować dane, gdy zostaną już pobrane

Planowanie integracji systemu PIM

Celem integracji systemu PIM jest:

• udostępnienie w Backend for Frontend metody takiej jak get_product_by_id.
• połączenie systemu Backend for Frontend z PIM, aby pobierał on dane odpowiadające danemu produktowi.
• skonfigurowanie pamięci podręcznej (cache) typu klucz-wartość na poziomie Backend for Frontend, aby uniknąć odpytywania PIM o znane już dane.
• wdrożenie metody czyszczenia pamięci podręcznej (poprzez wygaśnięcie lub udostępnienie API).

Możliwe jest jednak zaproponowanie etapu przejściowego, który pozwoli zaplanować późniejszą integrację PIM. W tym przypadku podejście jest następujące:

• udostępnienie w Backend for Frontend metody takiej jak get_product_by_id.
• połączenie Backend for Frontend z systemem legacy, aby pobierał on dane odpowiadające danemu produktowi.
• skonfigurowanie pamięci podręcznej typu klucz-wartość na poziomie Backend for Frontend, aby uniknąć odpytywania systemu legacy o znane już dane.
• wdrożenie metody czyszczenia pamięci podręcznej (poprzez wygaśnięcie lub udostępnienie API).

System legacy jest wykorzystywany jako narzędzie przejściowe w modelu headless poprzez odcięcie go od front-office'u. Dzięki temu system PIM będzie mógł w przyszłości zastąpić legacy bez wpływu na warstwę programistyczną.

Jak odłączyć frontend od systemu legacy, aby wdrożyć rozwiązanie przejściowe?

Istnieją dwie możliwe opcje.

W pierwszym przypadku system legacy jest „podpięty” na poziomie adresów URL. Domyślnie cała witryna jest obsługiwana przez system legacy. Gdy dany dział witryny zaczyna być zarządzany przez nową architekturę, ruch może być tam przekierowywany na podstawie adresu URL. Na przykład wszystkie adresy URL zawierające …./product_detail/… zostaną odłączone od systemu legacy. 

Należy jednak przewidzieć różne wyzwania:

• Czy elementy wspólne, takie jak nagłówek (header) lub stopka (footer), powinny zostać użyte ponownie, aby zachować spójność doświadczenia klienta?
• Czy styl graficzny powinien zostać zachowany?
• W jaki sposób wyświetlać koszyk na ekranie?
• Czy wiadomo, jak generować linki do aplikacji monolitycznej?

Druga metoda polega na osadzaniu na stronie komponentów pochodzących z nowej architektury. Nowe elementy (karuzela, treści redakcyjne, nowa metoda płatności itp.) są dodawane do strony za pomocą skryptu JavaScript wywoływanego bezpośrednio z poziomu systemu legacy. Tutaj również należy przewidzieć pewne kwestie: 

• Czy wiesz, jak zmodyfikować szablon monolitu, aby wstawić dynamiczny skrypt JavaScript?
• Czy zachowanie wstrzykniętego komponentu zależy od identyfikacji użytkownika?
• Jak dopasować się do stylu graficznego monolitu?

Najlepsze praktyki migracji do architektury composable

Oto kilka wskazówek, które pomogą Ci przygotować się do migracji na architekturę typu composable.

Akceptacja nieprzewidywalności 

Ważne jest zaplanowanie kluczowych punktów, ale proces ten wymaga również adaptacji i akceptacji tego, co nieoczekiwane:

• Cel jest jasny, ale szczegóły prawdopodobnie będą ewoluować.
• plan wdrożenia jest gotowy, ale w trakcie pojawią się nowe możliwości.
• Przygotowano prognozy, ale nie przetestowano ich jeszcze w praktyce

Zadaj sobie następujące pytania:

• Jak odróżnić szansę od złego pomysłu?
• Jak przygotować się do sprawnej oceny planów?
• Jak odróżnić czas potrzebny na naukę i zdobywanie umiejętności od zwykłej nieefektywności?

Przygotuj podstawy 

Jeśli architektura composable jest dla Ciebie częściowo lub całkowicie nowa, poćwicz jej obsługę przed rozpoczęciem właściwych prac programistycznych:

• Wybierz platformę chmurową.
• Wykorzystaj Terraform, aby wyświetlić „hello world” w aplikacji opartej na technologiach, na które się zdecydowałeś..
• Wdróż „hello world” w sposób zautomatyzowany.
  Jeśli napotkasz problemy sieciowe z dostępem do konkretnych zasobów, rozwiąż je już na etapie „hello world”.
• Skonfiguruj monitorowanie i centralizację logów. Ważne jest, aby zbierać te elementy w jednym miejscu, co pozwoli uniknąć straty czasu i szybko wykrywać problemy.

Skonfiguruj proces ciągłego wdrażania

Musisz skonfigurować proces ciągłego wdrażania, aby uniknąć jakichkolwiek blokad:

• Wdrażaj tak wcześnie, jak to możliwe: dzięki temu będziesz wiedzieć, co wdrażasz i zyskasz wskaźniki testowe w rzeczywistych warunkach.
• Monitoruj system, zbierając i centralizując logi oraz obserwując, jak zmienia się obciążenie serwerów przy kolejnych wdrożeniach.
• Stawiaj na małe przyrosty (increments), ponieważ łatwiej jest śledzić ich wpływ na system.
• Naucz się robić rollback – wycofywanie zmian musi być proste i szybkie.
• Preferuj aktywację nad samym wdrożeniem: w takim przypadku rollback staje się po prostu dezaktywacją funkcji.
• Przewiduj migracje danych – zazwyczaj są one bardziej skomplikowane, niż się wydaje.
• Nie zapomnij świętować sukcesów!

Testowanie systemu jest kluczowe:

• Nie wahaj się tworzyć projektów POC (Proof of Concept).
• Nie wahaj się wdrażać ich na produkcję (w stanie wyłączonym).
• Zainwestuj czas w przygotowanie testów automatycznych (z umiarem).
• Monitoruj wpływ zmian na użytkowników, planując analizę ich zachowań przed i po wdrożeniu.

Migracja do architektury composable i przewidywanie zmian

Migracja do architektury composable to nie tylko ewolucja technologiczna. Musi być ona również odpowiednio zaplanowana pod kątem akceptacji nadchodzących zmian. Korzystanie z architektury composable znacząco różni się od pracy z klasycznym systemem CMS, dlatego wymagany jest czas na adaptację, zanim zacznie się czerpać z niej korzyści.

Nie wahaj się otoczyć ludźmi, którzy posiadają wiedzę i doświadczenie niezbędne do wsparcia Cię w procesie migracji na architekturę composable. W tym celu skontaktuj się z Kaliop.