Microservice Tech ist die Zukunft für Hotels, Teil 1

In den letzten Jahrzehnten war die Client-Server-Architektur in der Reisetechnologie weltweit der IT-Standard.

Obwohl diese Methode viele Jahre lang die Grundbedürfnisse der Branche erfüllte, war sie auch für ineffiziente, schwer skalierbare Systeme verantwortlich, denen die Agilität fehlt, die in der heutigen schnelllebigen Reiseumgebung erforderlich ist.

Während sich der Rest der Technologie, sowohl auf Verbraucher- als auch auf Unternehmensebene, verändert und weiterentwickelt, steckt die Infrastrukturtechnologie ein Jahrzehnt in der Vergangenheit fest, was es Unternehmern erschwert, die richtige Geschäftsentscheidung zu treffen. Diese traditionelle Form der Architektur wird als „monolithische“ Architektur bezeichnet.

Glücklicherweise gibt es einen Weg nach vorne: „Microservice“-Hotel-PMS-Architektur. Es bietet Skalierbarkeit, Nachhaltigkeit und Sicherheit und ist bereit, die Zukunft der Travel-Tech-Infrastruktur zu sein.

Aber erstmal zum Verstehen Mikrodienste, Lassen Sie uns verstehen, was es nicht ist: Client-Server-Architektur.

Was ist eine Client-Server-Architektur?

Es wird geschätzt, dass über 90 % der Hotels derzeit über Legacy-Anwendungsinfrastrukturen verfügen. Damit nutzen derzeit neun von zehn Häusern Systeme, die in den 80er und 90er Jahren gebaut und konzipiert wurden und auf dem damaligen Standard basieren: Client-Server-Architektur.

Hotels verwenden weiterhin die Client-Server-Architektur, da sie immer noch in ihrer ursprünglich vorgesehenen Funktion funktioniert. Außerdem kann der Umstieg auf neue Technologien entmutigend sein, und lange Zeit gab es nicht viele Alternativen.

Tatsächlich ist dies nicht nur ein Gastfreundschaftsproblem. Wenn man sich den Technologie-Stack ansieht, der in den letzten vier Jahrzehnten von praktisch jedem Unternehmen verwendet wurde, ist es üblich, auf dieselbe Architektur zu stoßen:

  • Ein Server: ein komplexes, teures physisches Gerät, auf dem eine Datenbank gespeichert ist (z. B. Oracle, Microsoft, standortbasiert, gemeinsam genutzte Dateien usw.)
  • Mehrere Clients: Benutzer-PCs (normalerweise unter Windows oder davor DOS und Terminal-basierte Eingaben wie GDS)
  • Anwendungen: physisch auf Clients installierte Software, die mit der Datenbank des Servers kommuniziert

In der Client-Server-Architektur haben Sie auf der einen Seite Datenspeicherung in einer zentralen Datenbank (normalerweise eine relationale Datenbank wie SQL), die auf einem physischen Server gespeichert ist, und auf der anderen Seite mehrere UI, Windows/DOS-basierte kommunizierende Anwendungen zum Server.

Das Hauptproblem bei dieser Architektur besteht darin, dass die Geschäftslogik auf beide Orte verteilt ist. In der Datenbank findet man beispielsweise häufig nicht nur Datenspeicherung, sondern sogar Codierung.

Bis Ende der 90er Jahre waren Server sowohl für die Datenbankspeicherung als auch für die Ausführung einiger Geschäftslogiken verantwortlich. Dies mag wie ein triviales, semantisches Problem klingen, hat aber zahlreiche negative Implikationen.

Wenn beispielsweise ein bestimmter Geschäftsprozess auf der Datenbank schneller lief als auf dem Client, platzierten Entwickler einen Teil der Geschäftslogik direkt in der Datenbank oder in der UI-Schicht, anstatt dem herkömmlichen Verfahren zu folgen, zwischen den Clients hin und her zu wechseln und die Datenbank, wodurch ein fehlerhaftes Mix-and-Match entsteht, das fehleranfällig ist.

Neue Plattformen, alte Architektur

Software wurde jahrelang auf der Grundlage einer Client-Server-Infrastruktur geschrieben und entwickelt, aber Anfang der 2000er Jahre begann dank des Aufkommens des Internets und der gestiegenen Kunden- und Unternehmenserwartungen der Druck, eine bessere Lösung zu finden.

Doch selbst als HTML-Front-End-Webanwendungen immer üblicher wurden, bauten einige Entwickler weiterhin Software über dieselben veralteten Prozesse und änderten lediglich die Art und Weise, wie Anwendungen angezeigt wurden, während sie hinter den Kulissen dieselbe Client-Server-Architektur intakt hielten.

Erst in den späten 2000er Jahren, als sowohl die Internetkonnektivität als auch die Zahl der Benutzer zunahmen, erkannte die Entwicklungswelt, dass Anwendungen (in Bezug auf die Datenmenge) so groß wurden, dass der Client-Server sie nicht mehr bewältigen konnte .

Darüber hinaus führte die Verbreitung neuer und unterschiedlicher Browser und Geräte, alle mit unterschiedlichen Spezifikationen, dazu, dass Entwickler erkannten, dass sie sich nicht mit einer, sondern mit einer Vielzahl von Schnittstellen auseinandersetzen mussten.

Branchenführer wie Google, Amazon und Netflix haben den Wandel schnell verstanden und zur Aufrechterhaltung von Stabilität und Skalierbarkeit begonnen, den gesamten Prozess der Verarbeitung, Nutzung und Verwaltung von Daten zu analysieren und sicherzustellen, dass ihre Präsentationsebenen und Geschäftslogiken klar voneinander getrennt sind andere – einer von vielen vorausschauenden Schritten, die diese Unternehmen für den Erfolg positioniert haben.

Dreistufig vs. Client-Server-Architektur

Die Lösung von Google und anderen Branchenführern war einfach, aber brillant. Es bestand darin, erstens die Verantwortung der Server zu verringern, sich ausschließlich auf die Datenspeicherung zu konzentrieren; als nächstes die Erhöhung der Datenverarbeitungskapazität der Server (um praktisch in Echtzeit Terabytes an Daten zu sammeln und zu analysieren); und schließlich die Reduzierung der Verantwortlichkeiten für die Geschäftslogik der Server.

Das Hauptproblem bei der monolithischen Architektur besteht darin, dass sie praktisch nicht skalierbar ist.

Anthony Jagd

Dieses neue Konzept war die Geburtsstunde dessen, was wir heute als dreischichtige Architektur kennen, die aus drei unabhängigen Teilen besteht: einem vollständigen Follow-End-Datenspeicher-/-abrufsystem (transparent, schnell und stabil), einer Geschäftslogik (die ihre Funktionalitäten durch spezifizierte APIs) und eine Präsentationsebene (die Front-End-Benutzeroberfläche).

Das Erstellen und Warten von Software als unabhängige Module auf separaten Plattformen war ein revolutionäres, aber notwendiges Konzept, Lichtjahre entfernt von der Standardarchitektur der 80er und 90er Jahre.

Die Aufteilung aller Funktionalitäten eines Systems in mehrere Pakete mit zusammengesetzter Funktionalität macht die Softwareentwicklung skalierbar und wartbar, anstatt alles auf einer großen, klobigen Plattform entwickeln zu müssen.

Diese neue Vorgehensweise wird als „Microservice-Architektur“ bezeichnet, während die alte Vorgehensweise als „monolithische Architektur“ bekannt ist.

Das Hauptproblem bei der monolithischen Architektur besteht darin, dass sie sowohl für Technologieanbieter als auch für Endbenutzer praktisch nicht skalierbar ist.

Das Hinzufügen einer neuen, einfachen Funktion zu einer bestehenden Anwendung kann im schlimmsten Fall zum Absturz des gesamten Systems führen oder im besten Fall viel Zeit in der Entwicklung in Anspruch nehmen, was zu höheren Kosten für alle beteiligten Teile führt.

* Dieser Artikel erschien ursprünglich im Insights-Blog der Shiji Group. Teil 2 wird am Montag, den 18. Oktober veröffentlicht.

Über den Autor…

Anthony Hunt ist Vizepräsident für Produkt und Strategie des globalen Geschäftsteams von Shiji.

Leave a Comment