Budowanie i uruchamianie mikroserwisów w skali: Spojrzenie CTO

Budowanie i uruchamianie mikroserwisów w skali: Spojrzenie CTO

18 marca 2022 0 przez It-hits

Dylemat innowatora mówi nam, że współczesne organizacje odnoszące sukcesy będą coraz częściej zmuszone do przyjmowania nowych procesów, aby móc się rozwijać. W przypadku nowoczesnych organizacji, których przewaga konkurencyjna zależy od rozwoju oprogramowania, ta nieustanna potrzeba zmian wymaga zmiany sposobu pracy zespołów programistów. W Priceline – jednym z najczęściej odwiedzanych portali turystycznych na świecie, odwiedzanym przez miliony użytkowników miesięcznie – oznacza to nie tylko przyjęcie nowych, innowacyjnych technologii, ale także zupełnie nowego sposobu myślenia o tym, w jaki sposób tworzymy i wdrażamy usługi.

Jeśli chcemy odnieść sukces na bardzo konkurencyjnym rynku, musimy wspierać zupełnie nowe strategie świadczenia usług, a to wymaga przemyślenia i staranności ze strony kierownictwa ds. technologii. Nasz zespół technologów, składający się z samych gwiazd, skupił się wokół rozwoju aplikacji opartego na 12 czynnikach, monorepozycji, rozwoju opartego na pniu oraz zarządzania zależnościami, starając się przewodzić ewolucji technologii w branży turystycznej. Ale wciąż jest wiele do zrobienia.

Zastanówmy się nad mikroserwisami opartymi na kontenerach. Przedsiębiorstwa są znacznie dalej na krzywej adaptacji kontenerów i Kubernetes niż jeszcze kilka lat temu. Według badania przeprowadzonego przez Cloud Native Computing Foundation w 2020 roku, wykorzystanie kontenerów w produkcji wzrosło o 300 procent od 2016 roku. Obecnie 80% całej platformy produktowej firmy Priceline działa w chmurze Google Cloud w oparciu o kontenery i Kubernetes.

Wiele dużych organizacji technologicznych zaczyna czerpać korzyści (i odkrywać nowe wyzwania) z tej zmiany paradygmatu tworzenia aplikacji, ale wiele innych dopiero rozpoczyna tę podróż. A ekonomia sugeruje, że nigdy nie zatrudnimy wystarczającej liczby ekspertów ds. devops i SRE, aby nadążyć za rosnącymi wymaganiami w zakresie rozwoju oprogramowania. CTO na całym świecie muszą zadawać sobie pytanie nie tylko o to, jak sprawić, by ich aplikacje były bardziej odporne i skalowalne, ale także jak przekazać większą odpowiedzialność programistom, nie przytłaczając ich żmudną, ręczną pracą.

W Priceline opracowaliśmy plan modernizacji wszystkich naszych aplikacji w oparciu o jeden zestaw zasad, który kładzie nacisk na wydajność programistów. Oto jak i dlaczego ten plan został zrealizowany.

Przejście na 12-factor w celu zwiększenia szybkości i innowacyjności

Mimo że firma Priceline istnieje już od ponad 20 lat, pod wieloma względami nadal działa jak startup. Ciągła ewolucja nie jest tutaj luksusem – jest wręcz niezbędna. Zachowania i pragnienia naszych klientów często się zmieniają, a nasza konkurencja nieustannie znajduje nowe sposoby na zaspokojenie tych potrzeb. W związku z tym nasi programiści codziennie wprowadzają innowacje, zarówno w zakresie produktu, danych, SDLC, jak i infrastruktury, jednocześnie zarządzając długiem technicznym, niezawodnością oprogramowania i bezpieczeństwem. Jest to ogromne zadanie.

12-czynnikowa metodologia – której główne założenia koncentrują się wokół formatów deklaratywnych, automatyzacji i przenośności – pozwala naszemu zespołowi utrzymać kulturę innowacji poprzez oddzielenie naszego oprogramowania od wszelkich zależności infrastrukturalnych i zapewnienie, że nie jesteśmy związani z żadną chmurą, centrum danych, oprogramowaniem ani dostawcą usług. Oznacza to, że możemy wprowadzić środowisko arbitrażu infrastrukturalnego, a z czasem przenosić obciążenia do dowolnej chmury prywatnej lub publicznej w zależności od potrzeb”.

Metodologia 12 czynników wymaga również ścisłego zarządzania zależnościami w procesie budowania. Dotyczy to tego, co jest uruchamiane w naszych kontenerach, oraz wpływu zmian na te kontenery.Kontenery – czy to zmiany w systemie operacyjnym, czy w naszym własnym kodzie. Możliwość deklaratywnego sprawdzania i instancjonowania naszego kodu na wczesnym etapie procesu budowania pozwala nam zatwierdzać zmiany na wcześniejszym etapie procesu wysyłania, co prowadzi do większej innowacyjności i zmniejsza koszty związane z rozwiązywaniem problemów we wdrożeniach produkcyjnych.

Rozdzielenie procesów budowania i uruchamiania pozwala nam na przeprowadzanie zautomatyzowanych testów funkcjonalnych i ciągłego wdrażania, co jeszcze bardziej zwiększa szybkość pracy naszych zespołów. Nie tylko zwiększa to produktywność i satysfakcję programistów, ale także pozwala nam szybciej testować i ulepszać funkcje skierowane do klientów, co ostatecznie przekłada się na lepsze wyniki dla naszych podróżnych i naszej firmy.

Podejście skoncentrowane na kliencie

Nasz plan modernizacji umożliwił nam przekształcenie naszych danych i platformy, co przyniosło korzyści klientom i naszej działalności. Dzięki możliwości przesyłania danych w czasie rzeczywistym, możemy szybciej zrozumieć i reagować na działania i zachowania klientów na naszej platformie. Pozwala nam to lepiej spersonalizować nasze rekomendacje dotyczące miejsc, do których podróżni chcą się udać i w których chcą się zatrzymać, a także pomaga nam szybko eksperymentować z nowymi funkcjami i możliwościami.

Wykorzystanie architektury monorepo w procesie projektowania oprogramowania pozwoliło nam zapewnić spójne wrażenia klientów. Na przykład nasze komponenty kasowe mogą być teraz zbudowane raz, a następnie wykorzystywane przez wiele zespołów, zamiast wielu różnych komponentów kasowych, co prowadzi do rozproszonego doświadczenia użytkownika końcowego.

Zespoły mogą dodawać własne funkcje do tych wspólnych komponentów, a nasze zespoły ds. platformy mają pełny wgląd w to, co się dzieje. Dzięki temu, bez względu na to, jakie funkcje zostaną dodane do systemu kasowego, nie będą one miały negatywnego wpływu na naszą platformę oprogramowania ani na wskaźniki wydajności. Nasza architektura monorepo sprawia również, że aktualizacje są bardziej przewidywalne, a zarządzanie zależnościami zostaje przeniesione na proces projektowania i rozwoju, zamiast znajdować problemy w kolejnych wdrożeniach.

Zakłócanie rozwoju oprogramowania

Nasze skupienie się na metodologii 12 czynników, mikroserwisach opartych na kontenerach oraz podejściu monorepo pozwoliło na rozwinięcie architektury oprogramowania, która zasila platformę produktową Priceline. Korzyści, jakie do tej pory zaobserwowaliśmy, są następujące:

  • Programiści mają większą kontrolę nad tym, jak projektują i rozwijają oprogramowanie, ponieważ nie są związani zależnościami lub stosami technologii innego zespołu.
  • Stworzyliśmy mentalność „developer first”, przenosząc w ten sposób większość głównych obowiązków związanych z projektowaniem i rozwojem w ręce faktycznych programistów.
  • Programiści są odpowiedzialni za swoją własną produktywność. Na przykład, mogę zaprojektować i rozwinąć funkcję, która jest całkowicie odizolowana i nie ma zależności od innych elementów mojej infrastruktury.
  • Aplikacje są projektowane z myślą o wykorzystaniu zalet infrastruktury w chmurze, a nie tylko tworzone na miejscu, a następnie przesyłane do chmury.

Dokąd zmierzamy

Niestety, niewiele z dzisiejszych narzędzi ułatwia korzystanie ze strategii takich jak architektura 12-factor lub monorepo, a arena rozwoju oprogramowania nie jest jeszcze na tym etapie, na którym powinna być, aby innowacyjne, natywne praktyki rozwoju w chmurze zaczęły się rozwijać tak, jak powinny.

Obecnie tylko najbardziej zaawansowane organizacje technologiczne dysponują ludźmi i budżetami, które mogą poświęcić temu problemowi. W firmach takich jak Priceline, dysponujących wieloma wykwalifikowanymi inżynierami, możemy tworzyć zespoły DevX lub zespoły ds. platform

Ale nawet to wiąże się z kosztami alternatywnymi, a mianowicie z opracowywaniem nowych funkcji dla klientów. Większość przedsiębiorstw – a już na pewno startupy, małe firmy i starsze firmy przechodzące transformację cyfrową – nie ma tego luksusu.

W przyszłości zobaczymy deklaratywne narzędzia CI/CD nowej generacji, które umożliwią wszystkim firmom korzystanie z tych możliwości w sposób, który nie będzie wymagał zatrudniania zespołów ludzi. W Priceline już rozpoczęliśmy współpracę z innowacyjnymi startupami działającymi w tej dziedzinie. Startupy takie jak Slim.AI i inne przesuwają granice cloud-native i prawdopodobnie zmienią sposób, w jaki tworzymy nowoczesne oprogramowanie na skalę. Partnerstwo z tymi nowymi firmami ma kluczowe znaczenie dla każdej firmy technologicznej w celu wspierania innowacji.

Według cytowanego powyżej badania CNCF z 2021 roku, „złożoność” dołączyła do „zmian kulturowych w zespole programistów” jako główne wyzwanie związane z używaniem i wdrażaniem kontenerów. W Priceline odnieśliśmy sukces w modernizacji nie tylko naszego stosu technologicznego, ale także naszego sposobu myślenia o technologii. Jednak krzywa nadal przesuwa się na zewnątrz, a praca nigdy nie jest skończona. Nasze skupienie się na wydajności programistów będzie nadal odgrywać kluczową rolę w sposobie, w jaki poprawiamy doświadczenia klientów i osiągamy lepsze wyniki dla naszej firmy.

Marty Brodbeck jest dyrektorem ds. technologii w Priceline. Wcześniej zajmował czołowe stanowiska kierownicze w dziedzinie technologii w firmach Shutterstock, Pearson, Diageo i Pfizer, a obecnie doradza kilku firmom rozpoczynającym działalność w branży technologii chmury.

New Tech Forum zapewnia miejsce do badania i omawiania nowych technologii dla przedsiębiorstw w niespotykanym dotąd zakresie i stopniu szczegółowości. Wybór jest subiektywny i opiera się na naszej ocenie technologii, które naszym zdaniem są ważne i najbardziej interesujące dla czytelników InfoWorld. InfoWorld nie przyjmuje do publikacji materiałów marketingowych i zastrzega sobie prawo do redagowania wszystkich dostarczonych treści. Wszelkie zapytania prosimy kierować na adres newtechforum@infoworld.com.

Copyright © 2022 IDG Communications, Inc.


Czytaj dalej: https://www.infoworld.com/article/3648054/building-and-running-microservices-at-scale-a-ctos-view.html#tk.rss_all