100: Azure Functions”. Espero poder aportarte los conocimientos mínimos y necesarios para que puedas iniciarte en este apasionante mundo. Jose María Flores Zazo, autor
manejar Sección 2 Manos a la Obra Crearás funciones desde distintas opciones y entenderás que son las funciones Sección 3 Binding y Triggers ¿Qué son? ¿Cuáles podemos usar?, ¿puede crearme uno?, ...
Avanzado Desplegar, observar y monitorizar, buenas prácticas y grandes pifias Índice Resumen Anexo Te toca trabajar Donde puedes ver más documentación y una introducción a AKS + KEDA, …
YouTube podrás ver un video en el portal de YouTube Cuando veas el logotipo de GitHub junto a un enlace, es para ir a las fuentes de los ejemplos Cualquier texto con subrayado es un enlace, por ejemplo: https://jmfloreszazo.com
Service) es una opción muy popular de desarrollo en la nube. Con ellas puedes crear pequeños fragmentos de codigo que se ejecutan en un breve período de tiempo y alojarlos en una nube (Azure Functions, AWS Lambda, Google Cloud Functions, etc.). Se factura por tiempo de ejecución y prácticamente no necesitas preocuparte de alojamiento y escalados. Es decir, que la plataforma subyacente se encarga de todas las necesidades. En esta sección obtendrás el conocimiento básico de Azure Functions, que nos ayudará a progresar en este workshop. Estructura de la sección: 1. Introducción a Azure Functions 2. Introducción a Serverless 3. Azure Web Jobs vs Azure Functions 4. Ventajas e inconvenientes del uso de Azure Functions 5. Planes de Hosting de Azure Functions 6. Casos de uso de Azure Functions Objetivos: • Entender los fundamentos de la computación serverless y Azure Functions. • Identificar escenarios donde puedes usar Azure Functions. Resumen – En esta sección…
plataforma Azure y se base en el modelo FaaS. • Tu trabajo será crear el codigo del programa, activar la función y hospedarla. • La plataforma subyacente gestiona la infraestructura y el software de hospedaje. No necesitarás preocuparte dentro de tu codigo de los problemas de escalado. La plataforma subyacente, Azure, lo gestionará por ti. Se factura cuando nuestra función esta activa y trabajando. Por tanto, cuando esta parada no incurres en gasto. Sin embargo, puedes aumentar el tiempo de ejecución a través de los planes de alojamiento. Una función se ejecuta cuando es invocada con un desencadenador o vinculación (triggers o bindings). Esta se ejecuta durante un periodo de tiempo y luego entra en un estado de inactividad. Se despierta cada vez que es invocada. Tarda un tiempo en calentarse y comenzará a ejecutarse. Los desencadenadores (triggers) pueden ser desde un temporizador que activa la función en intervalos predefinidos de tiempo, un nuevo mensaje en una cola o una simple llamada HTTP. Puede ser vinculada (bindings) a un Azure Storage un Cosmos DB un SQL, etc. Cualquier acción en estos recursos puede poner en marcha la función. Y para desarrollar puedes usar: C#, JavaScript, F#, Java, PowerShell, Python y Typescript. Dependerá de los runtimes que actualmente soporta Azure Functions: 1.x, 2.x, 3.x y 4.x Serverless – Con Azure Functions
que es Serverless: • No es serverless: cuando empiezas a ser facturado por la nube tan pronto como se pone en marcha, te facturan incluso si no usas el servicio. Además, debes ser tu quien planifica y configura el escalado de lo servicios, aunque algunos afortunadamente te ayudan con estos ajustes, pero, en cualquier caso, terminas por trabajar también en este punto. • Si es serverless: se factura cuando el servicio se esta ejecutando y ejecutado el codigo alojado; no se te factura cuando el servicio esta inactivo y no se esta ejecutado nada. Pagas al proveedor de la nube en función del consumo real, lo que te ayuda a ahorrar dinero. La plataforma subyacente gestiona todos los aspectos de escalado de tu aplicación. No es necesario configurar nada. Los servicios serverless son lo suficientemente inteligente s para agregar nuevas instancias para, por ejemplo, gestionar el trafico entrante y eliminar las instancias adicionales cuando el trafico disminuye. Serverless, no significa que los servicios de la nube no estos alojados en ningún servidor. Logicamente lo que ocurre es que no tienes control sobre el servidor. Logicamente un PaaS no es Serverless, pero un SaaS tampoco. Serverless se encuentra en el punto intermedio de PaaS y SaaS. Estos son algunos ejemplos serverless que podemos encontrar en Azure: Azure Functions, Azure Logic Apps, Azure Event Grid, Serverless Azure Kubernetes Services, Serverless SQL Server, … Serverless – Sin servidor
Azure Functions, los Web Jobs siguen la premisa de Code First. Ambos se basan en un Azure App Service y admiten prácticamente las mismas cosas: autenticación vía AAD, integración seamless con Application Insight, casi los mismos triggers y bindings, etc. En resumen, es más productivo y ofrece más opciones Azure Functions. Pero los webs job pueden ser buenos para un mayor control de los eventos JobHost. Cuidado cuando compartes App Services Plan en Web Jobs. ¿Diferencias? – Comparación FUNCTIONS WEBJOBS Modelo serverless con escalado automático Si - Desarrollo y pruebas en navegador Si - Precios de pago por uso Si - Integración con Logic Apps Si - Triggers (indico punto importante) Admite HTTP, WebHooks y Event Grid. No admite Files. No puede usar HTTP, WebHooks, Event Grid. Y admite Files. Lenguajes C#, F#, … C#. Más lenguajes si no usas el Web Job SDK (no recomendable) Administración de paquetes NPM y NuGet NuGet y NPM sin no usas el Web Job SDK (no recomendable)
describen las ventajas e inconvenientes más visibles que tenemos al adoptar este paradigma. Pros: • El proveedor se encarga de lo esencial y tu de programar, supuestamente tienes más tiempo para centrarte en codigo y en la funcionalidad. • Se ejecuta cuando funciona, también permite que ahorres dinero. • Puedes integrarlo con Azure Logic Apps y crear aplicaciones empresariales muy potentes, sin preocuparte de otros aspectos. Es más, con ambos y los cientos de integraciones, hasta te olvidas de aprenderte APIs de terceros. Contras: • Como tienes un tiempo limitado para ejecutar tu codigo, este debe estar optimizado para ese tiempo. Obliga a conocer bien el patrón de responsabilidad para hacer cosas más pequeñas. • Las funciones se ejecutan cuando ser activan. Esto provoca el conocido cold-start, arranque en frio. • Que auto-escale te hace perder control de la estimación de costes o la concurrencia de usuarios. En ningún caso se trata de una Ecuación de Suma Cero, optar por este modelo es en base a los casos de uso que veremos más adelante. ¿Ventajas?/¿Inconvenientes? – Comparación
la especificación de la infraestructura subyacente para las Functions, esta define como escalará y también te permitirá usar opciones avanzadas como el soporte a redes virtuales. Estos son los planes: Consumption Plan: • No tienes control sobre el escalado de la función. • Es Azure quien agrega o quita instancias en función del trafico. • Logicamente ningún control sobre la infraestructura subyacente. • Se factura cuando se ejecuta. • Problema del cold-start, máximo de ejecución son 10 minutos, 5 como predeterminado. Si se agota el tiempo en medio de una transacción de tu codigo, se corta y se para tu ejecución. Premium Plan: • Puedes dejar precalentada la función, hot-start. Así evitas el fenómeno: cold-start. • Logicamente ningún control sobre la infraestructura subyacente. Pero si puedes adoptar un SKU tipo EP1, EP2 o EP3, que te permite ajustar un poco la memoria y la CPU. • Soporte a redes privadas virtuales. • Puedes ejecutar la función durante más tiempo. Máximo 30 minutos. • Las funciones se ejecutarán continuamente o casi continuamente. ¿Cómo vamos a gastar dinero? – No es gratis…
de un App Service de un Azure Application Web. • Puedes adoptar un SKU de cualquier App Service y por tanto un ajuste fino de la memoria y la CPU. • Puedes configurar un escalado automático o manual. • Soporte a redes privadas virtuales. • Es el plan más adecuado para aplicaciones de larga duración. Os dejo un enlace donde se explican los timeout de las Functions y que es el enlace:. https://docs.microsoft.com/es-es/azure/azure-functions/functions-host-json#functiontimeout
aplicar prácticamente en cualquier patrón moderno. A continuación, os muestro algunos escenarios que considero más adecuados: • Puedes crear una aplicación n-tier. Puedes dividir la lógica empresarial y de acceso a datos en fragmentos más pequeños y alojar cada uno de ellos en una función. • Puedes ejecutar trabajos de procesado en segundo plano. • Puedes usar Azure Functions y Azure Durable Functions (ya lo veremos más adelante) para crear aplicaciones basadas en flujos de trabajo en las que puedes orquestar cada uno de los pasos del flujo de trabajo. • Puedes usarlas para crear aplicaciones basadas en microservicios. Cada función puede albergar un servicio de negocio. • Puedes utilizarlas para aplicaciones basadas en ejecuciones programadas, es decir, que se ejecuten a intervalos de tiempo específicos o durante un momento dado del día. • Puedes crear sistemas de motivaciones para activar una función que notifique a un usuario final o un sistema de condiciones y eventos. • Puedes usarlo en escenarios de IoT para implementar una actividad empresarial o procesar los datos adquiridos para almacenarlos o enviarlos a otro subproceso. • Puedes usar Azure Functions y Azure Event Grid para arquitecturas event-driven, donde estas funciones se activan para ejecutar algun tipo de tarea. ¿Cuando debe usarse un modelo serverless? – Veamos...
opciones. Si te sientes cómodo con el CLI usa PowerShell o el CLI de Azure. Puedes usar entornos de desarrollo: VS Code o Visual Studio. O puedes incluso usar el portal. En esta sección aprenderás a crear Azure Functions, requisito previo antes de meterse a más bajo nivel. Estructura de la sección: 1. Crea una función usando el Portal de Azure 2. Crea una función localmente usando el CLI 3. Crea una función usando Visual studio code 4. Crea una función usando Visual studio 2022 Objetivos: • Entender las herramientas principales de Azure Functions. • Crear Azure Functions con las diversas herramientas. Resumen – En esta sección…
no soy partidario de usar el portal para crear infraestructura y aun menos codigo, pero ver de forma visual que es lo que debemos hacer para construir una Azure Functions, aporta una información valiosa y que podrás asociar con más facilidad cuando creas infraestructura por código (IaC). https://portal.azure.com – Video https://youtu.be/7Binzo0RM0s
mano, es un proceso muy instructivo que te servirá para entender mejor el trabajo dentro de un IDE, que veremos más adelante. Par poder trabajar debes: • Instalar Azure Functions Core Tools. npm install -g azure-functions-core-tools@latest –unsafe-perm true o https://github.com/Azure/azure-functions-core-tools • Instalar .Net 6. Línea de comandos – Prueba tus funciones en local https://youtu.be/56gk2LC5oEI
mundo la tiene, es una herramienta muy versátil. Que necesitas para poder crear funciones: • Instalar VS Code • Instalar .Net 6. • Extensión de Azure Functions: https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurefunctions Visual Studio Code – Más sencillo aún… https://youtu.be/HvD_Btcjbso
han servido para que veas algo más el interior de una function y con VS Code para que puedas ver que podemos trabajar con 0 problemas sin un IDE tan pesado como Visual Studio 2022: • Instalar Visual Studio 2022 • Instalar .Net 6. • Instalar Azure Development Workload desde la opción de reparar o añadir del instalador de Visual Studio Code. Mi herramienta habitual de trabajo – El IDE https://youtu.be/M1RcbWmRhS0
Functions permanecen en esta inactivo cuando no ejecutan ningun trabajo. Necesitas invocar a las funciones para que se puedan activar y ejecutar el codigo para el que se han construido. Para ejecutar vía triggers han de proporcionarnos los datos de entrada necesarios para ejecutar la función mientras que los bindings a de forma declarativa serán capaces de interactuar con otros servicios. En esta ocasión vamos a ver: 1. ¿Qué son los triggers y los bindings? 2. Triggers y Bindings soportados 3. Diversos Casos de uso 4. Demos 5. ¿Qué con Custom bindings? 6. Y un par de off-topics: Webhooks y Proxys Objetivos: • Al finalizar esta sección entenderás que son los triggers y bindings. • Y dónde debes o puedes usarlos. Resumen – En esta sección…
se ejecutará la función. Estos despiertan la función de su estado inactivo (idle) y hacen que se ejecute. Las funciones se pueden ser invocadas a traves de una amplia gama de servicios. Estos servicios invocan a la función pasándole los datos de entrada mediante un payload. Solamente podrás configurar un único triggers para cada función en Azure. Las funciones de Azure pueden interactuar con muchos servicios, por ejemplo, Blob Storages, Cosmos DB, Kafka, … Tambien podrás usar bindings (enlaces) para facilitar el intercambio entre estos servicios y las funciones de Azure. Este intercambio puede ser bidireccional, según lo necesites. No es necesario escribir codigo adicional para implementar triggers o bindings. Solamente mediante definiciones declarativas podrás habilitaros. Esto ahorra mucho esfuerzo de programación. Piensa en lo que ahorras. Si trabajas en C#, desde el IDE de VS Code o Visual Studio, podrás añadir decoradores a la function para habilitar los triggers y bindings. Sin embargo, desde el portal deberás modificar el fichero function.json (nunca esta de más saber esto). Su uso define a la función – Este prefijo define su uso
decir, pueden recibir datos de desencadenador, pero no pueden devolver ningún dato al servicio desencadenante. Los bindings, sin embargo, son bidireccionales, como indicaba antes. Las Functions pueden enviar o recibir datos a un servicio previamente configurado. Estas son los posibles flujos en un bindings: • In • Out • Inout Los bindings, sin embargo, son bidireccionales, como indicaba antes. Las Functions pueden enviar o recibir datos a un servicio previamente configurado. Estas son los posibles flujos en un bindings: Trigger Azure Cosmos DB Azure Function Service Bus Service Bus Queue
amplia gama de integraciones. Como ya hemos hablado antes, existen a fecha de Septiembre de 2022, cuatro versiones de Azure Functions, a saber: 1.x, 2.x, 3.x y 4.x. Logicamente estas versiones son indicativos de que puedo hacer con cada una de ellas. • Triggers soportados en versión 1.x: Blob Storage, Azure Cosmos DB, Event Grid, Event Hubs, HTTP and WebHooks, IoT Hub, Queue Storage, Service Bus, Timer. • Triggers soportados en versión 2.x y superior: Blob Storage, Azure Cosmos DB, Dapr, Event Grid, Event Hubs, HTTP and WebHooks, IoT Hub, Kafka, Queue Storage, RabbitMQ, Service Bus, Time. • Bindings soportados en versión 1.x: Blob Storage (input, output), Azure Cosmos DB (input, output), Event Grid (output), Event Hubs (output), HTTP and WebHooks (output), IoT Hub (output), Mobile Apps (input, output), Notification Hubs (output), Queue Storage (output), SendGrid (output), Service Bus (output), Table Storage (input, output), Twilio (output). • Bindings soportados en versión 2.x y superior: Blob Storage (input, output), Azure Cosmos DB (input, output), Event Grid (output), Event Hubs (output), HTTP and WebHooks (output), IoT Hub (output), Queue Storage (output), SendGrid (output), Service Bus (output), Table Storage (input, output), Twilio (output), Dapr (input, output), Kafka (output), RabbitMQ (output), SignalR (input, output). Nota: No podrás crear triggers con Kafka o RabbitMQ en planes de consumo. Y Dapr, solo son aplicables para Azure Kubernetes Services ¿Cuáles son? Binding & Trigger(3/3)
ejecutará la función. Estos despiertan la función de su estado inactivo (idle) y hacen que se ejecute. Las funciones se pueden ser invocadas a través de una amplia gama de servicios. Estos servicios invocan a la función pasándole los datos de entrada mediante un payload. Solamente podrás configurar un único triggers para cada función en Azure. Las funciones de Azure pueden interactuar con muchos servicios, por ejemplo, Blob Storages, Cosmos DB, Kafka, … Tambien podrás usar bindings (enlaces) para facilitar el intercambio entre estos servicios y las funciones de Azure. Este intercambio puede ser bidireccional, según lo necesites. No es necesario escribir codigo adicional para implementar triggers o bindings. Solamente mediante definiciones declarativas podrás habilitaros. Esto ahorra mucho esfuerzo de programación. Piensa en lo que ahorras. Si trabajas en C#, desde el IDE de VS Code o Visual Studio, podrás añadir decoradores a la function para habilitar los triggers y bindings. Sin embargo, desde el portal deberás modificar el fichero function.json (nunca esta de más saber esto). #1 – Caso de uso Output Binding Trigger Service Bus Queue Azure Function Service Bus Queue
de un blob para procesarlo y luego almacenar fichero procesado en el blob Esta opción es buena cuando necesitas realizar un par de actividades en segundo plano, por ejemplo, esta estrategia se puede usar en un sistema de procesamiento de imágenes. Un usuario carga imágenes mediante un UI y se guardan en un blog storage asociado. A intervalos de tiempo se ejecuta una Azure Function que recoge estas imágenes y las procesa para colocarlas nuevamente en el blob del usuario. O por ejemplo , como puede ser en cualquier web que enviamos la imagen del avatar en alta resolución y crea dos ficheros nuevos uno en baja resolución y el otro en la medida máxima soportada guardados en storages distintos. #2 – Caso de uso Trigger Timer Azure Function Azure Storage Blob Input/Output Binding
que se encarga de procesar la información para almacenarla. Siempre que se solicite un verbo REST API la Function puede estar enlazada para realizar un proceso lógico de negocio y persistirlos en una base de datos. Este escenario se ajusta muy bien para cuando necesitas construir una capa de acceso a datos por encima de la capa de la base de datos. Esta capa de acceso a datos expondrá datos subyacentes de la base de datos usando REST API. Es resumen estamos usando un Trigger HTTP exponiendo un API. #3 – Caso de uso Trigger Webhook Azure Function Azure Cosmos DB Output Binding
un mensaje y guardarlo en Azure Cosmos DB. Y que diferencia puede existir con el Caso de Uso #1, pues muy poco, pero se quiere hacer constancia que podemos mezclar cosas que no son de Azure, RabbitMQ puede estar en AWS, por ejemplo.. Un escenario real, es sin duda que esto te permite hacer aplicaciones basadas en microservicios. #4 – Caso de uso Trigger RabbitMQ Azure Function Azure Cosmos DB Output Binding
Function para enviar un correo con los datos del evento. Configuro un Event Grid para que lance una Function. Un suscriptor de eventos como Azure Server Bus Queue, puede suscribirse a un Event Grid. Cuando un mensaje llegue a una cola, genera un evento y envía el mensaje a un Event Grid. Esta invoca a la Function., que procesa los datos del mensaje y envía los datos como un email al equipo de operaciones.. Un ejempló típico, es poder crear aplicaciones reactivas mediante event-driven. #5 – Caso de uso Trigger Event Grid Azure Function SendGrid Output Binding
de uso, esto os ayudarán a identificar el uso dentro de una arquitectura. A continuación, vamos a implementar una serie de ejemplo básicos para que veáis su funcionamiento: • Queue Storage Trigger y enviar el mensaje a un ServiceBus Binding (repositorio y video). Para ello necesitas saber como trabajar con ServiceBus. Implementaciones – Functions & I/O Bindings
hacen que codifiquemos menos, simplifican nuestro código. Si tienes algún servicio que no esta en la lista y en tu organización lo usas mucho, o bien quieres aportar a la comunidad de desarrolladores, puedes crear tu propio enlace o bien existe un enlace, pero no cumple con los requisitos de negocio. La creación de un Binding personalizado es sencilla y el beneficio es obvio, reutilizar. Para poder ponerte en marcha necesitarás el SDK de Azure Functions basado en extensiones de WebJobs, gracias a este SDK te centrarás en la parte de negocio, ya que la parte subyacente y común en los Binding ya nos lo da el SDK. Como veis Microsoft nos lo pone fácil. Por cierto, a veces verás que Microsoft lo llama custom handlers (controladores personalizados). https://docs.microsoft.com/es-es/azure/azure-functions/functions-custom-handlers https://github.com/Azure-Samples/functions-custom-handlers Personalizaciones – Crea tus propios bindings
ya que estamos hablando una especie de Binding. Cuando tenemos una Function podemos modificarla para que admita más entradas y salidas. Por ejemplo, desde el portal, se ve muy bien: En este caso, podemos usar la salida para crear una nueva en formato HTTP que cumpla lo que la aplicación de un tercero, somo puede ser SharePoint, nos admita esa recepción de notificación. https://docs.microsoft.com/es-es/sharepoint/dev/apis/webhooks/sharepoint-webhooks-using-azure-functions Un pequeño paréntesis – Por si no conoces este concepto
off-topic. Como su propio nombre indica, es una pasarela, que se usa para controlar las peticiones que le llegan a tu servicio de Azure Functions y así poder redirigirlas si fuera necesario. El ejemplo más simple es que en la función que se crea con el template, el parámetro “name” lo concatenas con “Hello”, podemos usar un proxy para modificar esa petición: https://docs.microsoft.com/es-es/azure/azure-functions/functions-proxies Un pequeño paréntesis – Por si no conoces este concepto
escenario con lógica separada y cada parte esta alojada en una Function. Si las cosas las haces bien, no es necesario orquestarlo con Durable Functions. Durable Functions, nos ayuda en la orquestación, si bien es cierto que sin ellas es mas complejo, pero no imposible como vienen a contarnos muchos usuarios de Azure Functions. Por ejemplo, es posible que tengas que ejecutar Functions en un orden específico: podrías usar una cola y las Functions o bien usar uno de los patrones de Durable Functions. La realidad es que internamente se apoyan en los Azure Storages Account para mucho más que mantener los estados como las Azure Functions (clásicas). En esta ocasión vamos a ver: 1. Introducción a Azure Durable Functions 2. Beneficios de usar Azure Durable Functions 3. Patrones 4. Un ejemplo sencillo Objetivo: • Conocer y saber aplicar patrones de Azure Durable Functions. Resumen – En esta sección…
e-Learning donde los estudiantes al completar el curso on-line se les emite un certificado. Para que el anterior escenario funcione, es necesario los siguientes pasos: 1. Comprobar si el alumno completó todos los módulos del curso. 2. Comprobar que el alumno tenga abonado todo el curso, en caso contario, se le envía una notificación para que page las tasas. 3. Comprobar si el alumno ha aprobado el examen del curso. 4. Emitir un certificado para que el alumno si ha completado los módulos del curso, pagados las tasas y aprobado el examen. Debes incluir un estado en cada paso del flujo y para lograrlo puedes usar Azure Durable Functions creando workflows con estado. Podremos desarrollador con C#, F# o Node.js. Las Durable Functions constan de los siguientes componentes: • Función cliente. • Función orquestadora • Función de actividad.
de negocio y actúa como un paso dentro del workflow. La Function de Orquestación invoca a la Function de Actividad y organiza como debe trabajar el workflow y después se duerme. La Function de Actividad ejecuta la funcionalidad de negocio, y una vez completada avisa a la Function de Orquestación para que se desactive (se duerma). La Function de Orquestación se activa, invoca la siguiente Function de Actividad y luego se vuelve a dormir hasta que obtenga un estado de finalización por parte de la Function de Actividad. La Function Cliente invocará a la Function de Orquestación. El usuario final o la aplicación consumidora del workflow es quien invoca a la Function Cliente. Azure Durable Functions mantiene y administra sus estados vía Table Storage y colas. Cuando una Function de Orquestación completa la ejecución, se apoya en un Azure Storage Table para dejar los datos de su contexto. La Function de Orquestación y la Function de Actividad intercambian datos entre ellas mediante un Azure Queue Storage. Nota: Ten en cuenta que servicio de Azure Durable Function te ayuda a crear flujos de trabajo. Pero también puedes usar Azure Logic Apps. Desde mi punto de vista es más potente y eficiente que trabajar con Azure Durable Functions. Function Cliente Function Orquestador Function Actividad Function Cliente Function Cliente
los beneficios que aporta Azure Durable Functions: • Puedes implementar escenarios de encadenamiento de funciones en los que invocar una tras otra como una secuencia. • Puedes implementar una ejecución en paralelo. • Mantener el estado de la función. • Crear flujos de trabajo con estado (statefull). • Tambien son serverless, si no, no estarían este curso, y funcionan exactamente igual, la plataforma subyacente la gestiona la nube. • Admite una amplia gama de patrones que nos ayudan a resolver problemas, como, por ejemplo: a. Fan-out & Fan-in b. Functions Chaining c. Monitoring d. Human interaction e. Aggregator f. Async HTTP APIs Resumen – Para esclarecer en que pueden ayudarnos
los datos a un conjunto de funciones o múltiples instancias de funciones para que se ejecuten en paralelo. Este proceso se llama fan-out. Estas funciones paralelas o instancias procesan más datos y lógica de negocio. Estas a su vez envían los datos a otros procesos que agregan datos y ejecutan más lógica de negocio, a este proceso se le llama fan-in. Fan-Out & Fan-In – #1 Function 1 Function 2 Instance 2 Function 2 Instance 2 Function 2 Instance 3 Function 3
La primera Function envía los datos a la segunda, esta procesa los datos y los envía a una tercera y así sucesivamente. Este proceso encadena un conjunto de funciones para realizar lógica de negocio. Function Chaining – #2 Function 1 Function 2 Function 3
tengas una actividad de larga duración y el proceso de negocio tarde. En casos que necesites seguir rastreando el estado de ejecución de la actividad de larga duración y obtener los datos una vez procesados podrás usar HTTP Api asíncrona. Una aplicación cliente activará el orquestador mediante protocolo HTTP. Async Http Apis – #3 Client Application HTTP Client Function Orchestrator Function Activity Function
monitorizar eventos o estados de ejecuciones de otros Functions. Puede que tengas que utilizar funciones duraderas y de larga duración para comprobar continuamente esos eventos y realizar una actividad cuando se cumple cierta condición. Por ejemplo, puede ser que tengas una Azure Function que se activa cada vez que se interesa un elemento en una cola de almacenamiento y generar una notificación/excepción cada vez que la función deja de funciona. Gracias a una Durable Function ejecutándose de forma continuada y monitorizando la información que precisas, podrás enviar esa notificación. Aquí os dejo un ejemplo muy interesante que puedes investigar por tu cuenta: https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-monitor?tabs=csharp Async Http Apis – #4 Do work/Chek Status Poll & Sleep
solicitud y un verificador (marker o checker) debe aprobarla, a aquellas personas que usan Azure Logic Apps os sonará mucho, por eso decía mejor usar Azure Logic Apps. Por ejemplo, un sistema de aprobación de compras que se desarrolla mediante un workflow de Azure Durable Functions. La función cliente invoca al orquestado de las funciones. La función que invoca al orquestado desencadena el flujo de aprobación, puede que vía correo, vía interface, se queda esperando a que se marque y verifique esa solicitud. Como este flujo puede bloquear, habitualmente se usan también temporizadores, Azure Durable Functions Timers, si pasado un tiempo no se da el ok a la solicitud, el timer puede marcarla como rechazada. Human Interaction – #5 Request Approval Process Approval Ecalate
tenemos controladas con Azure Durable Functions. Como ya he contado, y vuelvo a insistir, mejor con Azure Logic Apps, aunque seamos Devs y queramos escribir codigo, a negocio le interesa: funcionalidad lo antes posible y si Azure Logic Apps nos lo da, pues adelante con el desarrollo… en ningún momento os he puesto en la balanza el tema del coste económico que es otro punto muy importante en la ecuación Azure Durable Functions vs Azure Logic Apps (si lo deseas aquí tienes una presentación sobre Azure Logic Apps y un debate sobre Serverless). HTTP Trigger que saluda a todas nuestras oficinas (repositorio y video) Implementaciones – Manos a la obra
serverless usando distintas opciones, incluso las Azure Durable Functions, pero aun no hemos tocado un punto esencial, que es como desplegar estas soluciones. Como sugiere el titulo de esta sección, vamos a desplegarlas. ¿Cómo? De dos formas, una usando los IDEs y otra usando pipelines de Azure DevOps. En esta ocasión vamos a ver: 1. Desplegar soluciones desde Visual Studio 2022 y VS Code (es similar) 2. Desplegar soluciones a un SLOT desde el IDE 3. Generar una build e implementar la integración continua (CI/CD1) con Azure pipelines Objetivo: • Desplegar Azure Functions desde el IDE. • Trabajar con ranuras de despliegue: Deployment Slots. • Trabajar con pipelines de CI/CD para desplegar Azure Functions. 1. No es momento de ponerse purista si es Continuos Delivery o Continuos Deployment. Resumen – En esta sección…
Azure Function, vamos a ir directamente al grano: Desplegar una Azure Functions HTTP Trigger desde Visual Studio 2022 (repositorio y video). ¿Cómo?: • Creamos una Azure Function desde Visual Studio 2022 de tipo HTTP Trigger y sin modificar nada de lo que nos propone por defecto la plantilla. • Arrancamos para ver si funciona y es el momento de ver por qué necesitamos un Azure Storage. • Usando las opciones de Publish… que dispone el IDE. • A llamar a una Azure Function desplegada desde Postman Manos a la obra – Ejemplo
reales, al menos una instancia se ejecuta en producción y antes de hacer de llegar allí hemos pasado al menos por el entorno de desarrollo para realizar pruebas sobre su comportamiento. Con las ranuras (slots) podrás: • Desplegar instancias para hacer sanity tests o smoke test. • Hacer despliegues tipo Blue-Green. • Hacer zero/minimal downtime. Esto logra que los tiempos de inactividad sean mínimo. • Restaurar una copia de seguridad, haciendo swapping. Nos permite también restaurar una copia anterior inmediatamente si el nuevo despliegue rompe algo. Cuando estas en un Consumption Plan, solamente tendrás un solo slot, mientras que en los App Service Plan tendrás opción a tener múltiples slots. Vamos a ir directamente al grano, reutilizamos la demo para hacer un cambio mínimo y desplegar a un nuevo slot: Desplegar una Azure Functions HTTP Trigger desde Visual Studio 2022 (repositorio y video) ¿Qué son? – Breve resumen
el artefacto: Desde Visual Studio 2022 (GitHub Actions CI/CD y Azure DevOps) ¿Qué vamos a ver?: • Crear un YAML desde el portal y sincronizarlo para que luego lo tengamos en el ejemplo local. • Subir a nuestro portal de Azure DevOps a. Crear el YAML de build. b. Ejecutar y crear la build. El objetivo de este documento no Azure DevOps o GitHub Actions (del cual os dejo otro de mis documentos), por tanto, no vamos a ver como: • A configurar una buena práctica de CI. • A pasar los test correspondientes. • Etc. CI/CD – Sin llegar a ser puristas…
has desarrollado la función y desplegado a producción, debes asegurarte de que siempre esta activa y funcionando tal y como se esperaba. De hecho, debes estar al tanto de cualquier fallo y recibir alertas cuando su funcionamiento no sea el esperado. Debes tener suficientes registros y métricas para depurar problemas y comportamientos inesperados en el entorno productivo. La monitorización ayuda a observar el comportamiento en ejecución de una Function y proporciona registro que con el contexto adecuado puede ayudarnos a depurar bugs o excepciones en producción. En esta ocasión vamos a ver: 1. Usar Build-in Logging 2. Usar Azure application Insight 3. Escalado de instancias 4. Configura CORS Objetivos: • Al finalizar esta sección podrás implementar Azure Application Insight en tu Azure Function. • Y a monitorizar en Azure tus Azure Functions. Resumen – En esta sección…
o SeriLog, nos os preocupéis, podéis seguir usándolo, pero no es el objetivo de este workshop, ya que configurar un Log4Net para que escriba el log en un Azure Storage y a su vez Application Insight, es algo más complejo que usar el que nos dejan por defecto. Vamos a crear una Azure Function desde el portal, para ello creamos un nuevo grupo de recursos y con un Application Insight asociado. Si lo haces en un paso posterior, con crear un Application Insight coger la Key, en la Function se pone una Settings con esa Key y ya esta enlazado, vemos como seria el resultado. Logging estándar – En mi blog podéis ver un ejemplo de Log4Net & SeriLog…
Trigger y entramos en edición. Añadimos el codigo anterior y cogemos el valor de Get Function Url, para ejecutarlo desde un navegador. Observar que se ejecuta correctamente la Function. Como podéis observar estamos usando Ilogger: https://docs.microsoft.com/es-es/aspnet/core/fundamentals/logging/?view=aspnetcore-3.1 Entramos en el recurso de Azure Applcation Insight >> Transaction search >> View in logs.
que estamos escribiendo en el log: Y vamos a la opción de la Function >> Monitor (donde se encuentra Code + Test) podréis ver también detalles de invocación (las trazas):
realizar diagnósticos automáticamente que nos ayudan a solventar problemas de forma rápido. Si ves que una función no responde o no funciona como esperas, realiza un diagnostico. Si usamos la anterior función, la paramos y hacemos una llamada. Vemos que en el navegador nos da un error, en el navegador el error es evidente un 403, pero supongamos que no se mapean bien los errores y esta Function en la 4 en una cadena de workflow. ¿Cómo diagnosticamos? Lo primero que debemos hacer es ir a “Diagnose and solve problems” y ver que los namings que usamos durante todo el curso son problemáticos (era deliberado), pero vamos a lo más importante, que no funciona la Function. Para ello puede usar el botón “Aviability and perfomance” y buscar por “Down”, lanzas ese reporte y veamos los resultados: Azure App Insight – Logger para .NET6
crear unos Dashboard personalizados que de un vistazo podamos ver información que sea levante. Como tampoco esta parte pertenece al workshop, os recomiendo leer este documento sobre “Observabilidad y Monitorización”: Por ejemplo: Azure Monitor – Aprender a observar y monitorizar una aplicación en Azure
puede tener ningún error 500, debido a que es una arquitectura de orquestación y no coreografía, podemos poner una alerta y avisar inmediatamente a operaciones de este problema, quien dice operaciones dice a quien sea: vía mail, aviso por móvil, a un grupo, usando granularidad, etc.
podrás ver el comportamiento en tiempo real (nada es tiempo real) e ir estudiando el comportamiento. Esta opción es muy buena cuando estas en Dev con la función parada en Azure, la arrancas en local y vas viendo que generas contra dev.
que mires los errores 500, que son los que no debería haber en la aplicación. Junto a un deploy en Azure con la marca de uso de Application Insight: https://jmfloreszazo.com/anotaciones-en-azure-application-insight/ Podrás ver en cada error que estes examinando, a que deploy pertenece: Es una buena practica agrupar Functions de un mismo ecosistema para que puedas ver el mapa de uso y la generación del error. Si dejas un App Insight aislado, pierdes mucha trazabilidad. Esto es un tema para otro día. Resumen – Aprender a estudiar un bug
se derivan de la comunicación entre servicios externos o internos. A parte de la autorización en Azure Functions, ya sea Api-Key, ADD o lo que sea. Existe un problema muy destacable: la denegación de la comunicación originada por una mala configuración de CORS. Para ello puedes modificar el fichero local.settings.json: { "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "UseDevelopmentStorage=true", "FUNCTIONS_WORKER_RUNTIME": "dotnet“ }, "Host": {"CORS": "*"} } Para llamar a funciones tendrás que usar endpoints, por tanto, habilitar CORS y definir el nombre del dominio y los puertos. En el ejemplo anterior con asterisco le decimo que puede ser llamadas desde cualquier aplicación, independientemente del dominio en el que se ejecute. Esto esta bien para desarrollo, pero en producción esto tenemos que configurarlo correctamente. ¿Ahora entiendes que es una de las primeras cosas si tienes una denegación en su servicio?. ¿Aquí? – Muchos problemas derivan una mala configuración
forma automática en Azure Functions basadas en plan de consumo. Donde debes ser tu quien escale la aplicación es en los App Service Plan. En realidad, os voy a enseñar como escala un App Service Plan. Existen dos opciones verticales (más CPU, memoria, etc.) y horizontal (más instancias). Esto se puede hacer de forma manual o de forma automática. La forma manual, es que operaciones este pendiente para subir o bajar el escalado vertical u horizontal con respecto a las necesidades. Mientas que el automático es capad de hacer scale-in o scale-out (más o menos) según una regla. Como todo esto se sale del propósito de este monográfico, os dejo un enlace donde podéis ampliar mucha más información: https://docs.microsoft.com/es-es/azure/app-service/manage-scale-up Operaciones – Manual o automática
relación a las Azure Functions. Has aprendido los mecanismos para crear e implementar. Has creado varias Azure Functions de demo, en el apéndice te pondré sobre la pista de cosa como Azure API Management, Azure Key Vault, te he contado varias veces que un binomio es Azure Logic Apps y Azure Functions, etc. Pero esto no te salvará de cometer errores. Para que en la medida de lo posible no cometas muchos errores al inicio vamos a ver . 1. Buenas prácticas 2. Grandes Pifias 3. Contenedores y Azure Functions en Azure Kubernetes Service (AKS) 4. Azure Container Apps Los objetivos son auto explicativos: • Por un lado, una serie de buenas prácticas que da la experiencia. • Por otro lado, evitar que vuelvas a cometer errores que yo he cometido. • Que veas como llevar una function a contenedores. • Y como punto y final unos enlaces de herramientas muy necesarias que debes conocer. Resumen – En esta sección…
construir soluciones eficientes, robusta, tolerantes a fallos, de alta escalabilidad y disponibilidad. Como bien sabéis Azure Functions (de la forma estándar) no te permite control sobre la infraestructura subyacente por tanto del alojamiento y como escala este. Tu misión es diseñar soluciones basadas en Azure Functions para que se ejecuten de manera optima y escalable según los requisitos comerciales. Aunque no tengas control sobre la capa de infraestructura, puede de diseñar aplicaciones eficientes para esa capa. Por tanto, eliges el mejor diseño que se adapte a los requisitos de negocio, por ejemplo, si se necesita una tarea de larga duración, puede que no sea buena idea alojarlo en un plan de consumo, máximo puedes estar 10 min ejecutando. En otras palabras, no puedes ejecutar codigo más allá de 10 min en un plan de consumo. O en otras ocasiones, también tienes que decir que forma es más eficiente par administrar y monitorizar las funciones. O cualquier caso se irá surgiendo. Con alguna de estas mejores prácticas, que no dejan de ser recomendaciones y directrices de diseño, puedes crear una solución basada en Azure Functions, sin que en el futuro estas decisiones sean un bloqueo y evolución del producto que estas creando. A continuación, vamos a ir desglosando cada una de ellas: Resumen – En esta sección…
En un escenario ideal, las funciones son serverless. No tienes control sobre la infraestructura subyacente o el alojamiento. Ni siquiera tienes control sobre aspecto como escalabilidad; la infraestructura subyacente escala a mediada que la aplicación lo necesita. Por tanto, debes validar si tu codigo se puede ejecutar de forma serverless o no. Es posible que tengas escenarios que necesiten un mayor control del entorno e instalar un software adicional para apoyar la ejecución de tu codigo. En tal caso, no puedes. Aunque puedes llegar al entorno via Kudu, poco más allá de manipular ficheros es lo que puedes hacer. En este caso la única opción es un PaaS o un IaaS. El uso de un PaaS brinda mayor control sobre la escalabilidad, pero te obliga a generar reglas manuales. Si necesitas mayor control, posiblemente tu plan sea usar APIs alojadas en un Azure WebApp. Para resumir: ten en cuenta que si necesitas mayor control sobre el entorno subyacente (software adicional) usa unas VM (IaaS), en caso de que no tengas que llegar a esa capa tan inferior, usa un PaaS como Azure WebApp. Elije el lenguaje de programación correcto Como bien sabéis se puede trabajar con diferentes lenguajes, pero antes de elegir algo distinto a C#, revisa bien que este lenguaje cumpla los requisitos que debe cumplir la Function, puede que algunas cosas estén en preview o estén pendientes en el roadmap. Tambien te permite mezclar lenguajes, unas Functions en Python por que son más matemáticas y las demás en C#. Es independiente, cada Function llevará el lenguaje que elijas.
del diseño. Si eres purista deberías usar plan de consumo al 100% ya que nos permite: desde ejecutar solo cuando se necesite (ahorrando dinero), que tu codigo este optimizado o disgregado (tiempo máximo de ejecución), olvidar la infraestructura subyacente, que escale según la demanda (esto aprovisiona nuevas instancias cuando lo necesitas y las decomisiona cuando ya no son necesarias). Tambien tiene sus peros: despertar la Function, no es instantáneo la ejecución si no se usa, debe arrancar cada vez, el conocido cold-start. Por otro lado, si usas un plan premium, te ahorras el cold-start, una instancia siempre esta en ejecución y además puedes controlar un poco los planes. Pero indudablemente a un precio mayor. Eso sí, continuamos siendo puristas y haciendo serverless 100% nuestra aplicación. Si ya no somos tan puristas y necesitamos que nuestro codigo se ejecute más allá de los 10 min, no nos queda más que usar un plan dedicado. Escoger entre Stateless y Statefull Debes evaluar el escenario del cliente, pero en resumen si necesitas una maquina de estados (un carrito de la compra) o bien usas Durable Functions o estudias muy bien el trabajo del workflow con colas y funciones, es decir esto es un escenario con estado. Si por el contrario la función se ejecuta de forma independiente, digamos que para coger los códigos de descuento que tienes, esto es stateless, es un simple CRUD que no exige mayor esfuerzo. Una mala elección puede hacer más compleja tu aplicación para resolver un problema que en principio era sencillo. Aprende a identificar el escenario.
marcha Las funciones se ejecutan cuando se activan, una vez completada su ejecución, entra en un estado de inactividad y finalmente en suspensión. Esto tiene que ver mucho con los planes de consumo, si necesitas que siempre este activa una instancia, vas aun plan o bien al final usas una especie de Azure Function que por debajo es una mera Azure WebApp. Recuerda los planes y sus características. Una aplicación de IoT que necesite mandar una alerta tras llegar una temperatura umbral, un plan de consumo para tu Function, es mala idea, ya que el tiempo hasta que se activa, es vital. Lidiar con codigo de larga duración Más de lo mismo, basado en los planes o bien puedes romper tu Function en diferentes subprocesos cada vez mas pequeño, si no tienes que mandar nada de vuelta. Facilitar la integración y la comunicación entre otros servicios externos y Azure Es posible que tengas que integrar una Azure Function con un Servidor Apache Kafka alojado en AWS. Yo siempre te diría que mejor todo en un solo Cloud, pero si no se puede, debes estudiar donde se ubican los distintos recursos para evitar lags, exponer adecuadamente tus Functions (uso de CORS que dije antes), usar VNet si es necesario, lo que veas para que se permita bajo unos estándares de seguridad mínimo.
una elección de una Azure Function 100% serverless, consumo, ya nos trae todo el escalado puede provocar un problema muy grande en los servicios que necesitas, como un Azure SQL Server o un CosmoDB, debes tener en cuenta que esos servicios escalen de forma adecuada a lo que puede escalar tus Azure Functions. Muchas veces esto se olvida y creamos unos cuellos de botellas que pueden tumbar un sistema. En resumen, donde debes tener cuidado es en los servicios IaaS y PaaS cuando trabajas con un FaaS. Tu aplicación debe ser tolerante a fallos Si tu función no se ejecuta, debes tener mecanismos que no te pierdan datos. Por ejemplo, una Function que escribe en SQL Server, da error al escribir, pues se pierde el dato: no rotundo, debes crear una cola que mueva esos datos y luego sean procesados o guardarlo en un fichero y enviar algún tipo de error. Existe muchas opciones, pero verás que ante nuevas ventajas nuevos problemas. Protege tus API desarrolladas en Azure Functions Desde oAuth, hasta ADD, pasando por APIM, CORS, etc. Existen muchas opciones, para un rato a estudiarlas (ver algunas en el anexo). Es crucial que desarrolles defensivamente.
que no puedes acceder a la infraestructura subyacente, cuantas más cosas: trazas, Insight, de terceros (DataDogs) obtengas, mucho mejor. Permite y facilita la auditoria de tu aplicación. Sobre todo, mucho cuidado con la burbuja de errores cuando trabajas con HTTP y sube los errores a la primera capa, que no se diluya con un 200 y luego un mensaje conde pones resultado de error. Cuida los verbos y respuestas HTTP. Incorporar prácticas de DevOps e IaC Tal y como comenté antes: marca de despliegue (por ejemplo) o que tengas la IaC por si tienes que tirar todo abajo y recuperarlo inmediatamente. No solo vale la IaC para recuperaciones, si no, para cualquier desarrollador que vea si el plan es o no adecuado, puede que no tenga acceso al portal de Azure. Enfoca tu trabajo con programación defensiva Ya lo he mencionado antes. Por ejemplo, digamos que tu función procesa imágenes y las carga a un Blob. Después de procesar 30 imágenes, se produce un error e intenta procesar otra vez desde 0, esto es erróneo, debería continuar con la 31 y por supuesto registrar el fallo de la imagen de error 30. Esto es programación defensiva. Un ejemplo claro es cuando trabajas con colas: las dead-letter o poison queues.
codificación: • Todos estamos a favor de la inyección de dependencias. Pero varios autores en el caso la configuración de una Function prefiere usar variables de entorno y no usar un fichero de configuración inyectado. Yo uso los dos dependiendo del proyecto y como se han realizado. Y prefiero usar fichero de configuración. • Hemos dicho que funciones pequeñas y usar la S de SOLID. Si debes separar, crea un “ecosistema” y que todas usen el mismo Insight. • Existen autores que defienden que no se debe comunicar vía HTTP una función, que se usen colas o eventos. Aquí no estoy muy desacuerdo. La experiencia me dice que una arquitectura bien orquestada te permite usar comunicación HTTP. ¿Os cuento la diferencia entre orquestar y coreografiar? • Usar Singleton para los clientes HTTP en vez de crear uno por invocación. • Usar asincronía siempre, evitaremos bloqueos. A modo de resumen para la seguridad: • Securiza tus endpoints, ya hemos hablado de ADD, API-KEY, etc. Toda clave sensible de la configuración usa Azure Key Vault. Aquí es cuando entra en juego si usamos un fichero o variables de entorno. • Usa Managed Identities para acceso a recursos. • Usa APIM, ya lo hemos comentado, es la mejor forma de exponer tus APIs • Valida siempre los inputs, ¿quién no hace esto? • Deshabilita acceso por FTP a la Function y restringe el acceso via CORS • Si puedes, ya hemos comentado esto, usa VNet o Private Links o Azure Applications Gateways o FrontDoor.
errores: • Las funciones deben ser idempotentes, es decir, misma entrada produce misma salida y sin guardar estados (que sea stateless). • Valida los inputs, relacionado con seguridad. Para finalizar: A nivel de codigo puedes y debes usar Open API para documentar y sobre todo que si luego lo llevas a APIM, es un trabajo casi terminado. Logicamente muchas de las buenas prácticas que usas en tu día día desarrollando son aplicables aquí: SOLID, DRY, KISS, etc.. Debes mantenerlas. Que uses funciones, no quiere decir que tengas que programar de forma funcional excepto si trabajas con F#. Una técnica muy útil cuando trabajas con Functions y el proyecto es grande es usar NuGet, no solo para cosa que se trabajan igual, si no, para generar un NuGet de contrato con los mapeos. Esto ayuda mucho. Se podrían añadir más cosa, pero estas son las que he vivido en mi día a día.
a la hora de diseñar una aplicación con Azure Functions. No hace falta que seas arquitecto, un desarrollador también debe saber verlo y decírselo a un arquitecto, no son perfectos. Estas que os pongo, son por que yo las he visto, no son ciencia ficción: Compartir funciones con un mismo App Service Si tienes demasiadas funciones es posible que los recursos se agoten. Muchas veces nos dicen, es que, llegado un pico de cierre de trabajo, la aplicación no escala y ves que el arquitecto había metido todo en un Service Plan. Recordar que los Services Plan tienen su propia opción de monitorización y observación de recursos. He visto que esto se olvida mucho. Procesado de los datos de entrada en una sola pieza Divide en subprocesos, esto hace que si aun esta procesando y llega otra request se vuelva a ejecutar de nuevo y pierdas el trabajo que venias realizando. Y si puede evitar entradas de datos de 1 en 1 mejor, intenta trabajar con lotes. Resumen – Bueno sí, son ca…s, pero tenía que usar un eufemismo
mismo plan Un clásico y que muchos clientes te lo piden, también con WebApp. Evitar esto y contar los problemas que tiene, sin pelos en la lengua. Una vez que tengáis ese correo del cliente: “lo quiero así y punto” os podéis proteger. Sobre todo, tener en cuenta que si usas Services Plan, el de producción debería ser siempre mejor que el de desarrollo. Y al final si ajustas bien, el coste es prácticamente despreciable (el coste es otra de las máximas del cliente). Y ya puestos aprovecha los slots para zero-downtime maintenance. Si mezclas también slots de desarrollo y producción, como nos los nombre bien, puedes liarla bien con un swap. Sí, he sufrido una metedura de pata debido a estos naming de los slots o los swaps en Azure DevOps. Compartir cuentas de almacenamiento entre Azure Functions (y con WebJobs) 1 Functions 1 Azure Storage. Una Function en un escenario de alta demanda puede llenar mucha información imaginaros 2, si es un LRS, pues peor aún. A colación viene los WebJobs, nunca, nunca enlaces un Storage de producción ya sea Dev con un WebJobs de local, puede que no se ejecute y es por que esta ejecutándose el de dev. Lo mismo pasa con una Azure Function Time Trigger (son primos hermanos), en local estas esperando 5 min para que se ejecute y nunca sucede por que los datos que marcan la siguiente ejecución están en el Storage y puede que la de desarrollo ya lo cambiara. Mucho cuidado.
queremos evitar la perdida de datos, cuando se configura mal o no se tiene un buen mecanismo con dead-letter en una cola, por ejemplo, nos lleva a una inconsistencia de nuestra aplicación. Azure Functions versión 3/4 y con C# ya lleva unas directivas que nos ayuda al respecto. Sin embargo, en la versión 2 no, y aquí es cuando te toca incluir la librería Polly. Por ejemplo: [FunctionName("EventHubTrigger")] [FixedDelayRetry(5, "00:00:10")] public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log) { // ... } Para más información: https://docs.microsoft.com/es-es/azure/azure-functions/functions-bindings-error-pages?tabs=csharp
de las Functions, pero existe la posibilidad de contenerizar tus Functions y desplegarlas en cualquier K8s del mercado ya sea AKS o AWS o en tu propia máquina local con tu Vagrant. A continuación os dejo unos enlaces que debéis investigar vosotros para que podemos usar contenedores, ya que este documento solo trata de serverless. Es importante conocerlo y ver las limitaciones que imponen en esto entornos: • Azure Container Apps. • Azure Functions en AKS. • Generación de una function en Linux con un contenedor personalizado. Con estos enlaces ya tienes suficiente información para ir viendo como funciona esta forma de trabajar. Vendor Lock-In –No, ya que puedes desplegar tus functions en K8s, ...
algunos recursos que son muy utilizados junto a las Azure Functions y es conveniente conocerlos. Si puedes intenta hacer una de las prácticas que te dejo: • Azure Key Vault • Azure API Management (enlace uno y enlace dos) • Azure Functions con Contenedores • Azure Logic Apps llamando a una Azure Functions Esto sumando a un par de pruebas con Azure Active Directory te habrán otorgado el conocimiento suficiente para acometer prácticamente cualquier proyecto Serverless. Y ya fuera del entorno serverless te recomiendo revisar el funcionamiento de KEDA.
“Experto/a en: asincronía con .NET”? En mi próximo libro podrás tener por primera vez toda la información que necesitas en español sobre este apasionante mundo. El libro que está en preparación y tengo previsto liberar en Enero de 2023, lleva: • + 200 páginas y me faltan… • Explicaciones gráficas. • Ejemplos de código. • Todo ello usando .NET6. ¡Hasta mi próxima publicación!
jmfloreszazo
.png){kind=avatar}
elith
shinoa
77web
pospome
jaguar_imo
konifar
hinakko2
kishida
bigamitiongit
giginet
pinkumohikan
bkuhlmann
schacon
kevinliebholz
philhawksworth
eileencodes
addyosmani
gr2m
sachag
iamctodd
smashingmag
jponch
skipperchong
