In den letzten Jahrzehnten war die Client-Server-Architektur in der Reisetechnik weltweit der IT-Standard. Obwohl diese Methode viele Jahre lang den grundlegenden Bedürfnissen der Branche entsprach, war sie auch für ineffiziente, schwer zu skalierende Systeme verantwortlich, denen es an der Flexibilität mangelte, die in der heutigen schnelllebigen Reiseumgebung erforderlich ist. Während sich die übrige IT, sowohl auf Verbraucher- als auch auf Unternehmensebene, wandelt und weiterentwickelt, steckt die Infrastrukturtechnologie ein Jahrzehnt in der Vergangenheit fest, was es für Unternehmer schwierig macht, die richtige Geschäftsentscheidung zu treffen. Diese traditionelle Form der Architektur wird als “monolithische” Architektur bezeichnet. Zum Glück gibt es einen Ausweg: Die “Microservice”-Hotel-PMS-Architektur. Sie bietet Skalierbarkeit, Nachhaltigkeit und Sicherheit und ist auf dem besten Weg, die Zukunft der IT-Infrastruktur für Reisen zu werden. In diesem Artikel tauchen wir tief in die Microservice-Hotel-PMS-Architektur ein und erfahren, warum sie die Zukunft der Reisetechnologie-Architektur ist. Aber um Microservices zu verstehen, müssen wir wissen, was sie nicht sind: Client-Server-Architektur.
Was ist eine Client-Server-Architektur?
Man schätzt, dass über 90 % der Hotels derzeit über veraltete Anwendungsinfrastrukturen verfügen. Das bedeutet, dass 9 von 10 Immobilien derzeit Systeme verwenden, die in den 80er und 90er Jahren entwickelt und konzipiert wurden und auf dem damaligen Standard basieren: Client-Server-Architektur.
Hotels verwenden weiterhin die Client-Server-Architektur, weil sie immer noch in ihrer ursprünglich vorgesehenen Funktion funktioniert. Außerdem kann die Umstellung auf eine neue Technologie entmutigend sein, und lange Zeit gab es nicht viele Alternativen.
In der Tat ist dies nicht nur ein Problem des Gastgewerbes. Wenn man sich den Technologie-Stack ansieht, der in den letzten vier Jahrzehnten von praktisch jedem Unternehmen verwendet wurde, stößt man häufig auf die gleiche Architektur:
- Ein Server: Ein komplexes, teures physisches Gerät, das eine Datenbank speichert (z. B. Oracle, Microsoft, standortbasiert, gemeinsam genutzte Dateien usw.)
- Mehrere Clients: Benutzer-PCs (in der Regel unter Windows oder früher unter DOS und terminalbasierte Eingaben wie GDS)
- Anwendungen: Auf den Clients physisch installierte Software, die mit der Datenbank des Servers kommuniziert.
Bei der Client-Server-Architektur werden die Daten auf einer zentralen Datenbank (in der Regel eine relationale Datenbank wie SQL) auf einem physischen Server gespeichert, während auf der anderen Seite mehrere Windows/DOS-basierte Anwendungen mit dem Server kommunizieren. Das Hauptproblem bei dieser Architektur ist, dass die Geschäftslogik über beide Orte verteilt ist. In der Datenbank beispielsweise ist nicht nur die Datenspeicherung, sondern auch eine gewisse Codierung üblich. Bis in die späten 90er Jahre waren Server sowohl für die Datenbankspeicherung als auch für die Ausführung einiger Geschäftslogiken zuständig. Dies mag wie ein triviales, semantisches Problem klingen, hat aber zahlreiche negative Auswirkungen.
Wenn beispielsweise ein bestimmter Geschäftsprozess in der Datenbank schneller abläuft als auf dem Client, würden die Entwickler einen Teil der Geschäftslogik direkt in der Datenbank oder in der Benutzeroberfläche platzieren, anstatt wie bisher zwischen Client und Datenbank hin- und herzuwechseln, was zu einem fehleranfälligen Mischmasch führt.
Neue Plattformen, alte Architektur
Jahrelang wurde Software auf der Grundlage von Client-Server-Infrastrukturen geschrieben und entwickelt, aber Anfang der 00er Jahre, mit dem Aufkommen des Internets und den gestiegenen Erwartungen von Kunden und Unternehmen, wurde der Druck immer größer, eine bessere Lösung zu finden. Doch selbst als HTML-Frontend-Webanwendungen alltäglicher wurden, erstellten einige Entwickler ihre Software weiterhin nach denselben veralteten Verfahren und änderten lediglich die Art und Weise, wie die Anwendungen angezeigt wurden, während im Hintergrund dieselbe Client-Server-Architektur beibehalten wurde.
Erst in den späten 00er Jahren, als sowohl die Internetkonnektivität als auch die Zahl der Nutzer zunahm, erkannte die Entwicklungswelt, dass die Anwendungen so groß wurden (in Bezug auf die Datenmenge), dass die Client-Server-Architektur sie nicht mehr bewältigen konnte. Darüber hinaus führte die Verbreitung neuer und unterschiedlicher Browser und Geräte mit unterschiedlichen Spezifikationen dazu, dass die Entwickler feststellen mussten, dass sie nicht nur mit einer, sondern mit einer Vielzahl von Schnittstellen umgehen mussten.
Branchenführer wie Google, Amazon und Netflix haben den Wandel schnell erkannt und begannen, um Stabilität und Skalierbarkeit zu gewährleisten, den gesamten Prozess der Datenverarbeitung, -nutzung und -verwaltung zu analysieren und sicherzustellen, dass ihre Präsentationsschichten und Geschäftslogiken klar voneinander getrennt sind – eine von vielen vorausschauenden Maßnahmen, die diesen Unternehmen zum Erfolg verholfen haben.
Dreistufige vs. Client-Server-Architektur
Die Lösung von Google und anderen Branchenführern war einfach, aber genial. Sie bestand zunächst darin, die Verantwortung der Server auf die reine Datenspeicherung zu reduzieren, dann die Datenverarbeitungskapazität der Server zu erhöhen (um praktisch in Echtzeit Terabytes von Daten zu sammeln und zu analysieren) und schließlich die Verantwortung der Server für die Geschäftslogik zu reduzieren.
Dieses neue Konzept war die Geburtsstunde dessen, was wir heute als dreistufige Architektur kennen, die aus drei unabhängigen Teilen besteht: ein vollständiges Follow-End-Datenspeicher- und -abrufsystem (transparent, schnell und stabil), eine Geschäftslogik (die ihre Funktionalitäten über spezifizierte APIs zur Verfügung stellt) und eine Präsentationsschicht (die Front-End-Benutzeroberfläche).
Microservices unterteilen Funktionalitäten, während monolithische sie zentralisieren. Mit anderen Worten: Microservices gliedern potenzielle Probleme auf, während Monolithen sie zentralisieren.
Der Aufbau und die Pflege von Software als unabhängige Module auf separaten Plattformen war ein revolutionäres, aber notwendiges Konzept, das Lichtjahre von der Standardarchitektur der 80er und 90er Jahre entfernt war. Die Aufteilung aller Funktionen eines Systems in mehrere Pakete mit zusammengesetzter Funktionalität macht die Softwareentwicklung skalierbar und wartbar, im Gegensatz zur Entwicklung aller Funktionen in einer großen, klobigen Plattform.
Diese neue Art, Dinge zu tun, wird als “Microservice-Architektur” bezeichnet, während die alte Art als “monolithische Architektur” bekannt ist.
“Monolithische Anwendungen können erfolgreich sein, aber immer mehr Menschen empfinden sie als frustrierend.”
“Monolithische Anwendungen können erfolgreich sein, aber immer mehr Menschen empfinden sie als frustrierend.”
– Martin Fowler
Das Hauptproblem der monolithischen Architektur ist, dass sie sowohl für Technologieanbieter als auch für Endnutzer praktisch nicht skalierbar ist. Das Hinzufügen einer neuen, einfachen Funktion zu einer bestehenden Anwendung könnte im schlimmsten Fall das gesamte System zum Absturz bringen oder im besten Fall viel Zeit für die Entwicklung in Anspruch nehmen, was zu höheren Kosten für alle Beteiligten führt.
Von der monolithischen zur Microservice-Architektur
Hotelgäste haben bestimmte Erwartungen. Sie möchten vielleicht über eine App von ihrem Telefon aus einchecken oder ihr Abendessen bestellen können. Und Hotels würden diese Dienste gerne anbieten, denn Kundenzufriedenheit ist für die Gastfreundschaft von grundlegender Bedeutung. Häufig sind Hotels jedoch nicht in der Lage, ihre Gäste angemessen zu bedienen, weil ihre veralteten Systeme nicht in der Lage sind, neue Funktionen zu integrieren, da jede zusätzliche Anpassungsebene in der Datenbank oder in der Client-Anwendung hart kodiert werden müsste. Die meiste Hotelsoftware besteht aus einem großen, unübersichtlichen Haufen Code, bei dem jede Zeile so stark von der anderen abhängt, dass es fast unmöglich ist, Neuerungen einzuführen, ohne das gesamte System zu zerstören, weshalb die Branche nicht in der Lage ist, sich an neue Marktanforderungen anzupassen.
Beim Microservices-Ansatz hingegen haben Sie mehrere kleine Programme, die völlig unabhängig voneinander sind, aber durch in den APIs geschriebene Regeln miteinander verbunden sind. Solange die API-Regeln befolgt werden, kann ein auf Mikrodiensten basierendes System auf unbestimmte Zeit gewartet und verbessert werden, ohne dass das Risiko besteht, das gesamte System bei jeder Aktualisierung zu zerstören. In operativer Hinsicht wird das Risiko eines Dominoeffekts durch die Dezentralisierung der Microservice-Architektur eingedämmt: Wenn eine Anwendung ein Update erhält oder ausfällt, wirkt sich das nicht auf die gesamte Struktur aus. Das gesamte Ökosystem wird widerstandsfähiger, und es ist viel einfacher, Fehler einzugrenzen und sich von Systemausfällen zu erholen.
Die Rolle von APIs
Die zunehmende Verbreitung von APIs in der Hotelbranche hat eine entscheidende Rolle bei der Verlagerung von monolithischen zu Microservice-Hotel-PMS-Architekturen gespielt. APIs sind für diesen flexibleren, dezentralisierten Ansatz von zentraler Bedeutung, da sie die Programmierung vereinfachen und die Möglichkeiten der Interkonnektivität erhöhen.
Diese Unabhängigkeit gibt den Entwicklern die Freiheit zu programmieren, ohne dass sie die für das Kernsystem verwendete Programmiersprache vollständig verstehen müssen. Programmierer, die an der Integration einer einzelnen Funktion aus einer Anwendung eines Drittanbieters arbeiten, müssen beispielsweise nicht das gesamte Dateisystem, die Programmierstruktur und die Sprache verstehen, sondern können sich einfach darauf konzentrieren, spezifische Informationen zur Lösung eines bestimmten Problems zu erhalten. Microservices unterteilen Funktionalitäten, während monolithische sie zentralisieren. Mit anderen Worten: Microservices gliedern potenzielle Probleme auf, während Monolithen sie zentralisieren.
Microservice-Hotel-PMS-Architektur und Datensicherung
Kaum ein Tag vergeht ohne Nachrichten über Datenschutzverletzungen. Die Reisebranche war schon immer anfällig für Datenverletzungen, vor allem weil sie (anders als die meisten Branchen) eine enorme Menge an Kundendaten sammeln muss, um ordnungsgemäß zu funktionieren, und der Wert dieser Daten mit der Fähigkeit des Hotels korreliert, den Kunden zu bedienen.
Auf dem Schwarzmarkt werden personenbezogene Daten für etwa 1 Dollar pro Stück verkauft, aber laut Justin Lie, CEO von CashShield, vervielfacht sich ihr Wert mit jeder weiteren zugehörigen Information. Fügt man den ursprünglich gestohlenen Daten eine Handynummer, eine persönliche E-Mail-Adresse und das Geburtsdatum hinzu, steigt ihr Wert auf 125 Dollar.
Es ist nicht schwer zu verstehen, dass Hoteldatenbanken buchstäblich Goldgruben für Hacker sind, da sie ein vollständigeres, genaueres individuelles Profil speichern als z. B. ein Web-Blog oder eine Spiele-App. Hotels sammeln äußerst wertvolle Daten, wie Telefonnummern, Kreditkartendaten und vor allem Pässe. In den Vereinigten Staaten gibt ein gestohlener Reisepass praktisch jedem die Möglichkeit, online eine Sozialversicherungsnummer anzufordern und damit Kreditkarten oder Kredite zu beantragen.
Die Hauptschwierigkeit besteht darin, dass die Kernstruktur der meisten Hotelsoftware Jahrzehnte vor dem Aufkommen des Internets programmiert wurde und daher nicht in der Lage ist, sich gegen Online-Cyberangriffe zu schützen. Der französische Philosoph Paul Virilio sagte einmal: “Wenn man das Schiff erfindet, erfindet man auch den Schiffbruch”. In den 80er Jahren und während eines Großteils der 90er Jahre, als es praktisch noch keine Internetverbindungen gab, wurde das Konzept des Web-Hacking einfach nicht in Betracht gezogen, weshalb so viele Hotelsoftwaresysteme so wehrlos sind, wenn es um Datenlecks geht.
Dank der Microservice-Hotel-PMS-Architektur können Entwickler heute persönliche und nicht-persönliche Daten voneinander trennen und je nach der auszuführenden Aufgabe den einen oder anderen Datensatz in den Mittelpunkt stellen.
Diese Flexibilität, wann immer möglich nur auf nicht-personenbezogene Daten aufzubauen, ist ein unschätzbarer Vorteil für Microservices-Software, insbesondere wenn es um Datenspeicherbeschränkungen bestimmter Länder geht, die verlangen, dass die Informationen ihrer Bürger lokal gespeichert werden. In monolithischen Architekturen sind die Daten oft über das ganze Land verteilt, was bedeutet, dass die personenbezogenen Daten russischer Kunden rechtmäßig in ihrem Land gespeichert werden sollten. Um mit Russland Geschäfte machen zu können, muss das gesamte System umgestellt werden, und der Zugriff auf die Daten kann nur durch Zwischenspeicherung erfolgen, was zu einem schwierigen (und teuren) Kreislauf der Komplexität führt.
Unternehmen wie Amazon und Netflix sind frühe Anwender der Microservices-Architektur, und ihre hohe Skalierbarkeit ist vor allem darauf zurückzuführen, dass ihre Anwendungen als eine Reihe von Microservices entwickelt und bereitgestellt werden und nicht als ein großer Code-Brocken.
Cloud-basierte Systeme: Flexibilität zum Schnäppchenpreis
Der Hauptvorteil der Cloud” hat weniger mit der Möglichkeit zu tun, eine Anwendung über einen Browser auszuführen, als vielmehr mit den Kosteneinsparungen bzw. den Gesamtbetriebskosten (TCO), die oft missverstanden (oder von Technologieunternehmen bewusst verdreht) werden. Die direkten und indirekten Kosten für die Bereitstellung eines Systems in der Cloud sind einfach viel geringer als die Kosten für die Beibehaltung einer Legacy-Plattform.
Erstens müssen die Hotels keine teure Hardware anschaffen (direkte Kosten). Darüber hinaus können die Hotels durch das Outsourcing von den Fachkenntnissen und Ressourcen des Anbieters profitieren, wenn etwas schief geht, und müssen sich nicht nur auf die internen Experten für Support und Wartung verlassen (indirekte Kosten). Anbieter von Cloud-Diensten garantieren oft sogar höhere Betriebszeiten als selbst verwaltete Altsysteme, was das Risiko potenzieller Umsatzeinbußen drastisch verringert. Außerdem wird die Zusammenführung verschiedener Technologien durch Microservices-Architekturen exponentiell einfacher.
Kurz gesagt: Cloud-Lösungen (Hotel-PMS- und POS-Lösungen) ermöglichen Skalierbarkeit, Wachstum und Nachhaltigkeit für Unternehmen jeder Größe, indem sie die Notwendigkeit unerschwinglicher Vorabinvestitionen (Hardware, Einrichtung von Rechenzentren, Installationskosten usw.) minimieren und den Lebenszyklus von Anwendungen verlängern.
Das Wachstum der Microservice-Hotel-PMS-Architektur
Es ist keine Überraschung, dass erfolgreiche Unternehmen wie Netflix, Google und Amazon in den letzten Jahren von monolithischen Architekturen zu Gunsten von Microservices abgerückt sind. Angesichts neuer Datenschutzgesetze, vielfältiger Anforderungen, schnellerer Technologien, disruptiver Zahlungssysteme und sich ständig ausbreitender Vertriebssysteme ist es offensichtlich, dass der monolithische Ansatz nicht mithalten kann.
Darüber hinaus müssen die Entwickler dank des Plug-and-Play-Ansatzes keine Zeit mit der Lösung von Problemen verschwenden, die bereits von jemand anderem gelöst wurden. Die zahlreichen Implikationen der Einführung von Microservice-Hotel-PMS und anderer IT-Architekturen mögen für einige überwältigend klingen, aber letztendlich sollte jedes Unternehmen, unabhängig von seiner Größe, in der Lage sein, jedes auf dem Markt erhältliche Tool zu wählen und es reibungslos mit anderen Tools zu verbinden – so wie sie Anwendungen auf ihrem persönlichen Smartphone installieren. Für Hotels könnte dies etwas so Einfaches bedeuten wie die Änderung eines internen Prozesses der Zimmerreinigung oder der Wartung.
Die Technologie sollte die Verwaltung eines Unternehmens und die Betreuung von Kunden oder Gästen erleichtern. Und wenn es um Hotels geht, sollten die Strategien nie von den Beschränkungen der zugrundeliegenden IT-Infrastruktur bestimmt werden, sondern durch deren Flexibilität verbessert werden. Es ist an der Zeit, dass das Gastgewerbe sich Innovation, Nachhaltigkeit und Skalierbarkeit zu eigen macht. Es ist an der Zeit, dass sich das Gastgewerbe die Microservice-Architektur zu eigen macht.
