En las últimas décadas, la arquitectura cliente-servidor ha sido la norma IT en todo el mundo. Aunque este método ha servido a las necesidades básicas del sector durante muchos años, también ha sido responsable de sistemas ineficaces y difíciles de escalar que carecen de la agilidad necesaria en el vertiginoso entorno actual de los viajes. Mientras que el resto de la tecnología, tanto de consumo como empresarial, se transforma y evoluciona, la tecnología de infraestructuras se ha quedado estancada una década en el pasado, lo que dificulta a los empresarios tomar la decisión empresarial correcta. Esta forma tradicional de arquitectura se conoce como arquitectura “monolítica”. Afortunadamente, existe un camino a seguir: la arquitectura PMS hotelera de “microservicio”. Ofrece escalabilidad, sostenibilidad y seguridad, y está llamada a ser el futuro de la infraestructura tecnológica para viajes. En este artículo, profundizaremos en la arquitectura de microservicios del PMS hotelero y en por qué es el futuro de la arquitectura de la tecnología de viajes. Pero para entender los microservicios vamos a entender, lo que no es: Arquitectura cliente-servidor.
¿Qué es la arquitectura cliente-servidor?
Se calcula que más del 90% de los hoteles disponen actualmente de infraestructuras de aplicaciones heredadas. Esto significa que 9 de cada 10 propiedades utilizan actualmente sistemas construidos y concebidos en los años 80 y 90 y basados en el estándar de la época: Arquitectura cliente-servidor.
Los hoteles siguen utilizando la arquitectura cliente-servidor porque sigue funcionando en su función original. Además, pasarse a una nueva tecnología puede ser desalentador, y durante mucho tiempo no hubo muchas alternativas.
De hecho, no se trata sólo de un problema de hostelería. Al observar la pila tecnológica utilizada en las últimas cuatro décadas por prácticamente cualquier empresa, es habitual toparse con la misma arquitectura:
- Un servidor: Dispositivo físico complejo y costoso que almacena una base de datos (por ejemplo, Oracle, Microsoft, basada en un sitio, con archivos compartidos, etc.).
- Múltiples clientes: PC de usuario (normalmente con Windows o, antes, DOS y entradas basadas en terminales como GDS).
- Aplicaciones: Programas instalados físicamente en los clientes, que se comunican con la base de datos del servidor.
En la arquitectura cliente-servidor, por un lado está el almacenamiento de datos en una base de datos central (normalmente relacional, como SQL) almacenada en un servidor físico y, por otro, múltiples aplicaciones de interfaz de usuario basadas en Windows/DOS que se comunican con el servidor. El principal problema de esta arquitectura es que la lógica empresarial está repartida en ambos lugares. En la base de datos, por ejemplo, es habitual encontrar no sólo almacenamiento de datos, sino incluso algo de codificación. Hasta finales de los años 90, los servidores eran responsables tanto del almacenamiento de las bases de datos como de la ejecución de parte de la lógica empresarial. Puede parecer una cuestión semántica trivial, pero tiene numerosas implicaciones negativas.
Por ejemplo, si un determinado proceso de negocio se ejecutara más rápido en la base de datos que en el cliente, los desarrolladores colocarían parte de la lógica de negocio directamente en la base de datos o en la capa de interfaz de usuario, en lugar de seguir el procedimiento convencional de ir y venir entre el cliente y la base de datos, creando una mezcla poco fiable y propensa a errores.
Nuevas plataformas, vieja arquitectura
Durante años se ha escrito y desarrollado software basado en la infraestructura cliente-servidor, pero, a principios de los años 00, gracias a la llegada de Internet y al aumento de las expectativas de los clientes y las empresas, empezó a crecer la presión para encontrar una solución mejor. Sin embargo, incluso cuando las aplicaciones web HTML front-end empezaron a generalizarse, algunos desarrolladores siguieron creando software mediante los mismos procesos obsoletos, limitándose a cambiar la forma en que se mostraban las aplicaciones mientras mantenían intacta la misma arquitectura Cliente-Servidor entre bastidores.
Sólo a finales de los años 00, con el aumento de la conectividad a Internet y de su número de usuarios, el mundo del desarrollo se dio cuenta de que las aplicaciones se estaban haciendo tan grandes (en términos de cantidad de datos) que la arquitectura cliente-servidor ya no podía manejarlas. Además, la proliferación de nuevos y diferentes navegadores y dispositivos, todos con especificaciones distintas, hizo que los desarrolladores se dieran cuenta de que tenían que lidiar no con uno, sino con multitud de interfaces.
Líderes del sector como Google, Amazon y Netflix comprendieron rápidamente el cambio y, para mantener la estabilidad y la escalabilidad, empezaron a diseccionar todo el proceso de procesamiento, uso y gestión de los datos, asegurándose de que sus capas de presentación y sus lógicas empresariales estuvieran claramente separadas entre sí.
Arquitectura de tres niveles frente a arquitectura cliente-servidor
La solución de Google y otros líderes del sector fue sencilla pero brillante. Consistía, primero, en disminuir la responsabilidad de los servidores para que se centraran exclusivamente en el almacenamiento de datos; después, en aumentar la capacidad de proceso de datos de los servidores (para recopilar y analizar, prácticamente en tiempo real, terabytes de datos); y, por último, en reducir las responsabilidades de lógica empresarial de los servidores.
Este nuevo concepto marcó el nacimiento de lo que hoy conocemos como arquitectura de tres niveles, compuesta por tres partes independientes: un sistema completo de almacenamiento/recuperación de datos (transparente, rápido y estable), una lógica de negocio (que expone sus funcionalidades a través de API específicas) y un nivel de presentación (la interfaz de usuario front-end).
Los microservicios compartimentan las funcionalidades mientras que los monolíticos las centralizan. En otras palabras, los microservicios compartimentan los problemas potenciales, mientras que los monolíticos los centralizan.
Construir y mantener el software como módulos independientes en plataformas separadas era un concepto revolucionario, aunque necesario, a años luz de la arquitectura estándar de los años 80-90. Dividir todas las funcionalidades de un sistema en varios paquetes con funcionalidades compuestas hace que el desarrollo de software sea escalable y mantenible, frente a tenerlo todo desarrollado en una plataforma grande y voluminosa.
Esta nueva forma de hacer las cosas se conoce como “arquitectura de microservicios”, mientras que la antigua se conoce como “arquitectura monolítica”.
“Las aplicaciones monolíticas pueden tener éxito, pero cada vez hay más gente que siente frustración con ellas”.
“Las aplicaciones monolíticas pueden tener éxito, pero cada vez hay más gente que siente frustración con ellas”.
– Martin Fowler
El principal problema de la arquitectura monolítica es que es prácticamente imposible de escalar, tanto para los proveedores de tecnología como para los usuarios finales. Añadir una función nueva y sencilla a una aplicación existente podría, en el peor de los casos, hacer que todo el sistema se bloquee o, en el mejor, llevar mucho tiempo de desarrollo, lo que se traduciría en mayores costes para todas las partes implicadas.
De la arquitectura monolítica a la arquitectura de microservicios
Los clientes de los hoteles tienen ciertas expectativas. Es posible que quieran poder hacer el check-in desde sus teléfonos o pedir la cena a través de una aplicación. Y a los hoteles les encantaría ofrecer estos servicios, ya que la satisfacción del cliente es fundamental para la hospitalidad. Sin embargo, la mayoría de las veces, los hoteles son incapaces de prestar un servicio adecuado a sus clientes únicamente porque sus anticuados sistemas no tienen capacidad para integrar nuevas funciones, ya que cada capa adicional de personalización tendría que codificarse en la base de datos o en la aplicación cliente. La mayoría del software hotelero se compone de un gran y desordenado trozo de código, en el que cada línea es tan interdependiente de las demás que resulta casi imposible innovar sin romper todo el sistema, de ahí la incapacidad del sector para adaptarse a las nuevas necesidades del mercado.
Con el enfoque de microservicios, por el contrario, tienes múltiples programas pequeños que son completamente independientes entre sí, pero vinculados entre sí por reglas escritas en las API. Por tanto, siempre que se sigan las reglas de la API, un sistema basado en microservicios podría ser mantenible y mejorable indefinidamente sin riesgo de aniquilar todo el sistema en cada actualización. Desde el punto de vista operativo, el riesgo del efecto dominó de un fallo está contenido por la propia descentralización de la arquitectura de microservicios: si una aplicación recibe una actualización o se cae, no afecta a toda la estructura. Todo el ecosistema se vuelve resistente, y es mucho más fácil aislar los errores y recuperarse de los fallos del sistema.
El papel de las API
El aumento de la tasa de adopción de API en el sector hotelero ha desempeñado un papel crucial en el cambio de una arquitectura de PMS hotelera monolítica a otra de microservicios. Las API son fundamentales para este enfoque más flexible y descentralizado, ya que simplifican el acto de programar y aumentan las posibilidades de interconectividad.
Esta independencia otorga a los desarrolladores la libertad de programar sin necesidad de conocer a fondo el lenguaje de programación utilizado para el sistema central. Los programadores que trabajan en la integración de una función concreta 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 centrarse simplemente en obtener información específica para resolver un problema concreto. Los microservicios compartimentan las funcionalidades mientras que los monolíticos las centralizan. En otras palabras, los microservicios compartimentan los problemas potenciales, mientras que los monolíticos los centralizan.
Arquitectura PMS de hotel de microservicio y protección de datos
Apenas pasa un día sin que aparezca alguna noticia sobre filtraciones de datos. El sector de los viajes siempre ha sido vulnerable a las violaciones de datos, principalmente porque (a diferencia de la mayoría de los sectores) para funcionar correctamente necesita recopilar una enorme cantidad de información sobre los clientes y el valor de esos datos está correlacionado con la capacidad del hotel para prestarles servicio.
En el mercado negro, la información personal identificable se vende a alrededor de 1 dólar cada una, pero, según el director general de CashShield, Justin Lie, su valor “se multiplica por 5 con cada información asociada añadida”. Si a los datos originales robados se les añade un número de móvil, una dirección de correo electrónico personal y una fecha de nacimiento, su valor se dispara hasta los 125 dólares.
No es difícil comprender que las bases de datos de los hoteles son literalmente minas de oro para los piratas informáticos, ya que almacenan un perfil individual más completo y preciso que, por ejemplo, un blog web o una aplicación de juegos. Los hoteles recopilan datos muy valiosos, como números de teléfono, datos de tarjetas de crédito y, lo que es más importante, pasaportes. En Estados Unidos, un pasaporte robado da la posibilidad a prácticamente cualquiera de pedir en línea un número de la seguridad social y, en consecuencia, solicitar tarjetas de crédito o préstamos.
La principal dificultad es que, como la estructura básica de la mayoría del software hotelero se ha codificado décadas antes del auge de la web, sencillamente no están preparados para defenderse de los ciberataques en línea. El filósofo francés Paul Virilio dijo una vez: “Cuando se inventa el barco, también se inventa el naufragio”. En los años 80 y durante buena parte de los 90, prácticamente sin conexión a Internet, no se tenía en cuenta el concepto de piratería web, y por eso muchos sistemas de software hotelero están tan indefensos ante las filtraciones de datos.
Hoy en día, gracias a la arquitectura de PMS hotelera de microservicio, los desarrolladores pueden separar los datos personales de los no personales, y elegir diseñar en torno a uno u otro conjunto de datos en función de la tarea específica que deba ejecutarse.
Esta flexibilidad para construir siempre que sea posible solo en torno a datos no personales da una ventaja inestimable al software de microservicios, especialmente cuando se trata de restricciones de almacenamiento de datos de países específicos que piden que la información de sus ciudadanos se almacene localmente. En las arquitecturas monolíticas, los datos suelen estar repartidos por todas partes, lo que significa que los datos personales de los clientes rusos deben almacenarse legalmente en su país. Para hacer negocios con Rusia, hay que trasladar todo el sistema, y sólo se puede acceder a los datos almacenándolos en caché, lo que crea un difícil (y costoso) círculo de complejidad.
Empresas como Amazon y Netflix son las primeras en adoptar la arquitectura de microservicios, y su gran escalabilidad se debe principalmente a que sus aplicaciones se desarrollan y despliegan como un conjunto de microservicios en lugar de como un gran trozo de código.
Sistemas basados en la nube: Flexibilidad a buen precio
A menudo malinterpretada (o tergiversada a sabiendas por las empresas tecnológicas), la principal ventaja de “la nube” tiene menos que ver con la posibilidad de ejecutar una aplicación desde un navegador y más con el ahorro de costes, o coste total de propiedad (TCO). Los costes directos e indirectos de implantar un sistema en la nube son sencillamente muy inferiores a los de mantenerlo en una plataforma heredada.
En primer lugar, los hoteles no tienen que adquirir ningún hardware caro (costes directos). Además, gracias a la externalización, los hoteles pueden beneficiarse de la experiencia y los recursos del proveedor en caso de que algo vaya mal, en lugar de tener que depender únicamente de los expertos internos para el soporte y el mantenimiento (costes indirectos). Los proveedores de servicios en la nube suelen garantizar incluso tiempos de actividad superiores a los de los sistemas heredados autogestionados, lo que reduce drásticamente el riesgo de posibles pérdidas de ingresos. Además, la fusión de distintas tecnologías resulta exponencialmente más fácil con las arquitecturas de microservicios.
En pocas palabras, las soluciones en la nube ( soluciones de PMS y POS para hoteles ) hacen posible la escalabilidad, el crecimiento y la sostenibilidad de empresas de cualquier tamaño al minimizar la necesidad de inversiones iniciales prohibitivas (hardware, configuración del centro de datos, costes de instalación, etc.) y ampliar el ciclo de vida de las aplicaciones.
El crecimiento de la arquitectura PMS hotelera de microservicios
No es de extrañar que, en los últimos años, empresas de éxito como Netflix, Google y Amazon hayan abandonado la arquitectura monolítica en favor de los microservicios. Hoy en día, con nuevas leyes de privacidad, requisitos variados, tecnología más rápida, sistemas de pago disruptivos y sistemas de distribución cada vez más amplios, es evidente que el enfoque monolítico no podrá seguir el ritmo.
Además, al utilizar un enfoque “plug and play”, los desarrolladores no tienen que perder el tiempo resolviendo problemas que ya han sido resueltos por otros. Las numerosas implicaciones de la adopción de pms para hoteles de microservicios y otras arquitecturas de IT pueden parecer abrumadoras para algunos, pero con el tiempo, todas las empresas, independientemente de su tamaño, deberían poder elegir cualquier herramienta disponible en el mercado y conectarla sin fricciones a otras herramientas, del mismo modo que instalan aplicaciones en su smartphone personal. Para los hoteles, esto podría significar algo tan sencillo como cambiar un proceso interno de la secuencia de limpieza o mantenimiento de las habitaciones.
La IT debe facilitar la gestión de una empresa y el servicio a los clientes o huéspedes. Y, cuando se trata de hoteles, las estrategias nunca deben estar determinadas por las limitaciones de su infraestructura IT subyacente, sino potenciadas por su flexibilidad. Es hora de que la hostelería adopte la innovación, la sostenibilidad y la escalabilidad. Es hora de que la hostelería adopte la arquitectura de microservicios.
