Over the last few decades in travel technology, Client-Server architecture has been the IT standard across the world. Even though this method served the industry’s basic needs for many years, it has also been responsible for inefficient, hard-to-scale systems that lack the agility required in today’s fast-paced travel environment. While the rest of tech, both consumer and enterprise-level, is transforming and evolving, infrastructure technology is stuck a decade in the past, making it difficult for entrepreneurs to make the correct business decision. This traditional form of architecture is known as “monolithic” architecture. Thankfully, there is a way forward: “microservice” hotel PMS architecture. It offers scalability, sustainability, and security and is poised to be the future of travel tech infrastructure. In this article, we’ll take a deep dive into microservice hotel PMS architecture and why it is the future of travel tech architecture. But to understand microservices let’s understand, what it is not: Client-Server architecture.

What is Client-Server Architecture?

It is estimated that over 90% of hotels currently have legacy application infrastructures. This means that 9 out of 10 properties are currently using systems that were built and conceived in the 80s and 90s and based on the standard at the time: Client-Server architecture.

Hotels continue to use Client-Server architecture because it still works in its originally intended capacity. Additionally, moving to new technology can be daunting, and for the longest time there weren’t many alternatives.

In fact, this is not only a hospitality problem. When looking at the technology stack used in the last four decades by virtually any company, it is common to bump into the same architecture:

  1. A server: A complex, expensive physical device storing a database (i.e. Oracle, Microsoft, site-based, file-shared, etc.)
  2. Multiple clients: User PCs (usually running on Windows or, before that, DOS and terminal based inputs like GDS)
  3. Applications: Software physically installed on clients, communicating with the server’s database.

In Client-Server architecture, you have, on one side, data storage on a central database (usually a relational one such as SQL) stored on a physical server and, on the other side, multiple UI, Windows/DOS-based applications communicating to the server. The main problem with this architecture is that the business logic is spread over both places. On the database, for example, it is common to find not only data storage, but even some coding. Up until the late ‘90s, servers were responsible for both database storage and for executing some business logic as well. This may sound like a trivial, semantic issue, but it has numerous negative implications.

For example, if a particular business process ran faster on the database than on the client, developers would place some of the business logic directly in the database or in the UI layer, instead of following the conventional procedure of going back and forth between the client and the database, creating a buggy mix and match prone to errors.

New Platforms, Old Architecture

Software has been written and developed for years based on Client-Server infrastructure, but, by the early ‘00s, thanks to the advent of the internet and increased customer and company expectations, pressure began building to find a better solution. Yet even when HTML front-end web applications started to become more commonplace, some developers kept building software via the same obsolete processes, merely changing the way applications were displayed while keeping the very same Client-Server architecture intact behind the scenes.

Only by the late ‘00s, with both internet connectivity and its number of users on the rise, did the development world realize that applications were becoming so big (in terms of amount of data) that the Client-Server architecture could no longer handle them. Moreover, the proliferation of new and different browsers and devices, all with distinct specifications, made developers realize they had to deal with not one, but with a multitude of interfaces.

Industry leaders like Google, Amazon and Netflix quickly understood the shift and, in order to maintain stability and scalability, started dissecting the whole process of how data was processed, used and managed, assuring that their presentation layers and business logics were clearly separated from each other– one of many prescient moves that positioned these businesses for success.

Three-Tier vs Client-Server Architecture

Google and other industry leaders’ solution was simple yet brilliant. It consisted of first, diminishing the responsibility of the servers to focus purely on data storage, next, increasing servers’ data-process capacity (to collect and analyze, virtually in real-time, terabytes of data), and finally, reducing servers’ business logic responsibilities.

This new concept marked the birth of what we now know as three-tier architecture, made of three independent parts: a full follow-end data storage/retrieval system (transparent, fast, and stable), a business logic (exposing its functionalities through specified APIs) and a presentation tier (the front-end user interface).

Building and maintaining software as independent modules on separate platforms was a revolutionary, yet necessary concept, lightyears away from the standard architecture of the ’80s-’90s. Splitting all functionalities of a system into multiple packages with compound functionality makes software development scalable and maintainable, versus having everything developed in one big, chunky platform.

This new way of doing things is known as “microservice architecture” while the old way is known as “monolithic architecture.”

“Monolithic applications can be successful, but increasingly people are feeling frustrations with them.”

The main problem with the monolithic architecture is that it is virtually impossible to scale, both for technology providers and end-users. Adding a new, simple, feature to an existing application could, in the worst scenario, make the whole system crash or, in the best one, take a lot of time in development, resulting in higher costs for all parts involved.

From Monolithic to Microservice Architecture

Hotel guests have certain expectations. They might want to be able to check in from their phones or order dinner via an app. And hotels would love to offer these services, as customer satisfaction is fundamental to hospitality. Yet, more often than not, hotels are unable to properly serve their guests solely because their outdated systems do not have the capability to integrate new features as each extra layer of customization would need to be hard-coded in the database or in the client application. Most hotel software is made of a big, messy chunk of code, where each line is so interdependent upon the other that it becomes nearly impossible to innovate without breaking the whole system down, hence the industry’s inability to adapt to the new market needs.

With the microservices approach, by contrast, you have multiple small programs that are completely independent from each other yet linked together by rules written in the APIs. Therefore, as long as the API’s rules are followed, a microservice-based system could be maintainable and improvable indefinitely without the risk of annihilating the whole system at each update. Operationally speaking, the risk of a bug’s domino effect is contained by the microservice architecture’s own decentralization– if one application gets an update or goes down, it does not affect the whole structure. The whole ecosystem becomes resilient, and it is much easier to isolate errors and recover from system failures.

— Source: Shiji— Source: Shiji
— Source: Shiji

The Role of APIs

The increased adoption rate of APIs in the hotel industry has played a crucial role in the shift from monolithic to microservice hotel PMS architecture. APIs are central to this more flexible, decentralized approach as they simplify the act of programming and increase the possibility of interconnectivity.

This independence grants developers the freedom to code without the need to fully comprehend the programming language used for the core system. Programmers working on integrating a singular feature from a third-party application, for example, do not have to understand the whole file system, programming structure, and language, and they can simply focus on getting specific information to solve a specific problem. Microservices compartmentalize functionalities while monolithic centralize them. In other words, microservices compartmentalize potential problems while monolithics centralize them.

Microservice Hotel PMS Architecture and Data Protection

Hardly a single day goes by without some news about data breaches. The travel industry has always been vulnerable to data violations, mainly because (unlike most industries) in order to properly function, it needs to collect an enormous amount of customer information and the value of that data is correlated to the hotel’s ability to serve them.

On the black market, personally identifiable information is sold at around $1 each, but, according to CashShield CEO Justin Lie, their value “multiplies 5x with each added associated information.” Add a mobile number, a personal email address and birth date to the original stolen data and its value skyrockets to $125.

It’s not difficult to understand that hotel databases are literally goldmines for hackers as they store a fuller, more accurate individual profile than, for example, a web blog or a gaming app. Hotels collect extremely valuable data, such as phone numbers, credit card details, and, most importantly, passports. In the United States, a stolen passport gives the possibility to virtually anyone to ask for a social security number online and, consequently, apply for credit cards or loans.

The main difficulty is that, because the core structure of most hotel software has been coded decades before the rise of the web, they are simply not ready to defend themselves from online cyber-attacks. French philosopher Paul Virilio once said, “When you invent the ship, you also invent the shipwreck.” Back in the ’80s and for a good part of the ’90s, with virtually no internet connection, the concept of web hacking was simply not considered, which is why so many hotel software systems are so defenseless when it comes to data leakage.

Today, thanks to microservice hotel PMS architecture, developers can separate personal from non-personal data, and choose to design around one or the other datasets based on what specific task should be executed.

This flexibility to build whenever possible only around non-personal data gives an invaluable advantage to microservices software, especially when it comes to data storage restrictions of specific countries who ask that their citizens’ information is stored locally. In monolithic architectures, data is often spread all around, meaning that the personal data of Russian customers should be legally stored in their country. In order to do business with Russia, the whole system should be moved, and data can be accessed only by caching, creating a challenging (and expensive) circle of complexity.

Cloud-Based Systems: Flexibility at a Bargain

Often misunderstood (or knowingly twisted by tech companies), the primary benefit of “the cloud” has less to do with being able to run an application from a browser and more with the cost savings, or total cost of ownership (TCO). The direct and indirect costs of deploying a system to the cloud are simply way lower than keeping it on a legacy platform.

First, hotels do not have to acquire any expensive hardware (direct costs). Moreover, by outsourcing, hotels can benefit from the expertise and resources of the provider if and when something goes wrong, rather than having to rely only on in-house experts for support and maintenance (indirect costs). Cloud service providers often even guarantee higher uptimes than self-managed legacy systems, dramatically decreasing the risk of potential revenue loss. Merging different technologies, moreover, becomes exponentially easier with microservices architectures.

In a nutshell, cloud solutions (hotel PMS and POS solutions) make scalability, growth, and sustainability possible for businesses of any size by minimizing the need for prohibitive upfront investments (hardware, data center setup, installation costs, etc.) and extending applications’ life cycle.

The Growth of Microservice Hotel PMS Architecture

It comes as no surprise that, over the last number of years, successful companies such as Netflix, Google, and Amazon have all moved away from monolithic architecture in favor of microservices. Today, with new privacy laws, varied requirements, faster technology, disruptive payments systems, and ever-broadening distribution systems, it is evident that the monolithic approach will not be able to keep up.

On top of that, by using a plug-and-play approach, developers don’t have to waste time solving problems that have already been solved by someone else. The numerous implications of the adoption of microservice hotel pms and other IT architecture may sound overwhelming for some, but eventually, every company, no matter the size, should be able to choose any tool available in the market and frictionlessly connect it to other tools– just like they install applications on their personal smartphone. For hotels, this could mean something as simple as changing an internal process of the room cleaning sequence or maintenance.

Technology should make it easier to manage a business and serve customers or guests. And, when it comes to hotels, strategies should never be determined by the limitations of their underlying IT infrastructure, but enhanced by its flexibility. It is time for the hospitality industry to embrace innovation, sustainability, and scalability. It is time for the hospitality industry to embrace microservice

View source