What aspects to consider when designing a scalable hotel technology stack and moving to the cloud?

It seems abundantly clear that hotels have and depend on many different systems – the Property Management System (PMS) is just one part of it. An average hotel can have 10, 20, or even 30+ integrated systems that need to share data in one form or another. 

From a software developers’ point of view, this leads us to consider questions like:

  • Where does the data reside?
  • Which is the system of records?
  • Where are the security risks?
  • Where are the places that I have to worry about redundant data?
  • Where do I have dependencies that may cause me to have excessive risk or cost of maintenance – or even an inability to innovate?

New trends in technology, such as Customer Data Platforms (CDP), want to support hotels in generating more first-party data by seeing (and storing) the data moving between your systems. This is an intriguing concept as it has the potential to give hoteliers the ability to play at par with the tech giants while reducing dependency on third party data sources.

However, it comes with security, scalability and legal risks.  While some of the legal risks can be offloaded to the vendors, the hoteliers are usually still named the data controller, so they still have the most skin in the game. It’s like the joke about the chicken and the pig at breakfast featuring an omelet with ham – the chicken is involved, but the pig is committed.

Here is a list of questions to ask and consider about the scalability of your hotel technology stack, especially when moving to cloud-based systems that are vendor-managed:

Is it a true cloud application or just legacy tech that was moved to the cloud?

You can never be 100% sure without asking the application vendor, but there are still some signs that you  should look for:

  • How old is the application? If its first launch is before 2005, there is a very high chance that it started as an on-premise solution that was moved to the cloud.
  • Does it have open Application Programming Interfaces (APIs) that one can use to perform all of the operations on the applications (rather than just some specialized APIs)? If so, there is a higher chance that the application is cloud-native.
  • If interacting with the application uses anything other than a modern browser - i.e. a Virtual Private Network (VPN), Remote desktop, etc., it is almost 100% a legacy system that was lifted-and-shifted to the cloud.
  • If it makes a lot of use of serverless computing, it is a clear sign this application was born on the cloud.

API-first and micro-services architecture are popular marketing terms. But practically, what does each mean, why should you care, and when is it important to you?

API-first is a term meaning that all of the application's functionality is accessible programmatically, i.e., any operation that a human operator can do is available to other systems to use. The term evolved as a counter to legacy products, where the user interface is wired directly to the back-end and data stores with no public API exposed. In the past, this led to human operators manually copying data between systems (e.g. between booking and Customer Relationship Management (CRM) systems, or between price recommendation systems and actual hotel prices). When choosing an API-first solution, you can be confident that you can seamlessly automate processes and integrate with other systems.

Microservices architectures aim to decompose large and complex systems into smaller, self-contained services. Microservices were born out of the scalability and maintainability problems of large, monolithic systems, and they address exactly that. An application  built with microservices is easier to maintain, evolve, and, most importantly - scale up/down individual functions of the application. So, for example, if you have a monolithic application, and suddenly you need to handle a 10x scale-up in availability queries, you have no choice but to scale up to 10x the entire application. With microservices, it is possible to scale up just the specific service(s) related to availability queries.

So my vendor says that the cloud application is secure.  According to normal standards of cloud computing (not to mention legal opinions), this means the data is “encrypted at transit and at rest.”  Here is what that really means, why it is important and how to ask your vendor if their product truly complies:

The security of an application is the combination of the security of the environment it runs on and the application’s security. So for a legacy, on-premise application, the hotel itself is responsible for the environment’s security. Think of this environment as the physical security of computers and network equipment and the possibility to copy hard drives or sniff network traffic. With a cloud application this environment is the  cloud itself, and it is the cloud vendor’s responsibility to ensure that the environment is secure. The application security itself is the same in both cases, but the cloud security, backed by top DevOps professionals, is times better than any individual hotel or chain can afford.

Topics such as data encryption are still within the domain of the application. Your best bet is to ask the vendor and trust them since there is no easy way without a full review of the application code to make sure encryption is applied when necessary. Still, since the cloud vendors make it extremely easy to implement proper encryption, there is a general tendency for  cloud applications to implement security more consistently.

So one of my products is legacy, and they want to replicate key guest personally identifiable data from the system of record to an external system. What question can I ask them to confirm if it will be straightforward for me to handle ‘right to be forgotten’ requests from guests, or if my hotel company will have a lurking liability?

This is very straightforward - ask for self-serve tools for all your compliance needs, including the “right to be forgotten.” By self-serve, I mean that you, the hotelier, can use the application’s User Interface (UI) to complete the request rather than sending a ticket to the vendor and waiting for a response. A self-serve function is an indication the process is implemented correctly. At the same time, a ticketing/request system usually means some manual operations need to be performed, which takes away control from you and is error-prone.

My understanding is that a true cloud scales up and down (both with processing power and response time) as needed without manual intervention. As a concerned hotelier, this can be very important when considering parts of the tech stack, such as distribution, which can see sharp demand spikes.  How can I confirm that my vendor’s system can really do this?

Most cloud vendors have tools that make it easier  to scale up and down automatically, but it is up to the application vendor to properly use them. Just because an application is hosted on a public cloud is no indication of whether it can effectively and reliably scale up or down.

What you should do in this case is ask the vendor for a Service Level Agreement (SLA) and insist on including that in the contract. SLAs typically cover response times, requests per second that the system can process, and maximum downtime. If the system does not scale property, they will definitely break their SLAs during high season, which will indicate that they do not handle high loads well.

When a vendor tells me their cloud application uses ‘serverless computing’, what does that really mean, and are there any risks to my hotel business?

Serverless computing is basically renting compute resources on a very fine-grained level. Instead of renting a virtual machine (which can be thought of as a ‘whole server’ with a processor, memory, disk, and network) for a fixed monthly cost, serverless allows you to “pay as you go” and pay only for the compute resources you use. In hospitality, where there are almost always seasonal trends, if you are not using serverless, you are either over-provisioned on virtual machines during low seasons, or your systems lag and underperform in the high seasons. It is a great cost-saver and enables great scalability, therefore widely used in hospitality tech stacks.

Serverless itself does not change the risk for the hotel. It is an internal tool for the vendor that does not impact security.

About the Author

Konstantin Vassilev, Vice President of Technology Development at Sciant

Konstantin Vassilev, VP Technology Development at Sciant

Konstantin’s background focuses on architecting highly scalable cloud-based solutions. As an architect who has worked on petabyte-scale, cloud-based Online Travel Agencies (OTAs), designed highly scalable microservices, consulted on complex ‘build or buy’ decisions for hospitality platforms valued at more than $1 Billion, and designed ground-breaking service layers that bridge legacy hospitality systems with modern microservices architectures, he believes that his value add to this discussion is to help identify aspects of modern technology that need to exist in critical parts of a modern hoteliers tech stack.

Konstantin often advises customers on what is called a “north star” architecture – in simple terms, this is a target architecture that is achieved over time. While today, especially due to fiscal constraints, we may not be able to migrate to/ implement only the latest, most scalable, secure, redundant architect, we want to point ourselves in that direction and use the target to guide our decision-making process along the way to avoid facing integration or scalability problems in the future. This is what we call our “north star.”

Connect with Konstantin on Linkedin.

Sciant is a Contributing Member of techtalk.travel.

Also, find these content elements on The Scalability of the Hotel Technology Stack:

Related techtalk.travel editorials

To all techtalk.travel editorials

Photo by Esther Jiao on Unsplash, Graphic by Sciant