Construir arquitecturas SaaS multi-inquilino

Capítulo 1. La mentalidad SaaS La mentalidad SaaS

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

He trabajado con varios equipos que estaban creando soluciones de software como servicio (SaaS). Cuando me siento con ellos para trazar su camino hacia el SaaS, suelen empezar con lo que parece una visión razonable y de alto nivel de lo que significa ser SaaS. Sin embargo, cuando profundizo un poco más en y me meto en los detalles de su solución, a menudo descubro variaciones significativas en su visión. Imagina, por ejemplo, que alguien te dice que quiere construir un edificio. Aunque todos tenemos cierta noción de que un edificio tiene paredes, ventanas y puertas, la naturaleza real de estas estructuras puede variar enormemente. Algunos equipos pueden estar imaginando un rascacielos, y otros pueden estar construyendo una casa.

Es normal que haya confusión sobre cómo es el SaaS. Como ocurre en todos los ámbitos tecnológicos, el universo del SaaS evoluciona continuamente. La aparición de la nube, las cambiantes necesidades de los clientes y la economía del sector del software están en constante movimiento. La forma en que definíamos el SaaS ayer puede no ser la forma en que lo definamos hoy. La otra parte del reto aquí es que el alcance del SaaS va mucho más allá de lo técnico. Es, en muchos aspectos, una mentalidad que abarca todas las dimensiones de la organización de un proveedor de SaaS.

Teniendo esto en cuenta, el lugar natural para comenzar este viaje es aclarando cómo defino SaaS y cómo creo que esta definición da forma a nuestro enfoque de la arquitectura, el diseño y la construcción de una solución SaaS. El objetivo de este capítulo es construir un modelo mental básico que reduzca parte de la confusión sobre lo que significa ser SaaS. Iremos más allá de algunas nociones vagas de SaaS y, al menos en el ámbito de este libro, adjuntaremos principios rectores más concretos a la definición de SaaS que darán forma a las estrategias que exploraremos en los próximos capítulos.

Para llegar ahí, tendremos que examinar las fuerzas que motivaron el paso al SaaS y ver cómo estas fuerzas influyeron directamente en los modelos arquitectónicos resultantes. Seguir esta evolución proporcionará una visión más concreta de los principios fundacionales que se utilizan para crear una solución SaaS que haga realidad toda la propuesta de valor del SaaS, mezclando los parámetros técnicos y empresariales que constituyen el núcleo del desarrollo de entornos SaaS modernos. Es esencial que los arquitectos de SaaS comprendan que SaaS no es una mentalidad que da prioridad a la tecnología. Un arquitecto de SaaS no diseña primero una arquitectura multiinquilino y luego determina cómo se superpone la estrategia empresarial. En lugar de eso, la empresa y la tecnología trabajan juntas para encontrar la mejor intersección entre los objetivos empresariales y las soluciones multiusuario que harán realidad esas estrategias. Este tema nos acompañará a lo largo de todo el libro.

Aunque puede que te sientas cómodo con lo que SaaS significa para ti, es posible que los conceptos fundamentales que exploraremos aquí desafíen tu visión de SaaS y la terminología que utilizamos para describir los entornos SaaS. Así que, aunque resulte tentador tratar este capítulo como opcional, puede que sea uno de los más importantes del libro. No es sólo una introducción; se trata de crear un vocabulario y un modelo mental comunes que se entretejerán en las estrategias de arquitectura, codificación e implementación que iremos cubriendo a lo largo del libro.

Dónde empezamos

Antes de adentrarnos en la definición de SaaS, tenemos que entender dónde empezó este viaje y los factores que han impulsado el impulso del modelo de entrega SaaS. Empecemos por ver cómo se ha construido, operado y gestionado tradicionalmente el software. En general, los sistemas anteriores al SaaS se suministraban en un modelo de "software instalado" en el que los clientes desempeñaban un papel en la instalación y configuración de su software. El equipo informático del cliente podía instalarlo en algún entorno proporcionado por el proveedor o podía ejecutarlo en su propia infraestructura. En este modo, la gestión y el funcionamiento de estos entornos, hasta cierto punto, podrían recaer en el equipo informático del cliente. Un equipo de servicios profesionales también podría desempeñar algún papel durante la instalación, personalización y configuración del entorno del cliente.

En este modelo, los equipos de desarrollo de software tendían a estar más alejados de estos detalles de entrega y configuración. Estaban más centrados en construir continuamente las capacidades funcionales de sus soluciones. La entrega y las operaciones a menudo se encontraban al otro lado del muro y se gestionaban en cierto modo por debajo de los esfuerzos de desarrollo cotidianos.

La Figura 1-1 ofrece una visión conceptual de la huella del modelo tradicional de entrega de software.

Figura 1-1. El modelo de software instalado

En la parte superior izquierda de la Figura 1-1, verás que he presentado a un proveedor de software independiente (ISV) que representa a la entidad que vende software a sus clientes. También he mostrado dos clientes que actualmente poseen el software del ISV, los Clientes 1 y 2. Cada uno de estos clientes utiliza versiones específicas del producto del ISV. Como parte de su incorporación, también necesitaron personalizaciones puntuales del producto que fueron abordadas por el equipo de servicios profesionales del ISV. También tenemos otros clientes que utilizan versiones diferentes de nuestro producto, que pueden tener o no personalizaciones.

A medida que se incorpora cada nuevo cliente, la organización de operaciones del proveedor puede tener que crear equipos especializados que puedan atender las necesidades cotidianas de estos entornos de clientes. Estos equipos pueden dedicarse a un cliente concreto o prestar apoyo a una muestra representativa de clientes.

Este modo clásico de entrega de software es un modelo mucho más orientado a las ventas, en el que la empresa se centra en captar clientes y entregarlos a los equipos tecnológicos para que atiendan las necesidades específicas de cada cliente entrante. Puedes imaginar cómo esta dinámica da forma a la cultura general y al ciclo de desarrollo de la experiencia. Cómo se construye tu producto, cómo se despliegan las nuevas funciones, cómo piensas en la personalización... todas estas áreas están influidas por la naturaleza de este enfoque. La mentalidad aquí es una en la que conseguir un acuerdo puede tener prioridad sobre la necesidad de agilidad, escala y eficacia operativa. Estas soluciones también se venden a menudo con contratos a largo plazo que limitan la capacidad del cliente para cambiar fácilmente a cualquier oferta de otro proveedor.

La naturaleza distribuida y variable de estos entornos de clientes suele ralentizar el lanzamiento y la adopción de nuevas funciones. Los clientes suelen tener el control en estos entornos, y a menudo dictan cómo y cuándo pueden actualizar a una nueva versión. La complejidad de las pruebas y la implementación de estos entornos podría llegar a ser difícil de manejar, empujando a los proveedores hacia lanzamientos trimestrales o semestrales.

Para ser justos, construir y entregar software utilizando este modelo es y seguirá siendo un enfoque perfectamente válido para algunas empresas. El legado, el cumplimiento y las realidades empresariales de un dominio determinado pueden ajustarse bien a este modelo. Sin embargo, para muchos, este modo de entrega de software introduce una serie de retos. En esencia, este enfoque se centra más en poder vender a los clientes lo que necesiten a cambio de compensaciones en torno a la escala, la agilidad y la eficiencia de costes/operativa.

A primera vista, estas compensaciones pueden no parecer tan significativas. Si tienes un número limitado de clientes y sólo consigues unos pocos al año, este modelo podría ser totalmente adecuado. Seguirías teniendo ineficiencias, pero serían mucho menos prominentes. Considera, sin embargo, un escenario en el que tengas una base instalada importante y quieras hacer crecer tu negocio rápidamente. En ese caso, los puntos débiles de este enfoque empiezan a representar un verdadero problema para muchos proveedores de software.

La eficiencia operativa y de costes suele estar entre las primeras áreas en las que las empresas que utilizan este modelo empiezan a sentir el dolor. Los gastos generales incrementales que supone dar soporte a cada nuevo cliente empiezan a tener repercusiones reales en el negocio, erosionando los márgenes y añadiendo continuamente complejidad al perfil operativo de la empresa. Cada nuevo cliente puede requerir más equipos de soporte, más infraestructura y más esfuerzo para gestionar las variaciones puntuales que acompañan a la instalación de cada cliente. En algunos casos, las empresas llegan a un punto en el que ralentizan intencionadamente su crecimiento debido a las cargas operativas de este modelo.

Pero la cuestión más importante es cómo afecta este modelo a la agilidad, la competencia, el crecimiento y la innovación. Por su propia naturaleza, este modelo es cualquier cosa menos ágil. Permitir que los clientes gestionen sus propios entornos, dar soporte a versiones separadas para cada cliente, permitir la personalización puntual... todas estas son áreas que minan la velocidad y la agilidad. Imagina lo que supondría desplegar una nueva función en estos entornos. El tiempo que transcurre entre que tienes la idea de una función, iteras sobre su desarrollo y la pones a disposición de todos tus clientes suele ser un proceso lento y deliberado. Cuando llega una nueva función, las necesidades de los clientes y del mercado pueden haber cambiado. Esto también puede afectar a la huella competitiva de estas empresas, limitando su capacidad de reaccionar rápidamente ante las soluciones emergentes que se construyen en torno a un modelo de menor fricción.

Mientras que la huella operativa y de desarrollo era cada vez más difícil de escalar, las necesidades y expectativas de los clientes también estaban cambiando. Los clientes se han centrado menos en conservar la capacidad de gestionar o controlar sus entornos. En cambio, están más interesados en maximizar el valor que pueden extraer de su software. Exigen cada vez más experiencias de menor fricción que puedan innovar continuamente para satisfacer sus necesidades, dándoles más libertad para moverse entre soluciones basadas en las necesidades cambiantes de sus negocios.

Los clientes también se sienten más atraídos por modelos de precios que se ajusten mejor a su perfil de valor y consumo. En algunos casos, buscan la flexibilidad de los modelos de precios de suscripción y/o pago por uso.

Puedes ver la tensión natural que está en juego aquí. Para muchos, el modelo de entrega clásico simplemente no se alinea bien con su capacidad para escalar o hacer crecer su negocio y satisfacer las necesidades cambiantes de sus clientes. La aparición de la nube también ha desempeñado un papel clave. El modelo de la nube alteró fundamentalmente la forma en que las empresas veían el alojamiento, la gestión y el funcionamiento de su software. La naturaleza de pago por uso y el modelo operativo de la nube cambiaron la mentalidad del sector, poniendo un mayor énfasis en la agilidad y las economías de escala. Juntas, estas fuerzas motivaron a los proveedores de software a replantearse cómo construyen, suministran, operan y venden sus soluciones.

El paso a un modelo unificado

A estas alturas, los retos básicos del modelo tradicional deberían estar claros. Mientras algunas organizaciones luchaban con este modelo, otras ya comprendían que este enfoque sencillamente no escalaría ni económica ni operativamente. Si eres un ISV B2B con miles de clientes, por ejemplo, es poco probable que tu empresa pueda soportar un modelo en el que cada cliente tenga que ser atendido, gestionado y operado por separado.

La respuesta, para muchos, era pasar a un modelo que unificara más la experiencia, reduciendo la complejidad y el coste que naturalmente conllevaba apoyar el modelo por cliente. Aquí es donde vimos equipos que adoptaban un modelo de infraestructura compartida que les permitiera escalar su negocio y racionalizar su modelo operativo con mayor eficacia.

Este cambio hacia un modelo más unificado y compartido abrió un abanico de nuevas oportunidades para los proveedores de software. La Figura 1-2 ofrece una visión conceptual de un entorno SaaS simplificado de infraestructura compartida.

Figura 1-2. Un modelo SaaS de infraestructura compartida

En la Figura 1-2, verás una visión simplificada de la noción tradicional de SaaS. Observarás que nos hemos alejado completamente de la naturaleza distribuida, puntual y personalizada del modelo clásico que vimos en la Figura 1-1. En su lugar, hemos pasado a una estrategia unificada en la que todos los servicios de aplicación y la infraestructura del sistema son compartidos por los clientes. También verás que he sustituido en el término "cliente" por "inquilino". Profundizaremos en la noción de inquilino en el Capítulo 2. La idea fundamental es que, al pasar a esta mentalidad unificada, vemos nuestro entorno de forma diferente. Ahora es un conjunto de recursos compartidos y ocupados por uno o varios consumidores. La idea es que estos consumidores representan ocupantes temporales de tu entorno, consumiendo sólo aquellos recursos que necesitan -de ahí el término "inquilino".

Trasladar una aplicación a un modelo de infraestructura compartida elimina muchos de los inconvenientes que conlleva tener entornos de cliente separados. Ahora, con todo compartido, tenemos un conjunto de recursos que pueden escalarse, gestionarse y operarse colectivamente. En la parte derecha de la Figura 1-2, verás que he añadido un recuadro para representar la gestión, las operaciones y la implementación de este entorno. Imagina cómo simplificaría esto la implementación de actualizaciones. Con una infraestructura compartida, tu automatización de la implementación simplemente desplegaría la actualización en este entorno SaaS unificado, y todos tus inquilinos tendrían acceso inmediato a los cambios. Se acabó la idea de entornos de cliente desplegados, versionados, gestionados y operados por separado.

La ventaja de la infraestructura compartida se extiende a casi todos los aspectos de un negocio de software. Puede agilizar la agregación y recopilación de telemetría operativa. Puede simplificar la complejidad de tu automatización DevOps. Sin duda, facilita la incorporación de nuevos inquilinos. Quizá la mayor ventaja sea la eficiencia de costes que puede suponer la infraestructura compartida. Poder correlacionar el consumo de infraestructura con la actividad real de los inquilinos permite a los equipos maximizar los márgenes y lograr economías de escala.

Puedes ver cómo este modelo tenía un atractivo masivo para las organizaciones que luchaban contra los costes y los retos operativos del modelo clásico. Además de unificar la experiencia, también aportó un nuevo nivel de agilidad a estos entornos. Bien construidos, estos entornos crean oportunidades para lanzar nuevas funciones y capacidades a un ritmo mucho más rápido, lo que permite a las organizaciones ser más ágiles a la hora de reaccionar y responder a las necesidades del cliente/mercado. La naturaleza de este modelo también crea nuevas oportunidades de crecimiento para algunos ISV, permitiéndoles añadir nuevos inquilinos a un ritmo más rápido sin erosionar sus márgenes ni absorber gastos operativos añadidos. La naturaleza elástica y de pago por uso de la infraestructura de la nube también se alinea muy bien con este modelo, apoyando los modelos de precios y escalado que encajan naturalmente con la elasticidad de la nube.

Merece la pena señalar que este paso a la infraestructura compartida también introduce una serie de nuevos retos. A medida que avances en este libro, verás todos los matices y la complejidad que conlleva tener una infraestructura compartida. Dar soporte a una infraestructura compartida influirá directamente en el perfil de seguridad, rendimiento, escala, disponibilidad y resistencia de tu entorno SaaS. Estos factores tendrán un claro impacto en cómo enfoques el diseño y la implementación de tu entorno SaaS.

Nota

Esta noción de que todos los inquilinos ejecuten la misma versión de tu oferta representa una prueba de fuego común para los entornos SaaS. Es fundamental para posibilitar muchas de las ventajas empresariales que constituyen el núcleo de la adopción de un modelo de entrega SaaS.

Para crear una experiencia unificada, también debemos introducir un nuevo conjunto de componentes transversales que proporcionen toda la funcionalidad necesaria para gestionar, operar e implementar de forma centralizada una aplicación SaaS. Separar estos componentes es esencial para construir un negocio SaaS exitoso y escalable, incluso si tu aplicación no tiene una infraestructura compartida. En realidad, estos componentes son la base para impulsar los objetivos de agilidad, innovación y eficiencia de las empresas SaaS. Para entender mejor este punto, veamos una visión ligeramente diferente de un entorno SaaS (mostrada en la Figura 1-3).

Figura 1-3. Crear capacidades SaaS transversales

En el centro de la Figura 1-3, verás un marcador de posición para la experiencia de tu aplicación SaaS. Aquí es donde se despliegan los distintos componentes de tu aplicación SaaS. Es aquí donde se encuentra la infraestructura de tu aplicación. Alrededor de la aplicación hay un conjunto de componentes necesarios para dar soporte a las necesidades más amplias de tu entorno SaaS. En la parte superior, por ejemplo, he destacado la incorporación y la identidad, que proporcionan toda la funcionalidad para introducir un nuevo inquilino en tu sistema. A la izquierda, verás los marcadores de posición para la funcionalidad de implementación y gestión del SaaS. Y, a la derecha, verás conceptos fundamentales como facturación, medición, métricas y análisis.

Ahora bien, para muchos creadores de SaaS, es tentador considerar estos componentes circundantes como elementos secundarios y menos críticos de su arquitectura SaaS. De hecho, he trabajado con equipos que han optado por aplazar la introducción de estos componentes/servicios, poniendo toda su energía y esfuerzo iniciales en crear sus aplicaciones multiinquilino.

Aunque acertar con la arquitectura de la aplicación es sin duda una parte importante de tu modelo SaaS, el éxito de tu negocio SaaS se verá muy influido por las capacidades de estos componentes circundantes. Estas capacidades son el núcleo que permite alcanzar gran parte de los objetivos de eficiencia operativa, crecimiento, innovación y agilidad que motivan a las empresas a adoptar un modelo SaaS. Por tanto, estos componentes -que son comunes a todos los entornos SaaS- deben ocupar un lugar destacado cuando construyas tu solución SaaS. Por eso siempre he animado a los equipos de SaaS a empezar su desarrollo de SaaS con ellos. Son estos componentes básicos -que no tienen nada que ver con la funcionalidad de tu aplicación- los que van a tener una influencia significativa en la huella SaaS de tu arquitectura, diseño, código y negocio.

Esto debería poner de relieve el hecho de que existen múltiples dimensiones en la historia de la eficiencia y la agilidad del SaaS. Parte de la eficiencia se consigue a través de los servicios que se muestran aquí, y parte se consigue a través de las estrategias que apliques a tu arquitectura de aplicaciones. Si tu arquitectura de aplicaciones comparte infraestructura, puede añadir más eficiencia y economías de escala a tu entorno. La clave es que debemos hacer que estos servicios circundantes representen los elementos fundacionales de nuestro modelo unificado. Luego, a partir de ahí, podemos pensar en cómo/si la arquitectura de la aplicación también puede optimizarse para maximizar la eficiencia y la agilidad.

Redefinir la multitenencia

Hasta ahora, he evitado introducir la idea de multiarrendamiento. Es un término que se utiliza mucho en el espacio SaaS y que aparecerá a lo largo del resto de este libro. Sin embargo, es un término que debemos abordar con elegancia. La idea de la multitenencia viene con mucho equipaje adjunto y, antes de ordenarlo, quería sentar algunas bases sobre los fundamentos que han impulsado a las empresas hacia la adopción del modelo de entrega SaaS. La otra parte del reto es que la noción de multitenencia -tal y como la definiremos en este libro- irá más allá de algunas de las definiciones tradicionales que suelen asociarse a este término.

Durante años, en muchos círculos se utilizó el término "multiarrendatario" para transmitir la idea de que algún recurso estaba siendo compartido por múltiples arrendatarios. Esto podría aplicarse en muchos contextos. Podríamos decir que alguna parte de la infraestructura de la nube, por ejemplo, podría considerarse multiarrendatario porque permite a los arrendatarios compartir partes de su infraestructura subyacente. Muchos servicios que funcionan en la nube pueden funcionar en un modelo multiarrendatario para lograr sus economías de escala. Como consumidor de la nube, esto puede estar ocurriendo totalmente fuera de tu vista. Incluso en entornos autoalojados, los equipos pueden crear soluciones en las que sus recursos informáticos, bases de datos y otros recursos son compartidos por los inquilinos. Esto crea una conexión muy estrecha entre la multitenencia y la idea de un recurso compartido. De hecho, en este contexto, se trata de una noción perfectamente válida de multitenencia.

Ahora, cuando empezamos a pensar en los entornos SaaS, es totalmente natural que traigamos con nosotros la cartografía de la multitenencia . Al fin y al cabo, los entornos SaaS comparten infraestructura, y esa compartición de infraestructura es ciertamente válida para etiquetarla como multiinquilino.

Para ilustrar mejor este punto, veamos un modelo SaaS de muestra que reúne los conceptos que hemos estado tratando en este capítulo. La imagen de la Figura 1-4 muestra un ejemplo de entorno SaaS multiarrendatario.

Figura 1-4. Un ejemplo de entorno multiinquilino

En este ejemplo, hemos colocado la infraestructura compartida de nuestros servicios de aplicación dentro de un conjunto de microservicios circundantes que se utilizan para gestionar y operar todas las partes móviles de nuestro entorno SaaS. Suponiendo que todos nuestros inquilinos compartan su infraestructura (computación, almacenamiento, etc.), esto seguiría encajando en la definición clásica de multiinquilino, y no es infrecuente que los proveedores de SaaS definan y ofrezcan su solución siguiendo este patrón.

El reto es que los entornos SaaS no se ajustan exclusivamente a este modelo. Supongamos, por ejemplo, que creo un entorno SaaS con el aspecto de la Figura 1-5.

Figura 1-5. Arrendamiento múltiple con recursos compartidos y dedicados

Observa que hemos modificado la huella de algunos de nuestros microservicios de aplicación. El microservicio Producto es sin cambios. Su infraestructura informática y de almacenamiento sigue siendo compartida por todos los inquilinos. Sin embargo, cuando pasemos al microservicio Pedido, verás que hemos mezclado un poco las cosas. Nuestros requisitos de dominio, rendimiento y/o seguridad pueden habernos obligado a separar el almacenamiento para cada inquilino. Así, el cálculo de nuestro microservicio Pedido sigue siendo compartido, pero tenemos bases de datos separadas para cada inquilino.

Por último, nuestro microservicio Fulfillment también ha cambiado. Nuestros requisitos nos empujaron hacia un modelo en el que cada arrendatario de ejecuta recursos informáticos dedicados. En este caso, sin embargo, la base de datos sigue siendo compartida por todos los inquilinos.

Sin duda, esta arquitectura ha añadido una nueva arista a nuestra noción de multitenencia. Si nos atenemos a la definición más pura de multiarrendamiento, en realidad no podríamos decir que todo lo que se ejecuta aquí se ajusta a la definición original de multiarrendamiento. El almacenamiento del servicio Pedido, por ejemplo, no comparte ninguna infraestructura entre inquilinos. El cálculo de nuestros microservicios de Cumplimiento tampoco se comparte, pero la base de datos de este servicio sí la comparten todos los inquilinos.

Difuminar estas líneas de multiinquilino es habitual en el universo SaaS. Cuando compones un entorno SaaS, no te ciñes a ninguna definición absoluta de multiarrendamiento; eliges las combinaciones de recursos compartidos y dedicados que mejor se alinean con los requisitos empresariales y técnicos de tu sistema. Todo esto forma parte de la optimización de la huella de tu arquitectura SaaS en torno a las necesidades de la empresa.

Aunque aquí los recursos no son compartidos por todos los inquilinos, los fundamentos de los principios SaaS que hemos esbozado antes siguen siendo válidos. Por ejemplo, este entorno no cambiaría nuestro enfoque de implementación de aplicaciones. Todos los inquilinos de este entorno seguirían ejecutando la misma versión del producto. Además, el entorno seguiría siendo incorporado, operado y gestionado por el mismo conjunto de servicios compartidos en los que confiábamos en nuestro ejemplo anterior. Esto significa que seguimos extrayendo de este entorno gran parte de la eficacia y agilidad operativas que se habrían conseguido en una infraestructura totalmente compartida (con algunas salvedades).

Para aclarar este punto, veamos un ejemplo más extremo. Supongamos que tenemos una arquitectura SaaS que se parece al modelo mostrado en la Figura 1-6. En este ejemplo, el dominio, el mercado y/o los requisitos heredados nos han exigido que todo el cálculo y el almacenamiento se ejecuten en un modelo dedicado, en el que cada inquilino tiene un conjunto de recursos de infraestructura completamente separado.

Figura 1-6. Un entorno multi-arrendatario con recursos totalmente dedicados

Aunque nuestros inquilinos no comparten infraestructura en este modelo, verás que siguen siendo incorporados, gestionados y operados a través del mismo conjunto de capacidades compartidas que se han extendido a todos nuestros ejemplos. Eso significa que todos los inquilinos siguen ejecutando la misma versión del software y siguen siendo gestionados y operados colectivamente.

Esto puede parecer un escenario improbable. Sin embargo, en la naturaleza, los proveedores de SaaS pueden tener cualquier número de factores diferentes que les obliguen a operar con este modelo. Los proveedores de SaaS que migran a menudo emplean este modelo como primer paso hacia el SaaS. Otras industrias pueden tener requisitos de aislamiento tan extremos que no se les permita compartir infraestructura. Hay una larga lista de factores que podrían llevar legítimamente a un proveedor de SaaS a este modelo.

Así que, con este telón de fondo, parece justo preguntarse cómo queremos definir la multitenencia en el contexto de un entorno SaaS. Utilizar la definición literal de infraestructura compartida de multiarrendamiento no parece ajustarse bien a los distintos modelos que pueden utilizarse para la implementación de infraestructura de inquilinos. En cambio, estas variaciones en los modelos SaaS parecen exigir que evolucionemos nuestra definición de lo que significa ser multiarrendatario.

Al menos en el ámbito de este libro, el término "multiarrendatario" se ampliará definitivamente para dar cabida a las realidades aquí expuestas. A medida que avancemos, multiarrendatario se referirá a cualquier entorno que incorpore, despliegue, gestione y opere arrendatarios a través de una experiencia única y unificada. La compartición de cualquier infraestructura no tendrá correlación con el término "multiinquilino".

En los capítulos siguientes, introduciremos en nueva terminología que nos ayudará a superar parte de la ambigüedad asociada a la multitenencia.

Evitar el término "inquilino único

Generalmente, cada vez que los arquitectos y constructores se refieren a algo como multiinquilino, existe una tendencia natural a suponer que debe existir una noción correspondiente de lo que significa ser de inquilino único. La idea de inquilino único parece asignarse a aquellos entornos en los que los inquilinos no comparten ninguna infraestructura.

Aunque sigo la lógica de esta forma de pensar, el término no parece encajar realmente en ninguna parte del modelo de SaaS esbozado aquí. Si vuelves a la Figura 1-6, en la que nuestra solución no tenía infraestructura compartida, observé que seguiríamos etiquetándola como entorno multiarrendatario, ya que todos los arrendatarios seguían ejecutando la misma versión y eran gestionados u operados colectivamente. Etiquetarlo como entorno de inquilino único socavaría la idea de que, de alguna manera, no estamos aprovechando las ventajas del modelo SaaS.

Teniendo esto en cuenta, el término "inquilino único" no se utilizará en ningún momento más allá de este capítulo. Todos los diseños y arquitecturas de los que hablemos se considerarán arquitecturas multiinquilino, y añadiremos nuevos términos para describir los distintos modelos de implementación, que nos seguirán permitiendo expresar si se comparte la infraestructura en un entorno SaaS determinado y de qué manera. El objetivo general aquí es desconectar el concepto de multiarrendamiento del uso compartido de la infraestructura y utilizarlo como un término más amplio para caracterizar cualquier entorno que se construya, implante, gestione y opere en un modelo SaaS.

Se trata menos de lo que es o no es SaaS y más de establecer un vocabulario que se alinee mejor con los conceptos que exploraremos a lo largo de este libro.

¿Dónde están los límites del SaaS?

Hemos sentado las bases de lo que significa ser SaaS, pero hay muchos matices de los que realmente no hemos hablado. Por ejemplo, supongamos que tu aplicación SaaS requiere que partes del sistema se desplieguen en alguna ubicación externa, o imaginemos escenarios en los que tu aplicación tiene dependencias de soluciones de otros proveedores. Tal vez utilices un sistema de facturación de terceros, o tus datos deban residir en otro entorno. Hay un sinfín de razones diferentes por las que puedes necesitar que partes de tu entorno general de SaaS estén alojadas en algún lugar que no esté totalmente bajo tu control.

Entonces, ¿cómo encajaría esta huella más distribuida con la idea de tener una experiencia única y unificada para todos tus inquilinos? Después de todo, tener pleno control sobre todas las partes móviles de tu sistema sin duda maximiza tu capacidad de innovar y avanzar con rapidez. Al mismo tiempo, es poco práctico pensar que algunos proveedores de SaaS no se enfrentarán a realidades de dominio y tecnología que les obliguen a dar soporte a componentes, herramientas o tecnologías alojados externamente.

Aquí es donde no queremos ser demasiado extremistas con nuestra definición de SaaS. Para mí, el límite está más en cómo se configuran, gestionan y operan estas dependencias externas. Si su presencia está totalmente oculta a tus inquilinos y siguen siendo gestionadas y operadas a través de tu experiencia centralizada, para mí esto sigue siendo SaaS. Puede introducir nuevas complejidades, pero no cambia el espíritu del modelo SaaS que intentamos construir.

Donde esto se pone más interesante es cuando los proveedores de SaaS dependen de recursos externos que están a la vista directa de sus inquilinos. Si, por ejemplo, mi solución SaaS almacena datos en alguna base de datos alojada por el inquilino, ahí es donde las cosas se ponen más delicadas. Es posible que dependas de una infraestructura que no está totalmente bajo tu control. Actualizar esta base de datos, cambiar su esquema, gestionar su salud... todo esto se complica en este modelo. Aquí es donde empezamos a preguntarnos si este recurso externo está rompiendo la tercera pared del SaaS, exponiendo a los inquilinos a la infraestructura y creando expectativas o dependencias que socavan la agilidad, las operaciones y la innovación de tu entorno SaaS.

Mi regla general aquí (con algunas excepciones) es que estamos proporcionando una experiencia de servicio. En un modelo de servicio, la visión de nuestros inquilinos se limita a la superficie de nuestro servicio. Las herramientas, tecnologías y recursos que se utilizan para dar vida a ese servicio deben quedar totalmente ocultos a nuestros inquilinos. En muchos aspectos, ésta es la barrera dura que impide que nuestro sistema vuelva a caer en patrones que podrían dar lugar a dependencias puntuales y variaciones.

El modelo de proveedor de servicios gestionados

Hay una última arruga que tenemos que abordar en mientras intentamos refinar nuestra visión de lo que significa ser un entorno SaaS multiinquilino. Algunas organizaciones han optado por lo que se conoce como modelo de Proveedor de Servicios Gestionados (MSP). En algunos casos, categorizarán el MSP como una variante del SaaS. Esto ha creado cierta confusión en el ámbito del SaaS. Para comprender mejor los retos que se plantean, empecemos analizando un entorno MSP y veamos cómo y dónde encaja en este debate. La Figura 1-7 ofrece una visión conceptual de un entorno MSP.

Este modelo se parece al modelo clásico de software instalado que hemos esbozado antes. En la parte inferior de este diagrama, verás una colección de clientes que ejecutan varias versiones del producto de un proveedor de software. Cada uno de estos clientes se ejecutará en su propia infraestructura o entorno.

Con los MSP, sin embargo, intentaremos obtener eficiencias y economías de escala trasladando las operaciones a un equipo o entidad centralizada. Éste es el servicio que prestan estos MSP. A menudo son responsables de instalar, gestionar y dar soporte a cada uno de estos clientes, intentando extraer cierta escala y eficiencia de las herramientas y mecanismos que utilizan para operar estos entornos de clientes.

Figura 1-7. Un modelo de Proveedor de Servicios Gestionados (MSP)

También he representado al proveedor de software en la parte superior del diagrama. Esto es para transmitir la idea de que el proveedor de software puede tener relaciones de terceros con uno o varios MSP que gestionen los entornos de sus clientes.

Puedes ver cómo algunos podrían equiparar el modelo MSP al SaaS. Al fin y al cabo, parece que intenta ofrecer una experiencia unificada de gestión y operaciones para todos los clientes. Sin embargo, si repasas los principios que utilizamos para describir el SaaS, podrás ver dónde hay diferencias sustanciales entre el modelo MSP y el SaaS. Una de las mayores diferencias es que se permite a los clientes ejecutar versiones independientes. Así que, aunque puede haber algunos intentos de centralizar la gestión y las operaciones, el MSP va a tener que tener variaciones puntuales en su experiencia operativa para dar soporte a las diferentes huellas del entorno de cada cliente. Esto puede requerir equipos dedicados; como mínimo, significará tener equipos que puedan hacer frente a las complejidades de dar soporte a las necesidades únicas de cada cliente. Una vez más, el modelo MSP añade mucho valor y sin duda crea eficiencias, pero es definitivamente diferente de tener un único panel de cristal que obtiene sus eficiencias de tener clientes que ejecutan una única versión de un producto y, en muchos casos, realizando economías de escala al compartir parte o toda su infraestructura. En algún nivel del modelo MSP, es probable que sigas heredando aspectos del dolor que suponen las variaciones puntuales de los clientes. Los MSP pueden introducir algunas medidas para compensar algunos de los retos, pero seguirán enfrentándose a las complejidades operativas y de agilidad que conlleva dar soporte a las necesidades únicas y puntuales de entornos de clientes separados.

La otra diferencia se refiere más a a cómo se estructuran y funcionan los equipos de SaaS. Generalmente, en una organización SaaS, intentamos evitar trazar líneas rígidas entre los equipos de operaciones y el resto de la organización. Queremos que las operaciones, los arquitectos, los propietarios de productos y las distintas funciones de nuestro equipo colaboren estrechamente para evaluar y perfeccionar continuamente la experiencia de servicio de su oferta.

Esto significa normalmente que estos equipos están estrechamente conectados. Están igualmente interesados en comprender cómo consumen sus sistemas los inquilinos, cómo imponen la carga, cómo se incorporan y muchas otras cuestiones clave. Las empresas SaaS quieren y necesitan tomar el pulso a sus sistemas. Esto es fundamental para impulsar el éxito del negocio y estar conectado más directamente con la experiencia general del inquilino. Así que, aunque se trata de un límite menos concreto, sigue representando una diferencia importante entre SaaS y MSP.

Ahora bien, es importante señalar que el MSP es un modelo totalmente válido. A menudo representa un buen ajuste para algunos proveedores de software. El MSP puede ser incluso un trampolín para algunos proveedores de SaaS, proporcionando acceso a algunas eficiencias mientras el equipo sigue avanzando hacia su modelo de entrega SaaS. La clave es que comprendamos claramente los límites entre SaaS y MSP y evitemos ver SaaS y MSP como sinónimos de alguna manera.

En esencia, el SaaS es un modelo de negocio

A estas alturas deberías tener una idea más clara de cómo caracterizamos lo que significa ser SaaS. Debería estar claro que el SaaS tiene mucho que ver con la creación de una cultura tecnológica, empresarial y operativa centrada directamente en impulsar un conjunto distinto de resultados empresariales. Así que, aunque resulte tentador pensar en el SaaS a través de la lente de los modelos y estrategias tecnológicos, en realidad deberías considerar el SaaS más como un modelo de negocio.

Para entender mejor esta mentalidad, piensa en cómo afecta la adopción de SaaS al negocio de un proveedor de SaaS. Influye directamente y da forma a cómo los equipos construyen, gestionan, operan, comercializan, apoyan y venden sus ofertas. En última instancia, los principios del SaaS se entretejen en la cultura de las empresas de SaaS, difuminando la línea entre los ámbitos empresarial y tecnológico. Con el SaaS, la estrategia empresarial se centra en crear un servicio que permita a la empresa reaccionar ante las necesidades actuales y emergentes del mercado sin perder impulso ni comprometer el crecimiento.

Sí, las características y funciones siguen siendo importantes para las empresas SaaS. Sin embargo, en una empresa SaaS, las características y funciones rara vez se introducen a expensas de la agilidad y la eficacia operativa. Cuando ofreces una solución SaaS multiinquilino, las necesidades de muchos siempre deben tener más peso que las necesidades de unos pocos. Atrás quedaron los días de perseguir oportunidades puntuales que requieren un apoyo dedicado y puntual a expensas del éxito a largo plazo del servicio.

Este cambio de mentalidad influye en casi todas las funciones de una empresa SaaS. El papel de un propietario de producto, por ejemplo, cambia significativamente. Los propietarios de productos deben ampliar su visión y considerar los atributos operativos como parte de la construcción de su backlog. La experiencia de incorporación, el tiempo de obtención de valor, la agilidad... todos ellos son ejemplos de elementos que deben estar en el radar del propietario del producto. Deben priorizar y valorar estos atributos operativos que son esenciales para crear un negocio SaaS de éxito. Los arquitectos, ingenieros y miembros de control de calidad están igualmente influidos por este cambio. Ahora deben pensar más en cómo la solución que están diseñando, construyendo y probando alcanzará las necesidades más dinámicas de su experiencia de servicio. También cambia la forma de comercializar, poner precio, vender y dar soporte a tu oferta de SaaS. Este tema de responsabilidades nuevas y superpuestas es común a la mayoría de las organizaciones SaaS.

Así pues, la pregunta es: ¿cuáles son los principios básicos que dan forma y guían el modelo de negocio de las empresas SaaS? Aunque puede haber cierto debate sobre la respuesta a la pregunta, hay algunos temas clave que parecen impulsar las estrategias empresariales de SaaS. A continuación se esbozan estos objetivos empresariales clave del SaaS:

Agilidad

Este término suele sobrecargarse en el ámbito del software. Al mismo tiempo, en el universo del SaaS, a menudo se considera uno de los pilares básicos y factores motivadores de un negocio SaaS. Muchas organizaciones que se pasan al SaaS lo hacen porque su modelo actual las ha paralizado desde el punto de vista operativo. Adoptar el SaaS es pasar a una cultura y una mentalidad que hacen hincapié en la velocidad y la eficacia. Lanzar nuevas versiones, reaccionar ante la dinámica del mercado, dirigirse a nuevos segmentos de clientes, cambiar los modelos de precios... son algunas de las muchas ventajas que las empresas esperan obtener al adoptar un modelo SaaS. El modo en que se diseña tu servicio, cómo se gestiona y cómo se vende está determinado por el deseo de maximizar la agilidad. Una oferta multiinquilino que redujera los costes sin hacer realidad la agilidad perdería sin duda la propuesta de valor más amplia del SaaS.

Eficacia operativa

SaaS, en muchos aspectos, es sobre escala. En un entorno multiinquilino, estamos muy centrados en hacer crecer continuamente nuestra base de clientes sin necesidad de recursos o equipos especializados para apoyar la incorporación de estos nuevos clientes. Con SaaS, básicamente estás construyendo una huella operativa y tecnológica que puede soportar un crecimiento continuo e, idealmente, rápido. Apoyar este crecimiento significa invertir en la construcción de una huella operativa eficiente para toda tu organización. A menudo pregunto a las empresas de SaaS qué pasaría si 1.000 nuevos clientes se suscribieran a su servicio mañana. Algunas se alegrarían, otras se acobardarían. Esta pregunta suele plantear cuestiones clave sobre la eficiencia operativa de una empresa de SaaS. Es importante señalar que la eficiencia operativa también consiste en reaccionar y responder a las necesidades de los clientes. La rapidez con la que se lanzan nuevas funciones, la rapidez con la que se incorporan los clientes, la rapidez con la que se resuelven los problemas... todo ello forma parte de la historia de la eficiencia operativa. Cada parte de la organización puede desempeñar un papel en la creación de una oferta eficiente desde el punto de vista operativo.

Innovación

La capacidad de moverse más rápido tiene muchas ventajas para las organizaciones SaaS. Las libera y les permite estar más abiertas a experimentar y cambiar de estrategia. Las inversiones en agilidad y eficiencia operativa permiten a las organizaciones ser mucho más fluidas y flexibles. Esto les permite adoptar nuevas oportunidades, nuevos segmentos de mercado, nuevas estrategias de empaquetado/precio y un sinfín de otras posibilidades. El objetivo general es utilizar los puntos fuertes subyacentes de tu modelo operativo y de costes como combustible de tu motor de innovación. Es esta innovación la que puede desempeñar un papel importante en el éxito general de tu negocio SaaS.

Incorporación sin fricciones

Las empresas de SaaS deben considerar cuidadosamente en cómo se introducen los clientes en sus entornos. Si intentas ser lo más ágil y eficiente posible desde el punto de vista operativo, también debes pensar en cómo agilizar la incorporación de los clientes. Para algunas empresas de SaaS, esto se conseguirá mediante una página de registro clásica en la que los clientes puedan completar el proceso de incorporación de forma totalmente autoservicio. En otros entornos, las organizaciones pueden basarse en un proceso interno para impulsar la incorporación. La clave es que todas las empresas de SaaS deben centrarse en crear una experiencia de incorporación que elimine las fricciones y permita la agilidad y la eficacia operativa. Para algunos, esto será sencillo. Para otros, puede requerir más esfuerzo replantearse cómo el equipo construye, opera y automatiza su experiencia de incorporación.

Crecimiento

Toda organización trata de crecer . Sin embargo, las organizaciones SaaS suelen tener una noción diferente del crecimiento. Están invirtiendo en un modelo y una huella organizativa construidos para prosperar en el crecimiento. Imagina construir una fábrica de coches altamente eficiente que optimizara y automatizara cada paso del proceso de construcción. Luego, imagina que sólo le pidieras que produjera dos coches al día. Algo sin sentido. Con el SaaS, estamos construyendo una huella empresarial que agiliza todo el proceso de adquisición, incorporación, asistencia y gestión de clientes. Una empresa de SaaS realiza esta inversión con la expectativa de que contribuirá a apoyar y alimentar la máquina de crecimiento que, en última instancia, influye en los márgenes y en el éxito general del negocio. Por tanto, cuando hablamos aquí de crecimiento, estamos hablando de alcanzar un nivel de aceleración que no podría lograrse sin la agilidad, la eficacia operativa y la innovación que forman parte del SaaS. El grado de crecimiento que consigas es relativo. Para algunos, el crecimiento puede ser añadir 100 nuevos clientes, y para otros podría significar añadir 50.000. Aunque la naturaleza de tu escala puede variar, el objetivo de centrarse en el crecimiento es igualmente esencial para todas las empresas de SaaS.

Los elementos que aquí se exponen representan algunos de los principios empresariales centrales del SaaS. Son conceptos que deben impulsarse de arriba abajo en una empresa SaaS en la que la dirección ponga un claro énfasis en impulsar una estrategia empresarial centrada en crear crecimiento mediante la inversión en agilidad, eficiencia operativa y objetivos de crecimiento.

Casi todas las dimensiones de tu arquitectura y estrategia de SaaS van a derivarse de tu visión empresarial. Los inquilinos objetivo, el paquete, el precio, el modelo de costes y muchos otros factores van a dar forma a la arquitectura, las operaciones y la huella de gestión de la solución que construyas en última instancia. Si no tienes claridad y alineación con la empresa en torno a estos puntos, es improbable que estés en una posición para construir una oferta SaaS que realice plenamente tus objetivos empresariales.

Construir un servicio, no un producto

Muchos proveedores de software se ven a sí mismos en el negocio de la creación de productos. Y, en muchos aspectos, esto encaja bien con su modelo de negocio. La mentalidad aquí se centra en un modelo en el que construimos algo, el cliente lo adquiere y, en su mayor parte, es suyo para utilizarlo. Hay muchas permutaciones y matices dentro de este modelo centrado en el producto, pero todos gravitan hacia un modelo centrado en crear algo más estático y hacer que los clientes lo compren.

En esta mentalidad centrada en el producto, el énfasis suele estar en definir las características y funciones que permitirán a un proveedor de software cerrar brechas y conseguir nuevas oportunidades. Ahora, con el SaaS, pasamos de crear un producto a crear un servicio. Entonces, ¿se trata sólo de terminología, o tiene un impacto significativo en cómo enfocamos la creación de una oferta SaaS? Resulta que es mucho más que un cambio terminológico.

Cuando ofreces software como servicio, piensas de forma diferente sobre cómo es el éxito. Sí, tu solución tiene que satisfacer las necesidades funcionales de tus clientes. Esa dimensión del problema no desaparece. Sin embargo, como servicio, te centras mucho más en la experiencia más amplia del cliente en todas las dimensiones de tu negocio.

Veamos un ejemplo que pone mejor de manifiesto las diferencias entre un servicio y un producto. Un restaurante proporciona un buen telón de fondo para explorar estas diferencias. Cuando sales a cenar, sin duda esperas con impaciencia la comida (el producto). Sin embargo, el servicio también forma parte de tu experiencia. La rapidez con que te reciben en la puerta, la rapidez con que el camarero viene a tu mesa, la rapidez con que te dan agua y la rapidez con que llega la comida son medidas de tu experiencia de servicio. Por muy buena que sea la comida, la calidad del servicio tendrá mucho que ver con tu impresión general del restaurante.

Ahora, piensa en esto a través de la lente de una oferta de SaaS. Tus clientes de SaaS tendrán expectativas de servicio similares. La facilidad con la que pueden incorporarse a tu solución, el tiempo que tardan en obtener valor, la rapidez con la que se lanzan nuevas funciones, la facilidad con la que pueden dar su opinión, la frecuencia con la que se cae el sistema... todas estas son dimensiones de un servicio que deben estar en primer plano para los equipos de SaaS. Tener un gran producto no importará si la experiencia general de los clientes no cumple sus expectativas.

Esto adquiere un significado adicional cuando el software se entrega en un modelo SaaS, en el que la única visión que tiene el arrendatario de tu sistema es la superficie de tu solución SaaS. Los inquilinos SaaS no tienen visibilidad de los elementos subyacentes de tu sistema. No piensan en parches, actualizaciones y configuración de la infraestructura. Sólo les importa que el servicio les proporcione una experiencia que les permita maximizar el valor de tu solución.

En este modelo de servicio, también vemos a menudo que las empresas de SaaS aprovechan su agilidad operativa para impulsar una mayor fidelidad de los clientes. Estos proveedores de SaaS entran en un modo en el que lanzan nuevas capacidades, responden a los comentarios y modifican sus sistemas a un ritmo rápido. Ver esta innovación constante y rápida da a los clientes la confianza de que se beneficiarán de esta evolución constante. De hecho, ésta es a menudo la herramienta que permite a las empresas emergentes de SaaS arrebatar el negocio a los líderes tradicionales del mercado que no son SaaS. Aunque algunos líderes de mercado masivos y establecidos pueden tener un conjunto de funciones mucho más profundo, su incapacidad para reaccionar rápidamente a las necesidades del mercado y de los clientes puede dirigir a éstos hacia ofertas más ágiles basadas en SaaS.

Así que, aunque esta comparación entre producto y servicio pueda parecer un poco pedante, la considero una parte esencial del modelo mental SaaS. Conecta directamente con la idea de que el SaaS es en gran medida una mentalidad que determina la forma en que organizaciones enteras de SaaS enfocan su trabajo y a sus clientes. De hecho, muchas organizaciones SaaS adoptarán una serie de métricas que midan su capacidad para cumplir sus objetivos centrados en el servicio. Puede resultar tentador ver esto como algo que puede atornillarse a tu servicio en alguna fecha futura de . Sin embargo, muchas organizaciones SaaS de éxito confían en estas métricas como un pilar clave de su negocio SaaS.

La historia del SaaS B2B y B2C

Cuando los equipos hablan de SaaS, a menudo asignan estrategias y patrones a los modelos de empresa a consumidor (B2C) y de empresa a empresa (B2B). Como comenté en el prefacio, es importante comprender que existen claras diferencias en la forma de enfocar la arquitectura para estos dos modelos. La escala del B2C, por ejemplo, requerirá a menudo estrategias muy especializadas que puedan adaptarse al perfil de la carga de trabajo y a los modelos de costes de estos entornos. Al mismo tiempo, a nivel conceptual, muchos de los temas y mecanismos tratados aquí podrían aplicarse a los entornos B2C y BCB. No intentaré destacar todos los casos en los que estos modelos podrían requerir enfoques diferentes. Aquí hay demasiadas variables como para hacer afirmaciones absolutas sobre lo que sirve para B2C y lo que sirve para B2B. Así que, para el alcance de este libro, reconozcamos que ser B2C o B2B puede influir ciertamente en el modelo arquitectónico general de tu solución.

Definición de SaaS

He dedicado la mayor parte de este capítulo a aportar más claridad a los límites, el alcance y la naturaleza de lo que significa ser SaaS. Parece justo tomar toda la información que hemos tratado aquí e intentar ofrecer una definición explícita de SaaS que, idealmente, incorpore los conceptos y principios que hemos tratado. Ésta es la definición que creo que resume mejor la visión del SaaS que utilizaré a lo largo del resto de este libro:

SaaS es un modelo de negocio y de entrega de software que permite a las organizaciones ofrecer sus soluciones en un modelo de baja fricción, centrado en el servicio, que maximiza el valor para clientes y proveedores. Se basa en la agilidad y la eficiencia operativa como pilares de una estrategia empresarial que promueve el crecimiento, el alcance y la innovación.

Verás que esta definición se ciñe al tema de que el SaaS es un modelo de negocio. No menciona ninguna tecnología ni consideraciones de arquitectura. Tu trabajo como arquitecto y constructor de SaaS es crear los patrones y estrategias subyacentes que permitan a la empresa alcanzar sus objetivos. Aunque parezca el trabajo de cualquier arquitecto, debe quedar claro que la mezcla única de exigencias empresariales y tecnológicas de los entornos SaaS se infundirá directamente en el diseño, la arquitectura y la implementación de tu solución SaaS.

Conclusión

Este capítulo trataba de establecer los elementos fundamentales de la mentalidad SaaS, proporcionándote un conjunto básico de conceptos y términos que serán fundamentales a medida que profundicemos en los patrones y estrategias de la arquitectura SaaS. Una parte clave de nuestro debate se centró en comprender los objetivos fundamentales del SaaS, destacando los elementos clave que han motivado a tantas organizaciones a adoptar un modelo de entrega SaaS. Esto nos obligó a examinar más de cerca los modelos clásicos de entrega de software, destacando algunos de los retos tradicionales asociados a estos modelos. A continuación, pasé a explorar cómo se utiliza el SaaS para superar estos retos, proporcionando eficiencias, economías de escala y agilidad que pueden permitir mayores niveles de crecimiento e innovación. Un punto clave es que los arquitectos y constructores de SaaS no pueden centrarse sólo en crear una aplicación SaaS sólida: también deben pensar en cómo su solución resolverá los objetivos operativos, de agilidad y eficiencia más amplios de la organización.

Gran parte de este capítulo también se centró en alinear algunos conceptos básicos. Introduje la idea de los inquilinos, destacando algunos de los matices clave con la creación de entornos en los que la infraestructura puede consumirse en un modelo compartido. Nuestro debate sobre la infraestructura compartida también puso de relieve algunas de las diferencias clave entre el SaaS y los modelos tradicionales instalados por cliente. En el centro de este tema estaba la idea de crear una experiencia unificada que te permitiera gestionar, implementar y operar colectivamente tus inquilinos SaaS.

También era esencial crear límites más claros en torno a lo que es SaaS y lo que no lo es (al menos en el ámbito de este libro). Aquí es donde empecé a analizar la multitenencia y el bagaje histórico que conlleva este término. El objetivo era crear una nueva visión de la multitenencia que tuviera en cuenta el SaaS y se alejara de la idea estrecha y centrada en la infraestructura de la multitenencia. Revisé una serie de estrategias de implementación de SaaS para poner de manifiesto la necesidad de una definición más amplia de multitenencia que no estuviera relacionada con el hecho de compartir infraestructura. Tener claro cuándo y cómo se utiliza el término multiinquilino es fundamental para hablar de SaaS y describir las arquitecturas SaaS.

Por último, hacia el final del capítulo, empecé a intentar afinar más los límites del SaaS. Me fijé en el modelo MSP, por ejemplo, y repasé algunos de los factores clave que separan los modelos MSP y SaaS. También examiné algunos de los principios básicos que, en mi opinión, deberían aplicarse a la hora de dar forma a la visión para crear una organización y una oferta de SaaS. Esto incluía revisar algunas de las diferencias clave asociadas a la creación de un servicio (en lugar de un producto).

Esperamos que este capítulo te haya proporcionado una idea más clara de cómo veremos el SaaS a lo largo del libro. La alineación con estos principios nos permitirá avanzar por conceptos adicionales más concretos con una visión común de las fuerzas que dan forma y guían nuestras elecciones arquitectónicas. Idealmente, también eliminará parte de la confusión que, históricamente, ha rodeado a este tema.

Ahora que ya tenemos estos principios básicos de la mentalidad SaaS, podemos empezar a pensar en cómo estos principios se corresponden con patrones y construcciones arquitectónicas más específicos. En el próximo capítulo, haré un recorrido de principio a fin por todos los mecanismos y estrategias clave de la arquitectura SaaS, sin entrar en los detalles específicos de ninguna solución o pila tecnológica. Esto expondrá una gama completa de las consideraciones que deben formar parte de la definición de cualquier arquitectura SaaS. Definir el contexto del inquilino, debatir qué servicios y capacidades comunes necesitamos, explicar la partición de datos... todo esto forma parte de una lista mucho más larga de perspectivas más detalladas que iremos cubriendo. El objetivo de este capítulo es repasar muchas de las construcciones de alto nivel de la arquitectura SaaS, explicando su función, sus matices y dónde encajan en el panorama general de la arquitectura SaaS .