El tema de hoy es uno del que casi todo el mundo ha oído hablar, pero que casi nadie puede explicar. Sin servidor, ¿qué es exactamente? ¿Es realmente solo código que se ejecuta en la nada o es algo mucho más grande? Dejemos una cosa clara. Sin servidor no significa que no haya servidor. Significa que no piensas en ellos. Y esa distinción cambia por completo la forma en que creas software. Al final de este episodio entenderás que son realmente las Azure Functions, cómo funcionan realmente los precios y cuándo deberías usarlas. Desglosaremos esto en los componentes básicos, empezando por el mito más grande. ¿Qué significa realmente sin servidor? Vamos a aclarar unos mitos de inmediato. El nombre sin servidor es el peor término de marketing que se le ha ocurrido a Microsoft. Así que la gente crea que literalmente no hay servidores de por medio. Eso no es cierto. Hay servidores. Simplemente no tienes que tocarlos.

Hace 20 años, si querías ejecutar un fragmento de código en Internet, tenías que trabajar mucho. Alquilarías una máquina virtual, instalarías un sistema operativo, configurarías un servidor web, implementarías tu aplicación. Luego pasarías cada fin de semana aplicando parches de seguridad y asegurándote de que el sistema no se bloqueara a las 3 de la mañana. Aquí está la cuestión. Pagabas por ese servidor tanto si tu código se estaba ejecutando como si. Se quedaba allí zumbando, quemando dinero mientras dormía. La tecnología sin servidor pone todo este modelo patas arriba. Escribes tu código, lo subes y la plataforma se encarga de todo lo demás. El sistema operativo, los parches de seguridad, el escalado y disponibilidad. Tu trabajo es simplemente escribir la lógica que importa. Piensa en ello como la diferencia entre gestionar la cocina de un restaurante y utilizar una máquina expendedora.

La cocina de un restaurante necesita personal completo, suministros constantes y mantenimiento. Cuesta dinero todos los días, incluso si nadie entra por la puerta. Una máquina expendedora está ahí en la esquina sin hacer nada hasta que alguien pulsa un botón. Entonces cobra vida, hace su trabajo y vuelve a dormir. Solo pagas la electricidad cuando realmente está funcionando. Ese es sin servidor en poca palabra. Azure Functions es la versión de Microsoft Edge. Ejecuta pequeños fragmentos de código en respuesta a eventos. Su código permanece inactivo hasta que algo lo activa. Luego se ejecuta, finaliza y vuelve a dormirse. Entonces, ¿cómo se ve realmente ese código? ¿Qué son Azure Functions? Una función es un único fragmento de código que realiza una tarea específica. Eso es todo. No es una aplicación completa con una página de inicio de sesión, una base de datos y 20 pantallas. Es una tarea específica.

Piensa en ello como el interruptor de su casa. Se apaga o se enciende para trabajar y luego vuelve a apagarse. Un servidor web tradicional es lo opuesto, como dejar las luces de casa encendidas 24-7 incluso durante los momentos en que no hay nadie en el hogar. Azure Functions admite varios lenguajes de programación diferentes. Puede usar el que le resulte más cómodo, JavaScript, Python, C, Java, PowerShell. Tiene una respuesta correcta. Elige el lenguaje que ya conozca. Ahora, aclaremos una confusión común. Una aplicación de funciones no es lo mismo que una función. La aplicación de funciones es el contenedor. Piensa que es una caja de herramientas. Creas una aplicación de funciones y dentro de esa caja de herramientas agregas varias funciones. Cada función es una herramienta aparte que hace su propio trabajo. Puedes tener una función que gestione los registros de usuarios, otra que procese las imágenes cargadas y una tercera que envíe informes nocturnos.

Viven en la misma caja de herramientas pero operan por separado. Otra cosa sobre las funciones es que no tienen estado por diseño. Eso significa que no recuerda nada entre ejecución. Si tu función procesa un archivo y finaliza, eso es todo. La próxima vez que se ejecute comenzará de cero sin recordar el timón. Esto parece una limitación, pero en realidad es la característica que las hace tan eficaces. Dado que las funciones no conservan la memoria ni el estado, Azure puede poner en marcha 100 copias de tu función al instante cuando hay picos de tráfico y cerrarlas con la misma rapidez cuando el tráfico disminuye. Así es como obtienes escalabilidad sin pagar por servidores inactivos. Aquí está la pregunta. Si una función simplemente permanece ahí sin hacer nada hasta que algo la despierta que la despierta realmente, ahí es donde entran los disparadores. Los disparadores y el cuándo. Cada función debe tener exactamente un disparador y eso no es opcional.

El disparador es el evento que despierta tu función. Sin él, tu código simplemente permanece ahí sin hacer absolutamente nada. Piensa en los disparadores como un tiempo. Tu función está dentro de la casa esperando. Podría esperar para siempre. No pasa nada hasta que alguien llama al timbre. Entonces la función entra en acción, abre la puerta, hace su trabajo y vuelve a esperar. Hay cuatro detonantes con los que los principiantes se topan seguido. Disparador HTTP es el punto de partida más común. Alguien visita una URL o realiza una llamada a la API y tu función se activa. Si es como se crean API ligeras sin configurar un servidor web completo, luego está el disparador de tiempo que se ejecuta por horario. Estableces una expresión Chrome, algo como ejecutar cada hora o ejecutar a medianoche todas las noches, y tu función se activa a esas horas exactas. Perfecto para tareas de mantenimiento, trabajos de limpieza o generación de informes nocturnos.

El desencadenador de blobs se activa cuando se carga un archivo en Azure Storage. Digamos que alguien cargue un PDF en una carpeta específica. El desencadenador de blobs detecta esa carga y ejecuta la función automáticamente. Esto es clave para el procesamiento de imágenes, la conversión de documentos y la validación de archivos. Y el desencadenador de colas se activa cuando aparece un mensaje en una cola. Las colas son una forma de desacoplar diferentes partes del sistema. Un servicio coloca un mensaje en una cola y la función lo recoge y lo procesa cuando está listo. Esto evita que un servicio lento bloquee todo lo demás. Este es el punto clave. Cuando se activa un desencadenador, pasa datos a la función automáticamente. No es necesario que la sondeen y que compruebe si ha ocurrido algo. El desencadenador le proporciona todo lo que necesite y la función simplemente lo procesa. Una función sin desencadenador es simplemente código que no hace nada.

Desencadenador es lo que le da un propósito. El desencadenador le indica tu función cuando ejecuta. Pero ¿de dónde provienen los datos y a dónde van? Ahí es donde entra en juegos. Enlaces, entrada de datos, salida de datos. Los enlaces son una forma de indicarle a tu función qué datos leer y dónde enviar los resultados sin escribir todo el código adicional. Es un trabalenguas, así que permíteme simplificar. Existen dos tipos. Los enlaces de entrada introducen datos en tu función. Los enlaces de salida envían datos. Sin enlaces, tendrías que escribir código SDK cada vez que quisieras comunicarte con una cuenta de almacenamiento, una base de datos o una cola. Gestionarías cadenas de conexión, administrarías reintentos, serializarías datos y deserializarías respuestas. Es mucho código repetitivo solo para leer un archivo. Con los enlaces, solo declaras lo que necesitas. Dices, quiero leer de este contenedor de blobs o quiero escribir en esta cola.

El entorno de ejecución se encarga. Abre la conexión, lee los datos y se los pasa a tu función como parámetro. Cuando tu función finaliza, toma el valor de retorno y lo escribe donde hayas especificado. Piensa en los enlaces como si fueran tubería. Conectas tu función a una cuenta de almacenamiento, una base de datos o una cola. Los datos fluyen a través de esas canalizaciones automáticamente. Tu función no necesita saber cómo funciona la canalización. Simplemente recibe lo que llega y envía todo lo que debe salir. Aquí tienes un ejemplo concreto. Imagina que tienes un enlace de entrada de blobs. Cuando tu función se inicia, lee automáticamente un archivo del almacenamiento de blobs y te lo entrega como parámetro. No escribes ningún código de LCD de almacenamiento. Solo obtienes los datos y los procesos. Otro ejemplo es un enlace de salida de cola. Tu función procesa algo y al final devuelves un valor.

El entorno de ejecución toma ese valor, lo serializa y lo coloca en la cola. No escribes ningún código de cola. Solo devuelves un valor. Los enlaces son opcionales. Puedes tener cero, uno o muchos. Algunas funciones solo necesitan un desencadenador sin ningún enlace. Otras pueden tener tres o cuatro enlaces que se conectan a diferentes servicios. La combinación de desencadenadores y enlaces es lo que hace que Azure Function sea tan eficaz. Escribes la lógica empresarial, el código de toma de decisiones real, la plataforma gestiona integración. Tu función se mantiene pequeña, centrada y fácil de entender. La historia de los precios. El precio es lo que más sorprende a los principiantes. Para la mayoría de las personas, el plan de consumo es la opción predeterminada y deberías empezar con él el 90% de las veces. Así es como funciona. Pagas o loco de tu función se ejecuta realmente. Cuando está inactiva no pagas nada.

Cero ni un céntimo. La factura está compuesta por dos componentes. Primero, el número de ejecuciones. ¿Cuántas veces se activa tu función? Segundo, el tiempo de ejecución. Medido en algo llamado GB segundos. Básicamente es el tiempo que se ejecutó tu función multiplicado por la cantidad de nubes que tienes. ¿La subvención gratuita es género? Obtienes un millón de ejecuciones al mes y 400.000 GB segundos completamente gratis. Para la mayoría de los proyectos pequeños, aplicaciones de pasatiempos y prototipos, nunca pagarás un céntimo. Nunca. Si superas la subvención gratuita, las tarifas siguen siendo increíblemente baratas. 20 céntimos por millón de ejecución. No es un error. 20 centavos por millón de ejecución. Piensa en ello como si pagaras la electricidad solo cuando enciendes el interruptor. No hay una cuota mensual básica por tener el cableado en las paredes. Solo pagas por la energía que realmente usa.

Ahora bien, existen los planes. Flex Consumption es más nuevo y te ofrece su parte virtual. Premium mantiene tus funciones siempre activas, por lo que no hay demoras de inicio en frío. Dedicated te ofrece capacidad fija en un plan de App Service tradicional. Pero para empezar, Consumption es la opción correcta casi siempre. Sin embargo, una adverte. La conciación gratuita se comparte entre todas tus aplicaciones de funciones en la misma suzco. Si tienes 10 aplicaciones de funciones, todas ellas utilizan el mismo millón de ejecuciones gratuitas. Así que te lo encuentras si empiezas a sacar más de unas cuantas, el precio es genial. Pero vamos a ponerlo en práctica con un ejemplo concreto. Un escenario del mundo real. Imagina que tienes un sitio web en el que los usuarios suben fotos de perfil. Esas imágenes son enormes, como 10 megabytes cada una. Y eso causa algunos problemas reales. Los archivos grandes cuestan más de almacenar, ralentizan tu sitio web cada vez que alguien cargue una página.

Y frustran a los usuarios que tienen que esperar a que aparezcan las fotos. Por lo tanto, necesitas una forma de reducir esas imágenes automáticamente. Sin Azure Functions, tendrías que crear un trabajador en segundo plano desde cero. Eso significa obtener un servidor independiente, configurar una cola para administrar la carga de trabajo y escribir código para gestionar todas las piezas móviles. Es una complejidad innecesaria para algo tan sencillo como reducir una imagen. Con Azure Functions, todo lo que necesitas es un desencadenador de blobs y una función. No hay servidores de los que preocuparse. Deja que te explique cómo funciona. Un usuario carga una foto a través de tu sitio web y se archivó y llega al almacenamiento de blobs de Azure. Al llegar, se activa automáticamente un desencadenador de blobs. Tu función se activa, ejecuta el código de compresión y guarda la versión más pequeña en el almacenamiento.

Todo esto ocurre en cuestión de segundos. El usuario nunca espera porque todo el proceso se ejecuta en segundo plano, completamente invisible. Aquí tienes otro ejemplo cotidiano. Enviar un correo electrónico de bienvenido cuando alguien se registra en tu servicio. Desencadenador HTTP captura la solicitud de registro de tu sitio web. Tu función se activa y obtiene la dirección de correo electrónico del usuario. Envía un mensaje de bienvenida a través de SendGrid y listo. El usuario recibe su correo electrónico casi alista. Sin servidores de correo que configurar ni con las que gestionar. Solo una función, una tarea y listo. Estas son las tareas exactas para las que se diseñó Azure Functions. Tareas pequeñas, centradas, controladas por eventos. No aplicaciones masivas ni flujos de trabajo complejos. Solo una cosa bien hecha, activada por algo que ocurre en otro lugar. ¿Cuándo usar Azure Functions?

Entonces, ¿cuándo deberías recurrir a una función y cuándo deberías usar otra cosa? Esta es una forma rápida de decidir. Pregúntate si la tarea es corta, si está controlada por eventos y si no tiene estado. Si he respondido sí a las tres, entonces Azure Functions es probablemente la herramienta adecuada. Empecemos por los buenos casos de uso. SAP y los webhooks, una combinación perfecta. Necesitas un punto final ligero que responda a una solicitud HTTP. Haga una cosa y devuelva un resultado. Y para eso están diseñados los activadores HTTP. Procesar archivos e imágenes es otro punto importante. Un archivo llega al almacenamiento, tu función se activa, lo transforma y guarda el resultado, todo, sin un servidor. Tareas como la limpieza nocturna o generar informes funcionan muy bien con activadores de temporizador. Transformar datos para tuberías CTL también es muy común. Las funciones son el pegamento perfecto para la integración, ya que conectan dos servicios que no se comunican entre sí de forma natural.

Ahora, hablemos de cuando las funciones no son una buena opción. Los procesos de ejecución son un problema, porque en el plan de consumo las funciones tienen un límite de tiempo de espera de 5 minutos de forma predeterminada, hasta ahí si lo configuras. E. Si tu trabajo tarda más que eso, necesitas algo más. Las aplicaciones con estado son otro desajuste. Las funciones no recuerdan nada entre ejecuciones. Si necesitan mantener el estado de la sesión o revisar un seguimiento del progreso en los pasos, estás yendo en contra de la sesión. Las cargas de cómputo pesadas también fallan. Si necesitas una CPU sostenida durante minutos u horas, una máquina virtual o un contenedor son una mejor opción. Y los flujos de trabajo complejos, en los que una tarea depende de otra, se gestionan mejor con funciones duraderas o aplicaciones lógicas. Aquí tienes una descripción general rápida de la salida. Azure Logic Apps es la opción sin código para conectar servicios.

Si no necesitas escribir código personalizado, Logic Apps puede hacer el trabajo con diseñador visual. Azure App Services es para aplicaciones web completas que se ejecutan las 24 horas de la semana. Si necesitas una web o API completa que esté siempre activa, esa es tu herramienta. Azure Container Apps te ofrece microservicios en contenedores con más control sobre el tiempo de ejecución. Y Azure Virtual Machines te ofrece control total sobre el sistema operativo si lo necesitas. Aquí tienes una regla general sencilla. Si puedes describir el trabajo en una frase, probablemente sea un buen candidato para una función. Comprime las imágenes cuando se cargue. Ve un correo de bienvenida cuando alguien se registra. Que ejecuta un proceso de limpieza cada noche a mediano. Una frase, un trabajo, una función. Errores comunes de principiante que debes evitar. Ahora, hablemos de algunas cosas a tener en cuenta.

Estos son los errores en los que casi todo el mundo comete el error de empezar. Un error común de principiante es creer que las funciones son siempre gratis. La concesión de funciones gratuitas se generó. Sé que un millón de ejecuciones parece mucho, pero si tu función se vuelve viral o la ataca un bot, esas ejecuciones se acumulan rápidamente. Por lo tanto, supervisa tu uso, configura una alerta de presupuesto en Azure y no recibas una factura sorpresa a final de mes. Otro error es ignorar los arranques en fin. La primera vez que tu función se ejecuta después de estar inactiva, tarda más. En el plan de consumo se puede ser unos segundos. Para casi todo uso está bien. Pero si estás creando una API sensible a la latencia en la que cada milisegundo importa, considera el plan premium o habilita instancias siempre listas. Luego está escribir funciones que se ejecutan durante la ansiedad. Plan de consumo tiene un tiempo de espera de 5 minutos por defecto y 10 minutos como máximo.

Si tu función tarda 15 minutos en procesar un archivo, se cerrará a mitad de camino. Vive ese trabajo en partes más pequeñas o usa un plan de alojamiento diferente. Otro error común es no usar la implementación de ejecución de este paquete. Es un simple cambio de configuración que mejora los arranques en frío y hace que las implementaciones sean más confiables. En lugar de copiar archivos individuales, implementa un paquete zip. Es una casilla de verificación en el portalado. Exponer puntos de conexión HTTP sin autenticación es otra trampa. Es fácil dejar una función en anónimo mientras estás haciendo pruebas y luego olvidarte bloquearla. Establece tu nivel de autorización correctamente desde el principio. Usa claves de función o de administración. No dejes la puerta abierta. Reutilizar cuentas de almacenamiento en varias aplicaciones de función también es un problema. En desarrollo está bien compartir.

En producción, cada aplicación de función debe tener su propia cuenta de almacenamiento. De lo contrario, tendrás problemas de vecinos ruidosos donde el tráfico de una función ralentiza a otra. Y por último, no habilitar Application Insights. Sin él estás volando a ciegas. No verás fallos, errores o problemas de rendimiento. No sabrás si tu función se está ejecutando demasiado tiempo o falla silenciosamente. Habilítalo desde el primer día. Tarda 30 segundos y ahorra horas de depuración. La regla de oro para todo esto es mantener las funciones pequeñas, centradas y sin estado. Un trabajo por función, nada más. Hacia el sistema. Azure Functions es un proceso sin servidor que ejecuta pequeños fragmentos de código en respuesta a eventos. Solo paga cuando se ejecuta el código. Los desencadenadores indican a la función cuando activarse. Los enlaces la conectan a los datos que necesita y el plan de consumo la mantiene casi gratuita para proyectos pequeños.

La mejor opción ahora mismo es crear una función desencadenada por HTTP simple en Azure Portal. Tarda 5 minutos y no cuesta nada. Suscríbase a Microsoft Knowledge Nuggets para obtener más desgloses en un lenguaje sencillo. Y comparta esto con alguien que no deja de preguntar qué significa sin servidor. Señora.