Serverless es un modelo de desarrollo en la nube que permite a los desarrolladores crear y ejecutar aplicaciones sin tener que gestionar la infraestructura subyacente (servidores, SO, etc.). El proveedor de la nube se encarga de todo, incluido el escalado, la gestión de servidores y la alta disponibilidad. Pero, ¿por dónde empezar? ¿Qué plataforma en nube elegir? ¿Y para qué usos? Infórmese sobre las mejores prácticas, los escollos que hay que evitar y siga nuestra hoja de ruta paso a paso...
El sin servidor es ahora una tendencia importante en la computación en nube. Cada vez más organizaciones adoptan este modelo para ganar mayor agilidad y reducir sus costes de infraestructura.
El mercado sin servidores tendrá un valor de unos 25.000 millones de dólares en 2025, impulsado por la demanda de agilidad y reducción de costes. Para los departamentos de TI, esto representa una palanca estratégica, pero también un reto que dominar.
Según un informe de Datadog de 2023, la mayoría de las empresas que utilizan AWS o Google Cloud ya tienen al menos un despliegue sin servidor, y casi la mitad de los usuarios de Azure están haciendo lo mismo.
Pero, ¿qué es exactamente serverless, de dónde viene y qué está cambiando para los profesionales de TI?
¿Qué es serverless?
Serverless es un modelo de desarrollo nativo en la nube que permite crear y ejecutar aplicaciones sin necesidad de gestionar servidores físicos o virtuales.
Al contrario de lo que sugiere el término, no hablamos de una ausencia total de servidores, sino de una abstracción completa de su gestión El proveedor de la nube se encarga del aprovisionamiento (preparación y configuración de los recursos de hardware y software necesarios), mantenimiento, escalado y disponibilidad de la infraestructura subyacente.
El desarrollador se concentra exclusivamente en el código y la lógica de negocio, que a menudo se empaqueta en forma de funciones o contenedores. La aplicación se ejecuta bajo demanda, en respuesta a eventos, y la facturación se basa en el uso real, lo que optimiza los costes, sobre todo para cargas de trabajo irregulares o impredecibles.
Diferencia con la computación en nube estándar
En un modelo estándar de computación en nube como elIaaS (Infraestructura como servicio), los usuarios compran unidades de capacidad por adelantado. Pagan a un proveedor de nube pública por componentes de servidor permanentemente activos para ejecutar sus aplicaciones. Es su responsabilidad utilizar y aumentar la capacidad de los servidores durante los periodos de alta demanda y reducirla cuando ya no sea necesaria. La infraestructura de la nube permanece activa incluso cuando la aplicación no está en uso, lo que puede generar costes.
Serverless, por otro lado, es un modelo de ejecución basado en eventos. Las aplicaciones responden a la demanda y se adaptan automáticamente según sea necesario. Cuando una función sin servidor está inactiva, no cuesta nada. El proveedor de la nube gestiona la infraestructura, incluidos el escalado y el mantenimiento. El objetivo principal es permitir a los desarrolladores concentrarse en el código de sus aplicaciones mientras el proveedor gestiona la infraestructura subyacente.
Las aplicaciones sin servidor se despliegan en contenedores que se inician automáticamente a petición.
Los diferentes tipos de computación sin servidor
La tecnología sin servidor se divide principalmente en dos categorías:
Función como servicio (FaaS) a menudo se considera el núcleo de la tecnología sin servidor, ya que implica el despliegue de funciones de aplicación que se activan mediante eventos, se ejecutan de forma efímera y se ejecutan en tiempo real. sin estado (sin estado) en contenedores temporales. El código del lado del servidor sigue siendo responsabilidad del desarrollador, pero su ejecución es gestionada por la plataforma en nube en contenedores que no retienen datos entre dos llamadas. Esto significa que cada vez que se invoca la función, se inicia en un nuevo entorno, lo que supone tareas cortas que no dependen de datos en memoria local persistente.
El Backend como servicio (BaaS) se refiere a servicios backend listos para usar proporcionados por terceros. Por ejemplo, servicios gestionados de bases de datos, autenticación, almacenamiento de archivos, mensajería en tiempo real, etc., en los que el desarrollador consume una API sin tener que desplegar él mismo estos componentes.
¿Cuáles son los orígenes de la tecnología sin servidor?
El concepto de serverless es el resultado de una evolución gradual en el mundo de la computación en nube. Mucho antes de que el término se popularizara, la idea de liberar a los desarrolladores de la gestión de servidores ya existía de otras formas.
Plataforma como servicio (PaaS)A finales de la década de 2000, por ejemplo, Google App Engine y Heroku ofrecieron un anticipo de la ausencia de servidores, permitiendo desplegar aplicaciones sin gestionar la infraestructura. Sin embargo, el término "sin servidor apareció más tarde para designar un enfoque aún más granular y basado en eventos de la computación en nube.
El punto de inflexión se produjo en 2014 cuando Amazon Web Services lance AWS Lambda. Para muchos, este es el punto de partida concreto para serverless tal y como lo entendemos hoy en día. AWS Lambda introduce un modelo para ejecutar funciones bajo demanda, activadas por eventos, con facturación por invocación y autoescalado completamente transparente. No es necesario iniciar ni detener máquinas virtuales: el código se ejecuta en un contenedor efímero administrado por AWS y se escala automáticamente.
Desde entonces, el ecosistema serverless ha ido a más. Han surgido nuevos servicios que complementan la ejecución de funciones: por ejemplo, bases de datos sin servidor (AWS DynamoDB en modo bajo demanda, Azure Cosmos DB sin servidor), procesamiento de flujos de trabajo (AWS Kinesis, Google Cloud Pub/Sub + Functions) u orquestadores sin servidor (AWS Step Functions, Azure Logic Apps).
También han surgido soluciones de código abierto (OpenFaaS, Apache OpenWhisk utilizado por IBM Cloud) para permitir la ausencia de servidor fuera de las grandes nubes.
¿Cuáles son las ventajas de la tecnología sin servidor?
Serverless ha tenido tanto éxito porque ofrece numerosas ventajas a los equipos de desarrollo y a las empresas. Estas son las principales ventajas:
- Sin gestión de servidores, sin centrarse en la aplicación. La primera ventaja, obvia, es liberar a los desarrolladores de las tareas de administración del sistema. No es necesario configurar ni mantener máquinas, parches del sistema operativo ni middleware: la nube se encarga de todo. Esto significa que el equipo puede concentrarse en la lógica de la aplicación, la funcionalidad y la experiencia del usuario, acelerando el desarrollo.
- Escalabilidad y elasticidad automáticas. Funciones y servicios sin servidor adaptarse automáticamente a la carga. Tanto si hay 10 peticiones al día como 10 millones, la plataforma asigna dinámicamente las instancias necesarias para procesar las peticiones en paralelo. Esta elasticidad instantánea es una gran ventaja a la hora de absorber picos de tráfico inesperados sin intervención manual. Por ejemplo, un sitio web de comercio electrónico alojado a través de una API Gateway + funciones Lambda podrá absorber un pico de visitas durante el Black Friday sin que los desarrolladores tengan que planificar un exceso de capacidad: las funciones se multiplican bajo demanda. A la inversa, en periodos valle, ningún recurso estará funcionando innecesariamente. El dimensionamiento es siempre "justo", lo que mejora la disponibilidad del servicio sin ningún esfuerzo arquitectónico particular.
- Pago por uso, optimización de costes. El modelo de negocio para serverless es generalmente pago por usoEn otras palabras, se factura bajo demanda, en función del consumo real. A diferencia de un servidor tradicional que se factura por horas (aunque no haga nada), una función sin servidor solo cuesta algo cuando se ejecuta. Así es como funciona, "los recursos nunca están inactivos, sólo se activan bajo demanda".. Los clientes sólo pagan por los recursos realmente utilizados (tiempo de CPU, memoria, número de llamadas), no por el tiempo de inactividad. Este modelo puede generar ahorros sustanciales, sobre todo para cargas de trabajo intermitentes o impredecibles. Por ejemplo, una aplicación cuya actividad es muy variable en el tiempo cuesta mucho menos con serverless que con un servidor asignado permanentemente.
- Rendimiento y rapidez de instalación. Las plataformas sin servidor aprovechan las capacidades de las nubes para ofrecer tiempos de respuesta muy cortos. El arranque de una función es casi instantáneo (unos milisegundos para un contenedor "caliente"), e incluso si una nueva instancia se arranca en frío, el retardo sigue siendo muy bajo en la mayoría de los entornos (sobre todo con lenguajes interpretados). Además, muchos componentes ya están soportados por el proveedor (equilibrio de carga, CDN, autenticación, etc. mediante servicios gestionados), se reduce el tiempo necesario para desarrollar e implantar una nueva aplicación. Puede pasar de una idea a un prototipo funcional en cuestión de horas. Por ejemplo, un desarrollador puede codificar e implementar una API REST completa en tan solo unos minutos utilizando AWS Lambda y API Gateway, mientras que configurar una pila de servidores tradicional habría llevado días. El rápido aprovisionamiento de serverless (no hay demora en pedir un servidor o iniciar una VM) significa que el desarrollo se puede llevar a cabo muy rápidamente.
Serverless también fomenta las buenas prácticas de DevOps: infraestructura como código (IaaS), despliegues frecuentes y una estrecha colaboración entre desarrolladores y operaciones. Se anima a los desarrolladores a adoptar "DevOps sin servidorIntegran la infraestructura (aunque gestionada por la nube) directamente en su ciclo de desarrollo a través de marcos (Serverless Framework, AWS SAM, Terraform, etc.). Dado que la barrera operativa de entrada es menor, suele haber una una cultura DevOps más sólida y un enfoque más democrático de la producción. Por ejemplo, un desarrollador puede incluir fácilmente la configuración de una función y sus activadores en el mismo repositorio de código que la aplicación, fomentando la autonomía y la responsabilidad de todo el ciclo de vida.
- Alta disponibilidad y tolerancia a fallos. Por diseño, los servicios sin servidor se distribuyen por la infraestructura del proveedor de la nube, lo que garantiza la redundancia. Por lo general, una función desplegada se replica en varias zonas para tolerar fallos de hardware. Los proveedores suelen garantizar una alta disponibilidad (por ejemplo, AWS Lambda se despliega en varias zonas de disponibilidad por defecto). El desarrollador no tiene que hacer ningún esfuerzo adicional para beneficiarse de esta robustez. Además, la naturaleza sin estado facilita la conmutación por error en caso de problema: una instancia de función que falla no afecta a otras llamadas, y los sistemas de orquestación pueden reiniciar automáticamente las ejecuciones fallidas. Junto con otros servicios gestionados (base de datos replicada, almacenamiento de objetos duradero, etc.), el resultado es una arquitectura inherentemente resistente a los fallos regionales o de hardware, sin tener que configurar manualmente la conmutación por error.
- Eficiencia y diseño ecológico. Utilizar sólo los recursos estrictamente necesarios tiene ventajas tanto ecológicas como técnicas. Desde el punto de vista técnico, elimina recursos ociosos La infraestructura se comparte al máximo entre los clientes y se asigna sobre la marcha, lo que mejora la eficiencia global de la red. centros de datos. Desde el punto de vista del ecodiseño de software, el serverless evita ejecutar continuamente servidores que apenas se utilizan, contribuyendo así a reducir el derroche de energía. Los principales proveedores optimizan sus instalaciones para el consumo de energía, por lo que delegar la computación en estas plataformas puede reducir la huella de carbono de su aplicación. Este es un argumento cada vez más popular: una aplicación sin servidor bien diseñada minimiza el uso de CPU y memoria, lo que, multiplicado a escala, tiene un menor impacto medioambiental.
Naturalmente, estas ventajas van acompañadas de contrapartes y límites (detallados más adelante en los escollos que hay que evitar). Pero en muchos escenarios, las ganancias en productividad, coste y flexibilidad hacen que serverless sea una opción atractiva en comparación con las arquitecturas tradicionales en servidores dedicados o incluso contenedores gestionados.
¿Por dónde empezar?
Dadas las promesas de la tecnología sin servidor, puede resultar tentador adoptarla de inmediato. Sin embargo, es importante empezar con buen pie. ¿Por dónde empezar cuando se quiere emprender sin servidor? El primer paso es una comprensión clara del concepto y de sus casos de uso. Es aconsejable leer sobre cómo funcionan las funciones sin servidor y sus modelos de eventos, y echar un vistazo a los ejemplos proporcionados por los principales proveedores (AWS, Azure, GCP) para entender en qué se diferencia esta arquitectura de un enfoque tradicional. En otras palabras, es necesario adoptar la "estado de ánimo sin servidor: piense eventos, sin estadoEsto significa que ya no dispones de un servidor permanente para almacenar sesiones o archivos temporales, por ejemplo.
A continuación, debemosidentificar un caso de uso inicial sencillo y apropiado para cogerle el truco. En lugar de cambiar toda una aplicación crítica directamente a serverless, tiene sentido elegir un proyecto piloto a pequeña escala. Por ejemplo, podría ser el desarrollo de una pequeña API interna, un script de automatización programado o un procesamiento de datos aislado. El objetivo es familiarizarse con el ciclo de desarrollo-implantación y sus características específicas (gestión de registros, supervisión, gestión de permisos) sin grandes riesgos. Idealmente, este primer proyecto debería tener características propicias para el serverless: una carga variable o poco frecuente (para aprovechar el pago por uso), sin necesidad de mantener un estado en memoria entre dos ejecuciones, y un rendimiento no crítico hasta el milisegundo (para tolerar posibles "caídas"). arranques en frío). Un ejemplo común es la creación de un pequeño servicio de generación de informes en PDF que se active bajo demanda, o una función que se ejecute cada noche para limpiar una base de datos: tareas bien definidas y adaptadas al modelo sin servidor.
Finalmente, por dónde empezar también implica preparar su entorno de desarrollo. Por lo general, esto significa abrir una cuenta con un proveedor de la nube (o reutilizar la cuenta de su empresa), instalar las herramientas de línea de comandos adecuadas (por ejemplo, AWS CLI, Azure CLI, Google Cloud SDK) y, posiblemente, un marco de despliegue. La mayoría de las plataformas ofrecen niveles gratuitos o de muy bajo coste para empezar, por lo que puedes experimentar sin limitaciones de presupuesto. Por ejemplo, AWS Lambda ofrece un millón de invocaciones gratuitas al mes, lo que es más que suficiente para las pruebas iniciales. Por lo tanto, te recomendamos que aproveches estas tercero libre. En resumen, empezamos con formación, elegir un proyecto pequeño, adquirir las herramientas y cuentas necesariasEntonces podremos pasar a la acción concreta.
Primeros pasos con serverless: una hoja de ruta en varias etapas
Una vez sentadas las bases e identificado el caso de uso objetivo, es hora de ponerse manos a la obra. Para ayudarte a empezar, aquí tienes una hoja de ruta paso a paso para empezar de forma eficaz con serverless. Esta guía paso a paso te ayudará a desarrollar tus habilidades y evitar los errores más comunes:
Paso 1: Elección del proveedor y del entorno
Comience por seleccionar la plataforma sin servidor que tenga más sentido para usted. La elección suele depender de su contexto: si su empresa ya tiene una presencia sólida en AWS, AWS Lambda será una elección natural si trabaja en un entorno Microsoft, Funciones Azure se integra bien; para necesidades específicas o un anexo a Google Cloud, Funciones de Google Cloud o Cloud Run será la adecuada. Cada nube principal tiene sus puntos fuertes, pero para empezar, todas ofrecen abundante documentación y ejemplos listos para usar. Una vez hecha tu elección, asegúrate de instalar las herramientas de desarrollo adecuadas (CLI, SDK) y configurar tus credenciales de acceso (claves API, etc.). Prepara tu entorno local con el lenguaje que vayas a utilizar (Python, Node.js, C#, etc.). - Elige un lenguaje compatible que ya conozcas, para no tener que aprender serverless y un nuevo lenguaje al mismo tiempo).
Paso 2: Despliegue de una función inicial "Hola Mundo
Empieza con un ejemplo mínimo para validar tu cadena de desarrollo y comprender el ciclo completo. Por ejemplo, cree una pequeña función que simplemente devuelva un mensaje de "Hola Mundo" o la fecha de hoy. Utilice la consola web o las herramientas de línea de comandos del proveedor para implementar esta función. En AWS Lambda, esto se puede hacer directamente a través de la consola en tan solo unos clics, o a través del comando aws lambda crear-función. En Azure, puede utilizar VS Code con la extensión Azure Functions para iniciar un proyecto de función local y publicarlo. El propósito de este paso es comprobar que sabes empaquete su código, despliéguelo y ejecútelo en la nube. Prueba la invocación de tu función: por ejemplo, si es una función HTTP, llama a su URL pública; si es una función activada por eventos, utiliza un mecanismo de prueba (AWS Lambda ofrece una herramienta de prueba en la consola). Una vez que "Hello World" esté funcionando, ya habrás logrado un hito psicológico importante: ¡tu código se está ejecutando "en algún lugar de la nube" sin que hayas configurado un servidor!
Paso 3: Añadir un activador e integrar un servicio
Enriquece tu ejemplo añadiendo un evento desencadenante real y posiblemente la integración con un servicio en la nube. Por ejemplo, conecta tu función a una API Gateway para activarla con una petición HTTP REST (caso típico para crear una API sin servidor). O configura un disparador temporal (un cron) si tu función necesita ejecutarse de forma programada - en Azure Functions, esto es un Disparador temporizador fácil de configurar, en AWS se utiliza EventBridge (anteriormente CloudWatch Events) para programar la ejecución. También podría vincular su función a un evento de almacenamiento: por ejemplo, una imagen caída en un bucket de S3 que active automáticamente una función de procesamiento de imágenes de Lambda. Aproveche este paso para llamar a un servicio gestionado, como una base de datos o una API externa, desde la función, de modo que pueda comprender cómo gestionar las llamadas salientes y los permisos. Por ejemplo, tu función podría escribir un registro en DynamoDB (base de datos AWS NoSQL) o en Tienda de fuegos en GCP, o enviar un mensaje a una cola (Azure Service Bus, AWS SQS). Aprenderá a configurar los roles de seguridad (IAM en AWS, equivalente a la Gestión de Identidades/Acceso en GCP/Azure) para dar a su función los derechos necesarios, sin abrir más de lo necesario. Esta etapa consolida su control de las interacciones entre la función y el ecosistema.
Etapa 4: Estructurar y desplegar utilizando un marco
Una vez que haya ido más allá de una simple función, es una buena práctica automatizar el despliegue utilizando código descriptivo (Infraestructura como código). Utilice una herramienta como Framework sin servidor, AWS SAM (Modelo de aplicación sin servidor), Terraformo la herramienta nativa de tu nube (Azure ARM/Bicep, Google Cloud Deployment Manager). Toma tu proyecto y transfórmalo para que la configuración (disparadores, recursos vinculados) se describa en un archivo (YAML, JSON o HCL dependiendo de la herramienta) y todo el despliegue se pueda hacer con un solo comando. Por ejemplo, con Serverless Framework, escribes un archivo llamado serverless.yml que define la función, su tiempo de ejecución y el evento que la desencadena, entonces el comando despliegue sin servidor crea todo automáticamente. Este paso puede parecer un esfuerzo extra, pero te acostumbra a gestionar tu código + configuración de forma versionada, y facilitará mucho la evolución a varias funciones y entornos (staging, producción). También es el momento de organizar tu código en módulos, gestionar las dependencias (por ejemplo, utilizar un requisitos.txt en Python o un paquete.json en Node.js para incrustar las librerías necesarias para la función).
Paso 5: Probar, controlar y optimizar
Una vez que su función (o pequeño conjunto de funciones) se ha desplegado a través de un framework, asegúrese de que pone en marcha la función herramientas de prueba y supervisión adecuado. Pruebe localmente si es posible: la mayoría de los frameworks ofrecen emuladores o herramientas de prueba locales para simular la ejecución (por ejemplo, la herramienta serverless invoke local te permite probar una Lambda localmente). Configure pruebas unitarias sobre la lógica de sus funciones, y pruebas de integración que invoquen realmente la función desplegada en la nube para comprobar su comportamiento. Por el lado de la monitorización, familiarízate con la plataforma : Registros de CloudWatch para AWS Lambda, Perspectivas de aplicación para Azure Functions, etc. Compruebe que su función está escribiendo registros útiles (por ejemplo, a través de console.log o imprimir) y que puedas consultar estos registros en caso de problema. Vigile también las métricas básicas: número de invocaciones, duración media, posibles errores o tiempos de espera. Esta etapa le enseña a depuración en un entorno sin servidorEsto es un poco diferente de la depuración tradicional en un servidor (no puedes simplemente conectarte a una máquina remota). Aprovecha para optimizar la configuración: por ejemplo, ajusta la memoria asignada a la función (más memoria puede acelerar la ejecución de la CPU a costa de un mayor coste unitario; a menudo hay que encontrar un punto óptimo). Observa el arranques en frío (arranques en frío): si nota un retraso notable en la primera invocación tras un periodo de inactividad, considere soluciones para mitigarlo (mantener una función "caliente" realizando llamadas regulares, o en AWS Lambda, habilitando Capacidad disponible para preasignar una instancia permanentemente activa si es realmente necesario).
Fase 6: Ampliación de la arquitectura e industrialización
Una vez que haya completado con éxito un proyecto piloto inicial, puede ir progresivamente ampliar el uso de serverless a otros componentes de su sistema. Identifica otras funcionalidades o microservicios en tu aplicación que podrían beneficiarse de la migración a serverless. Por ejemplo, después de una API sencilla, quizás migrar el procesamiento de imágenes, o establecer un sistema de notificaciones asíncronas a través de funciones. Construye una arquitectura más completa poco a poco, garantizando al mismo tiempo la coherencia general. En esta fase, también deberías considerar industrialice sus procesos CI/CD para sus funciones: integre el despliegue en sus flujos de trabajo (por ejemplo, despliegue automáticamente la función en la plataforma de pruebas cada vez que confirme la rama correspondiente). Asegúrese de que la estrategia de gestión de la configuración (variables de entorno, por ejemplo) y la estrategia de seguridad (codificación de secretosrotación de claves) para un uso más avanzado en producción. Por último, documente las mejores prácticas en su contexto empresarial, forme a sus colegas y comparta los comentarios. La adopción de serverless puede implicar un cambio cultural (infraestructura gestionada por código, mayor dependencia de un proveedor), por lo que es importante apoyar al equipo en esta transición.
Siguiendo esta hoja de ruta, pasarás gradualmente de ser un principiante a un experimentado practicante de serverless. Cada paso consolida tus habilidades y garantiza que no te saltes ninguna etapa, reduciendo así el riesgo de error al adoptar este nuevo enfoque.
¿Qué plataforma sin servidor elegir?
La elección de la plataforma es una cuestión clave cuando se trata de serverless. Existen muchas numerosas ofertas sin servidor y la elección dependerá de criterios técnicos, estratégicos y, a veces, personales. Los tres principales proveedores de nube - Servicios web de Amazon (AWS), Microsoft Azure, Plataforma en nube de Google (GCP) - dominan ampliamente el panorama, con soluciones maduras e integradas en sus respectivos ecosistemas. Pero no hay que olvidar la existencia de otros actores y plataformas especializadas, que pueden ser adecuadas para determinados usos.
He aquí una visión general de las principales plataformas sin servidor y los factores a tener en cuenta:
- AWS Lambda (AWS) AWS Lambda es la oferta pionera y más utilizada del mercado. AWS Lambda se beneficia de un ecosistema muy amplio de servicios integrados (API Gateway para convertirlo en una API web, S3 para activar la adición de archivos, DynamoDB Streams, CloudWatch Events, etc.). La comunidad en torno a AWS Lambda es masiva, lo que se traduce en numerosos ejemplos, tutoriales y herramientas de terceros (Serverless Framework nació con AWS Lambda como primer objetivo). AWS también ofrece servicios complementarios como AWS Step Functions para orquestar múltiples Lambdas en flujo de trabajo, o Amazon EventBridge para la gestión de eventos entre aplicaciones. Si buscas versatilidad y madurez, Lambda es una opción excelente. En cuanto a las limitaciones, AWS Lambda impone un tiempo máximo de ejecución (15 minutos por invocación) e históricamente ha sufrido de arranques en frío un poco más de tiempo para determinados tiempos de ejecución (por ejemplo, Java o .NET). Pero AWS ha introducido optimizaciones (Provisioned Concurrency) e incluso la posibilidad de empaquetar funciones en imágenes Docker para una mayor flexibilidad.
- Funciones Azure (Microsoft Azure) Azure Functions: muy bien integrado en el ecosistema de Microsoft, Azure Functions es una opción natural para las empresas que ya utilizan Azure o herramientas de Microsoft (.NET, Visual Studio). Es compatible con numerosos lenguajes (C#, JavaScript/TypeScript, Python, Java, PowerShell, etc.) y se integra fácilmente con otros servicios de Azure (Azure Event Grid para eventos, Azure Cosmos DB para salida/entrada, Azure DevOps para CI/CD, etc.). Azure Functions es único en el sentido de que puede alojarse no solo en modo serverless 100 % (plan de consumo bajo demanda), sino también en dedicado o premium lo que le permite disponer de instancias preasignadas, que pueden reducir la latencia en frío. Para un desarrollador .NET o un contexto de Microsoft 365, esta suele ser la plataforma ideal. La interfaz de desarrollo, en particular a través de Visual Studio Code, es muy fácil de usar para crear y desplegar funciones. Azure también se ha centrado en productividad de los desarrolladores Azure: depuración local, pruebas con Azure Functions Core Tools, etc.
- Google Cloud Functions y Cloud Run (Google Cloud) Google ofrece dos enfoques. Cloud Functions es el equivalente directo de Lambda/Azure Functions: una función gestionada basada en eventos. Cloud Run es un servicio sin servidor para contenedores: despliegas una imagen Docker (que contiene un pequeño servidor web o una aplicación, por ejemplo) y Google la ejecuta sin servidor (también con autoescalado y pago por uso). Cloud Run se ha hecho muy popular porque combina la facilidad de serverless con la flexibilidad de los contenedores (elección ilimitada del lenguaje, posibilidad de incluir binarios, etc.).
- Otras plataformas Más allá de los "tres grandes" de la nube, hay ofertas sin servidor a tener en cuenta. Entre ellas Funciones de IBM Cloud se basa en Apache OpenWhisk y también ofrece FaaS multilingüe. Nube de Oracle dispone de un servicio de Funciones (basado en el Proyecto Fn). Nube Alibaba en China dispone de Function Compute. También cabe destacar Trabajadores de Cloudflare que ofrece un enfoque original de la ausencia de servidor ejecutándolo en el borde (edge computing) directamente lo más cerca posible de los usuarios, lo que destaca para requisitos de latencia muy baja en contenidos distribuidos. Cloudflare Workers utiliza un modelo diferente (aislamiento a través de V8 isolates) y soporta especialmente la sintaxis JavaScript/Workers. Es una buena opción para generar páginas web dinámicamente en el borde de la red, por ejemplo, o para implementar API distribuidas globalmente. En otro orden de cosas, los servicios PaaS modernos como Funciones Netlify o Funciones de Vercel ofrecen sin servidor integrado para desarrolladores web, junto con el despliegue de sitios estáticos.
¿Cómo elegir?
El criterio principal será a menudo conocimientos existentes y el ecosistema. Si tu equipo ya está formado en AWS y hace un uso extensivo de sus servicios, lo más probable es que AWS Lambda le vaya como anillo al dedo (sobre todo porque, para empezar, muchas herramientas de terceros son compatibles con AWS). Igualmente, no subestime la bloqueo de proveedores Si le preocupa la dependencia de la propiedad, debe saber que migrar una aplicación sin servidor de un proveedor a otro no es trivial. Puede que sea más fácil mantener la coherencia con tu nube principal.
Cada plataforma tiene sus características específicas (límites de tiempo y memoria, formatos admitidos, modos de configuración). Lo mejor es estudiarlas de antemano para ver cuál se adapta a tus necesidades. Por ejemplo, AWS Lambda impone un máximo de 15 minutos por ejecución, GCP Cloud Functions 9 minutos, Azure Functions 10 minutos (en términos de consumo) - si estás planeando tiempos de procesamiento más largos, Cloud Run o Azure Functions Premium serían más adecuados. Otro ejemplo, en términos de rendimiento de arranque: las funciones de AWS en un tiempo de ejecución Node.js o Python arrancan muy rápidamente, mientras que una función Java puede tardar más; Azure Functions ofrece un tiempo de ejecución .NET muy eficiente si codifica en C# porque la plataforma está optimizada para .NET.
Modelo de costes y facturación también puede entrar en juego: los tres grandes son muy similares en términos de pago por uso (unas decenas de céntimos por millón de invocaciones, más tiempo de CPU/memoria). Sin embargo, puede haber diferencias en las opciones: Google Cloud Functions puede o no incluir las llamadas salientes a la red en la facturación, AWS cobra por separado el tráfico a través de API Gateway, etc. Dependiendo de su caso de uso (por ejemplo, una API muy utilizada donde el coste principal puede ser la API Gateway), esto puede influir en la elección que haga.
En resumen, a la hora de elegir una plataforma sin servidor, ten en cuenta lo siguiente su entorno tecnológico (afinidad con AWS/Azure/GCP), el casos de uso específicos (funciones simples frente a contenedores más complejos, requisitos globales en tiempo real, etc.), el datos técnicos (idiomas admitidos, limitaciones, rendimiento) y, en caso necesario, el costes. La buena noticia es que es totalmente posible tener éxito con cualquiera de las principales plataformas: todas están probadas. Algunos incluso adoptan una estrategia multicloud, aprovechando lo mejor de cada plataforma (por ejemplo, Cloudflare Workers para el borde + AWS Lambda para el backend interno). Como principiante, sin embargo, es aconsejable concentrarse en una plataforma al principio, para construir sus habilidades en ella, antes de explorar eventualmente otra.
En tan solo unos años, la tecnología sin servidor se ha convertido en un concepto consolidado. pilar de la informática moderna. Al liberar a los desarrolladores de la gestión de servidores, les permite innovar más rápido y a menor coste. Serverless se está aplicando ahora a una amplia gama de casos de uso: de la web a los datos, de la automatización al IoT, pasando por la aprendizaje automático. Por supuesto, no existe una solución única y serverless tiene sus limitaciones, pero si se gestiona adecuadamente, ofrece un una poderosa palanca de transformación para los sistemas de información. Así pues, tanto si eres desarrollador, arquitecto o director técnico, es muy probable que ahora -y más aún en el futuro- te cruces en tu camino con una arquitectura sin servidor.
