Upgrade to Pro — share decks privately, control downloads, hide ads and more …

De 0 a 100 con Azure Functions

De 0 a 100 con Azure Functions

Jose María Flores Zazo

September 12, 2022
Tweet

More Decks by Jose María Flores Zazo

Other Decks in Programming

Transcript

  1. De 0 a 100:
    Azure Functions
    Ver. 1.0.0

    View Slide

  2. Bienvenidos
    Acerca de…
    ¡Hola! Gracias por leer
    “De 0 a 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

    View Slide

  3. Licencia bajo…
    Creative Commons
    Atribución 4.0 Internacional
    ¡Esta es una Licencia de Cultura Libre!

    View Slide

  4. Descárgate el libro
    “Manos a la obra con: IoT con Azure”
    y
    apúntate a la comunidad.
    AZURE IOT # ESP
    https://jmfloreszazo.com/azure-iot-esp/

    View Slide

  5. Índice
    Resumen
    Sección 1
    Introducción
    Resumen y herramientas que
    debes 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?, ...

    View Slide

  6. Sección 4
    Durable Functions
    Introducción, beneficios,
    patrones, …
    Sección 5
    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, …

    View Slide

  7. Requisitos previos y herramientas
    Resumen
    Conocimientos sobre
    codificación en C#
    Entorno de desarrollo
    Visual Studio 2022
    Practicar, practicar,
    practicar…

    View Slide

  8. Cuando encuentres…
    A tener en cuenta
    Con el logotipo de 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

    View Slide

  9. Sección 1
    Introducción

    View Slide

  10. ¿Qué vamos a ver?
    Objetivos
    Las FaaS (Functions as a 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…

    View Slide

  11. Azure Functions
    Introducción
    Azure Functions en un servicio de la 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

    View Slide

  12. Serverless
    Introducción
    A través de la comparación vamos a entender 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

    View Slide

  13. Web Job vs Azure Functions
    Comparación
    Al igual que las 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)

    View Slide

  14. Uso de Azure Functions
    Pros y Contras
    A continuación, se 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

    View Slide

  15. Planes
    Hospedajes(1/2)
    El plan de alojamiento te ayuda a elegir 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…

    View Slide

  16. Planes
    Hospedajes(2/2)
    Dedicated Plan:
    • Es el mimo que el 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

    View Slide

  17. Casos y Ejemplos
    Usos
    El servicio Azure Functions se puede 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...

    View Slide

  18. 2022, el pasado…
    Azure Serverless
    https://youtu.be/a7R1PiQv3UI

    View Slide

  19. Sección 2
    Manos a la obra

    View Slide

  20. ¿Qué vamos a ver?
    Objetivos
    Puedes crear funciones con varias 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…

    View Slide

  21. Creando Azure Functions
    Portal
    Parto de la base de que 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

    View Slide

  22. Creando Azure Functions
    CLI
    Conocer como hacer una función a 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 [email protected] –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

    View Slide

  23. Creando Azure Functions
    Visual Studio Code
    Supongo que todo el 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

    View Slide

  24. Creando Azure Functions
    Visual Studio 2022
    Las anteriores acciones nos 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

    View Slide

  25. Sección 3
    Bindings y Triggers

    View Slide

  26. ¿Qué vamos a ver?
    Objetivos
    Las aplicaciones serverless con Azure 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…

    View Slide

  27. ¿Qué son?
    Binding & Trigger(1/3)
    Los triggers (desencadenadores) definen como 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

    View Slide

  28. ¿Qué son?
    Binding & Trigger(2/3)
    Los triggers son unidireccionales. Es 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

    View Slide

  29. Los escenarios reales (comerciales) necesitan que se de a una 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)

    View Slide

  30. Análisis
    Casos de Uso(1/5)
    Los triggers (desencadenadores) definen como 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 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

    View Slide

  31. Análisis
    Casos de Uso(2/5)
    Un trabajo programado recoge un fichero 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

    View Slide

  32. Análisis
    Casos de Uso(3/5)
    WebHooks enganchado a una Azure Function 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

    View Slide

  33. Análisis
    Casos de Uso(4/5)
    RabbitMQ desencadena una función para procesar 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

    View Slide

  34. Análisis
    Casos de Uso(5/5)
    Un Event Grid invoca a Azure 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

    View Slide

  35. .Net
    Algunos ejemplos
    Antes hemos visto una serie de casos 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

    View Slide

  36. ¿Qué es?
    Custom Bindings
    Como podrás haber visto, los Binding 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

    View Slide

  37. ¿Qué son?
    Webhooks
    No es exacto que sea un off-topic, 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

    View Slide

  38. ¿Qué es?
    Proxys
    En este caso si que es un 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

    View Slide

  39. Sección 4
    Durable Functions

    View Slide

  40. ¿Qué vamos a ver?
    Objetivos
    Casi seguro que tendrás un 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…

    View Slide

  41. Introducción
    Durable Functions(1/2)
    Supongamos un programa de una plataforma de 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.

    View Slide

  42. Introducción
    Durable Functions(2/2)
    La Function de Actividad realiza la lógica 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

    View Slide

  43. ¿En qué nos ayudan?
    Beneficios
    A continuación, un listado de 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

    View Slide

  44. Descripción
    Patrones(1/5)
    Una función ejecuta lógica de negocio y pasa 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

    View Slide

  45. Descripción
    Patrones(2/5)
    Varias funciones se ejecutan una tras la otra. 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

    View Slide

  46. Descripción
    Patrones(3/5)
    Existen escenarios en los que es posible que 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

    View Slide

  47. Descripción
    Patrones(4/5)
    Puede que tengas escenarios en los que necesites 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

    View Slide

  48. Descripción
    Patrones(5/5)
    Otro escenario es, que tengas que enviar una 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

    View Slide

  49. .Net
    Un ejemplo
    Hemos podido ver todas las casuísticas que 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

    View Slide

  50. Sección 5
    Avanzado

    View Slide

  51. ¿Qué vamos a ver?
    Desplegando(1/4)
    Hemos visto como crear soluciones 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…

    View Slide

  52. Visual Studio 2022
    Desplegando(2/4)
    Como ya sabemos como desarrollar una 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

    View Slide

  53. Deployment Slots
    Desplegando(3/4)
    Como regla general cuando trabajamos en proyectos 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

    View Slide

  54. CI/CD
    Build & Deploy (4/4)
    Vamos a crear la build, 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…

    View Slide

  55. ¿Qué vamos a ver?
    Observabilidad y Monitorización(1/12)
    Una vez que 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…

    View Slide

  56. Loggers(1/3)
    Observabilidad y Monitorización(2/12)
    Se que muchas personas usan Log4Net 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…

    View Slide

  57. Loggers(2/3)
    Observabilidad y Monitorización(3/12)
    Creamos una Function de tipo HTTP 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.

    View Slide

  58. Loggers(3/3)
    Observabilidad y Monitorización(4/12)
    Y podremos llegar a ver lo 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):

    View Slide

  59. Diagnósticos(1/2)
    Observabilidad y Monitorización(5/12)
    El portal de Azure nos permite 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

    View Slide

  60. Diagnósticos(2/2)
    Observabilidad y Monitorización(6/12)
    Entramos en “Function that are no tiggering” y podrás ver el informe de errores, con esto tu tarea es investigar:

    View Slide

  61. Métricas(1/3)
    Observabilidad y Monitorización(7/12)
    Desde la opción de métricas podemos 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

    View Slide

  62. Métricas(2/3)
    Observabilidad y Monitorización(8/12)
    Si sabemos que nuestra aplicación no 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.

    View Slide

  63. Métricas(3/3)
    Observabilidad y Monitorización(9/12)
    Gracias a la opción Live Metrics, 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.

    View Slide

  64. Estudiar un Bug
    Observabilidad y Monitorización(10/12)
    Lo más importante es 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

    View Slide

  65. CORS
    Observabilidad y Monitorización(11/12)
    Por qué muchos de los problemas 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

    View Slide

  66. Escalado
    Observabilidad y Monitorización(12/12)
    El auto escalado se produce de 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

    View Slide

  67. Anexo
    Te toca trabajar

    View Slide

  68. ¿Qué vamos a ver?
    Desplegando
    Hemos visto muchas cosas en 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…

    View Slide

  69. Descripción
    Buenas prácticas(1/8)
    Seguir unas buenas prácticas nos ayudará a 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…

    View Slide

  70. Descripción
    Buenas prácticas(2/8)
    ¿Las Azure Functions son para tu escenario?
    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.

    View Slide

  71. Descripción
    Buenas prácticas(3/8)
    Elección del plan de alojamiento
    Aspecto vital 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.

    View Slide

  72. Descripción
    Buenas prácticas(4/8)
    Mitigar el retraso en la puesta en 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.

    View Slide

  73. Descripción
    Buenas prácticas(5/8)
    Identificar y gestionar cuellos de botella
    Que 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.

    View Slide

  74. Descripción
    Buenas prácticas(6/8)
    Facilita la monitorización y la depuración
    Ya 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.

    View Slide

  75. Descripción
    Buenas prácticas(7/8)
    Varios apuntes más ya relacionados con la 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.

    View Slide

  76. Descripción
    Buenas prácticas(8/8)
    Varios apuntes más cuando se trata de 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.

    View Slide

  77. Descripción
    Pifias(1/3)
    A continuación, alguna de las pifias más habituales 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

    View Slide

  78. Descripción
    Pifias(2/3)
    Alojar funciones de producción y desarrollo en un 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.

    View Slide

  79. Descripción
    Pifias(3/3)
    Política de reintentos
    Mucho cuidado con esto, como 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

    View Slide

  80. Resumen
    Contenedores, AKS, Azure Container Apps
    A veces escucho eso 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, ...

    View Slide

  81. Otras cosas que debes conocer
    A partir de aquí
    Existen 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.

    View Slide

  82. Experto en: Asincronía con .NET
    Próximo libro
    ¿Quieres convertirte en
    “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!

    View Slide

  83. ¡Gracias!
    Puedes encontrarme buscando por jmfloreszazo en
    https://jmfloreszazo.com

    View Slide