Migracja platformy rozrywki pokładowej.

Stara platforma opierała się na modelu jednej instancji CMS na tenanta. Każda linia lotnicza miała własną instancję Umbraco, własną stronę w brandingu danej marki i własną konfigurację operacyjną.

Przez pewien czas to działało, ale utrzymanie stawało się coraz trudniejsze. Zarządzanie użytkownikami, treścią, konfiguracją, wdrożeniami i aktualizacjami platformy trzeba było powtarzać w osobnych instancjach. W środowisku produkcyjnym klient obsługiwał siedem stron linii lotniczych przez siedem instancji CMS.

Każda linia lotnicza miała inny branding, domeny, katalogi, języki, układy i funkcje. Treści nie były współdzielone między liniami, więc platforma nadal musiała utrzymywać wyraźną izolację tenantów. Zmienić musiał się jednak model operacyjny wokół tej izolacji.

Warstwa API również wymagała zmian. API było podzielone na wiele obszarów, takich jak filmy, audio, gry, loty i usługi pomocnicze. Stary proces synchronizacji pobierał dane z systemów klienta, ale rosnące wymagania produktowe coraz bardziej utrudniały rozwijanie tego modelu.

Przepisanie wszystkiego naraz byłoby zbyt ryzykowne. Stary i nowy system musiały działać obok siebie, a kolejne funkcje trzeba było wymieniać etapami.

Zaczęliśmy od analizy istniejącego API i jego obszarów biznesowych: filmów, audio, gier, lotów i usług pomocniczych.

Analiza pokazała, że nie musimy migrować wszystkiego naraz. Platformę można było unowocześniać stopniowo: wymieniać jeden obszar API po drugim, podłączać nowe usługi do istniejącego procesu synchronizacji i pozwolić starym oraz nowym częściom systemu współistnieć w czasie migracji.

Wybraliśmy architekturę mikroserwisową, aby każdy obszar biznesowy można było wydzielić i migrować niezależnie. Azure API Management pomagał kierować ruchem, gdy stare i nowe API działały równolegle.

Pierwsze usługi wprowadziliśmy do istniejącego procesu, zaczynając od lotów, później filmów, a następnie pozostałych obszarów API. Łącznie wymieniliśmy sześć modułów API.

Takie podejście zmniejszyło ryzyko. Produkt mógł działać dalej, podczas gdy architektura zmieniała się krok po kroku.

Po migracji API przeszliśmy do głębszych warstw platformy odpowiedzialnych za synchronizację i administrację.

Stary proces synchronizacji opierał się na odpytywaniu API. Pobierał dane z systemów klienta i synchronizował treści takie jak filmy, audio, gry i loty. Część danych trafiała też przez ręczne przesyłanie.

Przeprojektowaliśmy synchronizację tak, aby była sterowana zdarzeniami. Zdarzenia z systemów klienta uruchamiały dalsze przetwarzanie, zamiast polegać wyłącznie na cyklicznym odpytywaniu API.

Nowa synchronizacja pozwoliła też lepiej wzbogacać dane, zanim trafiły do pasażerów. Zespoły mogły dodawać tagi do filmów, uzupełniać brakujące tłumaczenia, podmieniać grafiki niskiej jakości i lepiej przygotowywać treści pod potrzeby konkretnych linii lotniczych.

Zsynchronizowane i wzbogacone dane były przechowywane w różnych częściach platformy: w CMS, bazach danych backendu i indeksach wyszukiwania, zależnie od tego, jak korzystały z nich strona pasażerska, API, panel administracyjny i zewnętrzni odbiorcy.

Klient potrzebował nowoczesnego panelu administracyjnego, ale jednorazowa wymiana wszystkich starych funkcji spowodowałaby zbyt duże zakłócenia dla użytkowników.

Zbudowaliśmy nowy panel w React i osadziliśmy w nim wybrane starsze widoki administracyjne przez iframe. Użytkownicy dostali jedno miejsce pracy, a stare funkcje można było stopniowo wymieniać w tle.

Zachowaliśmy ten sam model ról i uprawnień, więc użytkownicy nie musieli uczyć się osobnego modelu dostępu w trakcie migracji.

Z czasem stare funkcje przenosiliśmy do nowego panelu i dodawaliśmy nowe możliwości. Panel administracyjny stał się jednocześnie ulepszeniem produktu i praktycznym pomostem między starą a nową platformą.

Migracja CMS była jedną z najważniejszych zmian architektonicznych.

Stara platforma używała Umbraco 7.15, z jedną instancją Umbraco na każdą linię lotniczą. Nie istniała oficjalna, bezpośrednia ścieżka migracji z tej wersji do nowoczesnej wersji docelowej, więc warstwę CMS trzeba było zaprojektować od nowa, a nie po prostu zaktualizować.

Przeszliśmy na model headless CMS z wykorzystaniem nowoczesnego Umbraco, początkowo w wersji 14, a obecnie 17. Zamiast uruchamiać osobny CMS dla każdej linii lotniczej, nowa platforma używa jednej instancji CMS obsługującej wszystkich tenantów.

Każda linia lotnicza nadal ma własną stronę, domenę, katalog, języki, układ, branding i zestaw funkcji. Model działania jest jednak prostszy: jeden CMS, wielu tenantów i wyraźniejsze rozdzielenie zarządzania treścią od renderowania doświadczenia pasażera.

Strony dla pasażerów przebudowaliśmy w React i Next.js. Usunęło to potrzebę niestandardowego renderowania w starych stronach Umbraco i pozwoliło uniknąć wielu wcześniejszych problemów z renderowaniem po stronie serwera i klienta.

Rezultatem była czystsza architektura: Umbraco zarządza treścią, frontend renderuje stronę dla pasażera, a API zapewniają ustrukturyzowany dostęp dla stron, użycia na pokładzie, użycia przed lotem i w salonach oraz dla zewnętrznych partnerów.

Streaming był jednym z kluczowych powodów, dla których stary system wymagał zmiany.

W ramach migracji rozszerzyliśmy platformę o streaming w salonach lotniskowych. Zintegrowaliśmy ją z dostawcą streamingu i dostosowaliśmy tak, aby treści linii lotniczych mogły być prezentowane i odtwarzane w tym kontekście.

Nie była to wyłącznie funkcja frontendowa. Wymagała, aby platforma lepiej obsługiwała treści, metadane związane ze streamingiem, integracje z zewnętrznymi partnerami i zachowania zależne od tenanta.

Migracja zrobiła więc więcej niż tylko wymieniła starą technologię. Stworzyła fundament pod nowe możliwości produktu, których nie dało się wygodnie rozwijać w starym stacku.

Modernizacja zmieniła też model hostingu.

Stara platforma częściowo opierała się na maszynach wirtualnych. Nowa platforma działa w całości na Azure, bez aplikacji hostowanych na VM.

Unowocześniony stack obejmuje usługi ASP.NET Core, aplikacje React i Next.js, Umbraco, SQL Server, MongoDB Atlas, Service Bus, Azure Container Apps, Azure API Management, Azure B2C, Azure DevOps oraz infrastrukturę jako kod opartą na Terraform.

Dało to klientowi bardziej spójny model wdrożeń, wyraźniejszą odpowiedzialność za infrastrukturę i mocniejszą bazę pod dalszy rozwój platformy.

Migracja jest zakończona, platforma działa produkcyjnie, a my nadal ją utrzymujemy.

Klient przeszedł z siedmiu instancji CMS przypisanych do konkretnych linii lotniczych na jeden CMS w modelu multi-tenant. Siedem stron linii lotniczych działa teraz na współdzielonej architekturze, nadal z osobnymi domenami, katalogami, brandingiem, językami, układami i zestawami funkcji.

Wymieniliśmy sześć usług API, proces synchronizacji przeprojektowaliśmy wokół zdarzeń, a panel administracyjny unowocześniliśmy bez zmuszania użytkowników do nagłego przełączenia na inną aplikację.

Platforma obsługuje ponad 100 000 rekordów treści obejmujących filmy, audio, gry i loty.

Jednym z najwyraźniejszych usprawnień operacyjnych jest wdrażanie nowych linii lotniczych. Uruchomienie nowej instancji zajmuje teraz około trzech dni. Wcześniej mogło trwać około miesiąca.

Rezultatem jest nowoczesna platforma IFE, która obsługuje strony dla pasażerów, API dla zewnętrznych partnerów, panel administracyjny, synchronizację danych, użycie na pokładzie, przed lotem i w salonach oraz streaming w salonach lotniskowych — bez dalszego przenoszenia ciężaru starej architektury.