Aplicación web de inicio para el desarrollo de SaaS

Azure App Service

Id. externa de Microsoft Entra

Azure SQL Database

Azure Logic Apps

Azure Resource Manager

El software como servicio (SaaS) es un tema complejo con muchos aspectos a tener en cuenta. Los proveedores de software independientes (ISV) que compilan sus soluciones SaaS en Azure necesitan resolver problemas y tomar decisiones como:

¿Qué modelo de arrendamiento debo usar?
¿Cómo configuro una solución de identidad para su uso en una arquitectura multiinquilino?
¿Cómo controlo la incorporación de nuevos clientes?

Esta arquitectura tiene como objetivo responder a algunas de estas preguntas y proporcionar un punto de partida en el entorno SaaS. Esta arquitectura se puede adaptar a una amplia gama de escenarios.

Posibles casos de uso

A continuación se muestran algunos casos de uso de ejemplo en los que podría usar esta arquitectura:

Modernización de una aplicación existente para que admita el modelo de multiinquilinato completo como parte de un cambio a un modelo de negocio basado en SaaS.
Desarrollo de una oferta de SaaS completamente nueva.
Migración de una oferta de SaaS desde otro servicio en la nube a Azure.

Arquitectura

Descargue un archivo de PowerPoint de esta arquitectura.

Terminología

En la tabla siguiente se describen los términos que aparecen en este artículo.

Término	Descripción	Ejemplo
Proveedor de SaaS o proveedor de software independiente (ISV)	La entidad que posee la aplicación SaaS y el código, y que vende el producto SaaS.	Contoso Inc, en la venta de su aplicación SaaS: Contoso Tickets.
Inquilino	Una instancia adquirida de la aplicación SaaS del proveedor de SaaS.	Cuarta cafetería.
Administrador del cliente de SaaS	Persona que compra o administra un inquilino de aplicación.	Joe, propietario de Fourth Coffee Shop.
Usuario del cliente de SaaS	Personas que usan un inquilino de aplicación sin administrarlo y que normalmente pertenecen a la misma empresa o grupo que el administrador del cliente de SaaS.	Jill, gerente de eventos en Fourth Coffee Shop y Susan, cliente de Fourth Coffee Shop.
Usuario final	Un administrador o un usuario de cliente de SaaS, o cualquier otro tipo de usuario que se introduzca. Se trata de un término genérico para describir a los usuarios que inician sesión en la aplicación.	Joe, Jill y Susan son todos usuarios finales (desde la perspectiva del ISV).
Aplicación front-end	Cualquier aplicación de front-end.	La aplicación de incorporación y administración, y la aplicación SaaS son aplicaciones de front-end.

Flujo de trabajo

El administrador del cliente de SaaS navega al sitio hospedado en la aplicación Onboarding &admin.
El administrador del cliente de SaaS inicia sesión con el flujo de trabajo de inicio de sesión del usuario .
El administrador del cliente de SaaS completa el flujo de incorporación.
El administrador de clientes de SaaS navega al área de administración de inquilinos en la aplicación Onboarding & admin y agrega un usuario cliente de SaaS a su inquilino recién creado.
El usuario cliente de SaaS navega a la aplicación saaS y usa la aplicación SaaS.

El flujo de trabajo de inicio de sesión de usuario consta de los pasos siguientes:

El usuario final navega a una aplicación front-end y selecciona un botón Inicio de sesión .
La aplicación front-end redirige al usuario final a una página de inicio de sesión hospedada por el proveedor de identidades.
El usuario final escribe la información de la cuenta y envía el formulario de inicio de sesión al proveedor de identidades.
El proveedor de identidades emite una solicitud POST con la dirección de correo electrónico y el identificador de objeto del usuario final para recuperar sus permisos y roles.
La API de datos de permisos busca la información del usuario final en el almacenamiento de datos de permisos y devuelve una lista de permisos y roles asignados a ese usuario final.
El proveedor de identidades agrega los permisos y roles como notificaciones personalizadas al token de identificador, que es un token web JSON (JWT).
El proveedor de identidades devuelve un token de identificador al usuario final e inicia una redirección a la aplicación front-end.
El usuario final se redirige al punto de conexión de inicio de sesión en la aplicación front-end y presenta el token de identificador.
La aplicación front-end valida el token de identificador presentado.
La aplicación front-end devuelve una página de inicio de sesión correcta y el usuario final ahora ha iniciado sesión.

Para obtener más información sobre cómo funciona este flujo de inicio de sesión, consulte Protocolo OpenID Connect.

Incorporación de un nuevo inquilino

Un flujo de trabajo de incorporación de inquilino consta de los siguientes pasos:

El administrador del cliente de SaaS navega a la aplicación Onboarding & admin y completa un formulario de registro.
La aplicación Onboarding & admin emite una solicitud POST a la API de datos de inquilinos para crear un nuevo inquilino.
La API de datos de inquilino crea un nuevo inquilino en el almacenamiento de datos del inquilino.
La API de datos de inquilino emite una solicitud POST a la API de datos de permisos para conceder permisos de administrador de clientes de SaaS al inquilino recién creado.
La API de datos de permisos crea un nuevo registro de permisos en el almacenamiento de datos de permisos.
La API de datos permission devuelve correctamente.
La API de datos de inquilino se devuelve correctamente.
La aplicación Onboarding & admin emite una solicitud POST al proveedor de notificaciones por correo electrónico para enviar un mensaje de correo electrónico "inquilino creado" al administrador del cliente de SaaS.
El proveedor de notificaciones por correo electrónico envía el correo electrónico.
El proveedor de notificaciones por correo electrónico devuelve correctamente.
La aplicación Onboarding & admin emite una solicitud al proveedor de identidades para actualizar el token de identificador del administrador del cliente de SaaS para que incluya una notificación JWT al inquilino recién creado.
El proveedor de identidades emite una solicitud POST con la dirección de correo electrónico y el identificador de objeto del administrador del cliente de SaaS para recuperar sus permisos y roles.
La API de datos de permisos busca la información del administrador del cliente de SaaS en el almacenamiento de datos de permisos y devuelve una lista de permisos y roles asignados al administrador del cliente de SaaS.
El proveedor de identidades agrega los permisos y roles como notificaciones personalizadas al token de identificador.
El proveedor de identidades devuelve el token de identificador a la aplicación de incorporación y administración.
La aplicación Onboarding & admin devuelve un mensaje de éxito y un nuevo token de identificador al administrador del cliente de SaaS.

Incorporación de un usuario a un inquilino

La adición de un usuario a un flujo de trabajo de inquilino consta de los pasos siguientes:

El administrador de clientes de SaaS solicita ver una lista de inquilinos del área de administración de inquilinos en la aplicación Onboarding &admin.
La aplicación Onboarding & admin emite una solicitud GET a la API de datos de inquilinos para obtener una lista de inquilinos para el administrador del cliente de SaaS.
La API de datos de inquilino emite una solicitud GET a la API de datos de permisos para obtener una lista de inquilinos a los que el administrador del cliente de SaaS tiene acceso para ver.
Permission data API devuelve una lista de permisos de inquilino.
La API de datos de inquilino busca la información del inquilino en el almacenamiento de datos del inquilino y devuelve una lista de datos de inquilinos en función de la lista de permisos de inquilino recibidos.
La aplicación Onboarding & admin devuelve la lista de datos de inquilinos al administrador de clientes de SaaS.
El administrador de clientes de SaaS selecciona un inquilino de la lista para agregar un usuario de cliente de SaaS a y escribe la dirección de correo electrónico del usuario del cliente de SaaS.
La aplicación Onboarding & admin emite una solicitud POST a la API de datos de inquilinos para agregar un permiso para el usuario cliente de SaaS en el inquilino especificado.
La API de datos de inquilino comprueba que el administrador del cliente de SaaS tiene una notificación JWT válida para el inquilino especificado y tiene el permiso de escritura del usuario en él.
La API de datos de inquilino emite una solicitud POST a la API de datos de permisos para agregar un permiso para el usuario del cliente de SaaS en el inquilino especificado.
La API de datos de permisos emite una solicitud GET al proveedor de identidades para buscar el usuario del cliente de SaaS mediante la dirección de correo electrónico proporcionada.
El proveedor de identidades devuelve el identificador de objeto del usuario del cliente de SaaS.
La API de datos de permisos agrega un registro de permisos en el almacenamiento de datos de permisos para el usuario cliente de SaaS en el inquilino especificado mediante su identificador de objeto.
La API de datos permission devuelve correctamente.
La API de datos de inquilino se devuelve correctamente.
La aplicación Onboarding & admin devuelve correctamente.

Componentes

Esta arquitectura emplea los siguientes servicios de Azure:

App Service le permite compilar y hospedar aplicaciones web y aplicaciones de API en el lenguaje de programación que elija sin necesidad de administrar la infraestructura.
Azure Active Directory B2C permite fácilmente la administración de identidades y acceso para las aplicaciones de usuario final.
Azure SQL Database es un servicio administrado de base de datos relacional de uso general que admite datos relacionales, datos espaciales, JSON y XML.
Azure Logic Apps le permite crear rápidamente integraciones eficaces mediante una sencilla herramienta de interfaz gráfica de usuario (GUI).

Alternativas

La eficacia de cualquier opción alternativa depende en gran medida del modelo de arrendamiento que pretende admitir la aplicación SaaS. A continuación se muestran algunos ejemplos de enfoques alternativos que puede seguir al implementar esta solución:

La solución actual usa Azure Active Directory B2C como proveedor de identidades. En su lugar, podría usar otros proveedores de identidades, como el id. de Microsoft Entra.
Para obtener requisitos de seguridad y cumplimiento más estrictos, puede optar por implementar redes privadas para la comunicación entre servicios.
En lugar de usar llamadas REST entre servicios, podría implementar un estilo arquitectónico controlado por eventos para la mensajería entre servicios.

Consideraciones

Estas consideraciones implementan los pilares de Azure Well-Architected Framework, que es un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.

Esta solución se basa en la identidad como paradigma de seguridad. La autenticación y autorización de las aplicaciones web y las API se rige por la plataforma de identidad de Microsoft, que es responsable de emitir y comprobar los tokens de identificador de usuario (JWT).

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costos.

Los componentes de esta solución tienen algún costo asociado a su funcionamiento, pero este costo no es elevado para la mayoría de aplicaciones web y soluciones de SaaS. Además, puede controlar el costo mediante la administración de los siguientes valores de los recursos:

Puede escalar el plan de App Service que ejecuta la aplicación para adaptarse al rendimiento que necesita. Además, puede ejecutar cada aplicación en un plan independiente si necesita un rendimiento mayor, pero incurrirá en un costo más elevado como resultado. Para más información, consulte Introducción al plan de Azure App Service.
Azure AD B2C proporciona dos SKU: Premium P1 y Premium P2. Ambas SKU incluyen una asignación gratuita para el número de usuarios activos mensuales (MAU), pero debe evaluar qué características proporciona cada SKU para determinar cuáles son necesarias para su caso de uso. Para obtener más información, consulte Precios de Id. externo de Microsoft Entra.
Azure SQL tiene varios modelos de compra para adaptarse a una amplia gama de casos de uso, y entre estos modelos se incluye la capacidad de la escalabilidad automática. Debe evaluar el uso en sus propias bases de datos para asegurarse de que ajusta el tamaño correctamente. Para más información, consulte Comparación de modelos de compra basados en DTU y núcleo virtual de Azure SQL Database.

Eficiencia del rendimiento

La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. Para obtener más información, vea Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Esta arquitectura debe ser capaz de escalarse para satisfacer fácilmente las demandas de la mayoría de las cargas de trabajo medianas a grandes. Dado que la arquitectura usa principalmente los servicios de la plataforma como servicio (PaaS) de Azure, tiene muchas opciones para ajustar el escalado de la solución en función de sus requisitos y carga.

Implementación de este escenario

Si quiere implementar este escenario, consulte el Kit de desarrollo de SaaS de Azure en GitHub. Es una implementación de referencia implementable de esta arquitectura.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Landon Pierce | Ingeniero de clientes

Otros colaboradores:

Chris Ayers | Ingeniero superior de clientes
John Downs | Ingeniero superior de clientes
LaBrina Loving | Administrador principal de ingeniería de SVC
Gary Moore | Programador/Escritor
Nick Pinheiro | Consultor sénior
William Sentinel | Ingeniero superior de clientes
Ali Sanjabi | Ingeniero superior de clientes
Arsen Vladimirskiy | Ingeniero principal de clientes
Jason Young | Administrador principal de ingeniería de SVC

Pasos siguientes

Estos son algunos recursos recomendados adicionales para crear una aplicación SaaS en Azure:

Arquitectura de soluciones multiinquilino en Azure : describe los procedimientos recomendados.
Consideraciones de ISV para zonas de aterrizaje de Azure
Microsoft Azure Well-Architected Framework
Aplicación SaaS WingTips Tickets : proporciona detalles sobre los inconvenientes entre varios modelos de arrendamiento dentro de la capa de base de datos.