W ciągu ostatnich kilku dekad w technologii turystycznej architektura klient-serwer była standardem technologii informacyjnej na całym świecie. Mimo że metoda ta służyła podstawowym potrzebom branży przez wiele lat, była również odpowiedzialna za nieefektywne, trudne do skalowania systemy, którym brakuje zwinności wymaganej w dzisiejszym szybko zmieniającym się środowisku podróży. Podczas gdy reszta technologii, zarówno konsumenckich, jak i korporacyjnych, przekształca się i ewoluuje, technologia infrastrukturalna utknęła dekadę temu, co utrudnia przedsiębiorcom podjęcie właściwej decyzji biznesowej. Ta tradycyjna forma architektury znana jest jako architektura “monolityczna”. Na szczęście jest na to sposób: “mikrousługowa” architektura hotelowego systemu PMS. Technologia informacyjna oferuje skalowalność, zrównoważony rozwój i bezpieczeństwo i ma szansę stać się przyszłością infrastruktury technologicznej dla podróżujących. W tym artykule przyjrzymy się bliżej architekturze PMS dla hoteli opartej na mikrousługach i dowiemy się, dlaczego jest ona przyszłością architektury technologii dla branży turystycznej. Ale aby zrozumieć mikrousługi, zrozummy, czym one nie są: Architektura klient-serwer.
Czym jest architektura klient-serwer?
Szacuje się, że ponad 90% hoteli posiada obecnie starszą infrastrukturę aplikacyjną. Oznacza to, że 9 na 10 nieruchomości korzysta obecnie z systemów zbudowanych i zaprojektowanych w latach 80. i 90. i opartych na ówczesnych standardach: architekturze klient-serwer.
Hotele nadal korzystają z architektury klient-serwer, ponieważ wciąż sprawdza się ona w swoim pierwotnym przeznaczeniu. Ponadto przejście na nową technologię może być zniechęcające, a przez długi czas nie było wielu alternatyw.
W rzeczywistości nie jest to tylko problem hotelarstwa. Patrząc na stos technologiczny używany w ciągu ostatnich czterech dekad przez praktycznie każdą firmę, często można natknąć się na tę samą architekturę:
- Serwer: Złożone, kosztowne urządzenie fizyczne przechowujące bazę danych (tj. Oracle, Microsoft, oparte na lokalizacji, współdzielone pliki itp.)
- Wielu klientów: Komputery użytkowników (zwykle działające w systemie Windows lub, wcześniej, DOS i wejścia oparte na terminalach, takie jak GDS)
- Aplikacje: Oprogramowanie fizycznie zainstalowane na klientach, komunikujące się z bazą danych serwera.
W architekturze klient-serwer z jednej strony dane przechowywane są w centralnej bazie danych (zwykle relacyjnej, takiej jak SQL) przechowywanej na fizycznym serwerze, a z drugiej strony wiele aplikacji opartych na systemie Windows/DOS komunikuje się z serwerem. Głównym problemem tej architektury jest to, że logika biznesowa jest rozproszona w obu miejscach. Na przykład w bazie danych często znajduje się nie tylko przechowywanie danych, ale nawet pewne kodowanie. Aż do późnych lat 90. serwery były odpowiedzialne zarówno za przechowywanie baz danych, jak i za wykonywanie logiki biznesowej. Może się to wydawać trywialną, semantyczną kwestią, ale ma to wiele negatywnych konsekwencji.
Na przykład, jeśli określony proces biznesowy działał szybciej w bazie danych niż na kliencie, programiści umieszczali część logiki biznesowej bezpośrednio w bazie danych lub w warstwie interfejsu użytkownika, zamiast postępować zgodnie z konwencjonalną procedurą przechodzenia tam i z powrotem między klientem a bazą danych, tworząc podatną na błędy mieszankę.
Nowe platformy, stara architektura
Oprogramowanie było pisane i rozwijane przez lata w oparciu o infrastrukturę klient-serwer, ale na początku lat 00-tych, dzięki pojawieniu się Internetu i rosnącym oczekiwaniom klientów i firm, zaczęto wywierać presję na znalezienie lepszego rozwiązania. Jednak nawet gdy front-endowe aplikacje internetowe HTML zaczęły stawać się coraz bardziej powszechne, niektórzy programiści nadal tworzyli oprogramowanie za pomocą tych samych przestarzałych procesów, zmieniając jedynie sposób wyświetlania aplikacji, zachowując za kulisami tę samą architekturę klient-serwer.
Dopiero pod koniec lat 00-tych, wraz ze wzrostem zarówno łączności internetowej, jak i liczby użytkowników, świat programistów zdał sobie sprawę, że aplikacje stają się tak duże (pod względem ilości danych), że architektura klient-serwer nie może już ich obsługiwać. Co więcej, rozprzestrzenianie się nowych i różnych przeglądarek i urządzeń, z których wszystkie mają różne specyfikacje, sprawiło, że programiści zdali sobie sprawę, że muszą radzić sobie nie z jednym, ale z wieloma interfejsami.
Liderzy branży, tacy jak Google, Amazon i Netflix, szybko zrozumieli tę zmianę i, aby utrzymać stabilność i skalowalność, zaczęli analizować cały proces przetwarzania, wykorzystywania i zarządzania danymi, zapewniając, że ich warstwy prezentacji i logika biznesowa są od siebie wyraźnie oddzielone – jeden z wielu proroczych ruchów, które zapewniły tym firmom sukces.
Architektura trójwarstwowa a architektura klient-serwer
Rozwiązanie Google i innych liderów branży było proste, ale genialne. Polegała ona najpierw na zmniejszeniu odpowiedzialności serwerów, aby skupić się wyłącznie na przechowywaniu danych, następnie na zwiększeniu zdolności serwerów do przetwarzania danych (do gromadzenia i analizowania, praktycznie w czasie rzeczywistym, terabajtów danych), a na koniec na zmniejszeniu odpowiedzialności serwerów za logikę biznesową.
Ta nowa koncepcja oznaczała narodziny tego, co obecnie znamy jako architekturę trójwarstwową, składającą się z trzech niezależnych części: pełnego systemu przechowywania/odzyskiwania danych (przejrzystego, szybkiego i stabilnego), logiki biznesowej (udostępniającej swoje funkcje za pośrednictwem określonych interfejsów API) oraz warstwy prezentacji (front-endowy interfejs użytkownika).
Mikroserwisy dzielą funkcjonalności, podczas gdy monolityczne centralizują je. Innymi słowy, mikrousługi dzielą potencjalne problemy, podczas gdy monolity centralizują je.
Budowanie i utrzymywanie oprogramowania jako niezależnych modułów na oddzielnych platformach było rewolucyjną, ale niezbędną koncepcją, odległą o lata świetlne od standardowej architektury lat 80-tych i 90-tych. Podzielenie wszystkich funkcji systemu na wiele pakietów o złożonej funkcjonalności sprawia, że tworzenie oprogramowania jest skalowalne i łatwe w utrzymaniu, w przeciwieństwie do tworzenia wszystkiego na jednej dużej, masywnej platformie.
Ten nowy sposób działania znany jest jako “architektura mikrousług”, podczas gdy stary sposób znany jest jako “architektura monolityczna”.
“Aplikacje monolityczne mogą być skuteczne, ale coraz częściej ludzie odczuwają z nimi frustrację”.
“Aplikacje monolityczne mogą być skuteczne, ale coraz częściej ludzie odczuwają z nimi frustrację”.
– Martin Fowler
Głównym problemem architektury monolitycznej jest to, że jest ona praktycznie niemożliwa do skalowania, zarówno dla dostawców technologii, jak i użytkowników końcowych. Dodanie nowej, prostej funkcji do istniejącej aplikacji może, w najgorszym scenariuszu, spowodować awarię całego systemu lub, w najlepszym przypadku, zająć dużo czasu na rozwój, powodując wyższe koszty dla wszystkich zaangażowanych stron.
Od architektury monolitycznej do architektury mikrousługowej
Goście hotelowi mają pewne oczekiwania. Mogą chcieć mieć możliwość zameldowania się z telefonu lub zamówienia obiadu za pośrednictwem aplikacji. Hotele chciałyby oferować takie usługi, ponieważ zadowolenie klienta jest podstawą gościnności. Jednak najczęściej hotele nie są w stanie właściwie obsługiwać swoich Gości tylko dlatego, że ich przestarzałe systemy nie mają możliwości integracji nowych funkcji, ponieważ każda dodatkowa warstwa dostosowywania musiałaby być zakodowana na stałe w bazie danych lub w aplikacji klienckiej. Większość oprogramowania hotelowego składa się z dużego, niechlujnego fragmentu kodu, w którym każda linia jest tak zależna od drugiej, że prawie niemożliwe jest wprowadzanie innowacji bez zepsucia całego systemu, stąd niezdolność branży do dostosowania się do nowych potrzeb rynku.
Z kolei w przypadku podejścia opartego na mikrousługach mamy do czynienia z wieloma małymi programami, które są od siebie całkowicie niezależne, ale połączone ze sobą za pomocą reguł zapisanych w interfejsach API. Dlatego tak długo, jak przestrzegane są zasady API, system oparty na mikrousługach może być utrzymywany i ulepszany w nieskończoność bez ryzyka unicestwienia całego systemu przy każdej aktualizacji. Z operacyjnego punktu widzenia ryzyko efektu domina błędu jest ograniczone przez decentralizację architektury mikrousług – jeśli jedna aplikacja otrzyma aktualizację lub ulegnie awarii, nie wpłynie to na całą strukturę. Cały ekosystem staje się odporny, a izolowanie błędów i odzyskiwanie sprawności po awariach systemu jest znacznie łatwiejsze.
Rola interfejsów API
Wzrost popularności interfejsów API w branży hotelarskiej odegrał kluczową rolę w przejściu od monolitycznej do mikrousługowej architektury hotelowego systemu PMS. Interfejsy API mają kluczowe znaczenie dla tego bardziej elastycznego, zdecentralizowanego podejścia, ponieważ upraszczają programowanie i zwiększają możliwości wzajemnych połączeń.
Ta niezależność zapewnia programistom swobodę kodowania bez konieczności pełnego zrozumienia języka programowania używanego w podstawowym systemie. Na przykład programiści pracujący nad integracją pojedynczej funkcji z aplikacji innej firmy nie muszą rozumieć całego systemu plików, struktury programowania i języka, i mogą po prostu skupić się na uzyskaniu konkretnych informacji w celu rozwiązania konkretnego problemu. Mikroserwisy dzielą funkcjonalności, podczas gdy monolityczne centralizują je. Innymi słowy, mikrousługi dzielą potencjalne problemy, podczas gdy monolity centralizują je.
Architektura mikrousług hotelowych PMS i ochrona danych
Nie ma dnia, by nie pojawiały się informacje o naruszeniach danych. Branża turystyczna zawsze była podatna na naruszenia danych, głównie dlatego, że (w przeciwieństwie do większości branż), aby prawidłowo funkcjonować, musi gromadzić ogromną ilość informacji o klientach, a wartość tych danych jest skorelowana ze zdolnością hotelu do ich obsługi.
Na czarnym rynku dane osobowe są sprzedawane za około 1 dolara za sztukę, ale według Justina Lie, dyrektora generalnego CashShield, ich wartość “mnoży się pięciokrotnie z każdą dodaną powiązaną informacją”. Po dodaniu do skradzionych danych numeru telefonu komórkowego, osobistego adresu e-mail i daty urodzenia, ich wartość wzrasta do 125 dolarów.
Nietrudno zrozumieć, że hotelowe bazy danych są dosłownie kopalnią złota dla hakerów, ponieważ przechowują pełniejszy, dokładniejszy indywidualny profil niż na przykład blog internetowy lub aplikacja do gier. Hotele gromadzą niezwykle cenne dane, takie jak numery telefonów, dane kart kredytowych i, co najważniejsze, paszporty. W Stanach Zjednoczonych skradziony paszport daje praktycznie każdemu możliwość poproszenia o numer ubezpieczenia społecznego online, a co za tym idzie, ubiegania się o karty kredytowe lub pożyczki.
Główna trudność polega na tym, że ponieważ podstawowa struktura większości oprogramowania hotelowego została zakodowana dekady przed powstaniem sieci, nie są one po prostu gotowe do obrony przed cyberatakami online. Francuski filozof Paul Virilio powiedział kiedyś: “Kiedy wymyślasz statek, wymyślasz także katastrofę”. W latach 80-tych i przez znaczną część lat 90-tych, praktycznie bez połączenia z Internetem, koncepcja hakowania sieciowego po prostu nie była brana pod uwagę, dlatego tak wiele systemów oprogramowania hotelowego jest tak bezbronnych, jeśli chodzi o wyciek danych.
Obecnie, dzięki architekturze mikrousług hotelowych PMS, programiści mogą oddzielić dane osobowe od nieosobowych i zdecydować się na projektowanie w oparciu o jeden lub drugi zestaw danych w zależności od tego, jakie konkretne zadanie należy wykonać.
Ta elastyczność budowania, gdy tylko jest to możliwe, tylko wokół danych nieosobowych daje nieocenioną przewagę oprogramowaniu mikrousługowemu, zwłaszcza jeśli chodzi o ograniczenia dotyczące przechowywania danych w określonych krajach, które wymagają, aby informacje o ich obywatelach były przechowywane lokalnie. W architekturach monolitycznych dane są często rozproszone, co oznacza, że dane osobowe rosyjskich klientów powinny być legalnie przechowywane w ich kraju. Aby prowadzić interesy z Rosją, należy przenieść cały system, a dostęp do danych można uzyskać tylko poprzez buforowanie, tworząc trudny (i kosztowny) krąg złożoności.
Firmy takie jak Amazon i Netflix są wczesnymi użytkownikami architektury mikrousług, a ich wysoka skalowalność wynika głównie z faktu, że ich aplikacje są opracowywane i wdrażane jako zestaw mikrousług, a nie duży fragment kodu.
Systemy oparte na chmurze: Elastyczność w korzystnej cenie
Często źle rozumiana (lub świadomie przekręcana przez firmy technologiczne), główna zaleta “Chmury” ma mniej wspólnego z możliwością uruchamiania aplikacji z poziomu przeglądarki, a bardziej z oszczędnością kosztów lub całkowitym kosztem posiadania (TCO). Bezpośrednie i pośrednie koszty wdrożenia systemu w chmurze są po prostu znacznie niższe niż utrzymanie go na starszej platformie.
Po pierwsze, hotele nie muszą kupować drogiego sprzętu (koszty bezpośrednie). Co więcej, dzięki outsourcingowi hotele mogą korzystać z wiedzy i zasobów dostawcy, jeśli i kiedy coś pójdzie nie tak, zamiast polegać wyłącznie na wewnętrznych ekspertach w zakresie wsparcia i konserwacji (koszty pośrednie). Dostawcy usług w chmurze często gwarantują nawet dłuższy czas sprawności niż samodzielnie zarządzane starsze systemy, co znacznie zmniejsza ryzyko potencjalnej utraty przychodów. Co więcej, łączenie różnych technologii staje się wykładniczo łatwiejsze dzięki architekturom mikrousług.
Krótko mówiąc, rozwiązania w chmurze (hotelowe rozwiązania PMS i POS) umożliwiają skalowalność, rozwój i zrównoważony rozwój firmom dowolnej wielkości, minimalizując potrzebę zaporowych inwestycji początkowych (sprzęt, konfiguracja centrum danych, koszty instalacji itp.) i wydłużając cykl życia aplikacji.
Rozwój architektury mikrousług hotelowych PMS
Nie jest zaskoczeniem, że w ciągu ostatnich kilku lat odnoszące sukcesy firmy, takie jak Netflix, Google i Amazon, odeszły od architektury monolitycznej na rzecz mikrousług. Obecnie, w obliczu nowych przepisów dotyczących prywatności, zróżnicowanych wymagań, szybszej technologii, przełomowych systemów płatności i coraz szerszych systemów dystrybucji, oczywiste jest, że monolityczne podejście nie będzie w stanie nadążyć.
Co więcej, stosując podejście plug-and-play, deweloperzy nie muszą tracić czasu na rozwiązywanie problemów, które zostały już rozwiązane przez kogoś innego. Liczne implikacje związane z przyjęciem mikrousług hotelowych pms i innej architektury technologii informacyjnej mogą wydawać się przytłaczające dla niektórych, ale ostatecznie każda firma, bez względu na wielkość, powinna mieć możliwość wyboru dowolnego narzędzia dostępnego na rynku i płynnego połączenia go z innymi narzędziami – tak jak instalują aplikacje na swoim osobistym smartfonie. W przypadku hoteli może to oznaczać coś tak prostego, jak zmiana wewnętrznego procesu sekwencji sprzątania pokoju lub konserwacji.
Technologia powinna ułatwiać zarządzanie firmą i obsługę klientów lub gości. A jeśli chodzi o hotele, strategie nigdy nie powinny być determinowane przez ograniczenia ich podstawowej infrastruktury technologii informacyjnej, ale wzmacniane przez jej elastyczność. Nadszedł czas, aby przemysł hotelarski przyjął innowacje, zrównoważony rozwój i skalowalność. Nadszedł czas, aby przemysł hotelarski przyjął architekturę mikrousług.
