Z technologicznego punktu widzenia najbliższe miesiące to bardzo ekscytujący czas w Sabre. Wiele rzeczy ulega zmianie i prawie wszystkie one mają wspólny mianownik w postaci projektu Next Generation Platform. Podstawę migracji aplikacji firmy, jak i całego procesu deweloperskiego do chmury stanowią Kubernetes i OpenShift, czyli komercyjna wersja projektu od Google dostarczana przez RedHat.
Nie jest to pierwszy raz kiedy Sabre przystępuje do transformacji technologicznej, ani też pierwsza próba migracji aplikacji do chmury, ponieważ już teraz firma jest obecna w AWS. Tym razem u podstaw dalszej migracji leży konieczność swobodnej dystrybucji komponentów w obrębie hybrydowej chmury - składającej się zarówno z własnych serwerowni On-Premise, jak i rozwiązań chmur publicznych wielu dostawców z całego świata. Istotnym elementem przedsięwzięcia jest równoczesna zmiana architektury zmierzająca w kierunku tworzenia aplikacji w oparciu o paradygmat mikroserwisów.
Dla architektów i deweloperów oznacza to zasadnicze uproszczenie oraz oszczędność czasu w codziennej pracy. Potężny zestaw narzędzi do tworzenia w pełni automatycznego procesu budowy i dostarczania kodu (CI/CD) oraz możliwość dynamicznej alokacji zasobów na żądanie, pozwala skupić się nad kwestiami merytorycznymi oraz zmaksymalizować produktywność. Założeniem projektu jest, by nowi pracownicy byli w stanie rozpocząć produktywną pracę już w pierwszym dniu po dołączeniu do projektu. Tak nowoczesne i rozproszone środowisko, pozwalające na teoretycznie nieograniczone skalowanie horyzontalne oraz mechanizmy self-healing nie zwalnia jednak z odpowiedzialności za dostarczanie wydajnych i stabilnych aplikacji.
Głównym celem przyświecającym stworzeniu Next Generation Platform było usprawnienie pracy programistów, nie tylko od strony technologicznej, ale również od strony procesowej. Nowe możliwości automatyzacji oznaczają liczne wyzwania z punktu widzenia zarządzania zmianami kodu oraz konfiguracji systemów obsługujących ogromne liczby transakcji. W trakcie czytania tego artykułu klienci Sabre wygenerują około 15 milionów zapytań, co poskutkuje kilkukrotnie większą liczbą transakcji wewnątrz infrastruktury firmy. Założenie, że każdy scrumowy zespół developerski jest gotowy do codziennego instalowania nowej wersji swojej aplikacji, spowoduje 10-20-krotne zwiększenie liczby wykonywanych dziennie zmian. To właśnie obszar analizy zależności oraz eliminacja manualnych elementów procesów jest największym wyzwaniem oznaczającym istotną zmianę kultury organizacyjnej. Naszym celem jest wyeliminowanie technologicznych przeciwskazań do wydawania aplikacji kilka razy dziennie – jeśli ktoś nie potrafi tego dokonać w 2018 roku, to oznacza, że poniósł porażkę!
Next Generation Platform ma być w pełni heterogeniczna. Oznacza to na równi aplikacje napisane w języku Java, C/C++, Java Script, C# czy ostatnio Go. Natychmiast po zdeployowaniu aplikacji ma być ona zintegrowana z systemem logowania (opartym na stosie EFK), metrykami, alertami oraz dashboardami (poprzez tandem Prometheus i Grafana), transaction tracing (zestandaryzowane w oparciu o OpenTracing API oraz Jaeger). Dzięki podążaniu za otwartymi standardami (choćby definiowanymi przez Cloud Native Computing Foundation) integracja z tymi usługami ma nie wymagać więcej niż kilku linijek kodu.
Rozwijając projekty Open Source Sabre nawiązało współpracę z RedHat w ramach Early Access Program dla projektów Istio (Service Mesh), Strimzi (Kafka as a service), enmase (ActiveMQ as a service). Zespół pracowników Sabre Polska był również obecny na konferencji RedHat w San Francisco prezentując elementy NGP. Powoli, ale sukcesywnie firma będzie otwierać także kod niekrytycznych komponentów, z których kilka już obecnie rozwijanych jest na platformie GitHub (SabreOSS).
W zakresie wyzwań dla architektów Sabre największym jest niewątpliwie kwestia konsystencji i dystrybucji danych w ramach pojedynczego mikroserwisu i pomiędzy nimi. Dla wolumenów danych liczących dziesiątki terabajtów zaczyna być to problem na tyle duży, że nie można go ignorować (choćby z punktu widzenia kosztowego). Tutaj wkraczają zagadnienia CQRS, Event Sourcing, Saga Pattern itp.
W zakresie Infrastructure-as-a-Service jest to instalacja K8S w wielu data center oraz public cloud od różnych dostawców. Składa się na to cały proces, od zapewnienia niezbędnego połączenia pomiędzy klastrami, po kwestie bezpieczeństwa, izolacji i QoS dla środowiska wykorzystywanego przez wielu użytkowników (multitentant). Definitywnie nie istnieje tylko jeden słuszny sposób rozwiązania takich problemów, subtelne różnice np. w wyborze takiego, a nie innego storage przekładają się na duże różnice finansowe. Istnieje tu sporo miejsca do dalszych optymalizacji, jak choćby w pełni dynamiczne skalowanie infrastruktury czy poleganie w większym stopniu na spot instancjach w celu optymalizacji kosztów. Sporo uwagi pochłania również zgodność infrastruktury z wymaganiami prawnymi jak choćby GDPR, PII (Personally Identifiable Information) czy PCI DSS (Payment Card Industry Data Security Standard).
Jeżeli chodzi o usługę Platform-as-a-Service, to już w ramach samego Kubernetesa (K8S) są w Sabre zespoły pracujące właśnie nad usługami. Są to albo hostowane przez firmę rozwiązania Open Source lub rzadziej natywne dla żądanego dostawcy usług chmurowych. Ta druga opcja wymaga jednak, by usługa była oparta na publicznym API i umożliwiała migracje danych, dlatego jednym z głównych paradygmatów dla tej warstwy jest ustanowienie API usług niezależnego od docelowego miejsca wdrożenia. Tutaj pojawia się całe spektrum rozwiązań dotychczas trudno dostępnych w Sabre: DaaS (SQL/NoSQL), ML/AI, Big Data. Wszystkie one muszą być łatwo integrowalne z poziomu K8S, sama dostępność technologii nie gwarantuje sukcesu, ale na pewno jej brak blokuje kreatywność w poszukiwaniu rozwiązań.
W przypadku Software-as-a-Service kluczowe są aplikacje biznesowe, w których deweloperzy powinni mieć jak najłatwiejszą integrację z CI/CD oraz wszystkimi niefunkcjonalnymi wymaganiami na platformie. Jeśli są to standardowe frameworki (np. dla Javy jest to Spring Boot), zintegrowanie się powinno zająć kilka minut. Deweloperzy muszą skupić się na dostarczaniu wartości dodanej dla klientów w kluczowych obszarach biznesowych – tutaj na pewno spodziewać można się znacznie większego wykorzystania Machine Learning i Artificial Intelligence w najbliższej przyszłości. Wiele systemów Sabre ma krytyczne znaczenie dla działania linii lotniczych czy infrastruktury lotniczej. Konieczność zapewnienia stabilności, wydajności czy funkcjonalności nie znika po migracji do chmury, a wręcz staje się nawet bardziej krytyczna.
Wraz ze wzrostem możliwości rosną też wymagania wobec aplikacji i procesów, a tym samym i deweloperów. Praktyki DevOps wymuszają na zespole interdyscyplinarność: każdy deweloper musi być w stanie napisać test akceptacyjny, wydajnościowy czy przeprowadzić bezpieczne wdrożenie. Informacje o aplikacji, takie jak pokrycie kodu testami, wyniki testów akceptacyjnych czy wydajnościowych, są publicznie dostępne. Biorąc przykład z rozwiązań Open Source, Sabre wierzy, że otwartość w pozytywny sposób wpływa na jakość produktu.
Jednym z kluczowych elementów NGP jest kwestia spójnej strategii dla zmiany technologicznej, która ma obejmować całą firmę. Taki proces nie jest łatwy i wymaga zaangażowania i wykorzystania nowych możliwości przez wszystkie działy firmy. W przypadku Sabre takie podejście propagowane jest przez kadrę zarządzającą. CEO firmy Sean Menke wielokrotnie podkreśla, że klienci oczekują od Sabre przewodzenia transformacji rynku usług turystycznych. Spora tu rola działu marketingu oraz architektów, by wykorzystać możliwości nowej platformy i dostarczyć ulepszone i całkowicie nowe produkty dla klientów.
W przeciągu zaledwie sześciu miesięcy od początku funkcjonowania Next Generation Platform udało się już wdrożyć pierwsze aplikacje produkcyjnie. Na bazie tych doświadczeń i kolejnych kilku pilotów, do końca roku Sabre ma zamiar rozpocząć znacznie szersze wdrażenie nowej platformy. Już dziś jednak każdy pracownik może założyć konto na klastrze developerskim i eksperymentować do woli, firma jest bowiem przygotowana na skalowanie klastra do 120 instancji M5.large w AWS.
Sabre czeka dużo pracy, by przenieść i zmodernizować aplikacje, tak aby efektywnie rezydowały w chmurze. Dotyczy to także aplikacji obecnie uruchomionych na mainframe’ie, które w szczególności będą wymagały analizy pod kontem zarówno technicznym, jak i biznesowym w celu dostosowania ich do wymagań architektury mikroserwisów. W dalszych planach jest udoskonalenie i przeniesienie w chmurę całego procesu deweloperskiego oraz rozwój wraz z całym ekosystemem K8S/OpenShift. Na to wszystko Sabre daje sobie 5 lat, wbrew pozorom nie tak dużo, jeśli chce się technologicznie zmodernizować całą firmę.
Artykuł jest częścią akcji Zmienimy Świat.
Hej, jesteśmy na Google News - Obserwuj to, co ważne w techu
