En el capítulo anterior, has aprendido las distintas soluciones de Big Data disponibles en Azure. En este capítulo, descubrirás cómo la tecnología sin servidor puede ayudarte a gestionar una gran cantidad de datos.
Actualmente, «sin servidor» es uno de los términos de moda más candentes en el ámbito de la tecnología y todos quieren subirse al carro. La tecnología sin servidor ofrece muchas ventajas en la informática general, los procesos de desarrollo de software, la infraestructura y la implementación técnica. En el sector están sucediendo muchas: en un extremo del espectro está la infraestructura como servicio (IaaS) y en el otro, la tecnología sin servidor. Entre las dos encontramos la plataforma como servicio (PaaS) y los contenedores. He conocido a muchos desarrolladores y me parece que existe cierta confusión entre ellos sobre IaaS, PaaS, contenedores e informática sin servidor. Además, hay mucha confusión acerca de los casos de uso, la aplicación, la arquitectura y la implementación del paradigma sin servidor. El movimiento «sin servidor» es un nuevo paradigma que está cambiando no solo la tecnología, sino también la cultura y los procesos de las organizaciones.

Comenzaremos este capítulo con la introducción de la tecnología sin servidor
y abordaremos los siguientes temas a medida que avancemos:

• Funciones como servicio
• Azure Functions
• Durable Functions de Azure
• Azure Event Grid

Sin servidor
El término «sin servidor» se refiere a un modelo de implementación en el que los usuarios
solo son responsables del código de su aplicación y la configuración. En la informática
sin servidor, los clientes no tienen que preocuparse por aportar su propia plataforma e
infraestructura subyacentes y, en su lugar, pueden centrarse en resolver sus problemas
empresariales.
Cuando se habla de tecnología sin servidor, no quiere decir que no haya servidores.
El código y la configuración siempre necesitarán procesamiento, almacenamiento y redes
para ejecutarse. Sin embargo, desde la perspectiva del cliente, no hay visibilidad de estos
procesamientos, almacenamientos y redes. No se preocupan de la plataforma ni de la
infraestructura subyacentes. No necesitan administrar ni supervisar la infraestructura y la
plataforma. La tecnología sin servidor proporciona un entorno que puede escalar en todos
los sentidos, automáticamente, sin que el cliente lo sepa. Todas las operaciones relacionadas
con plataformas e infraestructuras ocurren en segundo plano y las ejecuta el proveedor de
cloud. A los clientes se les proporcionan acuerdos de nivel de servicio (SLA) relacionados
con el rendimiento y Azure se asegura de que cumpla con esos SLA independientemente
de la demanda total.
Los clientes solo tienen que introducir su código. Es responsabilidad del proveedor de cloud
facilitar la infraestructura y plataforma necesarias para ejecutar el código. Sigamos adelante
y profundicemos en las diversas ventajas de Azure Functions.
Las ventajas de Azure Functions
La informática sin servidor es un paradigma relativamente nuevo que ayuda a las
organizaciones a convertir grandes funcionalidades en pequeñas funciones discretas
a petición que pueden invocarse y ejecutarse a través de desencadenadores automáticos
y trabajos programados. También se denominan funciones como servicio (FaaS), en las
que las organizaciones pueden centrarse en los desafíos de su dominio en lugar de la
infraestructura y plataforma subyacentes. FaaS también ayuda a delegar las arquitecturas
de soluciones en funciones reutilizables más pequeñas, aumentando así el retorno de
la inversión.

Hay una gran cantidad de plataformas de informática sin servidor disponibles. Algunas
de las más importantes se mencionan aquí:

• Azure Functions
• AWS Lambda
• IBM OpenWhisk
• Iron.io
• Google Cloud Functions

De hecho, cada pocos días parece que se introduce una nueva plataforma o marco,
y cada vez es más difícil para las empresas decidir el marco que mejor se adapte a ellas.
Azure proporciona un entorno completo sin servidor conocido como Azure Functions
y a continuación presentamos algunas de las características que admite:

• Diversas maneras de invocar una función: manual, programada o basada en un evento.
• Numerosos tipos de compatibilidad de enlace.
• Capacidad para ejecutar funciones de forma sincrónica y asincrónica.
• Capacidad para ejecutar funciones basadas en varios tipos de desencadenadores.
• Capacidad para ejecutar funciones de larga y corta duración. Sin embargo,
  no se recomiendan funciones grandes de larga duración, ya que pueden dar
  lugar a tiempos de espera inesperados.
• Capacidad para utilizar características de proxy para diferentes arquitecturas de función.
• Varios modelos de uso, incluido el de consumo, así como el modelo de App Service.
• Capacidad para crear funciones con varios lenguajes, como JavaScript, Python y C#.
• Autorización basada en OAuth.
• La extensión Durable Functions ayuda a escribir funciones con estado.
• Varias opciones de autenticación, como Azure AD, Facebook, Twitter y otros proveedores
  de identidades.
• Capacidad para configurar fácilmente los parámetros entrantes y salientes.
• Integración de Visual Studio para la creación de funciones de Azure.
• Paralelismo masivo.

Veamos FaaS y qué funciones desempeña en la arquitectura sin servidor.

FaaS
Azure proporciona FaaS. Se trata de implementaciones sin servidor de Azure. Con Azure
Functions, el código puede escribirse en cualquier idioma con el que el usuario se sienta
cómodo y Azure Functions proporcionará un entorno de ejecución para ejecutarlo. Según
el idioma elegido, se proporciona una plataforma adecuada para que los usuarios traigan
su propio código. Las funciones son una unidad de implementación y pueden escalarse
automáticamente. Cuando se trata de funciones, los usuarios no pueden ver la plataforma
y las máquinas virtuales, pero Azure Functions proporciona una pequeña ventana para
verlas a través de la consola Kudu.
Existen dos componentes principales de Azure Functions:

• El entorno de ejecución de Azure Functions
• Enlaces y desencadenadores de Azure Functions

Vamos a conocer en detalle estos componentes.

El entorno de ejecución de Azure Functions
La base de Azure Functions es el entorno de ejecución. Azure WebJobs fue el precursor
de Azure Functions. El código para Azure WebJobs también constituye el núcleo de
Azure Functions. Existen funciones y extensiones adicionales agregadas a Azure WebJobs
para crear Azure Functions. El entorno de ejecución de Azure Functions es la magia que
hace que la función funcione. Azure Functions está hospedado en Azure App Service.
Azure App Service carga el entorno de ejecución de Azure y espera que ocurra un evento
externo o que tenga lugar una actividad manual. Al llegar una solicitud o la aparición de
un desencadenador, App Service carga la carga entrante, lee el archivo function.json de
la función para encontrar los enlaces y el desencadenador de la función, asigna los datos
entrantes a los parámetros entrantes e invoca la función con valores de parámetros.
Una vez que la función completa su ejecución, el valor se pasa nuevamente al entorno
de ejecución de Azure Functions mediante un parámetro saliente definido como vinculante
en el archivo function.json. El entorno de ejecución de la función devuelve los valores al
autor de la llamada. El entorno de ejecución de Azure Functions actúa como un pegamento
que permite el funcionamiento completo de las funciones.
La versión actual del entorno de ejecución de Azure es ~3. Se basa en el marco .NET Core 3.1.
Antes de esto, la versión ~2 se basaba en el marco .NET Core 2.2. La primera versión, ~1,
se basaba en el marco .NET 4.7.
Hubo cambios sustanciales de la versión 1 a la 2 debido a los cambios en el propio marco
subyacente. Sin embargo, hay muy pocos cambios importantes de la versión 2 a la 3
y la mayoría de las funciones escritas en la versión 2 también seguirán funcionando
en la versión 3. Aun así, se recomienda realizar pruebas suficientes después de migrar
de la versión 2 a la 3. También se han realizado cambios importantes de la versión 1 a la 2
con respecto a los desencadenadores y enlaces. Los desencadenadores y enlaces ahora están
disponibles como extensiones, cada uno en un ensamblado diferente en las versiones 2 y 3.

Enlaces y desencadenadores de Azure Functions
Si el entorno de ejecución de Azure Functions es el cerebro de Azure Functions, los enlaces
y los desencadenadores de Azure Functions son el corazón. Azure Functions promueve
el acoplamiento flexible y la alta cohesión entre los servicios que utilizan desencadenadores
y enlaces. Las aplicaciones escritas dirigidas a entornos con servidor implementan código
utilizando la sintaxis imperativa para los parámetros entrantes y salientes y los valores de
retorno. Azure Functions utiliza un mecanismo declarativo para invocar funciones mediante
desencadenadores y configurar el flujo de datos mediante enlaces.
«Enlazar» se refiere al proceso de crear una conexión entre los datos entrantes y la función
de Azure, junto con la asignación de los tipos de datos. La conexión podría ser en una única
dirección desde el entorno de ejecución hasta Azure Functions y viceversa, o podría ser
multidireccional: el enlace puede transmitir datos entre el entorno de ejecución de Azure
y Azure Functions en ambas direcciones. Azure Functions define enlaces de forma declarativa.
Los desencadenadores son un tipo especial de enlace a través del cual se pueden invocar
funciones basadas en eventos externos. Además de invocar una función, los desencadenadores
también pasan los datos entrantes, la carga y los metadatos a la función.
Los enlaces se definen en el archivo function.json de la siguiente forma:
{
«bindings»: [
{
«name»: «checkOut»,
«type»: «queueTrigger»,
«direction»: «in»,
«queueName»: «checkout-items»,
«connection»: «AzureWebJobsDashboard»
},
{
«name»: «Orders»,
«type»: «table»,
«direction»: «out»,
«tableName»: «OrderDetails»,
«connection»: «<>»
}
],
«disabled»: false
}

En este ejemplo, se declara un desencadenador que invoca la función cada vez que hay
un elemento nuevo en la cola de almacenamiento. El tipo es queueTrigger, la dirección es
entrante, queueName es checkout-items y también se muestran los detalles sobre la conexión
de la cuenta de almacenamiento de destino y el nombre de la tabla. Todos estos valores son
importantes para el funcionamiento de este enlace. El nombre checkOut se puede utilizar
en el código de la función como una variable.
Del mismo modo, se declara un enlace para el valor devuelto. Aquí el valor devuelto
se denomina Orders y los datos son el resultado de Azure Functions. El enlace escribe
los datos de retorno en Azure Table Storage utilizando la cadena de conexión provista.
Tanto los enlaces como los desencadenadores se pueden modificar y crear mediante la
pestaña Integrar en Azure Functions. El archivo function.json se actualiza en el back-end.
Se declara el desencadenador checkOut como se muestra a continuación:

A continuación, se muestra la salida Orders:

Los autores de las funciones de Azure no necesitan escribir ningún código base para
obtener datos de múltiples fuentes. Solo deciden el tipo de datos esperados del entorno
de ejecución de Azure. Esto se muestra en el siguiente segmento de código. Observa que la
verificación está disponible como una cadena para la función. Se pueden utilizar varios tipos
de datos como enlaces para funciones. Por ejemplo, un enlace de cola puede proporcionar
lo siguiente:

• Un objeto CLR (Common Language Runtime) antiguo (POCO)
• Una cadena
• Un byte
• CloudQueueMessage

El autor de la función puede usar cualquiera de estos tipos de datos y el entorno de
ejecución de Azure Functions garantizará que se envíe un objeto adecuado a la función
como parámetro. A continuación, se muestra un fragmento de código para aceptar datos
de cadena y el entorno de ejecución de Functions encapsulará los datos entrantes en un
tipo de datos de string antes de invocar la función. Si el entorno de ejecución no puede
convertir los datos entrantes en una cadena, generará una excepción:
using System;
public static void Run(string checkOut, TraceWriter log)
{
log.Info($»C# Queue trigger function processed: { checkOut }»);
}
También es importante saber que, en la Figura 10.2, los nombres de las cuentas de
almacenamiento son AzureWebJobsStorage y AzureWebJobsDashboard. Ambas son claves
definidas en la sección appSettings y contienen cadenas de conexión de la cuenta de
almacenamiento. Azure Functions utiliza estas cuentas de almacenamiento internamente
para mantener su estado y el estado de ejecución de la función.
Para obtener más información sobre los enlaces y desencadenadores de Azure, consulta
https://docs.microsoft.com/azure/azure-functions/functions-bindings-storage-queue.
Ahora que hemos tenido una buena noción de los enlaces y desencadenadores de Azure,
echemos un vistazo a las diversas opciones de configuración que ofrece Azure Functions.
Configuración de Azure Functions
Azure Functions proporciona opciones de configuración en varios niveles. Proporciona
configuración para:

• La propia plataforma
• App Services de Functions

Estos ajustes afectan a todas las funciones que contienen. Encontrarás más información
sobre estos ajustes en https://docs.microsoft.com/azure/azure-functions/functions-howto-
use-azure-function-app-settings.

Configuración de la plataforma
Las funciones de Azure están hospedadas en Azure App Service, de modo que obtienen
todas sus características. Los registros de diagnóstico y supervisión se pueden configurar
fácilmente con las características de la plataforma. Además, App Service proporciona
opciones para asignar certificados SSL mediante un dominio personalizado, autenticación
y autorización como parte de sus características de red.
Aunque a los clientes no les preocupa la infraestructura, el sistema operativo, el sistema de
archivos o la plataforma en la que se ejecutan las funciones, Azure Functions proporciona
las herramientas necesarias para mirar dentro del sistema subyacente y realizar cambios.
La consola en el portal y la consola Kudu son las herramientas que se utilizan con este
objetivo. Proporcionan un editor enriquecido para crear funciones de Azure y editar su
configuración.
Azure Functions, al igual que App Service, permite almacenar información de configuración
dentro de la sección de configuración de aplicación web.config, que se puede leer a
petición. En la Figura 10.3 se muestran algunas de las características de la plataforma de las
aplicaciones de función:

Estas características de la plataforma se pueden utilizar para configurar la autenticación,
dominios personalizados, SSL, etc. Además, la pestaña Características de la plataforma
proporciona información general sobre las herramientas de desarrollo que se pueden usar
con la aplicación de función. En la siguiente sección, echaremos un vistazo a la configuración
de la aplicación de función que está disponible en las características de la plataforma.

Configuración de la función de App Service
Esta configuración afecta a todas las funciones. La configuración de la aplicación se
puede administrar aquí. Los proxies de Azure Functions se pueden habilitar y deshabilitar.
Hablaremos sobre los proxies más adelante en este capítulo. También ayudan a cambiar
el modo de edición de una aplicación de función y la implementación en ranuras:

El presupuesto es un aspecto muy importante del éxito de cualquier proyecto. Vamos a explorar
los distintos planes ofrecidos para Azure Functions.
Planes de coste de Azure Functions
Azure Functions se basa en Azure App Service y proporciona un modelo económico
a los usuarios. Existen tres modelos de costes.

Plan de consumo
Se basa en el consumo por segundo y la ejecución de funciones. Este plan calcula el coste
en función del uso de proceso durante el consumo real y la ejecución de la función. Si una
función no se ejecuta, no tiene ningún coste asociado. Sin embargo, esto no significa que
el rendimiento se vea comprometido en este plan. Las funciones de Azure se escalarán
automáticamente según la demanda, para garantizar que se mantengan los niveles de
rendimiento mínimos básicos. Se permite una ejecución de la función de 10 minutos
para su finalización.
Uno de los principales inconvenientes de este plan es que si no se consumen funciones
durante unos segundos, la función podría quedar inactiva y la siguiente solicitud que
aparece podría enfrentarse a un breve retraso en obtener una respuesta, ya que la
función está inactiva. Este fenómeno se denomina arranque en frío. Sin embargo, hay
soluciones alternativas que pueden mantener las funciones en caliente incluso cuando
no hay solicitudes legítimas. Esto se puede hacer escribiendo una función programada
que invoca la función de destino para mantenerla en caliente.
Plan premium
Este es un plan relativamente nuevo y proporciona muchos beneficios en comparación con
App Service y un plan de consumo. En este plan, no hay arranques en frío para las funciones
de Azure. Las funciones se pueden asociar a una red privada y los clientes pueden elegir
sus propios tamaños de máquina virtual para ejecutar funciones. Proporciona numerosos
recursos «out of the box» que antes no eran posibles con los otros dos tipos de planes.
Plan de App Service
Este plan proporciona, en el back-end, funciones con máquinas virtuales completamente
dedicadas, por lo que el coste es directamente proporcional al coste de la máquina virtual
y su tamaño. Hay un coste fijo con este plan, incluso si las funciones no se invocan. El
código de la función puede ejecutarse durante el tiempo que sea necesario. Aunque no
hay ninguna restricción de tiempo, el límite predeterminado se establece en 30 minutos.
Esto se puede modificar cambiando el valor en el archivo hosts.json. Dentro del plan de
App Service, el entorno de ejecución de la función queda inactivo si no se utiliza durante
unos pocos minutos y se puede activar solo mediante un desencadenador de HTTP. El
ajuste Always On se puede usar para evitar que el entorno de ejecución de la función
quede inactivo. El escalado es manual o se basa en la configuración de escalado automático.
Junto con la opción de precios flexibles, Azure también ofrece varias opciones de hosting
para la implementación de arquitectura.

Hosts de destino de Azure Functions
El entorno de ejecución de Azure Functions se puede hospedar en Windows y en hosts
de Linux. Las funciones basadas en PowerShell Core, Node.js, Java, Python y .NET Core
se pueden ejecutar en sistemas operativos Windows y Linux. Es importante saber qué
tipo de sistema operativo subyacente es necesario para las funciones porque este ajuste
de configuración está vinculado a la aplicación de función y, a su vez, a todas las funciones
que contiene.
Además, es posible ejecutar funciones dentro de contenedores de Docker. Esto se debe a
que Azure proporciona imágenes de Docker que tienen instalado un entorno de ejecución
de función preconfigurado y las funciones se pueden hospedar utilizando estas imágenes.
Ahora, las imágenes de Docker se pueden utilizar para crear contenedores dentro de los
pods de Kubernetes y hospedarse en Azure Kubernetes Service, Azure Container Instances
o en clústeres de Kubernetes no administrados. Estas imágenes se pueden almacenar
en Docker Hub, Azure Container Registry o cualquier otro repositorio de imágenes
tanto global como privado.
Para comprenderlo mejor, vamos a examinar algunos de los casos prácticos más destacados
de Azure Functions.
Casos prácticos de Azure Functions
Azure Functions tiene muchas implementaciones. Veamos algunos de estos casos prácticos.
Implementación de microservicios
Azure Functions ayuda a dividir las aplicaciones grandes en unidades de código funcional
más pequeñas y discretas. Cada unidad se trata de forma independiente de las otras y
evoluciona en su propio ciclo de vida. Cada una de estas unidades de código tiene sus
propios requisitos de proceso, hardware y supervisión. Cada función se puede conectar
a todas las demás funciones. Estas unidades están entrelazadas por orquestadores para
construir una funcionalidad completa. Por ejemplo, en una aplicación de comercio
electrónico, puede haber funciones individuales (unidades de código) responsables de
enumerar catálogos, recomendaciones, categorías, subcategorías, carritos de compra,
pagos, tipos de pago, pasarelas de pago, direcciones de envío, direcciones de facturación,
impuestos, gastos de envío, cancelaciones, devoluciones, correos electrónicos, SMS,
etc. Algunas de estas funciones se unen para crear casos prácticos para aplicaciones
de comercio electrónico, como la navegación de productos y el flujo de pago.
Integración entre varios puntos de conexión
Azure Functions puede crear una funcionalidad general de la aplicación mediante
la integración de varias funciones. La integración puede basarse en la activación
de eventos o podría ser sobre una base push. Esto ayuda a descomponer grandes
aplicaciones monolíticas en pequeños componentes.

Procesamiento de datos
Azure Functions se puede usar para procesar datos entrantes en lotes. Es útil para procesar
datos en varios formatos, como XML, CSV, JSON y TXT. También puede ejecutar algoritmos
de conversión, enriquecimiento, limpieza y filtrado. De hecho, se pueden usar varias
funciones, cada una de las cuales realiza conversión o enriquecimiento, limpieza o filtrado.
Azure Functions también se puede usar para incorporar servicios cognitivos avanzados,
como el reconocimiento óptico de caracteres (OCR), la visión de proceso y la manipulación
de imágenes y la conversión. Esto es ideal si deseas procesar las respuestas de la API
y convertirlas.
Integración de aplicaciones heredadas
Azure Functions puede ayudar a integrar aplicaciones heredadas con protocolos más
nuevos y aplicaciones modernas. Las aplicaciones heredadas pueden no estar utilizando
protocolos y formatos estándar del sector. Azure Functions puede actuar como un
proxy para estas aplicaciones heredadas, aceptando solicitudes de los usuarios u otras
aplicaciones, convirtiendo los datos en un formato comprendido por una aplicación
heredada y hablando sobre los protocolos que comprende. Esto abre un mundo de
oportunidades para integrar y traer aplicaciones antiguas y heredadas a la cartera principal.
Trabajos programados
Azure Functions se puede utilizar para ejecutarse de forma continua y periódicamente para
algunas funciones de la aplicación. Estas funciones de la aplicación pueden realizar tareas
como la realización periódica de copias de seguridad, restauración, ejecución de trabajos
por lotes, exportación e importación de datos y correos electrónicos masivos.
Gateways de comunicación
Azure Functions se puede utilizar en puertas de enlace de comunicación al utilizar de
centros de notificaciones, SMS, correo electrónico, etc. Por ejemplo, puedes usar Azure
Functions para enviar una notificación push a dispositivos Android e iOS mediante Azure
Notification Hubs.
Las funciones de Azure están disponibles en diferentes tipos, que deben seleccionarse en
función de su relación para optimizar las cargas de trabajo. Veámoslas con más detenimiento.

Tipos de funciones de Azure
Las funciones de Azure se pueden clasificar en tres tipos diferentes:

• Funciones a petición: son funciones que se ejecutan cuando se llaman o invocan
  explícitamente. Ejemplos de tales funciones incluyen funciones basadas en HTTP
  y webhooks.
• Funciones programadas: estas funciones son como trabajos de temporizador
  y ejecutan funciones en intervalos fijos.
• Funciones basadas en eventos: estas funciones se ejecutan en base a eventos
  externos. Por ejemplo, cargar un archivo nuevo en Azure Blob Storage genera
  un evento que podría iniciar la ejecución de funciones de Azure.

En la siguiente sección, aprenderás a crear una función controlada por eventos que
se conectará a una cuenta de Azure Storage.
Cómo crear una función impulsada por eventos
En este ejemplo, se creará y conectará una función de Azure a la cuenta de Azure Storage.
La cuenta de almacenamiento tiene un contenedor para guardar todos los archivos blob.
El nombre de la cuenta de almacenamiento es incomingfiles y el contenedor es orders,
como se muestra en la Figura 10.5:

Sigue estos pasos para crear una nueva función de Azure desde Azure Portal:

1. Haz clic en el botón + junto al menú Funciones de la izquierda.
2. Selecciona En el portal en la pantalla resultante y haz clic en el botón Continuar.
3. Selecciona Desencadenador de Azure Blob Storage, como se muestra en la Figura 10.6:

Ahora mismo, esta función de Azure no tiene conectividad con la cuenta de
almacenamiento. Las funciones de Azure necesitan información de conexión para la cuenta
de almacenamiento y que sea visible desde la pestaña Claves de acceso en la cuenta de
almacenamiento. Se puede obtener la misma información mediante el entorno del editor
de Azure Functions. De hecho, ese entorno permite la creación de una nueva cuenta de
almacenamiento desde el mismo entorno de edición.
El desencadenador de Azure Blob Storage se puede agregar usando el botón Nuevo junto al
tipo de entrada Conexión de la cuenta de almacenamiento. Permite seleccionar una cuenta
de almacenamiento existente o crear una nueva cuenta de almacenamiento. Como ya tengo
un par de cuentas de almacenamiento, las estoy reutilizando, pero debes crear una cuenta
de Azure Storage independiente. La selección de una cuenta de almacenamiento actualizará
la configuración en la sección appSettings con la cadena de conexión agregada.
Asegúrate de que ya exista un contenedor dentro del servicio blob de la cuenta de Azure
Storage de destino. La entrada de ruta se refiere a la ruta al contenedor. En este caso,
el contenedor orders ya existe dentro de la cuenta de almacenamiento. El botón Crear
que aparece aquí aprovisionará la nueva función que supervisa el contenedor de la cuenta
de almacenamiento:

El código de la función de storagerelatedfunctions es el siguiente:
public static void Run(Stream myBlob, TraceWriter log)
{
log.Info($»C# Blob trigger function Processed blob\n \n Size {myBlob.
Length} Bytes»);
}
Los enlaces se muestran aquí:
{
«bindings»: [
{
«name»: «myBlob»,
«type»: «blobTrigger»,
«direction»: «in»,
«path»: «orders»,
«connection»: «azureforarchitead2b_STORAGE»
}
],
«disabled»: false
}

Ahora, cargar cualquier archivo blob en el contenedor orders debería activar la función:

En la siguiente sección, profundizaremos en Azure Functions Proxies, que te ayudará
a gestionar eficientemente las solicitudes y respuestas de tus API.
Functions Proxies
Azure Functions Proxies es una adición relativamente nueva a Azure Functions. Functions
Proxies ayuda a ocultar los detalles de las funciones de Azure y exponer puntos de conexión
completamente diferentes a los clientes. Functions Proxies puede recibir solicitudes en los
puntos de conexión, modificar el contenido, el cuerpo, los encabezados y la URL de la solicitud
mediante el cambio de los valores y aumentarlas con datos adicionales y pasarlas internamente
a las funciones de Azure. Una vez que obtienen una respuesta de estas funciones, pueden
volver a convertir, anular y aumentar la respuesta y enviarla de vuelta al cliente.
También ayuda a invocar diferentes funciones para las operaciones de CRUD (crear, leer,
eliminar y actualizar) utilizando encabezados diferentes para dividir, de este modo, las
funciones grandes en otras más pequeñas. Proporciona un nivel de seguridad al no exponer
el punto de conexión de la función original y también ayuda a cambiar la implementación y
los puntos de conexión de la función interna sin que afecte al autor de la llamada. Functions
Proxies ayuda al proporcionar a los clientes una única URL de función y luego invocar varias
funciones de Azure en el back-end para completar los flujos de trabajo. Encontrarás más
información sobre Azure Functions Proxies en https://docs.microsoft.com/azure/azurefunctions/
functions-proxies.
Abordaremos en detalle Durable Functions en la siguiente sección.

Durable Functions
Durable Functions es una de las últimas incorporaciones a Azure Functions. Permite a los
arquitectos escribir flujos de trabajo con estado en una función de orquestador, que es un
nuevo tipo de función. Como desarrollador, puedes optar por codificar o utilizar cualquier
forma de IDE. Algunas de las ventajas de usar Durable Functions son:

• La salida de la función se puede guardar en variables locales y puedes llamar a otras
  funciones de forma sincrónica y asincrónica.
• El estado se conserva para ti.

A continuación, se muestra el mecanismo básico para invocar Durable Functions:

Durable Functions de Azure se puede invocar mediante cualquier desencadenador
proporcionado por Azure Functions. Estos desencadenadores incluyen HTTP, Azure Blob
Storage, Table Storage, colas de Service Bus y mucho más. Cualquier persona que tenga
acceso a ellos puede activarlos manualmente o también mediante una aplicación. En la
Figura 10.9 se muestran un par de desencadenadores como ejemplo. También se conocen
como Durable Functions de inicio. Durable Functions de inicio invoca el desencadenador
de orquestador durable, que contiene la lógica principal para la orquestación y orquesta
la invocación de las funciones de actividad.

El código escrito en el orquestador durable debe ser determinista. Esto significa que,
independientemente del número de veces que se ejecute el código, los valores que este
devuelva deben seguir siendo los mismos. La función de orquestador es una función de
larga duración por naturaleza. Esto significa que puede insuflarse, serializarse por estado
y suspenderse después de llamar a una función de actividad duradera. Esto se debe a que
no sabe cuándo se completará la función de actividad duradera y no quiere esperar. Cuando
la función de actividad duradera termina su ejecución, la función de orquestador se vuelve
a ejecutar. La ejecución de la función comienza desde la parte superior y se ejecuta hasta
que llama a otra función de actividad duradera o termina la ejecución de la función. Tiene
que volver a ejecutar las líneas de código que ya ejecutó antes y debería obtener los mismos
resultados que obtuvo antes. Ten en cuenta que el código escrito en el orquestador durable
debe ser determinista. Esto significa que, independientemente del número de veces que se
ejecute el código, los valores que este devuelva deben seguir siendo los mismos.
Voy a explicarlo con la ayuda de un ejemplo. Si usamos una clase general de datetime
de .NET Core y devolvemos la fecha y hora actual, esto dará lugar a un nuevo valor cada
vez que ejecutemos la función. El objeto de contexto de Durable Functions proporciona
CurrentUtcDateTime, que devolverá el mismo valor de datetime durante la repetición de
la ejecución que devolvió la primera vez.
Estas funciones de orquestación también pueden esperar a eventos externos y habilitar
escenarios relacionados con la transferencia realizada por las personas. Este concepto
se explicará más adelante en esta sección.
Estas funciones de actividad se pueden llamar con o sin mecanismo de reintento. Durable
Functions puede ayudar a resolver muchos desafíos y proporciona características para
escribir funciones que pueden hacer lo siguiente:

• Ejecutar funciones de ejecución prolongada
• Mantener el estado
• Ejecutar funciones secundarias en paralelo o secuencialmente
• Recuperarse de errores con facilidad
• Orquestar la ejecución de funciones en un flujo de trabajo

Ahora que conoces bien el funcionamiento interno de una Durable Function, exploremos
cómo crear una Durable Function en Visual Studio.

Pasos para crear una Durable Function con Visual Studio
Estos son los pasos para crear una Durable Function:

1. Dirígete a Azure Portal y haz clic en Grupos de recursos en el menú de la izquierda.
2. Haz clic en el botón + Agregar del menú superior para crear un nuevo grupo de recursos.
3. Proporciona la información del grupo de recursos en el formulario resultante
   y haz clic en el botón Crear, como se muestra aquí:

4. Dirígete al grupo de recursos recién creado y añade una nueva aplicación de función
   al hacer clic en el botón + Agregar del menú superior y buscar function app en el
   cuadro de búsqueda resultante.
5. Selecciona Aplicación de función y haz clic en el botón Crear. Rellena el formulario
   de aplicación de función resultante y haz clic en el botón Crear. También puedes
   reutilizar la aplicación de función que creamos anteriormente.
6. Una vez creada la aplicación de función, entraremos en nuestro entorno de desarrollo
   local con Visual Studio 2019 instalado. Empezaremos con Visual Studio y crearemos
   un nuevo proyecto de tipo Azure functions, proporcionaremos un nombre
   y seleccionaremos Azure Functions v3 ( .NET core) para Entorno de ejecución
   de la función (Function runtime).
7. Después de crear el proyecto, tenemos que agregar el paquete NuGet de DurableTask
   al proyecto para trabajar con Durable Functions. La versión utilizada en el momento
   de redactar este capítulo es 2.2.2:

8. Ahora podemos codificar nuestras Durable Functions en Visual Studio. Agrega
   una función nueva, proporciona un nombre y selecciona el tipo de desencadenador
   Orquestación de Durable Functions (Durable Functions Orchestration):

9. Visual Studio genera el código reutilizable para Durable Functions y vamos a utilizarlo
   para obtener información sobre Durable Functions. Las actividades de Durable
   Functions son funciones que se invocan mediante la función de orquestador principal.
   Suele haber una función de orquestador principal y varias actividades de Durable
   Functions. Cuando esté instalada la extensión, indica un nombre para la función
   y escribe código que haga algo útil, como enviar un correo electrónico o un SMS,
   conectarse a sistemas externos y ejecutar una lógica, o ejecutar servicios con sus
   puntos de conexión, como Cognitive Services.
   Visual Studio genera tres conjuntos de funciones en una sola línea de código:

• HttpStart: esta es la función de inicio. Esto significa que es responsable de iniciar
  la orquestación de Durable Functions. El código generado consta de una función
  de inicio del desencadenador de HTTP; sin embargo, podría ser cualquier función
  basada en desencadenador, como BlobTrigger, una cola de ServiceBus o una
  función basada en desencadenador.
• RunOrchestrator: esta es la función de orquestación duradera principal. Es responsable
  de aceptar parámetros de la función de inicio y, a su vez, invoca varias funciones de
  tareas durables. Cada función de tarea durable es responsable de una funcionalidad
  y estas tareas durables se pueden invocar en paralelo o secuencialmente dependiendo
  de la necesidad.
• SayHello: esta es la función de tarea durable que se invoca desde el orquestador
  de Durable Functions para realizar un trabajo determinado.

10. El código para la función de inicio (HttpStart) se muestra a continuación. Esta
    función tiene un desencadenador de tipo HTTP y acepta un enlace adicional del tipo
    DurableClient. Este objeto DurableClient ayuda a invocar la función de orquestador:

11. El código para la función de orquestador (RunOrchestrator) se muestra a continuación.
    Esta función tiene un desencadenador de tipo OrchestrationTrigger y acepta un
    parámetro del tipo IDurableOrchestrationContext. Este objeto de contexto ayuda
    a invocar las tareas durables:

12. El código para la función de tarea durable (HelloFunction) se muestra a continuación.
    Esta función tiene un desencadenador de tipo ActivityTrigger y acepta un parámetro
    que puede ser cualquier tipo necesario para que ejecute su funcionalidad. Tiene un
    valor devuelto de tipo string y la función es responsable de devolver un valor de
    cadena a la función de orquestación:

A continuación, podemos ejecutar la función a nivel local, que iniciará un emulador de
almacenamiento si aún no se ha iniciado, y proporcionaremos una URL para la función
de desencadenador de HTTP:

Vamos a invocar esta URL con una herramienta conocida como Postman (se puede
descargar desde https://www.getpostman.com/). Solo tenemos que copiar la URL
y ejecutarla en Postman. Esta actividad se muestra en la Figura 10.17:

Ten en cuenta que se generan cinco URL al iniciar el orquestador:

• La URL statusQueryGetUri se utiliza para buscar el estado actual del orquestador.
  Al hacer clic en esta URL de Postman se abre una nueva pestaña y, si ejecutamos
  esta solicitud, se muestra el estado del flujo de trabajo:

• La URL terminatePostUri se utiliza para detener una función de orquestador que
  ya está en ejecución.
• La URL sendEventPostUri se utiliza para publicar un evento en una Durable Function
  suspendida. Durable Functions se puede suspender si está a la espera de un evento
  externo. Esta URL se utiliza en esos casos.

• La URL purgeHistoryDeleteUri se utiliza para eliminar el historial que mantiene
  Durable Functions para una invocación determinada de su cuenta de Table Storage.

Ahora que ya sabes cómo trabajar con Durable Functions usando Visual Studio, vamos
a abordar otro aspecto de las funciones de Azure: encadenarlas.
Crear una arquitectura conectada con funciones
Una arquitectura conectada con funciones se refiere a la creación de múltiples funciones,
por lo que la salida de una función activa otra función y proporciona datos para que la
siguiente función ejecute su lógica. En esta sección, continuaremos con el escenario
anterior de la cuenta de almacenamiento. En este caso, la salida de la función que se
desencadenará mediante archivos de Azure Storage Blob escribirá el tamaño del archivo
en Azure Cosmos DB.
La configuración de Cosmos DB se muestra a continuación. De forma predeterminada,
no hay colecciones creadas en Cosmos DB.
Una colección se creará automáticamente al crear una función que se activará cuando
Cosmos DB obtenga cualquier información:

Vamos a seguir los pasos siguientes para recuperar datos de la siguiente función a partir
de la salida de una función.

1. Crea una base de datos nueva, testdb, en Cosmos DB y una colección nueva llamada
   testcollection en ella. Necesitas tanto la base de datos como el nombre de la colección
   al configurar funciones de Azure:

2. Crea una función nueva que tenga un desencadenador de Blob Storage y un enlace
   de CosmosDB de salida. El valor devuelto de la función será el tamaño de los datos
   del archivo cargado. Este valor devuelto se escribirá en Cosmos DB. El enlace
   de salida escribirá en la colección de Cosmos DB. En la pestaña Integrar, haz clic
   en el botón Nueva salida debajo de la etiqueta Salidas y selecciona Azure Cosmos DB:

3. Proporciona los nombres apropiados para la base de datos y la colección (marca la
   casilla de verificación para crear la colección si no existe), haz clic en el botón Nuevo
   para seleccionar tu recién creado Azure Cosmos DB y deja el nombre del parámetro
   como outputDocument:

Modifica la función como se muestra en la Figura 10.23:

5. Ahora, al cargar un nuevo archivo a la colección de órdenes en la cuenta de Azure
   Storage se ejecutará una función que se escribirá en la colección de Azure Cosmos DB.
   Se puede escribir otra función con la cuenta recién creada de Azure Cosmos DB como
   un enlace de activación. Proporcionará el tamaño de los archivos y la función puede
   actuar sobre él. Esto se muestra aquí:

En esta sección se ha abordado cómo se puede utilizar la salida de una función para
recuperar datos para la siguiente función. En la siguiente sección, aprenderás a habilitar
los eventos sin servidor al entender Azure Event Grid.
Azure Event Grid
Azure Event Grid es un servicio relativamente nuevo. También se ha hecho referencia
a este servicio como una plataforma de eventos sin servidor. Ayuda a crear aplicaciones
basadas en eventos (también conocido como diseño controlado por eventos). Es importante
comprender qué son los eventos y cómo los tratamos antes de Event Grid. Un evento es algo
que ocurrió, es decir, una actividad que cambió el estado de un firmante. Cuando se cambia
el estado de un firmante, normalmente se genera un evento.

Normalmente, los eventos siguen el patrón de publicación/suscripción (popularmente
conocido como patrón de pub/sub), en el que un firmante genera un evento debido
a su cambio de estado; a continuación, ese evento puede ser suscrito por varias partes
interesadas, también conocidas como suscriptores. El trabajo del evento es notificar
a los suscriptores de dichos cambios y también proporcionarles datos como parte de
su contexto. Los suscriptores pueden tomar cualquier medida que consideren necesaria,
que varía de un suscriptor a otro.
Antes de Event Grid, no había ningún servicio que pudiera describirse como una plataforma
de eventos en tiempo real. Había servicios separados y cada uno proporcionaba su propio
mecanismo para gestionar los eventos.
Por ejemplo, Log Analytics, también conocido como Operations Management Suite
(OMS), proporciona una infraestructura para capturar registros de entorno y telemetría
donde se pueden generar alertas. Estas alertas se pueden usar para ejecutar un runbook,
un webhook o una función. Esto es casi en tiempo real, pero no totalmente. Además, era
bastante engorroso interceptar registros individuales y actuar sobre ellos. Del mismo modo,
existe Application Insights, que proporciona características similares a Log Analytics, pero
para aplicaciones.
Existen otros registros, como los registros de actividad y los registros de diagnóstico,
pero, de nuevo, utilizan principios similares a los de otras características relacionadas
con los registros. Las soluciones se implementan en varios grupos de recursos en múltiples
regiones y los eventos derivados de cualquiera de estos deben estar disponibles para los
recursos que se implementan en otro lugar.
Event Grid elimina todas las barreras y, como resultado, la mayoría de los recursos
pueden generar eventos (cada vez más disponibles); incluso se pueden generar eventos
personalizados. Cualquier recurso puede suscribirse a estos eventos, en cualquier región
y en cualquier grupo de recursos dentro de la suscripción.
Event Grid ya está establecido como parte de la infraestructura de Azure, junto con centros
de datos y redes. Los recursos de otras regiones pueden suscribirse fácilmente a los eventos
generados en una región; además, como estas redes están conectadas, es extremadamente
eficiente para la entrega de eventos a los suscriptores.
Event Grid
Event Grid te permite crear aplicaciones con una arquitectura controlada por eventos.
Hay publicadores de eventos y hay consumidores de eventos; sin embargo, puede haber
múltiples suscriptores para el mismo evento.
El publicador de un evento puede ser un recurso de Azure, como Blob Storage, el Internet
de las cosas (IoT), centros y muchos otros. Estos publicadores también se denominan
orígenes de eventos. Estos publicadores utilizan temas de Azure integrados para enviar
sus eventos a Event Grid. No es necesario configurar ni el recurso ni el tema. Los eventos
que generan los recursos de Azure ya usan internamente temas para enviar sus eventos
a Event Grid. Los suscriptores pueden utilizar el evento cuando este alcanza la cuadrícula.

Los suscriptores, o clientes, son recursos que están interesados en eventos y quieren ejecutar
una acción basada en estos eventos. Estos suscriptores proporcionan un controlador de eventos
cuando se suscriben al tema. Los controladores de eventos pueden ser funciones de Azure,
webhooks personalizados, aplicaciones lógicas u otros recursos. Tanto los orígenes de eventos
como los suscriptores que ejecutan los controladores de eventos se muestran en la Figura 10.25:

Cuando un evento alcanza un tema, se pueden ejecutar varios controladores de eventos
simultáneamente y cada uno toma sus propias medidas.
También es posible generar un evento personalizado y enviar un tema personalizado a Event
Grid. Event Grid proporciona características para crear temas personalizados que se adjuntan
automáticamente a Event Grid. Estos temas conocen el almacenamiento de Event Grid y envían
automáticamente sus mensajes a este. Los temas personalizados tienen dos propiedades
importantes, como se indica a continuación:

• Un punto de conexión: es el punto de conexión del tema. Los publicadores y los orígenes
  de eventos utilizan este punto de conexión para enviar y publicar sus eventos en Event
  Grid. En otras palabras, los temas se reconocen mediante sus puntos de conexión.
• Claves: los temas personalizados proporcionan un par de claves. Estas claves habilitan
  la seguridad del consumo del punto de conexión. Solo los publicadores que tienen
  estas claves pueden enviar y publicar sus mensajes en Event Grid.

Todos los eventos tienen un tipo de evento para su reconocimiento. Por ejemplo, Azure
Blob Storage proporciona tipos de eventos, como blobAdded y blobDeleted. Los temas
personalizados se pueden usar para enviar un evento definido por el usuario, como un
evento personalizado del tipo KeyVaultSecretExpired.
Por otro lado, los suscriptores tienen la capacidad de aceptar todos los mensajes o solo
obtener eventos basados en filtros. Estos filtros pueden basarse en el tipo de evento u otras
propiedades dentro de la carga del evento.
Todos los eventos tienen al menos las cinco propiedades siguientes:

• id: es el identificador único del evento.
• eventType: es el tipo de evento.
• eventTime: es la fecha y la hora de generación del evento.
• subject: es una descripción breve del evento.
• data: es un objeto de diccionario que contiene datos específicos de recursos
  o cualquier otro dato personalizado (para temas personalizados).

Actualmente, las funcionalidades de Event Grid no están disponibles con todos los recursos;
sin embargo, Azure agrega continuamente más y más recursos con la funcionalidad Event Grid.
Para obtener más información sobre los recursos que pueden generar eventos relacionados
con Event Grid y los controladores que los pueden gestionar, dirígete a https://docs.
microsoft.com/azure/event-grid/overview.
Eventos de recursos
En esta sección, se proporcionan los pasos siguientes para crear una solución en la que
los eventos generados por Azure Blob Storage se publican en Event Grid y al final se dirigen
a una función de Azure:

1. Inicia sesión en Azure Portal con las credenciales adecuadas y crea una nueva
   cuenta de almacenamiento en un grupo de recursos nuevo o existente. La cuenta
   de almacenamiento debe ser StorageV2 o Azure Blob Storage. Como se muestra
   en la Figura 10.26, Event Grid no funciona con StorageV1:

2. Crea una nueva aplicación de función o reutiliza una existente para crear una función
   de Azure. La función de Azure se hospedará en la aplicación de función.
3. Crea una función nueva mediante la plantilla de desencadenador de Azure Event
   Grid. En caso necesario, instala la extensión Microsoft.Azure.WebJobs.Extensions.
   EventGrid, como se muestra en la Figura 10.27:

4. Asigna un nombre a la función StorageEventHandler y créala. El siguiente código
   generado de forma predeterminada se utilizará como controlador de eventos:

La suscripción a eventos de almacenamiento se puede configurar desde la interfaz
de usuario (IU) de Azure Functions al hacer clic en Agregar suscripción a Event Grid
o desde la misma cuenta de almacenamiento.

5. Haz clic en el enlace Agregar suscripción a Event Grid en la IU de Azure
   Functions para agregar una suscripción a los eventos generados por la cuenta de
   almacenamiento creada en el paso anterior. Proporciona un nombre descriptivo para
   la suscripción y, a continuación, selecciona Esquema de eventos y Esquema de Event
   Grid. Establece Tipos de temas como Cuentas de almacenamiento, fija la Suscripción
   adecuada y el grupo de recursos que contiene la cuenta de almacenamiento:

Asegúrate de que la casilla de verificación Suscribirse a todos los tipos de evento esté
seleccionada y haz clic en el botón Crear (debe habilitarse al seleccionar una cuenta
de almacenamiento).

6. Si ahora nos dirigimos a la siguiente cuenta de almacenamiento en Azure Portal
   y hacemos clic en el enlace Eventos que se encuentra en el menú de la izquierda,
   debe mostrarse la suscripción para la cuenta de almacenamiento:

7. Carga un archivo en Azure Blob Storage después de crear un contenedor; a continuación,
   debe ejecutarse la función de Azure. La acción de carga activará un evento nuevo del
   tipo blobAdded y lo enviará al tema de Event Grid para las cuentas de almacenamiento.
   Como se muestra en la Figura 10.31, la suscripción ya está configurada para obtener
   todos los eventos de este tema y la función se ejecuta como parte del controlador de
   eventos:

En esta sección, has aprendido cómo los eventos que genera Azure Blob Storage se pueden
dirigir a una función de Azure. En la siguiente sección, aprenderás a aprovechar los eventos
personalizados.
Eventos personalizados
En este ejemplo, en lugar de usar recursos «out of the box» para generar eventos,
se utilizarán eventos personalizados. Utilizaremos PowerShell para crear esta solución
y reutilizar la misma función de Azure que se creó en el último ejercicio como controlador:

1. Inicia sesión y conéctate a la suscripción de Azure que prefieras con Login-AzAccount
   y Set-AzContext cmdlet.
2. El siguiente paso es crear un nuevo tema de Event Grid en Azure en un grupo
   de recursos. Se utiliza el cmdlet New-AzEventGridTopic para crear un tema nuevo:
   New-AzEventGridTopic -ResourceGroupName CustomEventGridDemo -Name
   «KeyVaultAssetsExpiry» -Location «West Europe»

3. Una vez creado, se deben recuperar la clave y la dirección URL del punto de conexión,
   ya que son necesarias para enviar y publicar el evento en el tema. Se utilizan los
   cmdlets Get-AzEventGridTopic y Get-AzEventGridTopicKey para recuperar estos
   valores. Ten en cuenta que Key1 se recupera para la conexión con el punto de conexión:
   $topicEndpoint = (Get-AzEventGridTopic -ResourceGroupName containers -Name
   KeyVaultAssetsExpiry).Endpoint
   $keys = (Get-AzEventGridTopicKey -ResourceGroupName containers -Name
   KeyVaultAssetsExpiry).Key1
4. Se crea una tabla hash nueva con las cinco propiedades de evento de Event Grid. Se
   genera una nueva propiedad id para el Id., la propiedad subject se establece en Key
   vault Asset Expiry, eventType se establece en Certificate Expiry, eventTime se
   establece en la hora actual y data contiene información sobre el certificado:
   $eventgridDataMessage = @{
   id = [System.guid]::NewGuid()
   subject = «Key Vault Asset Expiry»
   eventType = «Certificate Expiry»
   eventTime = [System.DateTime]::UtcNow
   data = @{
   CertificateThumbprint = «sdfervdserwetsgfhgdg»
   ExpiryDate = «1/1/2019»
   Createdon = «1/1/2018»
   }
   }
5. Puesto que los datos de Event Grid se deben publicar en forma de una matriz JSON,
   la carga se convierte en la matriz JSON. Los corchetes «[«,»]» representan una
   matriz JSON:
   $finalBody = «[» + $(ConvertTo-Json $eventgridDataMessage) + «]»
6. El evento se publicará mediante el protocolo HTTP y la información de encabezado
   adecuada debe agregarse a la solicitud. La solicitud se envía mediante el tipo de
   contenido JSON/aplicación y la clave que pertenece al tema se asigna al encabezado
   aeg-sas-key. Es obligatorio que el nombre del encabezado y la clave sea aeg-sas-key:
   $header = @{
   «contentType» = «application/json»
   «aeg-sas-key» = $keys}

7. Se crea una nueva suscripción al tema personalizado con un nombre, el grupo de
   recursos que contiene el tema, el nombre del tema, el punto de conexión de webhook
   y el punto de conexión real que actúa como el controlador de eventos. En este caso,
   el controlador de eventos es la función de Azure:
   New-AzEventGridSubscription -TopicName KeyVaultAssetsExpiry
   -EventSubscriptionName «customtopicsubscriptionautocar» -ResourceGroupName
   CustomEventGridDemo -EndpointType webhook ‘
   -Endpoint «https://durablefunctiondemoapp.
   azurewebsites.net/runtime/webhooks/
   EventGrid?functionName=StorageEventHandler&code=0aSw6sxvtFmafXHvt7iOw/
   Dsb8o1M9RKKagzVchTUkwe9EIkzl4mCg==’
   -Verbose
   La URL de la función de Azure está disponible en la pestaña Integrar, como se muestra
   en la Figura 10.31:

8. Por ahora, se han configurado tanto el suscriptor (controlador de eventos)
   como el publicador. El siguiente paso es enviar y publicar un evento en el tema
   personalizado. Los datos del evento ya se crearon en el paso anterior y, mediante
   el cmdlet Invoke-WebRequest, la solicitud se envía al punto de conexión junto con
   el cuerpo y el encabezado:
   Invoke-WebRequest -Uri $topicEndpoint -Body $finalBody -Headers $header
   -Method Post
   La llamada a la API activará el evento y Event Grid enviará un mensaje al punto de conexión
   que hemos configurado, que es la aplicación de función. Con esta actividad, concluimos
   este capítulo.

Resumen
La evolución de las funciones de los métodos tradicionales ha llevado al diseño de
la arquitectura sin servidor de acoplamiento flexible, de evolución independiente y
autosuficiente, que anteriormente era solo un concepto. Las funciones son una unidad
de implementación y proporcionan un entorno que no necesita que lo gestionen los
usuarios. Todo lo que tienen que importar es el código escrito para la funcionalidad.
Azure proporciona una plataforma madura para alojar funciones e integrarlas sin problemas,
en base a eventos o a petición. Casi todos los recursos de Azure pueden participar en una
arquitectura compuesta por funciones de Azure. El futuro está en las funciones, ya que
cada vez más organizaciones quieren mantenerse alejadas de la gestión de infraestructuras
y plataformas. Quieren descargar esto a los proveedores de cloud. Azure Functions es
una característica esencial que debe dominar todo arquitecto que trabaje con Azure.
En este capítulo, hemos visto los detalles de Azure Functions, funciones como servicio,
Durable Functions y Event Grid. El siguiente capítulo se centrará en Azure Logic Apps
y crearemos una solución integral que combina varios servicios sin servidor junto con
otros servicios de Azure, como Azure Key Vault y Azure Automation.