Over the last few decades in travel technology, Client-Server architecture has been the IT standard across the world.
NB: This is an article from Shiji
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.
Subscribe to our weekly newsletter and stay up to date
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:
- 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 ‘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.
