Microservice tech is the future for hotels, part 1

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.

But first, 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 nine 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 over the last four decades by virtually any company, it is common to bump into the same architecture: 

• A server: a complex, expensive physical device storing a database (i.e., Oracle, Microsoft, site-based, file-shared, etc.) 
• Multiple clients: user PCs (usually running on Windows or, before that, DOS and terminal-based inputs like GDS) 
• 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 2000s, 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-2000s, 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’ 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.

The main problem with the monolithic architecture is that it is virtually impossible to scale.

Anthony Hunt

Share this quote

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, light-years away from the standard architecture of the ’80s and ’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 one, take a lot of time in development, resulting in higher costs for all parts involved.

* This article originally appeared on Shiji Group's Insights blog. Part 2 will publish on Monday, October 18.