Capítulo 4. Incorporación e identidad

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Ahora que ya tienes una idea de la terminología y el panorama multiinquilino en general, veamos qué significa dar vida a estos conceptos en una solución operativa. La pregunta es: ¿por dónde empezar? Muchos equipos me hacen esta pregunta. Afortunadamente, es un área en la que creo que hay una respuesta bastante uniforme. Tanto si se trata de una migración como de un proyecto totalmente nuevo, yo siempre señalaría la incorporación, la identidad y el plano de control como el punto de partida para construir la mayoría de las arquitecturas multiinquilino. Cada uno de estos elementos fuerza construcciones importantes y fundacionales en tu entorno, definiendo cómo se introducirán los inquilinos y cómo se crearán y vincularán los usuarios a los inquilinos. Estos primeros pasos comenzarán a establecer los bloques de construcción de nuestro plano de control.

Empezando por aquí, pondrás la tenencia en primer plano. Esto significa que todas las capas de tu arquitectura están ahora obligadas a ser conscientes de la tenencia múltiple. Cada componente de tu sistema tendrá que tener en cuenta cómo la tenencia puede influir en su diseño e implementación. Aunque esto pueda parecer un matiz sutil, su impacto es bastante profundo. La mera presencia de la tenencia afecta a la forma de aislar a los inquilinos, de representar sus datos, de dar soporte a múltiples personas, de facturar a los inquilinos y a muchos otros aspectos de tu solución. También empieza a establecer el límite claro entre los planos de control y de aplicación. El objetivo es evitar caer en la trampa de empezar por la aplicación y añadir la tenencia a posteriori. Esto nunca funciona bien y suele conducir a refactorizaciones y compromisos significativos que socavan el diseño de tu arquitectura SaaS.

Empezaré el capítulo analizando lo que se necesita para poner en marcha los aspectos básicos de nuestro plano de control. Aquí veremos el aprovisionamiento de la infraestructura y los recursos necesarios para alojar los distintos servicios que se utilizarán para gestionar y hacer funcionar tu arquitectura SaaS. Aunque, en última instancia, este plano de control albergará muchos servicios, este capítulo se centrará principalmente en la incorporación y la funcionalidad de identidad. Luego, más adelante, podremos ver cómo construimos más aspectos del plano de control.

A medida que profundicemos en la incorporación, tendrás una idea mucho más clara de todas las partes móviles que forman parte de este proceso. Para algunos entornos, la orquestación de este proceso puede ser bastante compleja. Aunque la naturaleza de la incorporación puede variar en cada entorno SaaS, hay algunos temas comunes que abarcan muchas implantaciones. Profundizaré en algunos de estos temas mientras te guío a través de un ejemplo de flujo de incorporación. Esto debería sacar a la luz algunas de las consideraciones necesarias para crear tu propio servicio de incorporación. También debería poner de relieve el papel fundamental que desempeña el onboarding dentro de tu arquitectura SaaS.

La siguiente área que revisaré es la identidad. Profundizaré en los detalles de cómo vinculamos usuarios individuales a inquilinos para llegar a la noción de contexto de inquilino que se trató en el Capítulo 1. Esto incluirá profundizar en los mecanismos de identidad específicos que nos permiten dar forma a cómo se autentican los inquilinos, inyectando contexto de inquilino en las solicitudes que fluyen a través de todos los servicios backend de tu aplicación SaaS. Veremos cómo este contexto acaba dando forma e influyendo en la forma en que los equipos construyen y gestionan las características multiarrendatario de su arquitectura SaaS.

El examen conjunto de todos estos conceptos fundamentales debería darte una visión más clara de lo esencial que es abordar estos conceptos desde el principio. El objetivo es exponerte las estrategias, pautas y consideraciones clave sin acercarte demasiado a los detalles específicos de ninguna tecnología. Comprender estos conceptos básicos te dotará de las ideas que darán forma a tu forma de abordar muchos de los temas de multiinquilino que trataremos en los capítulos siguientes.

Crear un entorno de referencia

Para empezar este viaje, quiero abordar la incorporación y la identidad como si partiéramos de cero. Esto te dará una idea más clara de cómo puedes plantearte la aplicación de estas estrategias desde cero. Eso significa que tenemos que dar un paso atrás en los aspectos específicos de la incorporación y la identidad y pensar primero en las piezas fundamentales que tenemos que poner en marcha antes de poder empezar a incorporar inquilinos. Los servicios que apoyan la incorporación se ejecutan dentro del plano de control, así que tenemos que empezar por colocar todas las piezas necesarias para ejecutar todos los microservicios del plano de control que apoyan la incorporación y la identidad.

La creación de la infraestructura, sus recursos dependientes y el plano de control es lo que yo denomino crear un entorno base. Esencialmente, necesitamos crear los scripts y la automatización que nos permitirán poner en marcha todas las construcciones necesarias para alojar nuestro entorno SaaS. Aunque nuestro objetivo es poner en marcha la integración y la identidad, el alcance del entorno base incluye todos los recursos que se aprovisionarían una sola vez para configurar nuestro entorno multiinquilino antes de empezar la integración. Esto significa que configuraremos algunos recursos que van más allá del ámbito de la incorporación de inquilinos y la identidad. No nos centraremos ahora en esos otros aspectos, pero es importante tener en cuenta que un entorno base incluye todos estos conceptos.

La creación real de nuestro entorno base se consigue mediante un modelo DevOps clásico, utilizando herramientas de automatización de infraestructuras para crear, configurar e implementar todos los activos que requiere nuestro entorno base. La Figura 4-1 ofrece una visión muy conceptualizada de esta experiencia.

La idea básica es que elijas la(s) herramienta(s) DevOps que se adapte(n) a tu entorno y crees un único modelo de automatización repetible que pueda configurar todo lo necesario para que tu entorno pase a un estado en el que pueda empezar a incorporar inquilinos.

Por supuesto, lo que hay realmente en tu entorno de referencia variará enormemente en función de la naturaleza de la pila tecnológica específica que utilices para tu solución SaaS. Una pila Kubernetes, por ejemplo, podría ser muy diferente de una pila sin servidor. Los matices de los distintos proveedores de la nube también influirían en el proceso de aprovisionamiento. Examinaremos ejemplos más concretos para ver cómo encajan, pero por ahora queremos subir un nivel y centrarnos en lo que hay que aprovisionar en este paso para preparar nuestro sistema para empezar a incorporar inquilinos.

Crear tu entorno base

Para tener una idea más clara de , veamos una muestra de lo que podría aprovisionarse, configurarse e implementarse para dar vida a tu entorno base. En la Figura 4-2 verás que he reunido una vista conceptual de los componentes y la infraestructura que podrían crearse en un entorno base. El objetivo era representar algunos de los conceptos básicos de la infraestructura de línea de base sin perderse demasiado en los detalles de ninguna tecnología concreta.

En el centro de la Figura 4-2, verás que he creado la infraestructura de red básica necesaria para alojar mi entorno SaaS multiinquilino. Para este ejemplo, sólo he tomado algunas construcciones de red comunes de AWS (una VPC, zonas de disponibilidad y algunas subredes) para representar la red de alta disponibilidad que albergará mi entorno SaaS. Estas mismas construcciones de red podrían asignarse a cualquier número de tecnologías diferentes. La clave en esta fase es centrarse en el hecho de que la configuración de este entorno de referencia requerirá que aprovisiones y configures todas las construcciones de red básicas que utilizará tu plano de control y, potencialmente, tus inquilinos.

Dentro de esta red, también he mostrado la implementación del plano de control. Como el plano de control es compartido por todos los inquilinos, puede configurarse e implementarse como parte del aprovisionamiento de tu entorno base. El plano de control también debe estar en su sitio para que podamos empezar a dar de alta a los inquilinos y establecer su identidad. Aquí, para simplificar las cosas, he incluido una muestra de algunos servicios. En realidad, la lista de servicios del plano de control incluiría una gama mucho más amplia. Veremos esos servicios con más detalle cuando empecemos a profundizar en soluciones más concretas.

En la parte inferior derecha de la Figura 4-2, también verás una colección de recursos agrupados. Los elementos que aparecen aquí representan los marcadores de posición conceptuales para cualquier recurso que puedan compartir los inquilinos. Generalmente, si tienes recursos agrupados que serán compartidos por todos los inquilinos, puedes aprovisionarlos durante la configuración de tu entorno base (ya que no será necesario crearlos durante el proceso de incorporación). El almacenamiento suele ser un buen ejemplo. Imagina que tienes una base de datos mancomunada para algún microservicio de tu solución. Si está agrupada, podría crearse cuando se aprovisione el entorno base. También verás la configuración de una construcción de identidad compartida y una cola de mensajes agrupada. Una vez más, esto es sólo para resaltar el hecho de que querrás considerar si deben aprovisionarse durante la configuración de tu entorno base. Hablaré de algunas de las ventajas y desventajas cuando profundicemos en la experiencia de incorporación de inquilinos más adelante en este capítulo.

Por último, en la parte superior derecha, he mostrado marcadores de posición para la identidad del administrador del sistema y la consola de administración. Esto representa a los usuarios que inician sesión en las herramientas específicas que has creado para dar soporte, actualizar, configurar y, en general, gestionar el estado de tu arquitectura multiinquilino. Me refiero a estas herramientas específicas como tu consola de administración del sistema. Es esta consola la que sirve como único plano de cristal para tu entorno SaaS, proporcionando a tu equipo una colección de funciones y capacidades creadas específicamente que son esenciales para el funcionamiento de tu entorno multiinquilino; se utilizará en combinación con otras soluciones estándar que proporcionan una funcionalidad más generalizada. Incluso con estas otras herramientas, la mayoría de los equipos de SaaS necesitan su propia aplicación de administración personalizada que pueda abordar las necesidades multiusuario específicas de su entorno.

La Figura 4-3 muestra una instantánea de una sencilla aplicación de consola de administración SaaS para ayudar a concretar este concepto. A través de esta aplicación tendrás acceso a toda la información básica sobre tu solución SaaS. Podrás monitorizar el estado de incorporación de los inquilinos, activar y desactivar inquilinos, gestionar las políticas de los inquilinos, ver las métricas de los inquilinos y de los niveles, y cualquier otra funcionalidad necesaria para gestionar y hacer funcionar tu solución SaaS. Esta aplicación debe configurarse e implementarse como parte de la configuración de tu entorno base.

Merece la pena señalar que algunos equipos tienden a invertir poco en sus consolas de administración, recurriendo a soluciones prefabricadas en lugar de construir algo ellos mismos. En general, esta compensación rara vez parece merecer la pena. Aunque puedas utilizar soluciones de terceros para componer una experiencia de consola, hay operaciones, conocimientos y opciones de configuración específicos que sólo pueden abordarse eficazmente mediante la creación de una experiencia específica.

Crear y gestionar identidades de administrador del sistema

Como parte de la configuración de tu entorno base y de la configuración de tu aplicación de administración, verás que tu proceso de aprovisionamiento también debe configurar tu modelo de identidad de administrador del sistema. Cada vez que actives la creación de un entorno base, se te pedirá que proporciones el perfil del usuario administrativo inicial que podrá iniciar sesión en tu consola de administración. La creación de esta identidad es totalmente independiente de la creación de una identidad de inquilino. Esto también significa que tendrás que tener una experiencia de autenticación completamente independiente para permitir que estos usuarios administradores del sistema accedan a la consola de administración o a cualquier herramienta de línea de comandos que puedas estar utilizando para gestionar tu entorno multiarrendamiento.

Para soportar esta identidad de administrador del sistema, necesitarás tener algún proveedor de identidades que posea y autentique a estos usuarios. El proveedor de identidades que utilices aquí podría ser el mismo proveedor de identidades que se utilizará para las identidades de tus inquilinos. O podría ser un proveedor de identidades independiente que se utilice como parte de una estrategia de administración empresarial más global. Independientemente del proveedor de identidad que utilices, la mecánica básica de la introducción de una identidad de administrador del sistema va a ser muy similar.

La conclusión clave es que necesitarás algunos pasos en tu automatización de aprovisionamiento inicial para crear y configurar tu modelo de identidad de administración del sistema. Esta automatización incluirá la creación y configuración del proveedor de identidades junto con la creación de los usuarios iniciales de administración del sistema. Una vez configurado ese usuario, deberías poder utilizar esta identidad para acceder a tu consola de administración del sistema. Una vez que hayas accedido a la consola de administración del sistema, podrás gestionar y crear más usuarios de administración del sistema.

Resulta que el ejemplo de la Figura 4-3 muestra una vista de la gestión de usuarios administradores del sistema. Aquí, he accedido y me he autentificado en la consola después de aprovisionar mi entorno. Ahora puedo utilizar esta misma página para crear y gestionar otros usuarios administradores del sistema.

Activar la Incorporación desde la Consola de Administración

Una vez que has establecido tu usuario administrador del sistema y tienes tu consola de administración en funcionamiento, tienes todas las piezas en su sitio para crear e incorporar inquilinos. Ahora, en la versión final de tu oferta, tu incorporación podría invocarse como parte de alguna experiencia de autoservicio, o podría estar dirigida por algún proceso interno. Obviamente, si se trata de un proceso interno, querrás utilizar la consola de administración del sistema para gestionar la incorporación. Esto significaría tener alguna operación dentro de tu consola que recoja todos los datos necesarios para un nuevo inquilino antes de invocar la operación de incorporación.

Algunos equipos encuentran mucho valor en poder incorporar inquilinos desde la consola de administración del sistema. Incluso si la incorporación se convirtiera finalmente en un modelo de autoservicio, podrías seguir teniendo la posibilidad de probar y validar tu experiencia de incorporación desde la consola de administración. Esto puede ser especialmente útil para los equipos que están validando y probando la experiencia de incorporación de tu aplicación.

Opciones de aprovisionamiento del plano de control

En la Figura 4-2, mostré el plano de control desplegado en la misma infraestructura de línea de base , donde también aterrizarían tus inquilinos. Ésta es una opción perfectamente válida. Sin embargo, vale la pena señalar que cómo y dónde se coloca este plano de control puede variar en función de las necesidades de tu entorno y de la pila tecnológica que se utilice para tu arquitectura multiinquilino. En Kubernetes, por ejemplo, podría tener un espacio de nombres separado para el plano de control, colocando mis entornos de inquilinos junto al plano de control dentro del mismo clúster e infraestructura de red. También podría optar por aterrizar el plano de control en una infraestructura completamente separada y dedicada al plano de control.

La Figura 4-4 ofrece una vista conceptual de estas dos opciones. A la izquierda, verás el modelo de plano de control compartido, en el que el plano de control se implementa en el mismo entorno que la infraestructura de tu inquilino. Y, a la derecha, verás un enfoque en el que el plano de control tiene su propio entorno dedicado. Aquí los inquilinos se ejecutan en una red o clúster completamente separado que traza una línea más dura entre los planos de control y de aplicación.

Las ventajas y desventajas de estas dos opciones son bastante sencillas. Podrías elegir tener un entorno de plano de control dedicado si quieres escalar, gestionar y operar estos entornos de forma totalmente independiente. El cumplimiento también podría ser un factor aquí; esos requisitos o tu dominio podrían abordarse mejor colocando límites más fuertes entre tus planos de control y de aplicación. Por supuesto, colocar el plano de control en el mismo entorno que el plano de aplicación simplifica un poco las cosas. Reduce el número de piezas móviles que tienes que gestionar, configurar y aprovisionar. También puede reducir tu huella de costes. Si optas por el modelo dedicado, tendrás que decidir cómo vas a integrar estas construcciones separadas para permitir que el plano de control interactúe con tu plano de aplicación.

Tu elección de pila tecnológica también puede influir en cómo implementas tu plano de control. Algunos equipos, por ejemplo, pueden optar por diferentes pilas tecnológicas para los planos de control y de aplicación. Yo, por ejemplo, podría elegir serverless para el plano de control y contenedores para el plano de aplicación. Esto podría orientarte más hacia un modelo de plano de control dedicado.

La experiencia de incorporación

Ahora que nuestro entorno base está aprovisionado y configurado, podemos centrar nuestra atención en la incorporación de inquilinos. Es a través del onboarding como te darás cuenta de que estás estableciendo y ejercitando algunos de los elementos más fundamentales de una arquitectura multiinquilino. De hecho, cuando trabajo con clientes nuevos o que migran a SaaS, siempre les sugiero que centren su atención inicial en el proceso de incorporación.

Empezar aquí obliga a los equipos a responder a muchas de las preguntas difíciles que influirán y darán forma al resto de su arquitectura SaaS. La incorporación no consiste sólo en crear un inquilino. Se trata de crear y configurar todas las partes móviles de tu infraestructura necesarias para dar soporte a ese nuevo inquilino. En algunos casos, eso puede ser un ejercicio ligero y, en otros, puede requerir una cantidad significativa de código para orquestar cada paso del proceso de incorporación. Cómo se clasifican tus inquilinos por niveles, cómo se autentican, cómo se gestionan sus políticas, cómo se configura su aislamiento, cómo se enrutan... todas estas son áreas que se ven afectadas por la experiencia de incorporación de tu entorno multiinquilino.

La incorporación forma parte de tu servicio

Muchos equipos caen en la trampa de considerar la incorporación como algo que se atornilla al sistema una vez construido. Crean marcadores de posición y soluciones para simular la experiencia de incorporación con la idea de que pueden "hacerla realidad" más adelante en el proceso. Esto nos remite al debate de comparar un servicio con un producto. En un entorno SaaS, la incorporación no se ve como un guión o una automatización que de alguna manera está fuera del alcance de tu oferta. Por el contrario, es uno de los componentes más fundamentales de tu experiencia SaaS y hacerlo bien debería ser clave para cualquier equipo que esté construyendo una solución multi-tenant.

La incorporación se sitúa justo en medio de tus prioridades empresariales y técnicas. La experiencia que cada cliente tenga con la incorporación puede tener un profundo impacto en el éxito general de la empresa. Lo fluido, eficiente y fiable que sea este proceso tendrá un impacto directo en la experiencia y percepción de los clientes que consumen tu producto. Es tu oportunidad de causar una primera impresión positiva. La experiencia de incorporación también está directamente relacionada con la noción de tiempo de obtención de valor, que se refiere al tiempo que tarda un cliente en pasar de la inscripción a la productividad real y el valor de tu oferta de SaaS. Cualquier fricción añadida que aparezca aquí va a afectar a la impresión que causes como servicio y podría, potencialmente, influir en tu capacidad de hacer que los clientes pasen de adoptantes a promotores.

La incorporación también es el momento en que se ponen en marcha las estrategias de implementación, identidad, enrutamiento y organización en niveles. Por ejemplo, la forma en que los inquilinos se dividen en silos y se agrupan, tendrá que expresarse y realizarse directamente a través de tu experiencia de incorporación. Cómo y dónde autentificas a los inquilinos se configurará y aplicará como parte de la incorporación. El modo en que tus inquilinos se dirigen contextualmente en función de su nivel y modelo de implementación se configurará dentro del ámbito de la incorporación. Muchas de estas opciones clave de diseño multi-arrendatario que tomas en tu arquitectura SaaS se expresan y cobran vida en última instancia a través del proceso de incorporación de tu sistema. En muchos aspectos, tu código de configuración, automatización e implementación del onboarding estará en el epicentro de la realización de las estrategias multiinquilino que adoptes para tu entorno SaaS.

La cantidad de esfuerzo y código que conlleva la automatización de la incorporación puede sorprender a algunos equipos. No es infrecuente que los equipos de SaaS subestimen el nivel de esfuerzo e inversión que conlleva crear una sólida experiencia de incorporación. En realidad, el onboarding representa uno de los elementos más fundamentales de un entorno multi-tenant. Es a través del onboarding como puedes alcanzar los objetivos operativos y de agilidad que son esenciales para un negocio SaaS.

Autoservicio frente a incorporación interna

Hasta ahora, puede parecer que este debate sobre el onboarding está describiendo principalmente mecanismos que se utilizan por organizaciones que se basan en una experiencia de registro de inquilinos de autoservicio. Muchos de nosotros nos hemos inscrito en innumerables ofertas de SaaS B2C en las que rellenamos algún formulario, enviamos nuestra información y empezamos a utilizar algún servicio de SaaS. Aunque este modo clásico de incorporación está dentro de nuestro alcance, también debemos considerar escenarios en los que nuestro proceso de incorporación no admita un modelo de autoservicio. Imagina, por ejemplo, algún proveedor de SaaS B2B que sólo se incorpora después de que hayas llegado a un acuerdo y aceptado incorporarlo a tu sistema. Es posible que estos proveedores de SaaS sólo tengan cierta experiencia en incorporación gestionada internamente.

Lo que quiero decir es que la incorporación no está vinculada a una experiencia concreta. Puedes tener un onboarding de autoservicio o puedes utilizar un onboarding interno. Cada solución SaaS, independientemente de cómo presente su experiencia de incorporación, debe seguir apoyándose en el mismo conjunto de valores. Para mí, el listón de los procesos de incorporación de autoservicio y de gestión interna es el mismo. Ambos enfoques deben crear un proceso de incorporación totalmente automatizado, repetible y de baja fricción que se centre en maximizar el tiempo de obtención de valor del cliente. Sí, puede que alguien de operaciones dirija tu proceso interno. Sin embargo, esto no significa que esperes menos automatización, escala o durabilidad de ese proceso de incorporación.

Para cualquier sistema SaaS que construya, quiero estar seguro de que estoy tratando esta experiencia de incorporación como una parte clave de mi sistema. Es el centro para asegurarme de que tengo un mecanismo de incorporación automatizado, repetible y coherente que garantice que cada nuevo inquilino se introducirá sin necesidad de procesos manuales ni configuraciones puntuales.

Las partes fundamentales de la incorporación

Ahora que tienes una idea más clara de la importancia de la incorporación, vamos a centrarnos más en los detalles de los componentes subyacentes de una experiencia de incorporación. Aunque hay muchos detalles en la implementación del proceso de incorporación, mi objetivo en este momento es darte una visión de alto nivel de los componentes básicos de este proceso y esbozar los principios rectores que suelen dar forma a esta experiencia.

La Figura 4-5 ofrece una visión conceptual de las partes móviles de una experiencia de incorporación multiusuario.

A la izquierda verás en la ilustración de los dos patrones habituales que podrían utilizarse para impulsar un proceso de incorporación. En primer lugar, he mostrado un administrador de inquilinos que se incorpora a través de algún proceso de registro de autoservicio, presumiblemente una aplicación web que permite al inquilino enviar su información, seleccionar un plan y proporcionar cualquier información de configuración necesaria para establecerse como nuevo inquilino en el sistema. También he mostrado un segundo flujo de incorporación que, en este ejemplo, lo inicia un administrador del sistema. Esto representa algún rol interno en el proveedor de SaaS que utiliza una consola de administración (o alguna otra herramienta) para introducir los datos de incorporación de un nuevo inquilino y activar el proceso de incorporación. En este ejemplo, he incluido ambas vías de incorporación. Sin embargo, en la mayoría de los casos, una organización SaaS admitirá uno de estos dos enfoques. Sólo las he mostrado aquí para que quede clara la idea de que la incorporación, independientemente de su punto de entrada, debe ser un proceso totalmente automatizado para cualquiera de estos dos casos de uso.

Para estas rutas de incorporación, verás que ambas envían una solicitud de incorporación al servicio de Incorporación (paso 1). Para la incorporación, generalmente prefiero tener un único servicio de incorporación que pueda encargarse de toda la orquestación de la incorporación. Este servicio es el propietario de todo el ciclo de vida del proceso de incorporación, gestionando y garantizando que todos los pasos del proceso se completan con éxito. Esto es especialmente importante porque algunos aspectos del onboarding pueden ejecutarse de forma asíncrona o depender de integraciones de terceros que podrían tener problemas de disponibilidad.

A continuación, el proceso de incorporación llama a una serie de servicios distribuidos que se utilizan para crear y configurar los ajustes del inquilino y la infraestructura de apoyo. La secuencia de este flujo de incorporación puede variar en función de la naturaleza de tu aplicación SaaS. En general, el objetivo es crear y configurar todos los activos del inquilino necesarios antes de activar el inquilino y/o notificar al usuario administrador del inquilino que su cuenta está activa.

Aunque hay múltiples formas de implementar este flujo de incorporación, tendrás que empezar por crear un identificador de inquilino . En nuestro ejemplo, este identificador de inquilino se creará enviando una solicitud de creación de inquilino a , el servicio de Gestión de Inquilinos (paso 2), pasando toda la información sobre nuestro inquilino (nombre de la empresa, configuración de identidad, nivel, etc.). También generará el identificador único que se asociará a nuestro inquilino. Los equipos suelen utilizar un identificador único global (GUID) como valor para su identificador de inquilino, evitando incluir cualquier atributo que pueda estar relacionado con el nombre u otra información identificativa del inquilino. Esto impide que nadie pueda relacionar un inquilino con un identificador determinado. Este inquilino también se crea con alguna noción de estado "activo" que gestiona el estado actual de un inquilino. En este caso, en el que estamos incorporando, el estado activo se establecerá inicialmente en falso. Una vez que el sistema cree este inquilino, tendrás un identificador de inquilino que podrás utilizar en el resto de la experiencia de incorporación. Entraré en más detalles sobre el servicio de Gestión de Inquilinos y su papel dentro del plano de control en el Capítulo 5.

El siguiente paso en nuestro ejemplo de incorporación de inquilinos consistirá en el aprovisionamiento de los recursos del inquilino que sean necesarios (paso 3). Este paso de aprovisionamiento puede representar, para algunas arquitecturas multiarrendatario, una de las piezas más significativas de tu implementación de incorporación. Para una implementación de silo de pila completa, por ejemplo, esto podría significar el aprovisionamiento de una colección completamente nueva de servicios de infraestructura y aplicaciones. En cambio, un entorno de pool de pila completa podría requerir un aprovisionamiento y una configuración mínimos de la infraestructura.

A medida que profundicemos en más ejemplos prácticos, puede que te sorprenda descubrir cuánto código y automatización se dedican a esta experiencia de incorporación. De hecho, ésta suele ser un área en la que los sistemas SaaS desdibujan los límites de DevOps. Mientras que, en los entornos tradicionales, gran parte del ciclo de vida DevOps se centra en el aprovisionamiento y la actualización de tu infraestructura de base, los entornos SaaS pueden depender de la ejecución de código DevOps durante la incorporación de cada inquilino individual. Tu sistema puede estar aprovisionando y configurando nueva infraestructura en tiempo de ejecución para procesar la creación de una infraestructura de inquilino en silos. Como puedes imaginar, esto conlleva nuevas consideraciones y mentalidades sobre cómo organizar y construir la huella general de DevOps de tu solución multiarrendatario. Para algunos, esto representa una nueva mentalidad y nuevos enfoques de las herramientas utilizadas para aprovisionar entornos de inquilinos.

En esta fase, tenemos un inquilino creado y nuestros recursos de inquilino están aprovisionados. Ahora podemos añadir este nuevo inquilino al sistema de facturación (paso 4). Aquí es esencialmente donde proporcionarás información al sistema de facturación que identifique al nuevo inquilino y cualquier información que sea necesaria para caracterizar el modelo de facturación que debe aplicarse a este inquilino en particular. Se supone que, antes de dar de alta a un nuevo arrendatario, has configurado y establecido los distintos niveles o planes de facturación que determinan el modelo de precios general de tu solución. Entonces, durante la incorporación, tu servicio de Facturación correlacionará el perfil de incorporación del inquilino con el plan de facturación apropiado (preconfigurado).

Observarás que la Figura 4-5 menciona un proveedor de facturación independiente. La idea es que tu servicio de facturación gestione y orqueste cualquier integración que puedas tener con tu sistema de facturación. En muchos casos, este proveedor de facturación puede estar respaldado por un sistema de terceros. Es en estos casos cuando puedes ver el valor de poner un servicio de Facturación separado entre tu proceso de incorporación y el proveedor de facturación, permitiéndote gestionar cualquier consideración única que pueda ser necesaria para dar soporte a un proveedor de facturación determinado. En otros casos, podrías integrarte directamente con el proveedor de facturación desde tu servicio de Onboarding. También hay que tener en cuenta que algunas empresas de SaaS utilizan un sistema de facturación interno. Incluso en este caso, querrás que tu proceso de incorporación siga un patrón de integración similar. Hay mucho más que considerar sobre la facturación (fuera del ámbito de la incorporación). Entraré más en detalle en el Capítulo 14.

Para la pieza final de la experiencia de incorporación a , tenemos que crear el usuario administrador del inquilino (paso 5). Si recuerdas, el rol de administrador del inquilino representa el primer usuario que se crea para un inquilino determinado. Este inquilino tendrá la capacidad de crear usuarios adicionales que podrán acceder al sistema. En esta fase, sin embargo, nuestro objetivo principal es crear este usuario inicial dentro de nuestro proveedor de identidad para permitir a nuestro inquilino autenticarse y acceder a su entorno aprovisionado. Aquí, tendrás que confiar en las funciones de tu proveedor de identidad para orquestar la notificación y validación de este nuevo inquilino. La mayoría de los proveedores de identidad admitirán la generación de un mensaje de correo electrónico que incluya una URL y una contraseña temporal para acceder al sistema. Este proceso hace que el usuario autenticado introduzca una nueva contraseña como parte del flujo de inicio de sesión. El objetivo es trasladar gran parte de la automatización de este proceso de registro a tu proveedor de identidad. Confía en estos proveedores para que envíen invitaciones por correo electrónico y contraseñas temporales y gestionen los restablecimientos de contraseña.

Hay una última parte de este flujo de incorporación que deberás tener en cuenta. Antes, cuando se creó el inquilino (paso 2), establecí el estado activo del inquilino en falso. Es tarea de tu servicio de Onboarding hacer un seguimiento del estado de todos estos diferentes estados de onboarding. Sólo cuando determine que cada proceso se ha completado con éxito, establecerá el estado activo del inquilino en verdadero. Esto puede incluir reintentos del proceso y otras estrategias de emergencia para solucionar cualquier fallo que pueda haber ocurrido durante el aprovisionamiento y la configuración del entorno del inquilino. Suponiendo que la incorporación tenga éxito, el servicio de Incorporación puede ahora llamar al servicio de Gestión de Inquilinos y actualizar el estado activo a verdadero. Esto es especialmente importante para la consola de administración de tu entorno SaaS, que proporciona la funcionalidad que se utiliza para ver y gestionar el estado de los inquilinos. Durante este proceso de incorporación, la vista de inquilinos debe mostrar el estado de cualquier inquilino que se esté incorporando y resaltar el estado activo de tus inquilinos.

Rastrear y sacar a la superficie los estados de embarque

Viendo este proceso, debería estar claro que tu proceso de incorporación incluye muchas partes móviles y dependencias. Cuanto más complejo sea este proceso, más importante es disponer de información operativa útil y detallada sobre los distintos estados de tu flujo de incorporación. Esto es esencial para analizar el progreso, identificar problemas y perfilar el comportamiento general y las tendencias de tu automatización del proceso de incorporación. También significa identificar el diseño y las herramientas adecuadas para capturar y visualizar eficazmente el perfil de incorporación de tu solución.

Como mínimo, podrías imaginar tener un conjunto distinto de estados asignados a cada uno de los pasos de nuestro flujo de incorporación. Así, podrías tener estados distintos para TENANT_CRE⁠ATED, TENANT_PROVISIONED, BILLING_INITIALIZED, USER_CREATED, y TENANT_ACTIVATED. Cada uno de estos estados podría mostrarse a través de la vista del inquilino en tu consola de administración, lo que te permitiría inspeccionar la incorporación de cualquier inquilino en un momento dado.

El valor real de asignar y mostrar estados de incorporación es proporcionar una visión operativa más rica del estado de tu progreso de incorporación. Esto será esencial para solucionar cualquier problema de incorporación inesperado. Saber con precisión dónde está fallando tu proceso de incorporación es de vital importancia para tus equipos operativos. Esto es especialmente importante cuando tu proceso de incorporación incluye una cantidad significativa de aprovisionamiento y configuración de la infraestructura. En estos casos, podrías hacer un seguimiento de estados más granulares que te den una idea de las distintas etapas que hay dentro de las partes móviles de tu proceso de aprovisionamiento.

Incorporación por niveles

Como parte del análisis del flujo de incorporación, describí el papel del servicio de Aprovisionamiento y su función en la creación y configuración de entornos de inquilinos. Este proceso de aprovisionamiento se vuelve un poco más interesante cuando consideras cómo los distintos niveles de inquilino podrían influir en la forma de implementar tu ciclo de vida de aprovisionamiento. Si recuerdas, utilizamos los niveles para ofrecer a los distintos perfiles de inquilino experiencias diferentes. Estas experiencias diferentes a menudo se traducen en una necesidad de infraestructura y configuraciones separadas en función del nivel de tu sistema.

Para entenderlo mejor, veamos un ejemplo conceptual de incorporación por niveles. La Figura 4-6 muestra un entorno que admite dos niveles distintos (básico y premium).

He reducido la vista para centrar exclusivamente en el servicio de Aprovisionamiento dentro de nuestro plano de control. Cada vez que el servicio Onboarding activa este servicio de Aprovisionamiento, proporciona al inquilino información contextual que incluye el nivel que se asociará al nuevo inquilino. Cuando el servicio de Aprovisionamiento reciba esta solicitud, evaluará el nivel y determinará cómo influirá el nivel seleccionado en la configuración y la infraestructura que serán necesarias para dar soporte al entorno del inquilino. En este ejemplo, nuestra solución SaaS ofrece a los inquilinos de nivel premium un modo de implementación en silo de pila completa con recursos totalmente dedicados para cada inquilino. Esto significa que cada evento de incorporación tendrá que automatizar el aprovisionamiento de estas pilas completas de inquilinos. Los inquilinos de nivel básico, sin embargo, se incorporan a un modelo de pool de pila completa en el que toda la infraestructura es compartida por los inquilinos. En este caso, la incorporación será una experiencia más ligera, simplemente aumentando la configuración para añadir compatibilidad con este nuevo inquilino.

Estos modelos de implementación de pila completa tienen experiencias de incorporación bastante distintas que son relativamente fáciles de digerir. Donde esto se pone más interesante es cuando tienes un modelo de implementación mixto. Con una implementación de modo mixto, tus recursos se dividen en silos y se agrupan con una granularidad más fina. Esto significa que tu proceso de incorporación tendrá que aplicar las políticas de incorporación basadas en niveles a cada recurso en función de su configuración de silo o pool. La Figura 4-7 muestra un ejemplo de cómo la implementación en modo mixto influye en tu proceso de aprovisionamiento.

He hecho intencionadamente esta arquitectura un poco recargada. Aquí se muestra nuestro mismo servicio de Aprovisionamiento, pero ahora tiene mucho más que considerar a medida que cada inquilino se incorpora. Empecemos por la izquierda de la Figura 4-7, donde verás que tengo dos servicios que se implementan por separado para el Inquilino 1 y el Inquilino 2. Por tanto, para cada inquilino de nivel superior, tu servicio de Aprovisionamiento tendrá que configurar e implementar los servicios de Cumplimiento y Pedido en un modelo totalmente aislado. El almacenamiento y el cálculo de estos dos microservicios están totalmente aislados.

Ahora bien, aunque estos dos microservicios se implementan por separado para los arrendatarios de nivel superior, estos mismos servicios también son consumidos por tus arrendatarios de nivel básico. Esto se representa en el centro del diagrama, donde he identificado versiones agrupadas de los microservicios Cumplimiento y Pedido que comparten todos los inquilinos de nivel no premium (en este caso, los inquilinos 3..N). Esto significa que el servicio de Aprovisionamiento debe realizar una única configuración e implementación de estos servicios para dar soporte a los inquilinos agrupados. Una vez que estos servicios estén en marcha, el trabajo del servicio de Aprovisionamiento de para cada nuevo inquilino requerirá menos piezas móviles. Puede que tengas que configurar el enrutamiento o establecer algunas políticas, pero la mayor parte del trabajo pesado se hará después del aprovisionamiento y la implementación iniciales de estos servicios.

Por último, en la parte derecha del entorno de la Figura 4-7, verás una serie de servicios que se implementan en distintos modelos para satisfacer las necesidades de los inquilinos de nivel básico y superior. Las opciones de silo y pool que elijas aquí se basan más en las necesidades universales de tu arquitectura multiinquilino (que en los niveles). La idea es que estás seleccionando opciones de silo y pool basadas en un conjunto de necesidades globales (vecino ruidoso, cumplimiento, etc.).

En este ejemplo, he creado intencionadamente algunas variaciones en estos servicios para resaltar los casos de uso que puedes necesitar apoyar como parte de la incorporación de inquilinos. El microservicio Producto, por ejemplo, utiliza computación en silo para todos los inquilinos; por eso verás una instancia separada del servicio para los inquilinos 1-3. Sin embargo, también verás que este mismo servicio utiliza almacenamiento agrupado. Esto añade una nueva arista a la historia del aprovisionamiento. Ahora, tu servicio de Aprovisionamiento debe gestionar esta variación, aprovisionando el almacenamiento una sola vez para todos los inquilinos, al tiempo que aprovisiona e implementa instancias separadas del microservicio Producto a medida que se incorpora cada inquilino.

Los otros servicios (Ratings y Cart) son sólo aquí para destacar patrones adicionales que podrías ver al implementar tu servicio de Aprovisionamiento. Ratings está totalmente agrupado para el cálculo y el almacenamiento, mientras que el microservicio Cart tiene cálculo agrupado y almacenamiento en silos. El apoyo a la incorporación de estos servicios consiste en saber qué está en silos y qué está agrupado, y en activar contextualmente la creación y configuración de estos recursos. Esto refleja el debate que mantuvimos (en el Capítulo 3) sobre la implementación en modo mixto. Sin embargo, aquí veremos cómo ese modo mixto puede influir en la experiencia de incorporación de tu entorno multiusuario.

A menudo surge una pregunta clave en torno al momento general de aprovisionar los recursos agrupados durante el proceso de incorporación a . Dado que estos recursos se configuran e implementan una vez, muchos prefieren preaprovisionarlos como parte de la configuración inicial de todo el entorno multiinquilino. Por tanto, si estás configurando un entorno base completamente nuevo, podrías optar por aprovisionar todos los recursos agrupados en ese momento. A mí me parece el enfoque más natural. Esto podría significar que tu servicio de Aprovisionamiento admitiría una ruta separada invocada por tus herramientas DevOps para realizar la creación única de estos recursos. Después, cuando cada nuevo inquilino se incorpore, esta infraestructura compartida ya estará en funcionamiento.

La otra opción podría ser retrasar la creación de estos recursos agrupados y activar su creación durante la incorporación de tu primer inquilino (casi como el patrón de carga perezosa). Aunque esto podría ralentizar tu proceso de incorporación, la sobrecarga de este proceso sólo sería absorbida por tu primer inquilino. Mi tendencia general es preaprovisionar estos recursos. Sin embargo, puede haber otros factores que te inclinen hacia una u otra de estas estrategias.

Aunque puede ser interesante y potente dar soporte a estos diferentes modelos de implementación basados en niveles, también es esencial tener en cuenta cómo puede afectar la complejidad de tu incorporación a la complejidad de nuestro entorno SaaS general. Sí, quieres dar a la empresa muchas herramientas para poder dar soporte a diferentes perfiles de inquilinos. Al mismo tiempo, no quieres rotar demasiado en este sentido. Además, es importante destacar que éste sigue siendo un nivel de personalización. Nunca debes ver este mecanismo como una forma de apoyar cualquier noción de personalización puntual para inquilinos individuales.

Seguimiento de los recursos incorporados

Si tu proceso de incorporación necesita aprovisionar recursos dedicados al inquilino, también tendrás que considerar cómo tu entorno multiinquilino rastreará e identificará estos recursos. Lo que encontrarás aquí es que otros aspectos de tu sistema acabarán necesitando localizar y orientar estos recursos específicos del inquilino.

Para entender realmente a qué me refiero, veamos un ejemplo más concreto. Imagina que has dado de alta a un inquilino en el modelo de implementación mixto de la Figura 4-7. Este modelo incluye muchos ejemplos de recursos en silo y agrupados. Ahora, imagina que acabas de incorporar un inquilino de nivel superior a este entorno y has creado los recursos individuales necesarios para dar soporte a ese inquilino.

Una vez que se haya realizado la incorporación y nuestro inquilino esté en funcionamiento, seguirás desplegando actualizaciones en este entorno. Parches, nuevas funcionalidades y otros cambios tendrán que desplegarse a lo largo del ciclo de vida de tu aplicación. Aquí es donde las cosas se ponen un poco interesantes. Con la implementación de modo mixto que tenemos aquí, no podemos simplemente desplegar en una ubicación estática para actualizar nuestro sistema. Imagina, por ejemplo, que desplegamos una nueva versión del servicio de Pedidos. Para desplegar el nuevo código, tu experiencia DevOps tendrá que encontrar las implementaciones separadas del servicio de Pedidos que abarcan todos los diferentes recursos que fueron aprovisionados por la experiencia de incorporación. En este caso, eso significaría desplegar el servicio de Pedido en los silos de nivel superior del Inquilino 1 y del Inquilino 2 y en la instancia agrupada de nivel básico que comparten los demás inquilinos.

Así pues, cabe preguntarse: ¿cómo sabría tu proceso de implementación cómo manejar esto? ¿Cómo sabría qué recursos están en silo para cada inquilino? La única forma de que esto funcione es que tu experiencia de incorporación capture y registre la ubicación e identidad de estos recursos por inquilino. Aunque la necesidad de esta información de seguimiento es evidente, no existe una estrategia clara o estándar que se aplique habitualmente para abordarla. Algunos colocan los datos en una tabla a medida que se incorporan nuevos inquilinos y hacen referencia a esta tabla durante su proceso de implementación. Otros pueden utilizar partes de su cadena de herramientas DevOps para abordar este reto. La principal conclusión es que, si tu proceso de incorporación prevé recursos dedicados a los inquilinos, tendrás que capturar y registrar la información sobre estos recursos para que puedan ser consultados por otras partes de tu experiencia operativa y de implementación. Verás ejemplos más concretos de esto cuando empecemos a ver la orquestación de la incorporación a en los ejemplos EKS(Capítulo 10) y sin servidor(Capítulo 11).

Manejar los fallos de incorporación

Cualquier fallo en el proceso de incorporación puede representar un problema importante para los proveedores de SaaS. Sin embargo, estos fallos adquieren una importancia añadida en cualquier entorno multi-arrendatario que tenga una experiencia de onboarding de autoservicio. La incorporación representa la primera impresión que das a un inquilino, y cualquier fallo en este proceso podría traducirse en una pérdida de negocio.

Aunque parte de tu fiabilidad aquí se extraerá de aplicar prácticas de ingeniería sólidas, también hay áreas dentro del onboarding en las que tus dependencias de sistemas externos pueden afectar a la durabilidad de tu proceso de onboarding. Para tener una mejor idea de las opciones, veamos un ejemplo concreto de una posible dependencia externa que podría formar parte de tu experiencia de incorporación. La Figura 4-8 ofrece una vista conceptual de la integración de la facturación que podría formar parte de tu flujo de incorporación.

En este ejemplo, supongamos que dependes de una integración con un proveedor de facturación externo. Al incluir una solución de facturación de terceros en tu incorporación (lo que es habitual), has hecho que la fiabilidad de tu experiencia de incorporación dependa directamente de la disponibilidad del proveedor de facturación. Si el sistema de facturación no funciona, tampoco lo hará la incorporación de inquilinos.

Ahora bien, podrías suponer que éste es sólo el riesgo asociado al uso de soluciones de terceros. Sin embargo, en este escenario, es muy probable que tu sistema pueda seguir funcionando, incluso cuando el sistema de facturación esté caído. Si bien es cierto que necesitas crear la cuenta de facturación, tu sistema podría terminar su proceso de incorporación y completar la configuración de la facturación cuando el sistema vuelva a estar en línea.

En la Figura 4-8, he destacado un posible enfoque de este problema: hacer que la integración de la facturación sea completamente asíncrona. En este modelo, tu proceso de incorporación solicitaría la adición de un nuevo inquilino a través de una cola. A continuación, el servicio de Facturación recoge la solicitud e intenta crear una cuenta en el sistema de facturación mediante una solicitud asíncrona. Si esta solicitud falla, el servicio de Facturación capturará el fallo y programará un reintento. Hay muchas estrategias diferentes para implementar una integración tolerante a fallos. No te pierdas en los detalles. La clave es que he creado un modelo de integración con el proveedor de facturación que permite que mi flujo de incorporación continúe sin esperar a la creación de la cuenta de facturación. Para algunos, puede ser preferible que sea siempre una integración asíncrona, simplemente para agilizar la experiencia de incorporación.

Me he centrado en la facturación sólo porque proporciona una ilustración natural de la importancia de tener una experiencia de incorporación tolerante a fallos. En realidad, debes examinar todas las partes móviles de tu automatización del onboarding y buscar puntos de fallo o cuellos de botella que puedan requerir nuevas estrategias que agilicen o añadan durabilidad a tu proceso de onboarding. El coste de un onboarding fallido es generalmente alto y quieres hacer todo lo posible para que este mecanismo sea lo más robusto posible.

Prueba tu experiencia de incorporación

Llegados a este punto, el papel y la importancia del onboarding deberían estar claros. La complejidad potencial y el número de piezas móviles de este proceso pueden hacerlo especialmente propenso a errores. Teniendo esto en cuenta, también debe quedar claro que querrás tomar medidas adicionales para validar la eficacia y repetibilidad de tu proceso de incorporación. Demasiados equipos crean un proceso de incorporación y simplemente confían en la actividad de los clientes para descubrir cualquier cuello de botella o fallo de diseño que pueda estar afectando a su experiencia de incorporación. Para evitarlo, siempre sugiero que los equipos inviertan en crear una rica colección de pruebas de incorporación que puedan utilizarse para ejercitar y presionar en todas las dimensiones de la experiencia de incorporación.

Aquí puedes considerar una serie de tipos de pruebas potenciales. Por ejemplo, podrías crear pruebas de carga para la incorporación que simulen diferentes cargas de trabajo de incorporación. O podrías crear pruebas que validen tu capacidad para recuperarte de los fallos. Algunos equipos introducirán pruebas de rendimiento que midan el tiempo que se tarda en incorporar a los inquilinos. Cada una de estas pruebas podría ejecutarse con una mezcla de diferentes niveles de inquilinos, donde un nivel de inquilino podría ejercitar diferentes rutas de tu experiencia de incorporación.

El objetivo es garantizar que el diseño, la arquitectura y los supuestos de automatización de tu experiencia de onboarding se cumplen plenamente en tu solución de trabajo. Eso significa aumentar la escala simulando una gama completa de casos de uso que impulsarán el diseño y la implementación de tu onboarding. También te permitirá verificar que tu entorno está mostrando correctamente cualquier métrica clave que se utilice para medir tu capacidad de cumplir cualquier SLA que hayas definido. Aquí no se trata sólo de garantizar que el camino feliz funcione, sino de asegurar que el onboarding cumpla los requisitos de escala y disponibilidad y ofrezca una experiencia de servicio que satisfaga las expectativas de tus clientes.

Crear una identidad SaaS

Hasta ahora, he tratado brevemente el papel de la identidad como parte del proceso de incorporación. Sin embargo, hay muchas piezas del rompecabezas de la identidad que es necesario explorar. Sí, el onboarding configura la identidad, pero ¿qué significa eso? ¿Cómo se configura la identidad y cómo afecta la multitenencia a la experiencia general de nuestro entorno SaaS? Aquí profundizaremos en cómo la tenencia da forma a la autenticación, la autorización y la huella multitenencia general de un entorno SaaS.

Con la identidad multi-arrendatario, tendrás que ir más allá de pensar en la identidad puramente como una herramienta para autenticar usuarios. Debes ampliar tu visión de la identidad para incluir la idea de que cada usuario autenticado debe serlo siempre en el contexto de un inquilino. Es cierto que los usuarios están conectados a esta experiencia, pero gran parte de la implementación subyacente de tu arquitectura multiinquilino se centra principalmente en el inquilino asociado a ese usuario. Por tanto, esto significa que nuestro modelo de identidad debe ampliarse para abarcar tanto a los usuarios como a los inquilinos. El objetivo básico es crear un vínculo más estrecho entre usuarios e inquilinos que permita acceder a ellos, compartirlos y gestionarlos como una sola unidad.

En la Figura 4-9 verás una vista conceptual de cómo se compone una identidad SaaS. A la izquierda, tengo la vista clásica de lo que he etiquetado como identidad de usuario . Esta identidad se centra directamente en describir y capturar los atributos de un individuo. Nombre, número de teléfono, correo electrónico... todos ellos son descriptores típicos que se utilizarían para caracterizar al usuario de un sistema. En el lado derecho, sin embargo, también he introducido la idea de una identidad de inquilino . Un inquilino es más una entidad que un individuo. Una empresa, por ejemplo, se suscribe a tu servicio SaaS como inquilino, y ese inquilino suele tener muchos usuarios.

En los entornos multiusuario, estas dos nociones distintas de identidad se unen para crear lo que yo llamo una identidad SaaS. Esta identidad SaaS debe introducirse de forma que se convierta en una construcción de identidad de primera clase que pase por todas las capas de tu sistema. Se convierte en el vehículo para transmitir el contexto de tu inquilino a todas las partes de tu sistema que necesitan acceder a estos atributos de usuario e inquilino. Esta identidad SaaS se corresponde directamente con el concepto de contexto de inquilino que describí en el Capítulo 1.

La clave es que esta identidad SaaS tiene que introducirse sin afectar o complicar de algún modo la experiencia de autenticación tradicional. Tu experiencia de autenticación SaaS debe conservar la libertad de seguir un flujo de autenticación clásico y, al mismo tiempo, permitir la fusión de las identidades del usuario y del inquilino. La Figura 4-10 muestra este concepto en acción.

En el flujo que ves aquí, un usuario inquilino intenta acceder a una aplicación web SaaS (paso 1). La aplicación detecta que el usuario no está autenticado y lo redirige a un proveedor de identidades que conoce tanto la identidad del usuario como la del inquilino (paso 2). Cuando el usuario se autentique, el proveedor de identidades se responsabilizará de devolver la identidad SaaS (paso 3). A continuación, esta identidad SaaS se transmite al resto de las partes móviles de nuestro sistema (paso 4). Esta identidad incluye todos los atributos del inquilino y del usuario necesarios para dar soporte a las necesidades del resto de elementos de tu aplicación SaaS.

Aunque este flujo puede variar en función de la naturaleza de tu tecnología de identidad, el espíritu de esta experiencia debe seguir siendo similar en los distintos modelos de identidad. También puede verse influido por la forma en que los inquilinos entran en tu sistema y se dirigen a un proveedor de identidad. Los subdominios, las direcciones de correo electrónico o las tablas de búsqueda, por ejemplo, podrían determinar cómo resuelves la ruta de un inquilino al proveedor de identidad correspondiente. Al final, tu objetivo es resolver y crear esta identidad SaaS en la parte delantera de este proceso y evitar empujar esta responsabilidad hacia los detalles de tu diseño e implementación.

Adjuntar una identidad de inquilino

Hasta ahora, he hablado de unir las identidades de usuario y de inquilino. Aunque esto puede tener sentido conceptualmente, en todavía no hemos hablado de cómo puedes combinar estos dos conceptos en una verdadera construcción de identidad SaaS de primera clase. Naturalmente, la forma de hacerlo variará de un proveedor de identidad a otro.

Para este debate, voy a centrarme en cómo pueden utilizarse las especificaciones Open Authorization (OAuth) y OpenID Connect (OIDC) para crear y configurar una identidad SaaS. Estas especificaciones son utilizadas ampliamente por una serie de proveedores de identidad modernos, sirviendo como un estándar abierto para la autenticación y autorización descentralizadas. Como tal, deberías encontrar que las técnicas que he cubierto aquí deberían tener alguna correspondencia natural con el modelo de identidad de tu aplicación.

Para conseguir inquilinos vinculados a usuarios, primero tenemos que entender cómo la especificación OIDC empaqueta y transmite la información de autenticación de un usuario. Por lo general, al autenticarte con un proveedor de identidad compatible con OIDC, verás que cada autenticación devuelve tokens de identidad y acceso. Éstos se representan en como JSON Web Tokens (JWTs) que contienen todo el contexto de autenticación que se utilizará para la autorización posterior. El token de identidad sirve para transmitir información sobre un usuario, mientras que el token de acceso se utiliza para autorizar el acceso de ese usuario a distintos recursos.

Dentro de estos JWT, encontrarás un conjunto de propiedades y valores que proporcionan información más detallada sobre un usuario. Estos datos se denominan reclamos. Hay un conjunto predeterminado de reclamaciones que generalmente se incluyen con cada token para garantizar una representación estandarizada de los atributos comunes. Son estos JWT los que se convierten en la moneda universal de nuestro modelo de identidad multiusuario.

La buena noticia de los JWT es que permiten introducir afirmaciones personalizadas. Estas reclamaciones personalizadas son esencialmente el equivalente de campos definidos por el usuario que pueden utilizarse para adjuntar tus propios pares propiedad/valor a los JWT. Esto te brinda la oportunidad de adjuntar datos contextuales del inquilino a estos tokens. La Figura 4-11 ilustra cómo se añadirían estas declaraciones de inquilino personalizadas a tus JWT.

A la izquierda hay un ejemplo de JWT rellenado con las declaraciones de ejemplo que forman parte de la especificación OIDC. No voy a repasarlas todas, pero merece la pena destacar los atributos de usuario específicos que aparecen aquí. Verás que name, given_name, family_name, gender, birthdate, y email están todos en esta lista. A la derecha, sin embargo, están los atributos de nuestro inquilino que hay que fusionar en el JWT. Éstos simplemente se añaden como pares propiedad/valor a la representación estandarizada.

Aunque no hay nada mágico ni elegante en este modelo, poder introducir estas reclamaciones personalizadas como ciudadanos de primera clase proporciona una ventaja significativa. Imagina cómo la incorporación de estos atributos como reclamaciones acaba dando forma a tu experiencia de autenticación y autorización multiusuario. La Figura 4-12 muestra cómo esta construcción aparentemente sencilla acaba teniendo un impacto en cascada en tu arquitectura multiusuario.

En este ejemplo, el flujo comienza en la aplicación web. El usuario accede a esta página y no se autentica, lo que le envía al proveedor de identidad para que se autentique (paso 1). Esto representa un flujo muy familiar y vainilla que probablemente hayas construido varias veces. Lo que es diferente es que los datos vuelven de esta experiencia de autenticación. Cuando te autentiques aquí, el proveedor de identidad te devolverá sus tokens estándar (paso 2). Sin embargo, como he configurado el proveedor de identidad con reclamaciones personalizadas específicas del inquilino, los tokens que se devuelven ahora se alinean con la identidad SaaS de la que se habló antes. Los tokens participan y se comportan como cualquier otro token, pero están enriquecidos con el contexto añadido del inquilino que necesitamos para crear una identidad SaaS.

Ahora, estos tokens pueden inyectarse como tokens portadores y enviarse a tus servicios backend, heredando todos los mecanismos de seguridad, ciclo de vida y otros que están incorporados en las especificaciones OIDC y OAuth (paso 3). Esta estrategia es especialmente poderosa cuando observas cómo afecta a la experiencia más amplia de tus servicios backend. La Figura 4-13 ofrece un ejemplo de cómo podrían fluir estos tokens a través de los diferentes microservicios multiusuario de tu aplicación.

Tengo tres microservicios diferentes, cada uno de los cuales requiere acceso al contexto del inquilino. Cuando te autenticas y recibes un token con contexto de inquilino, este token se pasa al microservicio al que estés llamando inicialmente. En este caso, la llamada entra en el microservicio Pedido (paso 1). Luego, imagina que este servicio necesita invocar a otro servicio backend (Producto) para completar su tarea. Entonces puede pasar este mismo token al servicio Producto (paso 2). Este patrón puede continuar en cascada a través de otras invocaciones de servicios posteriores (paso 3). En este ejemplo, he supuesto que puedo insertar el JWT en una solicitud HTTP como token portador. Sin embargo, aunque estés utilizando otro protocolo, es probable que haya formas de inyectar este JWT como parte de tu contexto.

Puedes imaginar cómo este mecanismo tan sencillo acaba teniendo un impacto bastante profundo en tu arquitectura multiusuario general. Este único JWT afectará a muchas de las partes móviles de la implementación de tu entorno multiusuario. Los microservicios lo utilizarán para el registro, las métricas, la facturación, el aislamiento de inquilinos, la partición de datos y muchas otras áreas. Tu arquitectura SaaS más amplia lo utilizará para la jerarquización, estrangulamiento, enrutamiento y otros mecanismos globales que requieren el contexto del inquilino . Así que, sí, es un concepto sencillo, pero no se puede subestimar la importancia de su papel dentro de tu arquitectura SaaS.

Rellenar solicitudes personalizadas durante la incorporación

Ya hemos visto cómo las reivindicaciones personalizadas nos ofrecen una forma de conectar a los usuarios con los inquilinos. Lo que puede estar menos claro es cómo y cuándo se introducen realmente estas reclamaciones. Hay dos pasos bastante sencillos asociados a la adición y rellenado de estas reclamaciones personalizadas. En primer lugar, antes de incorporar a cualquier inquilino, normalmente tendrás que configurar tu proveedor de identidad, identificando cada uno de los atributos personalizados que te gustaría que se añadieran a tu experiencia de autenticación. Aquí definirás cada propiedad y tipo que quieras que acabe en tus reclamaciones personalizadas. Esto prepara a tu proveedor de identidad para aceptar nuevos inquilinos que puedan almacenar y configurar sus inquilinos con los atributos adicionales.

La segunda mitad de este proceso se ejecuta durante la incorporación. Antes he hablado de la creación del usuario de administración del inquilino como parte del flujo general de incorporación. Sin embargo, lo que no mencioné fue la población de las reclamaciones personalizadas para tu inquilino recién creado. Al añadir la información sobre tu usuario (nombre, correo electrónico, etc.), también rellenarás todos los campos de contexto del inquilino para ese usuario (ID de inquilino, función, nivel). Estos datos deben rellenarse para cada usuario dentro del proveedor de identidad, por lo que incluso después de que se haya completado la incorporación, la introducción de usuarios adicionales debe incluir la población de estos atributos personalizados.

Utilizar juiciosamente las cláusulas personalizadas

Las reivindicaciones personalizadas son una construcción útil para adjuntar contexto de inquilino a tus tokens. En algunos casos, los equipos se unirán a este mecanismo y ampliarán su función, utilizándolo para capturar y transmitir el contexto de seguridad de la aplicación. Aunque aquí no hay reglas rígidas y rápidas, generalmente asumo que si algo es una reivindicación personalizada, está desempeñando un papel esencial en la configuración del contexto del inquilino e influyendo en tu historia de autorización global.

Muchas aplicaciones se basan en construcciones de control de acceso para habilitar o deshabilitar el acceso a funcionalidades específicas de la aplicación. Estos controles deben gestionarse fuera del ámbito de tu proveedor de identidad. En general, me parecería un error hinchar tus tokens con reclamaciones personalizadas que formen parte de tu estrategia tradicional de control de acceso a la aplicación. En su lugar, este tipo de controles deberían implementarse con cualquiera de los mecanismos de lenguaje o pila tecnológica construidos exclusivamente para este fin.

Puede haber ocasiones en las que no esté claro si un atributo pertenece a una reivindicación personalizada o al modelo de control de acceso de tu aplicación. Para mí, esto suele resolverse en función del ciclo de vida y la función del atributo. Si el atributo tiende a evolucionar con la introducción de características, funciones y capacidades de la aplicación, entonces debería gestionarse más a través de los controles de acceso de la aplicación. Por lo general, es poco probable que los atributos que aparecen en tus reivindicaciones personalizadas cambien a medida que cambia tu aplicación. El contenido de tus tokens, por ejemplo, no debería cambiar semanalmente en función de la adición de nuevas funciones u opciones de configuración de la aplicación.

No hay servicios centralizados para resolver el contexto del inquilino

Algunos equipos intentan trazar una línea más dura entre la identidad del inquilino y la identidad del usuario. En estos entornos, el proveedor de identidad sólo se utiliza para autenticar a los usuarios. Aquí, cuando se autentica a un usuario, los tokens devueltos por este proceso no incluyen ninguna información contextual del inquilino. En este modelo, estos sistemas deben confiar en algunos mecanismos posteriores para resolver la tenencia. La Figura 4-14 proporciona un ejemplo de cómo podría implementarse esto.

En este ejemplo, la aplicación web se autentica contra un proveedor de identidad que no conoce el contexto del inquilino (paso 1). Una autenticación correcta devolverá los JWT de los que hemos hablado. Sin embargo, estos tokens no incluirán ninguna de las afirmaciones personalizadas específicas del inquilino que se han descrito anteriormente (paso 2). En su lugar, los únicos datos aquí son los del usuario. A continuación, este token se pasa al microservicio de pedidos (paso 3). Ahora, cuando este servicio de pedidos necesita acceder a los datos de un inquilino concreto, necesita identificar qué inquilino está asociado a la solicitud actual. Como el JWT no incluye esta información, tu código tendría que adquirir el contexto de otro servicio (paso 4). En este ejemplo, he introducido un servicio de Mapeo de Inquilinos que toma el JWT, extrae la información del usuario, resuelve el usuario a un inquilino y devuelve el identificador del inquilino (paso 5). Este identificador se utiliza entonces para obtener un pedido para este inquilino específico (paso 6).

A primera vista, puede parecer una estrategia perfectamente válida. Sin embargo, en realidad presenta verdaderos retos para muchos entornos SaaS. El menor de los problemas es que crea una dura separación entre el usuario y el inquilino, lo que obliga a los equipos a gestionar el estado acoplado del usuario y del inquilino de forma independiente. El mayor problema, sin embargo, es que cada servicio del sistema debe pasar por este mecanismo de mapeo centralizado para resolver el contexto del inquilino. Imagina que este paso se realiza a través de cientos de servicios y miles de solicitudes. Muchos de los que adoptan este enfoque descubren rápidamente que este servicio de mapeo de inquilinos acaba creando un importante cuello de botella en su sistema, lo que lleva a los equipos por el camino de intentar optimizar un servicio que, en realidad, no aporta ningún valor empresarial.

Ésta es otra razón por la que es tan esencial que los contextos del usuario y del inquilino estén unidos y se compartan universalmente en toda la superficie de tu arquitectura multiinquilino. Como regla general, mi objetivo es que un servicio nunca tenga que invocar algún mecanismo externo para resolver y adquirir el contexto del inquilino. Quieres tener casi todo lo que necesitas saber sobre el inquilino compartido a través del JWT que incluye tu información de identidad SaaS. Sí, puede haber excepciones, pero ésta debería ser la mentalidad general que adoptes cuando pienses en cómo estás asignando usuarios a inquilinos.

Identidad SaaS Federada

La mayor parte de lo que he descrito hasta ahora supone que tu sistema SaaS podrá funcionar con un único proveedor de identidad que esté bajo tu control. Aunque esto representa el escenario ideal de y maximiza tus opciones, tampoco es práctico suponer que todas las soluciones SaaS se construyan con este modelo. Algunos proveedores de SaaS se enfrentan a necesidades empresariales, de dominio o de cliente que les obligan a dar soporte a un proveedor de identidad alojado en un cliente o en un tercero.

Un caso común que he visto es un escenario en el que un cliente de SaaS tiene cierta dependencia empresarial de un proveedor de identidad interno existente. Algunos de estos clientes pueden exigir, como condición para su compra, que el proveedor de SaaS admita la autenticación de estos proveedores de identidad internos. Estos casos a menudo se reducen a sopesar el valor de adquirir este cliente frente a añadir complejidad a tu entorno que podría afectar a la agilidad y eficacia operativa de tu experiencia SaaS general. Aun así, cuando se presenta la oportunidad adecuada, los parámetros empresariales pueden empujar a los equipos hacia estrategias que les permitan apoyar este modelo.

Normalmente, esto se consigue a través de algún nivel añadido de configuración del inquilino, en el que tu incorporación al inquilino añadirá soporte adicional para configurar este proveedor de identidad alojado externamente. El objetivo sería que esto fuera lo más fluido posible, limitando la introducción de cualquier código invasivo o puntual que incluyera la personalización centrada en el inquilino. El otro reto es que, en algunos casos, tendrás que proporcionar soporte paralelo para los proveedores de identidad externos e internos. La realidad es que es probable que la mayoría de tus clientes esperen que tu solución incluya soporte de identidad integrado. La Figura 4-15 ofrece una visión de las partes móviles de este patrón de identidad.

En el centro de este ejemplo, verás que tengo un gestor de autenticación. Se trata de un marcador de posición conceptual para introducir algún servicio en tu flujo de autenticación que pueda soportar un conjunto más distribuido de proveedores de identidad. Para que esto funcione, tu sistema tendrá que determinar siempre cómo se aloja un proveedor de identidad. Cada vez que un usuario necesite autenticarse, tendrás que examinar a ese usuario y recuperar la configuración de identidad, que incluirá datos que describan la ubicación y configuración de un determinado inquilino.

En la parte izquierda de la Figura 4-15, he incluido una mezcla de proveedores de identidad alojados interna y externamente que deben ser soportados por una única experiencia SaaS. Dos inquilinos utilizan su propio proveedor de identidades. El resto utiliza tu proveedor de identidad interno.

Este modelo parece bastante sencillo. Sin embargo, el problema es que tu sistema no tiene control sobre estos proveedores de identidad externos. Como tal, no puedes configurar las reclamaciones de estos proveedores ni hacer que tu proceso de incorporación añada contexto de inquilino adicional a los datos de identidad que gestionan estos proveedores. Esto significa que los JWT devueltos por tus solicitudes de autenticación no incluirán nada del contexto de inquilino que es esencial para tu entorno multiinquilino. Para resolver esto, tu solución tendrá que introducir una nueva funcionalidad que pueda enriquecer los tokens devueltos por estos proveedores de identidad externos, asumiendo la responsabilidad de enriquecer estos tokens con el contexto del inquilino que se gestiona dentro de tu entorno SaaS. Esto permite que todos los servicios posteriores sigan confiando en los tokens JWT conscientes del inquilino, independientemente del proveedor de identidad que se haya utilizado para autenticar al usuario. La forma de enriquecer estos tokens dependerá de la naturaleza de nuestra solución. Hay estrategias que proporcionarán ganchos que te permitirán inyectar dinámicamente el contexto de inquilino añadido. En otros casos, puede que necesites una solución más personalizada. En general, sin embargo, los modelos de federación del espacio de identidad suelen ofrecerte diferentes técnicas para tratar este caso de uso.

He incluido este modelo porque representa un patrón inevitable que aparece en la naturaleza. Vale la pena señalar que este enfoque tiene claros inconvenientes. Cada vez que tengas que introducirte en el flujo de autenticación, estarás asumiendo un papel añadido dentro de la huella de seguridad de tu arquitectura multiinquilino. También es posible que tengas que hacer frente a los requisitos de escala y de punto único de fallo que conlleva el hecho de intervenir en el flujo de autenticación. Así que, aunque esto puede ser necesario, viene con un bagaje real que querrás considerar detenidamente en .

Construcciones de agrupación/mapeo de inquilinos

Aunque los proveedores de identidad suelen ajustarse a especificaciones bien establecidas (OIDC, OAuth2), las construcciones que se utilizan para organizar y gestionar las identidades pueden variar de un proveedor de identidad a otro. Estos proveedores ofrecen una serie de construcciones diferentes para agrupar y organizar a los usuarios. Esto es especialmente importante en entornos multi-arrendatario, donde puede que quieras agrupar a todos los usuarios que pertenecen a un arrendatario. Estos constructos de grupo pueden tener implicaciones que influirán en la forma de asignar inquilinos dentro de tu proveedor de identidad. En algunos casos, también podrías utilizar estos grupos para aplicar políticas de nivelación a los inquilinos para dar forma a su experiencia de autenticación y autorización.

Si nos fijamos en Amazon Cognito, por ejemplo, verás que ofrece múltiples formas de organizar los inquilinos de . Cognito introduce la idea de un Pool de Usuarios. Estos Grupos de Usuarios son utilizados para albergar una colección de usuarios, y pueden configurarse individualmente, permitiendo que los grupos ofrezcan experiencias de autenticación separadas. Esto podría conducir a un modelo de Grupos de Usuarios por inquilino, en el que cada inquilino tendría su propio grupo. La alternativa sería poner a todos los inquilinos en una única Reserva de Usuario y utilizar otros mecanismos (grupos, por ejemplo) para asociar usuarios a inquilinos. También tendrías que considerar cómo podrían influir los límites de tu proveedor de identidad a la hora de elegir una estrategia.

Hay ventajas y desventajas que deberás tener en cuenta a la hora de elegir entre estas diferentes construcciones de identidad. El número de inquilinos que tengas, por ejemplo, puede hacer poco práctico tener Grupos de Usuarios distintos para cada inquilino. O puede que no necesites mucha variación entre inquilinos y prefieras tener a todos los inquilinos configurados y gestionados colectivamente. También podrías estar pensando en cómo las decisiones que tomes aquí podrían afectar al flujo de autenticación de tu solución SaaS. Si tienes Grupos de Usuarios separados para cada inquilino, tienes que pensar en cómo asignar los inquilinos a sus grupos designados durante el proceso de autenticación. Esto puede añadir un nivel de indirección que quizá no quieras absorber como parte de tu solución.

La escala, los requisitos de identidad y muchas otras consideraciones van a determinar la forma en que decidas asignar los inquilinos a las construcciones que admita tu proveedor de identidad. La clave es que, cuando empieces a diseñar tu estrategia de identidad SaaS, querrás identificar las diferentes unidades de organización que pueden utilizarse para agrupar a tus inquilinos y determinar cómo determinarán la escala, la autenticación y la configuración de tu experiencia de autenticación multiinquilino.

Con diferentes construcciones organizativas también vienen diferentes opciones de configuración de identidad. Los proveedores de identidad suelen ofrecer una serie de opciones que pueden utilizarse para configurar tu experiencia de autenticación en . La autenticación multifactor (MFA), por ejemplo, se ofrece como una característica de identidad que puede activarse o desactivarse. También puedes configurar requisitos de formato de contraseña y políticas de caducidad.

Los ajustes de estas distintas opciones de configuración no tienen por qué aplicarse globalmente a todos tus inquilinos. Puede que quieras poner diferentes funciones de identidad a disposición de diferentes niveles de inquilinos. Tal vez sólo pongas MFA a disposición de tus inquilinos de nivel premium, o tal vez decidas hacer emerger estas opciones de configuración dentro de la experiencia de administración de inquilinos de tu aplicación SaaS y permitir que cada inquilino configure estos diferentes ajustes de identidad. Esto puede ser una característica diferenciadora que añada valor a tus inquilinos y les permita crear la experiencia de identidad que mejor se adapte a las necesidades de su negocio.

Cómo o si puedes ofrecer esta personalización de la identidad dependerá de cómo tu proveedor de identidad específico organice y ponga en superficie estas opciones. Algunos proveedores te permitirán configurar esto por separado para inquilinos individuales, y otros sólo permitirán configurarlo globalmente. Tendrás que indagar en las construcciones de tu proveedor de identidad específico para averiguar si puedes asociar estas políticas de identidad a inquilinos individuales.

Compartir ID de usuario entre inquilinos

Cada usuario de tu sistema SaaS tiene un identificador de usuario que lo identifica ante un inquilino. Este identificador de usuario suele estar representado por una dirección de correo electrónico. En muchos casos, un único usuario estará asociado a un único inquilino SaaS. Sin embargo, hay ocasiones en las que los proveedores de SaaS tienen interés en asociar una única dirección de correo electrónico a muchos inquilinos. Esto, por supuesto, añade un nivel de indirección a tu autenticación. En algún punto de tu flujo de acceso, tu sistema SaaS tendrá que determinar a qué inquilino estás accediendo.

Aunque he visto peticiones para dar soporte a este modo, aún no he descubierto ninguna estrategia "out-of-the-box" para manejar este caso de uso. Dicho esto, hay algunos patrones que he visto aplicados aquí. La forma más forzada que he visto es la que traslada la resolución del inquilino al usuario final; durante el inicio de sesión, el sistema detectará que un usuario pertenece a varios inquilinos y le pedirá que seleccione un inquilino de destino. Esto es cualquier cosa menos elegante, y crea una fuga de información en el sentido de que cualquiera puede utilizar una dirección de correo electrónico para ver a qué inquilinos perteneces (si y sólo si perteneces a más de uno). En el modelo, tendrías una tabla de asignación que conectara a los usuarios con los inquilinos y la utilizarías como búsqueda antes de iniciar el flujo de autenticación.

Un enfoque más limpio sería basarse en una experiencia de autenticación que proporcionara el contexto de forma más explícita. El mejor ejemplo son probablemente los dominios y subdominios. Si a cada uno de tus inquilinos se le asigna un subdominio(inquilino1.saasprovider.com), tu proceso de autenticación puede utilizar este subdominio para adquirir el contexto del inquilino. Entonces el sistema te autenticaría contra el inquilino especificado. Esto permitiría al usuario autenticarse sin ningún proceso intermedio para identificar al inquilino de destino.

Hay otras complicaciones en este escenario. Imagina, por ejemplo, que todos tus usuarios se ejecutan en una construcción de proveedor de identidad compartida. En ese modo, el proveedor de identidad va a exigir que cada usuario sea único. Esto haría imposible soportar tener un único ID de usuario asociado a varios inquilinos. En su lugar, puedes considerar la posibilidad de confiar en una construcción más granular para mantener los datos de cada inquilino (como la Reserva de Usuarios mencionada anteriormente).

La autenticación del inquilino no es el aislamiento del inquilino

Como parte de este debate sobre la autenticación y las JWT, a veces me encuentro con que los equipos equiparan la autenticación al aislamiento del inquilino. Se supone que la autenticación es la barrera de entrada para los inquilinos y que, una vez superado ese reto, se han cumplido los criterios para el aislamiento de inquilinos en entornos multiinquilino.

Ésta es sin duda un área de desconexión. Sí, la autenticación inicia la historia del aislamiento emitiendo un JWT con el contexto del tenant. Sin embargo, el código de tus microservicios aún puede incluir implementaciones que -incluso cuando trabajan en nombre de un usuario autenticado- pueden acceder a los recursos de otro inquilino. El aislamiento de inquilinos se basa en el contexto de inquilino que obtienes de un usuario autenticado, implementando una capa completamente independiente de controles y medidas para garantizar que tu código no pueda cruzar los límites de un inquilino. Profundizarás en estas estrategias de en el Capítulo 9.

Conclusión

Este capítulo trataba de describir los elementos fundamentales que representan el punto de partida para crear una arquitectura multiarrendamiento. Me he centrado en introducir las construcciones básicas que se utilizan para inyectar la noción de tenencia en tu arquitectura. Observarás que nada de estos primeros pasos incluye ningún esfuerzo por definir la experiencia de la aplicación. En su lugar, se trata de poner la tenencia al frente y en el centro de tu arquitectura. Colocar estas piezas fundamentales en su lugar desde el principio requerirá que tu equipo diseñe, construya, pruebe y opere en un contexto multiinquilino en todas las etapas de tu proceso de desarrollo. Desde el primer día, tu arquitectura tendrá que tener en cuenta toda la dinámica que conlleva dar soporte a múltiples inquilinos. El objetivo general es evitar la trampa de considerar el multiarrendamiento como un complemento que puede añadirse después de haber creado la aplicación. Ese modo rara vez funciona y suele conducir a dolorosos compromisos y refactorizaciones.

Empezamos el capítulo en el nivel más básico, explorando el proceso de creación de tu entorno base y la implementación de los primeros elementos de tu plano de control. Poner en marcha el armazón del plano de control te permite esculpir el espacio que acabará albergando todos los servicios que formarán parte de él. También te obliga a empezar a pensar en la implementación global, el control de versiones y el ciclo de vida general de tu plano de control.

A partir de ahí, centramos nuestra atención en la experiencia de incorporación, destacando la complejidad, los retos y las consideraciones que conlleva la introducción de inquilinos en tu entorno. Recorrimos una vista conceptual de un flujo de incorporación para darte una mejor idea de las partes móviles que forman parte de esta experiencia. Una gran parte de este debate también giró en torno a la mentalidad que conlleva la automatización de tu flujo de incorporación. Es aquí donde vimos cómo la automatización de esta incorporación aporta nuevos matices DevOps a tu entorno, ampliando tu forma de pensar sobre dónde y cuándo se aprovisionan y configuran los entornos de los inquilinos. Nuestro análisis del onboarding también hizo hincapié en el papel más amplio que desempeña a la hora de apoyar y permitir los objetivos de escala, agilidad e innovación de tu empresa.

Con la incorporación, hablamos de cómo se introducen los inquilinos en tu entorno. La progresión natural era ver cómo la configuración de estos inquilinos influye en la experiencia de autenticación de tu entorno. Es a través de la autenticación como vemos algunos de los frutos del trabajo realizado durante la incorporación. Nuestra revisión de la autenticación cambió nuestro enfoque hacia el papel que desempeña la identidad en un entorno SaaS. Examinamos cómo nuestro proveedor de identidad crea una conexión entre los usuarios y los inquilinos, estableciendo lo que yo denominaba una identidad SaaS. Esto hace que la identidad SaaS sea un concepto de primera clase en nuestra arquitectura. Exploramos cómo la autenticación de los inquilinos produce tokens que incluyen todo el contexto que necesitamos inyectar en todas las partes posteriores de nuestra arquitectura SaaS. Esto debería haber puesto de relieve lo esencial que es tener esta identidad SaaS entretejida en tu experiencia desde el principio de la construcción de un entorno multi-arrendatario.

Aunque sólo he tocado los elementos conceptuales de la incorporación y la identidad, esto debería darte una mejor idea de las partes móviles y las consideraciones que conlleva la creación de estas construcciones fundacionales. A medida que avancemos, veremos versiones más concretas de estos mecanismos y veremos cómo los distintos modelos de implementación y pilas tecnológicas pueden influir en el diseño y la implementación de la incorporación y la identidad. También veremos que esta noción de contexto de inquilino aparece en nuestra revisión de otras dimensiones de tu arquitectura, como la partición de datos, el aislamiento de inquilinos, los microservicios multiinquilino, etc.

Pero primero vamos a profundizar un poco más en el plano de control y examinar el componente Gestión de Inquilinos. En este capítulo ya se ha insinuado cómo aparece la Gestión de Inquilinos como parte de la experiencia de incorporación. Ahora, quiero fijarme más exclusivamente en el papel de este servicio dentro de tu plano de control. Aunque no es exótico ni excesivamente complejo, a menudo se sitúa en el centro de nuestra historia multiusuario. Examinaré lo que significa crear este servicio y esbozaré algunas de las consideraciones clave que pueden influir en su implantación.

Get Construir arquitecturas SaaS multi-inquilino now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Capítulo 4. Incorporación e identidad

Crear un entorno de referencia

Figura 4-1. Automatizar la creación de un entorno base

Crear tu entorno base

Figura 4-2. Aprovisionamiento de un entorno base

Figura 4-3. Creación e implementación de una consola de administración del sistema

Crear y gestionar identidades de administrador del sistema

Activar la Incorporación desde la Consola de Administración

Opciones de aprovisionamiento del plano de control

Figura 4-4. Elegir un modelo de implementación del plano de control

La experiencia de incorporación

La incorporación forma parte de tu servicio

Autoservicio frente a incorporación interna

Las partes fundamentales de la incorporación

Figura 4-5. Fundamentos de la incorporación de inquilinos

Rastrear y sacar a la superficie los estados de embarque

Incorporación por niveles

Figura 4-6. Ejemplo de incorporación por niveles

Figura 4-7. Incorporación por niveles con implementaciones de modo mixto

Seguimiento de los recursos incorporados

Manejar los fallos de incorporación

Figura 4-8. Integración tolerante a fallos con un proveedor de facturación

Prueba tu experiencia de incorporación

Crear una identidad SaaS

Figura 4-9. Crear una identidad lógica SaaS

Figura 4-10. Flujo de autenticación de identidad SaaS

Adjuntar una identidad de inquilino

Figura 4-11. Añadir reclamaciones personalizadas de inquilino a un JWT

Figura 4-12. Autenticación con contexto de inquilino incrustado

Figura 4-13. Pasar tokens a microservicios descendentes

Rellenar solicitudes personalizadas durante la incorporación

Utilizar juiciosamente las cláusulas personalizadas

No hay servicios centralizados para resolver el contexto del inquilino

Figura 4-14. Utilizar un servicio de mapeo usuario/arrendatario independiente

Identidad SaaS Federada

Figura 4-15. Soporte de proveedores de identidad alojados externamente

Construcciones de agrupación/mapeo de inquilinos

Compartir ID de usuario entre inquilinos

La autenticación del inquilino no es el aislamiento del inquilino

Conclusión

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly