Automatización en la nube basada en eventos

La automatización de flujos de trabajo y tareas repetitivas en la nube mediante tecnologías sin servidor puede mejorar enormemente la productividad del equipo de DevOps de una organización. Un modelo sin servidor es más adecuado para escenarios de automatización que se ajustan a un enfoque basado en eventos.

Architecture

Escenarios

En este artículo se ilustran dos de escenarios clave de automatización en la nube:

1. Etiquetado del centro de coste: esta implementación realiza el seguimiento de los centros de coste de cada recurso de Azure. El servicio Azure Policyetiqueta todos los recursos nuevos de un grupo con un identificador de centro de costos predeterminado. Azure Event Grid supervisa los eventos de creación de recursos y, luego, llama a una función de Azure. La función interactúa con Microsoft Entra ID y valida el identificador del centro de costos del nuevo recurso. Si es diferente, actualiza la etiqueta y envía un correo electrónico al propietario del recurso. Por motivos de simplicidad, las consultas REST de Microsoft Entra ID se han simulado. Microsoft Entra ID también se puede integrar mediante el módulo de Microsoft Graph PowerShell o la biblioteca de autenticación de Microsoft (MSAL) para Python.

2. Respuesta a la limitación: en este ejemplo se supervisa la limitación de una base de datos de Azure Cosmos DB. Las alertas de Azure Monitor se desencadenan cuando las solicitudes de acceso a datos para Azure Cosmos DB superan la capacidad de las Unidades de solicitud (o RU). Un grupo de acciones de Azure Monitor está configurado para llamar a la función de automatización en respuesta a estas alertas. La función escala las RU a un valor mayor, lo que aumenta la capacidad y, a su vez, detiene las alertas.

La implementación de referencia del primer escenario está disponible en GitHub.

Las funciones de estos escenarios de automatización de la nube sin servidor se escriben normalmente en PowerShell y Python, dos de los lenguajes de scripting más comunes que se usan en la automatización del sistema. Se implementan mediante Azure Functions Core Tools en la CLI de Azure. Como alternativa, use el cmdlet Az.Functions de PowerShell para implementar y administrar Azure Functions.

Flujo de trabajo

Los escenarios de automatización basada en eventos se implementan mejor mediante Azure Functions. Siguen estos patrones comunes:

• Respuesta a eventos sobre recursos. Son respuestas a eventos, por ejemplo, que un recurso o un grupo de recursos de Azure se ha creado, eliminado, cambiado, etc. Este patrón usa Event Grid para desencadenar la función cuando se producen dichos eventos. El escenario de etiquetado del centro de coste es un ejemplo de este patrón. Otros escenarios comunes son los siguientes:

  • conceder a los equipos de DevOps acceso a los grupos de recursos recién creados,
  • enviar una notificación al equipo de DevOps cuando se elimina un recurso y
  • responder a los eventos de mantenimiento de recursos, como Azure Virtual Machines (VM).

• Tareas programadas. Normalmente, son tareas de mantenimiento que se ejecutan mediante funciones desencadenadas por un temporizador. Ejemplos de este patrón son:

  • detener un recurso por la noche e iniciarlo por la mañana,
  • leer contenido de Blob Storage a intervalos periódicos y convertirlo en un documento de Azure Cosmos DB,
  • examinar periódicamente los recursos para ver los que ya no se usan y quitarlos, y
  • hacer copias de seguridad automatizadas.

• Procesamiento de alertas de Azure. Este patrón usa la facilidad de integración de las alertas y grupos de acciones de Azure Monitor con Azure Functions. La función suele tomar medidas correctivas en respuesta a las métricas, los análisis de registros y las alertas originadas en las aplicaciones, y en la infraestructura. El escenario de respuesta a la limitación es un ejemplo de este patrón. Otros escenarios comunes son:

  • truncar la tabla cuando SQL Database alcance el tamaño máximo,
  • reiniciar un servicio en una máquina virtual cuando se detenga por error, y
  • enviar notificaciones si se produce un error en una función.

• Organización con sistemas externos. Este patrón permite la integración con sistemas externos usando Logic Apps para organizar el flujo de trabajo. Los conectores de Logic Apps se pueden integrar fácilmente con varios servicios de terceros, así como con servicios de Microsoft, como Microsoft 365. Azure Functions se puede usar para la automatización real. El escenario de etiquetado del centro de coste demuestra este patrón. Otros escenarios comunes son los siguientes:

  • supervisar los procesos de TI, como solicitudes de cambio o aprobaciones, y
  • enviar una notificación por correo electrónico cuando se complete la tarea de automatización.

• Exposición como webhook o API web. Las tareas de automatización que usan Azure Functions pueden integrarse en aplicaciones de terceros o incluso en herramientas de línea de comandos, mediante la exposición de la función como un webhook o una API web mediante un desencadenador HTTP. PowerShell y Python cuentan con varios métodos de autenticación para proteger el acceso externo a la función. La automatización se produce en respuesta a los eventos externos específicos de la aplicación, por ejemplo, la integración con Power Apps o GitHub. Entre los escenarios habituales se incluyen los siguientes:

  • desencadenar la automatización cuando un servicio produce un error e
  • incorporar usuarios a los recursos de la organización.

• Creación de la interfaz de ChatOps. Este patrón permite a los clientes crear una interfaz operativa basada en chat y ejecutar funciones y comandos de desarrollo y operaciones en consonancia con la colaboración humana. Se puede integrar con Azure Bot Framework y usar los comandos de Microsoft Teams o Slack para la implementación, la supervisión, las preguntas comunes, etc. Una interfaz de ChatOps crea un sistema en tiempo real para administrar los incidentes de producción, donde cada paso se documenta automáticamente en el chat. Para más información, lea Cómo ChatOps puede ayudarle a mejorar DevOps.

• Automatización híbrida. Este patrón utiliza las conexiones híbridas de Azure App Service para instalar un componente de software en la máquina local. Este componente permite el acceso seguro a los recursos de esa máquina. La capacidad de administrar entornos híbridos está disponible actualmente en sistemas basados en Windows con funciones de PowerShell. Entre los escenarios habituales se incluyen los siguientes:

  • administrar las máquinas locales y
  • administrar otros sistemas detrás del firewall (por ejemplo, una instancia de SQL Server local) mediante un servidor de salto.

Componentes

La arquitectura consta de los siguientes componentes:

• Azure Functions. Azure Functions proporciona las funcionalidades de proceso sin servidor basadas en eventos de esta arquitectura. Una función realiza tareas de automatización cuando se desencadena por medio de eventos o alertas. En dos escenarios, se invoca una función con una solicitud HTTP. La complejidad del código se debe minimizar mediante el desarrollo de una función que sea sin estadoeidempotente.

  Varias ejecuciones de una función idempotente crean los mismos resultados. Para mantener la idempotencia, el escalado de la función en el escenario de limitación se ha simplificado. En la automatización real, asegúrese de escalarla o reducirla verticalmente de forma adecuada. Para conocer los procedimientos recomendados al escribir las funciones, lea Optimización del rendimiento y confiabilidad de Azure Functions.

• Azure Logic Apps. Logic Apps se puede usar para realizar tareas más sencillas, que se implementan fácilmente con los conectores integrados. Estas tareas pueden abarcar desde notificaciones por correo electrónico hasta la integración con aplicaciones de administración externas. Para información sobre cómo usar Logic Apps con aplicaciones de terceros, lea Integración empresarial básica en Azure.

  Logic Apps proporciona un diseñador visual sin código o de poco código, que se puede usar solo en algunos escenarios de automatización. Para ver qué servicio puede ajustarse a su escenario, lea esta comparación entre Azure Functions y Logic Apps.

• Event Grid. Event Grid tiene compatibilidad integrada con eventos de otros servicios de Azure, así como con eventos personalizados (también denominados temas personalizados). Los eventos operativos, como la creación de recursos, se pueden propagar fácilmente a la función de automatización mediante el mecanismo integrado de Event Grid.

  Event Grid simplifica la automatización basada en eventos con un modelo de publicación-suscripción, lo que permite una automatización confiable para eventos entregados mediante HTTP.

• Azure Monitor. Las alertas de Azure Monitor pueden supervisar condiciones críticas y tomar las medidas correctivas adecuadas mediante grupos de acciones de Azure Monitor. Estos grupos de acciones se integran fácilmente con Azure Functions, lo que resulta útil para supervisar y corregir las condiciones de error de la infraestructura, como la limitación de la base de datos.

• Acción de automatización. Este amplio bloque representa otros servicios con los que la función puede interactuar para proporcionar la funcionalidad de automatización. Por ejemplo, Microsoft Entra ID para la validación de etiquetas como en el primer escenario, o una base de datos para aprovisionar como en el segundo escenario.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Resistencia

Azure Functions

Control de los tiempos de espera HTTP

Para evitar los tiempos de espera HTTP con tareas de automatización más largas, ponga en cola este evento en una instancia de Service Bus y controle la automatización real en otra función. El escenario de automatización de respuesta a la limitación ilustra este patrón, aunque el aprovisionamiento real de las RU de Azure Cosmos DB es rápido.

Durable Functions, que mantiene el estado entre invocaciones, proporciona una alternativa al enfoque anterior. En Durable Functions solo se admiten lenguajes específicos.

Registro de errores

Como procedimiento recomendado, la función debe registrar cualquier error en la realización de tareas de automatización. De esta forma, se pueden solucionar correctamente las condiciones de error. Azure Functions admite de forma nativa la integración con Application Insights como sistema de telemetría.

Simultaneidad

Compruebe el requisito de simultaneidad de la función de automatización. La simultaneidad se limita con el establecimiento de la variable maxConcurrentRequests en el archivo host.json. Este valor limita el número de instancias de función simultáneas que se ejecutan en la aplicación de función. Puesto que cada instancia consume CPU y memoria, este valor debe ajustarse en el caso de operaciones que consuman mucha CPU. Si las llamadas a la función parecen ser demasiado lentas o no se pueden completar, reduzca el valor de maxConcurrentRequests. Para más información, consulte la sección Configuración de los comportamientos de host para controlar mejor la simultaneidad.

Idempotencia

Asegúrese de que la función de automatización sea idempotente. Tanto Azure Monitor como Event Grid pueden emitir alertas o eventos que indiquen progresión, por ejemplo, el evento suscrito está resuelto, se ha desencadenado, está en curso, etc., el recurso se está aprovisionando, se ha creado correctamente, etc., o incluso enviar alertas falsas debido a una configuración errónea. Asegúrese de que la función solo actúa sobre las alertas y los eventos pertinentes y omite todos los demás, de modo que los eventos falsos o mal configurados no produzcan resultados indeseados. Para obtener más información, vea Diseño de funciones de Azure para entradas idénticas.

Event Grid

Si el flujo de trabajo usa Event Grid, compruebe si su escenario podría generar un gran volumen de eventos, suficientes para bloquear la cuadrícula. Consulte Entrega y reintento de entrega de mensajes de Event Grid para comprender cómo se controlan los eventos cuando no se confirma la entrega y modificar la lógica en consecuencia. El flujo de trabajo del centro de costos no implementa comprobaciones adicionales en estos casos, ya que solo inspecciona los eventos de creación de recursos de un grupo de recursos. Los recursos de supervisión creados en una suscripción completa pueden generar un mayor número de eventos, lo que requiere un control más resistente.

Azure Monitor

Si se genera un número suficientemente grande de alertas y la automatización actualiza los recursos de Azure, es posible que se alcancen los límites de Azure Resource Manager. Esto puede afectar de forma negativa al resto de la infraestructura de esa suscripción. Para evitar esta situación, limite la frecuencia de las alertas generadas por Azure Monitor. También puede limitar las alertas que se generan cuando se produce un error determinado. Para más información, consulte la documentación sobre las alertas de Azure Monitor.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

Control de acceso a la función

Restrinja el acceso a una función desencadenada por HTTP estableciendo el nivel de autorización. Con la autenticación anónima, se puede acceder fácilmente a la función con una dirección URL, como http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. La autenticación de nivel de función puede ofuscar el punto de conexión http al requerir las claves de función en la dirección URL. Este nivel se establece en el archivo function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

En el entorno de producción, es posible que se requieran estrategias adicionales para proteger la función. En estos escenarios de referencia, otros servicios de Azure ejecutan las funciones en la plataforma Azure, y no se exponen a Internet. En ocasiones la autorización de funciones es suficiente para las funciones a las que se accede como enlaces web.

Considere la posibilidad de agregar capas de seguridad sobre la autenticación de funciones, como,

• autenticación con certificados de cliente, o
• asegúrese de que el autor de la llamada forme parte del directorio en el que se hospeda la función, o tenga acceso a él, mediante la habilitación de la autenticación de App Service.

La autenticación de nivel de función es la única opción disponible para los grupos de acciones de Azure Monitor que usan Azure Functions.

Si es necesario llamar a la función desde una aplicación o un servicio de terceros, se recomienda proporcionar acceso a ella con una capa de API Management. Esta capa debe exigir la autenticación. API Management tiene un nivel de consumo integrado con Azure Functions, lo que le permite pagar solo si se ejecuta la API. Para más información, lea Creación y exposición de las funciones con OpenAPI.

Si el servicio que realiza la llamada admite puntos de conexión de servicio o vínculo privado, se pueden considerar las siguientes opciones más costosas:

• Use un plan de App Service dedicado, donde puede bloquear las funciones de una red virtual para limitar el acceso a ella. Esto no es posible en un modelo sin servidor basado en el consumo.
• Use el plan Premium de Azure Functions, que incluye una red virtual dedicada que usarán las aplicaciones de función.

Para comparar los precios y las características entre estas opciones, lea Escalado y hospedaje de Azure Functions.

Control del acceso de la función

Identidades administradas de recursos de Azure, una característica de Microsoft Entra, simplifica el modo en que la función se autentica y accede a otros recursos y servicios de Azure. No es necesario que el código administre las credenciales de autenticación, ya que se administran mediante Microsoft Entra ID.

Hay dos tipos de identidades administradas:

• Identidades administradas asignadas por el sistema: se crean como parte del recurso de Azure y no se pueden compartir entre varios recursos. Se eliminan cuando se elimina el recurso. Úselas en escenarios que abarquen un único recurso de Azure o que necesiten identidades independientes. En los dos escenarios se usan identidades asignadas por el sistema, ya que solo actualizan un recurso. Las identidades administradas solo son necesarias para actualizar otro recurso. Por ejemplo, una función puede leer las etiquetas de recursos sin una identidad administrada. Consulte estas instrucciones para agregar una identidad asignada por el sistema a la función.

• Identidades administradas asignadas por el usuario: se crean como recursos de Azure independientes. Se pueden compartir entre varios recursos y deben eliminarse de forma explícita cuando ya no sean necesarias. Lea estas instrucciones sobre cómo agregar identidades asignadas por el usuario a la función. Úselas en escenarios que:

  • requieran el acceso a varios recursos que pueden compartir una única identidad,
  • necesiten autorización previa para proteger los recursos durante el aprovisionamiento o
  • tengan recursos que se reciclen con frecuencia, pero sea necesario mantener la coherencia de los permisos.

Una vez asignada la identidad a la función de Azure, asígnele un rol mediante el control de acceso basado en rol de Azure (Azure RBAC) para acceder a los recursos. Por ejemplo, para actualizar un recurso, se tendrá que asignar el rol Colaborador a la identidad de la función.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Puede usar la calculadora de precios de Azure para calcular los costos. A continuación, se incluyen algunas consideraciones que se deben tener en cuenta para reducir el costo.

Azure Logic Apps

Logic Apps tiene un modelo de precios de pago por uso. Cada vez que se ejecuta una aplicación lógica se miden los desencadenadores, las acciones y las ejecuciones de conectores. Todas las acciones, tanto las correctas como las incorrectas, entre las que se incluyen los desencadenadores, se consideran ejecuciones.

Logic Apps también tiene un modelo de precios fijo. Si necesita ejecutar aplicaciones lógicas que se comunican con recursos protegidos en una red virtual de Azure, puede crearlas en un Entorno del servicio de integración (ISE).

Para más información, consulte Modelo de precios de Azure Logic Apps.

En esta arquitectura, se usan aplicaciones lógicas en el escenario de etiquetado del centro de costos para organizar el flujo de trabajo.

Se usan conectores integrados para conectarse a Azure Functions y enviar notificaciones por correo electrónico cuando se completa una tarea de automatización. Las funciones se exponen como un webhook o una API web mediante un desencadenador HTTP. Solo se desencadenan aplicaciones lógicas cuando se produce una solicitud HTTPS. Este es un método rentable en comparación con un diseño en el que las funciones sondean y comprueban de forma continuada determinados criterios. Cada solicitud de sondeo se mide como una acción.

Para obtener más información, consulte Precios de Logic Apps.

Azure Functions

Azure Functions está disponibles con los tres planes de precios siguientes.

• Plan de consumo. Este es el plan sin servidor más rentable disponible, donde solo se paga por el tiempo que se ejecuta la función. En este plan, las funciones se pueden ejecutar durante 10 minutos como máximo cada una.

• Plan Premium. Considere la posibilidad de usar el plan Premium de Azure Functions para escenarios de automatización con requisitos adicionales, como una red virtual dedicada, una duración de ejecución más larga, etc. Estas funciones se pueden ejecutar durante una hora como máximo, y deben elegirse para tareas de automatización más largas, como la ejecución de copias de seguridad, la indexación de la base de datos o la generación de informes.

• Plan de App Service. Los escenarios de automatización híbridos que usan las conexiones híbridas de Azure App Service deberán utilizar el plan de App Service. Las funciones creadas en este plan se pueden ejecutar con una duración ilimitada, de forma parecida a una aplicación web.

En estos escenarios de automatización, se usa Azure Functions para tareas como la actualización de etiquetas en Microsoft Entra ID o la modificación de la configuración de Azure Cosmos DB mediante el escalado vertical de las RU a un valor superior. El plan de consumo es el adecuado para este caso de uso, ya que esas tareas son interactivas y no de larga duración.

Azure Cosmos DB

Azure Cosmos DB factura el rendimiento aprovisionado y el almacenamiento consumido por hora. El rendimiento aprovisionado se expresa en unidades de solicitud por segundo (RU/s), que se pueden usar para las operaciones de base de datos comunes, como inserciones o lecturas. El almacenamiento se factura por cada GB usado para los datos e índice almacenados. Para obtener más información, consulte Modelo de precios de Azure Cosmos DB.

En esta arquitectura, las alertas de Azure Monitor se desencadenan cuando las solicitudes de acceso a datos a Azure Cosmos DB superan la capacidad de las Unidades de solicitud (o RU). En respuesta a estas alertas, se configura un grupo de acciones de Azure Monitor para llamar a la función de automatización. La función escala las RU a un valor superior. Esto ayuda a reducir el costo porque solo se paga por los recursos que necesitan las cargas de trabajo por hora.

Para obtener una estimación rápida del costo de la carga de trabajo, use la calculadora de capacidad de Azure Cosmos DB.

Para más información, consulte la sección Costo en Marco de buena arquitectura de Microsoft Azure.

Consideraciones de la implementación

En el caso de flujos de trabajo de automatización críticos que administran el comportamiento de la aplicación, se debe conseguir una implementación sin tiempo de inactividad mediante una canalización de DevOps eficaz. Para más información, lea Implementación del back-end sin servidor.

Si la automatización abarca varias aplicaciones, mantenga los recursos necesarios para la automatización en un grupo de recursos aparte. Si la automatización abarca una sola aplicación, se puede compartir un solo grupo de recursos entre los recursos de la aplicación y de automatización.

Si el flujo de trabajo conlleva una serie de funciones de automatización, agrupe las funciones que atienden a un escenario en una sola aplicación de función. Para más información, lea Administración de la aplicación de funciones.

A medida que implemente la aplicación, tendrá que supervisarla. Considere la posibilidad de usar Application Insights para que los desarrolladores puedan supervisar el rendimiento y detectar problemas.

Para más información, consulte la sección DevOps en Marco de buena arquitectura de Microsoft Azure.

Acciones imperativas en recursos de Azure

En los dos escenarios anteriores, el resultado final ha sido un cambio en el estado de los recursos de Azure mediante la interacción directa con Azure Resource Manager. Aunque este era el resultado previsto, tenga en cuenta el impacto que podría tener en el entorno si los recursos modificados se han implementado originalmente mediante declaración, por ejemplo, con plantillas de Bicep o Terraform. A menos que esos cambios se repliquen de nuevo en las plantillas de origen, el siguiente uso de esas plantillas podría deshacer los cambios realizados por esta automatización. Tenga en cuenta el impacto de combinar cambios imperativos en los recursos de Azure que se implementan de forma rutinaria mediante plantillas.

Implementación de este escenario

Para implementar el escenario del centro de coste, vea los pasos de implementación en GitHub.

Pasos siguientes

• Curso: Introducción a Azure Functions
• Documentación: Introducción a Azure Functions
• ¿Qué es Azure Event Grid?

Recursos relacionados

• Tutorial de código: aplicación sin servidor con Functions
• Diseño de arquitectura de funciones sin servidor
• Arquitecturas de referencia de funciones sin servidor