Compartir a través de

Enfoques de arquitectura para los planos de control en soluciones multiinquilino

  • Artículo

Los planos de control son una parte importante del software como servicio (SaaS) y las soluciones multiinquilino, especialmente para ayudar a administrar una solución a gran escala. Normalmente, hay dos componentes principales que componen un plano de control:

  • El catálogo de inquilinos, que almacena información importante sobre los inquilinos, como:
    • Configuración del inquilino.
    • SKU implementadas para los recursos de inquilino.
    • A qué sellos de implementación se asignan los inquilinos.
  • Procesos para administrar los cambios en el entorno, que se desencadenan mediante eventos de ciclo de vida del inquilino. Por ejemplo, la incorporación de inquilinos, la retirada de inquilinos y cualquier mantenimiento normal necesario.

Un plano de control es una aplicación. Hay que pensar detenidamente en el plano de control y diseñarlo con el mismo rigor y cuidado que cualquier otra parte de la solución. Para obtener más información sobre qué es un plano de control, por qué debería usarlo y consideraciones para diseñar uno, consulte Consideraciones para los planos de control multiinquilino.

En este artículo se describen algunos enfoques que puede considerar para diseñar y crear un plano de control. La lista de enfoques descritos aquí no es completa. Aunque todos los enfoques son válidos, hay otras arquitecturas válidas.

Enfoques y patrones que se deben tener en cuenta

En la tabla siguiente se resumen las diferencias entre algunos de los enfoques que puede considerar para un plano de control. Se comparan los enfoques manuales, de código bajo y personalizados.

Consideración Manual Con poco código Personalizado
Sobrecarga operativa Alto Baja-Media Bajo
Frecuencia de los eventos del ciclo de vida para los que es adecuado el enfoque poco frecuente Ocasionalmente, a menudo Frecuentemente
Tiempo y complejidad a implementar Bajo Medio Alto
Responsabilidades de mantenimiento del plano de control Bajo Medio Alto
Capacidad de prueba Bajo Medio Alto
Riesgo de incoherencias Alto Medio-bajo Bajo

Procesos manuales

No siempre es esencial crear un plano de control totalmente automatizado, sobre todo cuando se está empezando y solo se tiene un pequeño número de inquilinos.

Puede conservar su catálogo de inquilinos en algún lugar centralizado, como un libro de Excel o un archivo JSON almacenado en un lugar al que su equipo pueda acceder. Independientemente del formato, es una buena idea almacenar la información de forma estructurada para que pueda trabajar fácilmente con los datos mediante programación.

Nota:

Un plano de control manual es una excelente manera de empezar a administrar la aplicación multiinquilino, pero solo es adecuado para un pequeño número de inquilinos (menos de 5-10). La sobrecarga administrativa y el riesgo de incoherencias aumentan con cada inquilino que incorpore manualmente. Solo debe usar este enfoque si tiene pocos inquilinos y no necesita una incorporación automatizada o de autoservicio.

Para procesos como la incorporación de inquilinos y las actividades de mantenimiento:

  • Cree scripts o canalizaciones automatizadas siempre que sea posible, incluso si los ejecuta manualmente. Al usar scripts o canalizaciones, asegúrese de que los pasos se ejecutan de forma coherente para cada inquilino.
  • Para las tareas en las que no se puedan crear scripts inicialmente, documente el proceso de forma exhaustiva y explícita. Documente el cómo y el por qué. Si alguien acaba automatizando la tarea en el futuro, debería conocer bien ambas cosas.

En el diagrama siguiente se muestra una manera de usar procesos manuales para un plano de control inicial:

Diagrama con una forma de usar scripts y otros procesos manuales en un plano de control.

Descargue un archivo Visio de esta arquitectura.

Ventajas de un enfoque manual

  • Ligero: la documentación, los scripts y las canalizaciones son fáciles de desarrollar y modificar. Esto hace que sean apropiados cuando se están definiendo los procesos, ya que se pueden iterar y evolucionar rápidamente.
  • Bajo coste: mantener y ejecutar un enfoque manual es económico.
  • Valida el proceso: incluso si con el tiempo tiene la intención de utilizar un enfoque más automatizado, empezar con un enfoque manual como prueba de concepto es una buena forma de validar la estrategia de mantenimiento antes de invertir tiempo en desarrollar una automatización más sólida.

Desventajas de un enfoque manual

  • Falta de control: este enfoque se basa en que todos los implicados hagan lo correcto. Alguien podría desviarse de los procesos prescritos, ya sea accidental o intencionadamente. Cada variación en el proceso aumenta el riesgo de incoherencia en su entorno, lo que hace que la administración continua sea mucho más difícil.
  • Desafíos de control de acceso: cuando se usa este enfoque, normalmente es necesario conceder un acceso muy permisivo y amplio a cualquiera que use la solución, lo que dificulta seguir los procedimientos recomendados para la segmentación de acceso.
  • Escalabilidad: el trabajo necesario para ejecutar procesos manuales se escala con el número de inquilinos que necesita administrar.
  • Capacidad de prueba: los procesos manuales son difíciles de validar y probar.

Cuándo considerar la posibilidad de abandonar el enfoque manual

  • Cuando el equipo no puede mantenerse al día con la cantidad de trabajo necesaria para mantener la aplicación. Por ejemplo, cuando el número de inquilinos supera un punto crítico, que para la mayoría de los equipos se sitúa entre 5 y 10 inquilinos.
  • Cuando prevé que el número de inquilinos crecerá por encima de un número crítico y necesita prepararse para el trabajo que supone administrar ese número de inquilinos.
  • Cuando necesite mitigar el riesgo de incoherencias. Por ejemplo, puede observar que se producen algunos errores porque alguien no sigue los procesos correctamente o porque hay demasiada ambigüedad en los procesos. El riesgo de incoherencia suele aumentar a medida que más inquilinos se incorporan manualmente y a medida que crece el equipo.

Plano de control de código bajo

Un plano de control de poco código o ninguno se basa en una plataforma diseñada para automatizar los procesos empresariales y realizar un seguimiento de la información. Hay muchas plataformas que le permiten realizar estas tareas sin escribir código personalizado.

Microsoft Power Platform es un ejemplo de una de estas plataformas. Si usa Power Platform, puede mantener el catálogo de inquilinos en Dynamics 365, Dataverse o Microsoft 365. También puede pensar en mantener el mismo catálogo de inquilinos que usa para sus procesos manuales, si no desea encargarse de automatizar todo al principio.

Para la integración y el mantenimiento de inquilinos, puede usar Power Automate para ejecutar flujos de trabajo que se ocupen de la administración de inquilinos, configuren inquilinos, activen procesos o llamadas a API, etc. Puede usar Power Automate para buscar cambios en el catálogo de inquilinos, si los datos están en algún lugar accesible para Power Automate. Si usa un catálogo de inquilinos manual, los flujos de trabajo de Power Automate también se pueden desencadenar manualmente. Puede que decida incluir pasos de aprobación manual en sus flujos de trabajo si necesita que alguien de su equipo compruebe algo o realice pasos adicionales que no pueden automatizarse por completo.

Este método también le permite habilitar un registro de autoservicio a sus clientes al permitir que la aplicación web acepte registros directamente a su catálogo de inquilinos sin intervención humana.

En el diagrama siguiente se muestra cómo puede crear un plano de control con el registro de autoservicio mediante Microsoft Power Platform:

Diagrama con una forma de usar Power Automate y Dataverse como plano de control con poco código.

Descargue un archivo Visio de esta arquitectura.

Ventajas de un enfoque de código bajo

  • Ligero: a menudo es más rápido y económico crear un conjunto de flujos de trabajo con poco código y conectarlos a los sistemas circundantes.
  • Usa herramientas de plataforma: puede usar características nativas de la plataforma para almacenar datos, crear portales administrativos para que el equipo los use y supervisar los flujos de trabajo a medida que se ejecutan. Mediante el uso de características nativas de la plataforma, evita crear muchos componentes por su cuenta.
  • Personalizable: si necesita más personalización, normalmente puede aumentar los flujos de trabajo con código y procesos personalizados. Por ejemplo, puede usar Power Automate para desencadenar un flujo de trabajo de implementación en Acciones de GitHub o puede invocar Azure Functions para ejecutar su propio código. Esto también favorece una implementación gradual.
  • Baja sobrecarga: los servicios de código bajo suelen estar totalmente administrados, por lo que no es necesario administrar la infraestructura.

Desventajas de un enfoque de código bajo

  • Experiencia necesaria: para utilizar plataformas de código bajo para crear procesos, y para utilizar eficazmente estas plataformas, normalmente se necesitan conocimientos propios. Muchas organizaciones ya utilizan estas herramientas, por lo que es posible que su equipo ya cuente con los conocimientos necesarios, pero puede que no. Debe plantearse si necesita formar a su equipo para utilizar eficazmente estas plataformas.
  • Administración: puede ser difícil controlar la administración de grandes cantidades de configuración de código bajo.
  • Capacidad de prueba: considere la posibilidad de probar y promover cambios en el plano de control. En una plataforma administrada, crear un proceso típico de DevOps para probar y promover cambios es más difícil, ya que los cambios se realizan normalmente a través de la configuración, no a través del código.
  • Diseño: piense detenidamente en cómo cumplir los requisitos no funcionales, como la seguridad y la confiabilidad. Estos requisitos a menudo se administran automáticamente en una plataforma de código bajo.

Cuándo hay que plantearse abandonar un enfoque de código bajo

  • Con el tiempo, sus requisitos pueden llegar a ser tan complejos que no pueda incorporarlos de forma razonable en una solución de código reducido. Cuando necesite trabajar con herramientas limitadas para satisfacer sus necesidades, probablemente tenga sentido alejarse de una solución administrada y optar por un plano de control personalizado.

Plano de control personalizado

También puede considerar la posibilidad de crear su propio plano de control completamente personalizado. Esta opción es la más flexible y potente, pero también la que requiere más trabajo. Normalmente, el catálogo de inquilinos se almacena en una base de datos. En este caso, no se trabaja directamente con el catálogo, sino que se administra a través de una interfaz administrativa, que puede ser una aplicación personalizada o un sistema como la aplicación de administración de las relaciones con el cliente (CRM) de su organización.

Normalmente se crea un conjunto de componentes del plano de control diseñado en torno a todas las funciones administrativas del inquilino. Estos componentes pueden incluir un portal administrativo u otra interfaz de usuario, una API y componentes de procesamiento en segundo plano. Si necesita hacer cosas como implementar un código o una infraestructura cuando se producen eventos de ciclo de vida de inquilino, las canalizaciones de implementación también pueden formar parte del plano de control.

Asegúrese de que cualquier procesamiento de larga duración usa las herramientas adecuadas. Por ejemplo, puede usar Durable Functions o Azure Logic Apps para componentes que orquestan la incorporación o implementación de inquilinos, o para componentes que necesitan comunicarse con sistemas externos.

Al igual que el enfoque de código bajo, este enfoque le permite ofrecer un registro de autoservicio a sus clientes al permitir que su aplicación web añada directamente registros a su catálogo de inquilinos sin intervención humana.

En el diagrama siguiente se muestra una manera de crear un plano de control personalizado básico que proporciona registro de autoservicio:

Diagrama con un plano de control creado con Durable Functions, una base de datos SQL y un bus de servicio.

Descargue un archivo Visio de esta arquitectura.

Ventajas de un enfoque personalizado

  • Total flexibilidad y personalización: tiene control completo sobre lo que hace el plano de control y puede cambiarlo si cambian sus requisitos.
  • Capacidad de prueba: puede usar un ciclo de vida de desarrollo de software estándar (SDLC) para la aplicación del plano de control e implementar enfoques normales para pruebas e implementaciones, como lo haría con las aplicaciones principales.

Desventajas de un enfoque personalizado

  • Responsabilidades de mantenimiento: este enfoque requiere más sobrecarga de mantenimiento, ya que tiene que crearlo todo usted mismo. Un plano de control es tan importante como cualquier otra parte de la aplicación. Debe tener mucho cuidado al desarrollar, probar y utilizar su plano de control para asegurarse de que sea fiable y seguro.

Enfoques híbridos

También puede considerar el uso de un enfoque híbrido. Puede usar una combinación de sistemas manuales y automatizados, o puede usar una plataforma administrada como Microsoft Power Platform y aumentarla con aplicaciones personalizadas. Plantéese la posibilidad de implementar un modelo híbrido si prefiere la personalización de un plano de control a medida, pero no necesariamente desea crear y mantener un sistema totalmente personalizado. Tenga en cuenta que, en algún momento, las personalizaciones automatizadas de sus procesos manuales o de su plataforma administrada pueden llegar a ser tan complejas como un sistema totalmente personalizado. El punto de inflexión es diferente en cada organización, pero si su modelo híbrido le resulta difícil de mantener, debería considerar pasar a un sistema totalmente personalizado.

Implementación gradual

Incluso si sabe que con el tiempo desea automatizar el plano de control, no tiene por qué empezar con ese enfoque. Un enfoque común durante las etapas iniciales de la creación de la aplicación es comenzar con un plano de control manual. A medida que la aplicación progrese e incorpore más inquilinos, debería empezar a identificar las áreas con cuellos de botella y automatizarlas según sea necesario, pasando a un enfoque híbrido. A medida que se automatiza más, se puede llegar a tener un plano de control totalmente automatizado.

Antipatrones que se deben evitar

  • Confiar en procesos manuales durante demasiado tiempo. Aunque es razonable utilizar procesos manuales cuando se empieza o cuando se tiene un número bajo de inquilinos y se requiere una administración bastante ligera, hay que planificar cómo escalar a una solución automatizada a medida que se crece. Si necesita contratar más miembros al equipo para cubrir la demanda de sus procesos manuales, sería recomendable comenzar a automatizar partes de su plano de control.
  • Usar herramientas inapropiadas para flujos de trabajo de larga duración. Por ejemplo, evite utilizar funciones estándar de Azure, llamadas API sincrónicas u otras herramientas que tengan un límite de tiempo de ejecución para realizar operaciones de larga duración, como implementaciones de Azure Resource Manager u orquestaciones de varios pasos. En su lugar, use herramientas como Azure Logic Apps, Durable Functions y otras herramientas que puedan realizar flujos de trabajo de larga duración o secuencias de operaciones. Para más información, consulte Rendimiento y confiabilidad de Azure Functions y Patrón asincrónico de solicitud-respuesta.

Colaboradores

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

Creadores de entidad de seguridad:

Otros colaboradores:

Pasos siguientes