Compartir a través de

Enfoques arquitectónicos para planos de control en soluciones multiinquilino

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 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. Debe pensar cuidadosamente en el plano de control y diseñarlo con el mismo rigor y cuidado que use con cualquier otra parte de la solución. Para obtener más información sobre lo que es un plano de control, por qué debe usarlo y consideraciones para diseñar uno, vea Consideraciones para 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.

Procedimientos 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 bajo código y personalizados.

Consideración Guía Código bajo Personalizado
Sobrecarga operativa Alto Bajo medio Bajo
Frecuencia de eventos del ciclo de vida que el enfoque es adecuado para Raro 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, especialmente cuando se inicia y solo tiene un pequeño número de inquilinos.

Es posible que mantenga el catálogo de inquilinos en algún lugar ubicado centralmente, como en un libro de Excel o en un archivo JSON que esté almacenado en un lugar al que el 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 a 10). La sobrecarga administrativa y el riesgo de incoherencias aumentan con cada inquilino que incorpore manualmente. Solo debe usar este enfoque si solo tiene algunos inquilinos y no necesita la 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 que no pueden ser automatizadas inicialmente, documente el proceso exhaustivamente y con detalle explícito. Documente cómo y por qué. Si alguien termina automatizando la tarea en el futuro, deben tener una buena comprensión de ambos.

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

Diagrama que muestra una manera de usar scripts y otros procesos manuales para un plano de control.

Descargar un archivo de 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 costo: mantener y ejecutar un enfoque manual es económico.
  • Valida el proceso: incluso si finalmente piensa usar un enfoque más automatizado, a partir de un enfoque manual como prueba de concepto es una buena manera 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 todos los implicados en hacer 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 acceso ampliamente con ámbito y altamente permisivo a cualquier persona que trabaje con la solución, lo que dificulta el seguimiento de 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 alejarse de un enfoque manual

  • Cuando el equipo no puede mantenerse al día con la cantidad de trabajo que deben realizar para mantener la aplicación. Por ejemplo, cuando el número de inquilinos se escala más allá de un punto crítico, que para la mayoría de los equipos está comprendido 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 algunos errores que se producen porque alguien no sigue correctamente los procesos o porque hay demasiada ambigüedad en los procesos. El riesgo de incoherencia suele crecer a medida que se incorporan más inquilinos manualmente y a medida que crece el equipo.

Plano de control de código bajo

Un plano de control sin código o bajo código se basa en una plataforma diseñada para automatizar los procesos empresariales y realizar un seguimiento de la información. Hay muchas plataformas que 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 considerar la posibilidad de mantener el mismo catálogo de inquilinos que usa para los procesos manuales, si no desea comprometerse plenamente a automatizar todo desde el principio.

Para la incorporación y el mantenimiento de inquilinos, puede usar Power Automate para ejecutar flujos de trabajo que realizan la administración de inquilinos, configurar inquilinos, desencadenar canalizaciones o llamadas API, etc. Puede usar Power Automate para ver los cambios en el catálogo de inquilinos, si los datos están accesibles en algún lugar para Power Automate. Si usa un catálogo de inquilinos manual, los flujos de trabajo de Power Automate también se pueden desencadenar manualmente. Es posible que decida incluir pasos de aprobación manuales en los flujos de trabajo si necesita que alguien del equipo compruebe algo o realice pasos adicionales que no se puedan automatizar completamente.

Este enfoque también le permite proporcionar un registro de autoservicio a los clientes al permitir que la aplicación web agregue directamente registros al catálogo de inquilinos sin intervención humana.

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

Diagrama que muestra una manera de usar Power Automate y Dataverse como plano de control de código bajo.

Descargar un archivo de Visio de esta arquitectura.

Ventajas de un enfoque de código bajo

  • Ligero: a menudo es rápido y económico crear un conjunto de flujos de trabajo de código bajo y conectarlos a los sistemas circundantes.
  • Usa herramientas de plataforma: puede usar características de plataforma nativas 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 usted mismo.
  • 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 ayuda a facilitar una implementación gradual.
  • Sobrecarga baja: los servicios de código bajo suelen administrarse completamente, por lo que no es necesario administrar la infraestructura.

Desventajas de un enfoque de poco código

  • Conocimientos necesarios: para usar plataformas de poco código para crear procesos y para usar eficazmente estas plataformas, normalmente necesita conocimientos propietarios. Muchas organizaciones ya usan estas herramientas, por lo que es posible que el equipo ya tenga la experiencia necesaria, pero es posible que no lo haga. Debe considerar si necesita entrenar a su equipo para poder usar 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 cuidadosamente 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 poco código.

Cuándo considerar la posibilidad de alejarse de un enfoque de código bajo

  • Finalmente, los requisitos podrían ser tan complejos que no se puedan incorporar con sensibilidad en una solución de código bajo. Cuando necesite solucionar las limitaciones de las herramientas para satisfacer sus necesidades, probablemente tenga sentido alejarse de una solución administrada y hacia 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 proporciona la mayor flexibilidad y potencia, pero también requiere el mayor trabajo. Normalmente, el catálogo de inquilinos se almacena en una base de datos. En este caso, no trabaja directamente con el catálogo, sino que lo administra a través de una interfaz administrativa, que podría ser una aplicación personalizada o un sistema como la aplicación de administración de relaciones con el cliente (CRM) de su organización.

Normalmente, se crea un conjunto de componentes del plano de control diseñados 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 código o infraestructura cuando se produzcan eventos de ciclo de vida del inquilino, las canalizaciones de implementación también pueden componer el 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 los componentes que necesitan comunicarse con sistemas externos.

Al igual que el enfoque de poco código, este enfoque le permite proporcionar un registro de autoservicio a los clientes al permitir que la aplicación web agregue directamente registros al 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 que muestra un plano de control creado con Durable Functions, una base de datos SQL y un bus de servicio.

Descargar un archivo de Visio de esta arquitectura.

Ventajas de un enfoque personalizado

  • Total flexibilidad y personalización: tiene control total 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 porque necesita crear todo usted mismo. Un plano de control es tan importante como cualquier otra parte de la aplicación. Debe tener mucho cuidado en el desarrollo, las pruebas y el funcionamiento del plano de control para asegurarse de que es confiable 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. Considere la posibilidad de implementar un enfoque híbrido si necesita la personalización de un plano de control personalizado, pero no quiere compilar y mantener un sistema totalmente personalizado. Tenga en cuenta que, en algún momento, las personalizaciones automatizadas en los procesos manuales o la plataforma administrada pueden ser tan complejas como un sistema totalmente personalizado. El punto de inflexión es diferente para cada organización, pero si el enfoque híbrido es complicado de mantener, debe considerar la posibilidad de pasar a un sistema totalmente personalizado.

Implementación gradual

Incluso si sabe que desea automatizar finalmente el plano de control, no es necesariamente necesario empezar con ese enfoque. Un enfoque común durante las fases iniciales de creación de la aplicación es comenzar con un plano de control manual. A medida que la aplicación avanza e incorpora más inquilinos, debe empezar a identificar las áreas de cuello de botella y automatizarlas según sea necesario, pasando a un enfoque híbrido. A medida que automatiza más, es posible que finalmente tenga un plano de control totalmente automatizado.

Antipatrones que se deben evitar

  • Confiar en procesos manuales durante demasiado tiempo. Aunque es razonable usar procesos manuales cuando empiece o cuando tenga un número bajo de inquilinos y requiera una administración bastante ligera, debe planear cómo escalar a una solución automatizada a medida que crezca. Si necesita contratar miembros adicionales del equipo para mantenerse al día con la demanda de los procesos manuales, es una buena señal de que debe empezar a automatizar partes del plano de control.
  • Uso de herramientas inapropiadas para flujos de trabajo de larga duración. Por ejemplo, evite usar 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 o orquestaciones en varios pasos. En su lugar, use herramientas como Azure Logic Apps, Durable Functions y otras herramientas que pueden realizar flujos de trabajo de larga duración o secuencias de operaciones. Para más información, consulte Rendimiento y confiabilidad de Azure Functions ypatrón de Request-Reply asincrónico.

Colaboradores

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

Autores principales:

Otros colaboradores:

Pasos siguientes