En las últimas décadas de la tecnología de viajes, la arquitectura cliente-servidor ha sido el estándar en todo el mundo. Incluso aunque este método ha satisfecho las necesidades básicas del sector durante muchos años, también ha sido responsable de la ineficiencia y poca escalabilidad de los sistemas y programas de gestión hotelera, a los que les ha faltado la agilidad requerida en el rápido entorno de viajes. Mientras que el resto de los ámbitos tecnológicos, tanto en el plano del consumidor, como de la empresa, se están transformando y evolucionando, la tecnología de infraestructuras está atascada en una década anterior, lo que hace difícil que los empresarios tomen las decisiones correctas. Esta forma tradicional de arquitectura se conoce como monolítica. Afortunadamente, existe una alternativa: una arquitectura de microservicios PMS hoteleros. Ofrece escalabilidad, sostenibilidad y seguridad, y está lista para ser el futuro de la infraestructura tecnológica de viajes. En este artículo, exploraremos la arquitectura de microservicios PMS para hoteles y la razón por la que representa el futuro. Pero para entender los microservicios tenemos que entender lo que no es: una arquitectura cliente-servidor.
¿Qué es una arquitectura cliente-servidor?
Se estima que el 90 % de los hoteles ha heredado infraestructuras de aplicaciones. Esto significa que 9 de cada 10 propiedades están utilizando sistemas que se construyeron e idearon en los 80 y 90, basados en los estándares de ese momento: la arquitectura cliente-servidor.
Muchos PMS hoteleros siguen utilizando arquitectura cliente-servidor porque aún sirve para el objetivo para el que se creó. Además, cambiar a nuevas tecnologías puede resultar todo un reto y durante mucho tiempo no existían demasiadas alternativas.
De hecho, esto no es solo un problema en el sector hotelero. Cuando observamos la tecnología utilizada en las últimas cuatro décadas por casi todas las empresas, es común encontrarse con la misma arquitectura:
- Un servidor: un dispositivo físico complejo y costoso que alberga una base de datos (por ejemplo: Oracle, Microsoft, en una ubicación específica, con archivos compartidos, etc.).
- Clientes múltiples: usuarios de PC (generalmente con Windows, o antes de eso, con DOS y basados en terminales como GDS).
- Aplicaciones: software instalado en clientes que se comunican con la base de datos del servidor.
En la arquitectura cliente-servidor, de un lado está el almacenamiento de datos en una base de datos central (generalmente una relacional, como la de lenguaje de consulta estructurado (SQL) almacenada en un servidor físico, y, de otro lado, múltiples UI, aplicaciones Windows/DOS que se comunican con el servidor. El mayor problema con esta arquitectura es que la lógica empresarial se extiende a ambos lugares. En la base de datos, por ejemplo, es común encontrarse no solo con almacenamiento de datos, sino incluso con algo de código. Hasta la década de los 90, los servidores eran responsables tanto del almacenamiento de la base de datos, como de la ejecución de parte de la lógica de negocios. Esto puede parecer trivial, y un tema semántico, pero en realidad tiene muchas implicaciones negativas.
Por ejemplo, si un proceso empresarial particular puede funcionar más rápidamente en la base de datos que en el cliente, los desarrolladores colocarían parte de la lógica empresarial directamente en la base de datos o en la capa de UI, en lugar de seguir el procedimiento convencional de ir de acá para allá entre el cliente y la base de datos, creando un sistema de funcionamiento mix and match propenso a errores informáticos.
Nuevas plataformas, arquitectura antigua
Durante años, el software se ha escrito y desarrollado basado en la infraestructura cliente-servidor, pero a comienzos de la década de los 2000, gracias a la llegada de Internet y a las crecientes expectativas de usuarios y empresas, comenzó a aumentar la presión por encontrar una solución mejor. Incluso cuanto las aplicaciones front-end HTML comenzaron a ser más comunes, algunos desarrolladores siguieron haciendo software con los mismos procesos obsoletos, cambiando apenas la forma de presentar las aplicaciones, pero manteniendo la misma arquitectura cliente-servidor intacta en la base.
Solo a finales de los 2000, con la conectividad de Internet y el creciente número de usuarios, el mundo del desarrollo entendió que las aplicaciones se estaban haciendo tan importantes (en términos de volúmenes de datos) que la arquitectura cliente-servidor no podía seguir gestionándolos. Más aún, la proliferación de navegadores y dispositivos nuevos y diferentes, todos con especificaciones distintas, hizo que los desarrolladores se dieran cuenta de que tenían que lidiar no solo con una, sino con un gran número de interfaces.
Líderes de la industria como Google, Amazon y Netflix entendieron rápidamente el cambio y, para mantener la estabilidad y escalabilidad, comenzaron a diseccionar el proceso del tratamiento, uso y gestión de los datos, para asegurarse de que la presentación y lógica de negocio estaban claramente separadas entre sí: uno de los muchos cambios providenciales que posicionaron a estas empresas para el éxito.
Arquitectura de tres niveles versus arquitectura cliente-servidor
La solución de Google y de otros líderes de la industria fue simple y brillante. Al principio, consistió en disminuir la responsabilidad de los servidores para enfocarlos únicamente en el almacenamiento de datos, para luego aumentar la capacidad de procesamiento de datos de los servidores (para compilar y analizar, de forma virtual y en tiempo real, terabytes de datos), y finalmente, reducir las responsabilidades de lógica empresarial de los servidores.
Este nuevo concepto marcó el nacimiento de lo que conocemos hoy en día como arquitectura de tres niveles, con tres partes independientes: un completo sistema de almacenamiento y recuperación de datos centrales (transparente, rápido y estable), una lógica empresarial (exponiendo sus funcionalidades a través de API específicas) y un nivel de presentación (la interfaz usuario front-end).
Los microservicios compartimentalizan las funcionalidades, mientras que los sistemas monolíticos, las centralizan. En otras palabras, los microservicios compartimentalizan los problemas potenciales, mientras que los sistemas monolíticos, los centralizan.
Construir y mantener software como módulos independientes en plataformas separadas era un concepto revolucionario, y necesario, años atrás, con la arquitectura estándar de los 80 y 90. Separar todas las funcionalidades de un sistema en paquetes múltiples con funcionalidades compuestas hace posible el desarrollo de software escalable y sostenible, en comparación a tenerlo todo desarrollado en una gran plataforma.
Esta nueva forma de hacer las cosas se conoce como arquitectura de microservicios, mientras que la antigua forma se conoce como arquitectura monolítica.
«Las aplicaciones monolíticas pueden funcionar, pero generan cada vez frustración entre los usuarios».
«Las aplicaciones monolíticas pueden funcionar, pero generan cada vez más frustración entre los usuarios».
— Martin Fowler
El mayor problema con la arquitectura monolítica es que es virtualmente imposible de escalar, tanto desde el punto de vista de los proveedores de tecnología, como de los usuarios. El añadir una funcionalidad sencilla y novedosa a una aplicación existente podría, en el peor de los escenarios, hacer colapsar todo el sistema, o en el mejor de los casos, requerir mucho tiempo de desarrollo, lo que resulta en mayores costes para todas las partes. Por ello es necesario dar un paso más allá en la arquitecturade los PMS hoteleros.
De arquitectura monolítica a arquitectura de microservicios
Los huéspedes de los hoteles tienen ciertas expectativas. Quieren poder hacer el check-in desde el teléfono o un pedido desde una aplicación. Y los hoteles quieren ofrecer estos servicios, ya que la satisfacción del cliente es fundamental para la experiencia hotelera. De hecho, más a menudo de lo que creemos, los hoteles no consiguen satisfacer correctamente las necesidades de sus clientes porque emplean sistemas obsoletos sin capacidad para integrar nuevas funciones y cada capa extra de personalización exige una labor ingente de programación en la base de datos o en la aplicación del cliente. La mayor parte de los PMS hoteleros se basan en gran cantidad de código, en el que cada línea es independiente de la anterior, por lo que se hace casi imposible innovar sin destruir todo el sistema. Por esa razón, el sector es incapaz de adaptarse a las nuevas necesidades del mercado.
Por el contrario, con el enfoque de los microservicios, el usuario cuenta con múltiples programas completamente independientes, pero vinculados por reglas escritas en las API. Por lo tanto, mientras se sigan las reglas de las API, un sistema basado en microservicios podría ser gestionable y mejorable de manera indefinida, sin riesgo de destruir el sistema como un todo con cada actualización. Desde el punto de vista operativo, el riesgo de sufrir el efecto dominó de un error informático queda contenido gracias a la descentralización misma de la arquitectura de microservicios. Si se actualiza una aplicación o si se cae, no se ve afectada la estructura como tal. El sistema gana en resiliencia y es mucho más fácil aislar los errores y recuperarse de fallos en el sistema.
El papel de las API
La creciente tasa de adopción de API en el sector hotelero ha desempeñado un papel fundamental en el cambio de la arquitectura PMS para hoteles, de monolítica a microservicios. Las API resultan cruciales en este enfoque más flexible y descentralizado ya que simplifican la programación y aumentan la posibilidad de interconectividad.
Esta independencia aporta a los desarrolladores mayor libertad para codificar sin tener que abarcar todo el lenguaje de programación utilizado en el sistema central. Los programadores que se ocupan de integrar una funcionalidad única de una aplicación de terceros, por ejemplo, no tienen que entender todo el sistema de archivos, la estructura de programación, y el lenguaje, y pueden concentrarse simplemente en obtener información específica para solucionar un problema determinado. Los microservicios compartimentalizan las funcionalidades, mientras que los sistemas monolíticos las centralizan. En otras palabras: los microservicios compartimentalizan los problemas potenciales, mientras que los sistemas monolíticos los centralizan.
Arquitectura de microservicios PMS para hoteles y protección de datos
Raro es el día en el que no se produce algún tipo de vulneración de datos. El sector del turismo siempre ha sido vulnerable a la filtración de datos, particularmente porque, a diferencia de otros sectores, para funcionar correctamente, necesita mucha información del usuario y el valor de esos datos se correlaciona con capacidad del hotel para tratarlos.
En el mercado negro, la información personal identificable se vende a 1 $ por dato, aproximadamente, pero de acuerdo con Justin Lie, director ejecutivo de CashShield, el valor de esta «se multiplica por 5 con cada dato asociado». Si le agregamos un número de móvil, una dirección de correo electrónico personal y la fecha de nacimiento a la información robada, su valor aumenta hasta 125 $.
Eine universelle Content-Management-Lösung
Die Gruppe wandte sich dann dem zu, was manche als den heiligen Gral des Content-Managements im Gastgewerbe betrachten: Eine universelle Content-Management-Lösung, die die einzige Quelle für alle Inhalte auf allen Plattformen wäre, die ein bestimmtes Hotel nutzt. Wie würde dies aussehen, welche Hindernisse gibt es, und was ist derzeit verfügbar?
Natalie Kimball: Wir [Shiji] müssen als Technologieanbieter berichten, welche Datenpunkte es gibt. Durch HTMG, wurden so viele Datenpunkte gesammelt. Wir haben bereits die Daten. Wir brauchen jemanden, der die Verantwortung übernimmt und sagt: “So wird es funktionieren”. Und dazu brauchen wir die Hilfe von GDS und von allen Beteiligten. Vielleicht müssen Wyndham, Hilton und Marriott irgendwann sagen: “Wir müssen aufhören, in dieses Hamsterrad stecken zu bleiben.”
Warum sollten die Anbieter aufstehen und sagen: “Okay, ja, wir machen das”, wenn es keinen Anreiz von kommerzieller Seite gibt? Vielleicht muss der Anstoß von einem großen Anbieter kommen, der über genügend finanzieller Mittel verfügt, um anfangs in die Sache zu investieren. Und wenn sie ein kommerzielles Modell entwickeln, das Einnahmen generiert, wird man anfangen, die Kosten zu decken. Aber es kann sein, dass es anfangs einen Verlust geben wird, damit wir es für die Branche anpassen können.
Gianna Rivera: Viele unserer Unternehmen denken über die verschiedenen Inhaltskanäle auf individuelle Weise nach. Ich glaube nicht, dass das nur für das eine oder andere Unternehmen gilt. Wir müssen dazu beitragen, dass diese Gespräche zu einem einheitlichen Denkprozess führen und dass sie verstehen, dass es im eigentlichen Sinne um Inhalte geht.
Hochwertige visuelle Inhalte
Zum Abschluss des Gesprächs diskutierte die Gruppe darüber, dass nicht alle Inhalte gleich sind, und tauschte einige Ideen darüber aus, wie hochwertige Inhalte tatsächlich aussehen.
Sarah Fults: Eine der größten Herausforderungen ist, dass man sein Hotel für das Fotoshooting vorbereiten muss. Für diejenigen von uns, die eine hohe Auslastung haben, kann es sehr schwierig sein, einen Termin für ein Fotoshooting für ein Hotel zu finden. Das ist die größte Herausforderung: Die Zeit zu finden, den Raum einzurichten und sicherzustellen, dass man überhaupt das Wissen dazu hat. Welche Blickwinkel? Von was sollte man das Bild machen? Wie kann man das im Rahmen des Budgets machen? Wie viele Jahre dauert es, bis man das nächste Fotoshooting machen muss?
Natalie Kimball: Es ist eine aufwendige aber wichtige Investition. Und jeder Geschäftsführer wird sich fragen: “Was ist mein Return on Investment?” Selbst wenn die Auslastung um 2 % steigt, ist das nicht genug.
Inhalte sind ein Verkaufsförderungsinstrument, und die OTAs haben uns das bewiesen. Es gibt einen Grund, warum jeder von ihnen Badezimmerfotos verlangt.
Ich glaube, es geht darum, dass ein Hotel nicht mehr darüber nachdenken muss, welches Foto wichtig ist und wie man es bekommt. Es geht um die Automatisierung. Und haben wir dann das Recht, das Foto auf jedem Kanal zu verwenden, der Zugang zu dieser Hosting-Plattform hat?
No resulta difícil entender que las bases de datos de los hoteles son literalmente minas de oro para los piratas informáticos ya que almacenan perfiles más completos y precisos que, por ejemplo, el blog de una web o una aplicación de juegos. Los PMS hoteleros recopilan datos extremadamente valiosos como son los números de teléfono, información sobre tarjetas de crédito y más importante aún, números de pasaportes. En EE. UU., un pasaporte robado proporciona a prácticamente cualquiera la posibilidad de solicitar el número de seguridad social en línea y, en consecuencia, solicitar tarjetas de crédito o préstamos.
La mayor dificultad es que, como la estructura central de la mayoría del software hotelero ha sido codificada décadas antes de Internet, no está preparada para defenderse de ataques cibernéticos. El filósofo francés Paul Virilio dijo una vez: «cuando inventas el buque, también inventas el naufragio». En los 80 y la mayor parte de los 90, con prácticamente ninguna conexión a Internet, el concepto de «pirateo» de la web simplemente no se contempló, y esta es la razón por la cual tantos sistemas de software de gestión hotelera son tan vulnerables a la filtración de datos.
Hoy en día, gracias a la arquitectura de microservicios PMS hoteleros, los desarrolladores pueden separar datos personales de los no personales, y elegir diseñar alrededor de uno u otro conjunto de datos según la tarea específica que haya que realizar con ellos.
Esta flexibilidad para construir siempre que sea posible, únicamente alrededor de datos no personales, le aporta una ventaja muy valiosa al software y PMS hotelero basado en microservicios, especialmente cuando se trata de restricciones al almacenamiento de datos de determinados países que requieren que la información de sus ciudadanos sea almacenada localmente. En las arquitecturas monolíticas, los datos están repartidos por todas partes, lo que significa que los datos personales de los usuarios rusos deberían ser almacenados legalmente en su país. Para poder trabajar con Rusia, todo el sistema debería cambiarse de ubicación y los datos ser accesibles solo mediante almacenamiento en caché, lo que genera un círculo de complejidad difícil (y costoso).
Empresas como Amazon y Netflix han sido de las primeras en adoptar la arquitectura de microservicios, y su gran escalabilidad se debe particularmente al hecho de que sus aplicaciones se han desarrollado y presentado como un conjunto de microservicios, en lugar de como una gran porción de código.
Sistemas y soluciones cloud: flexibilidad a buen precio
Muchas veces incomprendida, o tergiversada a sabiendas por empresas tecnológicas, el principal beneficio de «la nube» tiene poco que ver con la habilidad de ejecutar una aplicación desde un navegador y más con el ahorro de costes, o el coste total de propiedad (TCO). Los costes directos e indirectos de desplegar una solución en la nube es simple y llanamente mucho menores que los de mantenerlo en una plataforma.
En primer lugar, los hoteles no tienen que adquirir ningún hardware costoso (costes directos). Más aún, gracias a la subcontratación, los hoteles pueden beneficiarse de la experiencia y recursos del proveedor, en caso de que, y cuando algo funcione mal, en lugar de depender únicamente de expertos internos para soporte y mantenimiento (costes indirectos). Los proveedores de servicios en la nube garantizaban un mayor tiempo de actividad que los sistemas heredados autogestionados, lo que disminuye drásticamente el riesgo de pérdidas potenciales de beneficios. Y, además, fusionar distintas tecnologías se hace exponencialmente más fácil con arquitecturas de microservicios.
En pocas palabras, las soluciones en la nube (PMS hoteleros y soluciones POS) hacen posible la escalabilidad, el crecimiento y la sostenibilidad para empresas de cualquier tamaño ya que minimizan la necesidad de grandes inversiones iniciales (hardware, configuración del centro de datos, costes de instalación, etc.) y alargan el ciclo de vida de las aplicaciones.
Crecimiento de la arquitectura de microservicios PMS hoteleros
No es ninguna sorpresa que, en los últimos años, empresas de éxito como Netflix, Google y Amazon hayan dejado atrás la arquitectura monolítica a favor de la de microservicios. Hoy en día, con nuevos reglamentos sobre privacidad, distintos requisitos, tecnología más rápida, sistemas de pago revolucionarios y sistemas de distribución cada vez más amplios, resulta evidente que el enfoque monolítico no va a poder seguir el ritmo.
Además de esto, utilizando un enfoque de fácil conexión (plug-and-play), los desarrolladores no tienen que perder tiempo solucionando problemas que ya han sido solucionados por otra persona. Las numerosas implicaciones de la adopción de PMS hoteleros de microservicios y otras arquitecturas de TI pueden resultar abrumadoras para algunos, pero eventualmente, cada empresa, independientemente de su tamaño, podría elegir cualquier herramienta disponible en el mercado y conectarse sin problema con otras herramientas igual que si instalaran una aplicación cualquiera en sus móviles personales. Para los hoteles, esto podría significar algo tan sencillo como cambiar un procedimiento interno de la secuencia de limpieza de una habitación o de mantenimiento.
La transformación digital en las empresas debería facilitar la gestión de un negocio y del servicio a los clientes o huéspedes. Y cuando se trata de hoteles, las estrategias no deberían nunca estar determinadas por las limitaciones de la infraestructura de TI, sino mejorada por su flexibilidad. Es hora de que el sector hotelero adopte la innovación, la sostenibilidad y la escalabilidad. Es hora de que el sector hotelero adopte la arquitectura de microservicios.
