Why Microservice Hotel PMS Architecture is the Future

Client-server architecture has long powered hospitality IT but limits scalability and agility. Microservice-based PMS offers a solution enabling rapid innovation and flexibility, essential for today’s evolving hotel tech needs. In this article, you will explore the microservice hotel PMS architecture world and why it is the future of hotel tech architecture. 

From Traditional PMS Architecture to Leading-Edge Microservice Architecture

Over the last few decades in hospitality 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 hospitality environment. Tech giants like Google, Amazon, and Netflix have paved the way toward modern, scalable systems by adopting a microservice-based architecture, allowing them to innovate rapidly while ensuring stability and scalability.

The hotel industry, by contrast, has largely relied on traditional, client-server architecture to power their Property Management Systems (PMS). This traditional form of architecture is known as “monolithic” architecture. Thankfully, there is a way forward: “microservice” hotel PMS 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 Client-Server architecture, you have, on one side, data storage on a central database 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 executing some business logic, and this had numerous negative implications.

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.

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’s and other industry leaders’ solutions were 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:

1. A full follow-end data storage/retrieval system (transparent, fast, and stable)
2. A business logic (exposing its functionalities through specified APIs)
3. 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.” 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 case, 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. However, some hotel tech companies, like, Shiji Group, are pioneering microservice-based platforms that enable seamless integration and flexibility.

With the microservices approach, by contrast, you have multiple small programs that are completely independent of 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.

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 hospitality 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.

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 that ask that their citizens’ information be 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.

The Growth of Microservice Hotel PMS Architecture

It comes as no surprise that, over the last few 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.

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.

Technology should make it easier to manage a hotel business and serve guests. Strategies should never be determined by the limitations of their underlying IT infrastructure but enhanced by their flexibility. It is time for the hospitality industry to embrace innovation, sustainability, and scalability. It is time for the hospitality industry to embrace microservice architecture! 

Free Guide: Choosing the Right Hotel PMS System through the RFP Process