Construir funciones serverless

Visión General

La computación serverless ejecuta tu código sin que aprovisiones ni parchees un solo servidor. Escribes funciones, las subes a un proveedor de nube y la plataforma se encarga del escalado y la disponibilidad por su cuenta. Pagas solo por el tiempo de ejecución — por eso encaja tan bien con cargas esporádicas y sistemas por eventos.

Esta receta recorre la creación y el despliegue de funciones en las tres grandes nubes — AWS Lambda, Google Cloud Functions y Azure Functions — con código que corre tal cual.

Cuándo Usar

Usa este recurso cuando:

• Tienes cargas de trabajo por eventos (webhooks, procesamiento de archivos, jobs programados). Consulta Microservicios Event-Driven para patrones por eventos.
• Quieres escalado automático de cero a miles de peticiones. Consulta Optimización de Cold Start para minimizar la latencia de arranque.
• Necesitas evitar el mantenimiento de servidores y la sobrecarga de infraestructura.
• Tu tráfico es esporádico y aprovisionar servidores sería un desperdicio. Consulta API Gateway Serverless para construir APIs de pago por uso.

Solución

Python (AWS Lambda)

import json

def handler(event, context):
    # Extraer parámetro de query
    name = event.get("queryStringParameters", {}).get("name", "World")

    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"message": f"Hello, {name}!"})
    }

JavaScript (Google Cloud Functions)

const functions = require('@google-cloud/functions-framework');

functions.http('helloHttp', (req, res) => {
  const name = req.query.name || 'World';
  res.json({ message: `Hello, ${name}!` });
});

Java (Azure Functions)

import com.microsoft.azure.functions.*;
import java.util.Optional;

public class HelloFunction {
    @FunctionName("hello")
    public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET}, authLevel = AuthorizationLevel.ANONYMOUS)
        HttpRequestMessage<Optional<String>> request,
        final ExecutionContext context) {

        String name = request.getQueryParameters().getOrDefault("name", "World");
        return request.createResponseBuilder(HttpStatus.OK)
            .body("Hello, " + name + "!")
            .build();
    }
}

Explicación

Las plataformas serverless abstraen la gestión de infraestructura:

• Triggers de eventos: peticiones HTTP, subidas de archivos, cambios en base de datos, temporizadores.
• Escalado automático: cada invocación corre en un contenedor fresco; la plataforma sube y baja contenedores según demanda.
• Pago por uso: se factura por milisegundos de ejecución y número de invocaciones.

Los cold starts ocurren cuando una función lleva tiempo sin invocarse: un contenedor nuevo tiene que arrancar primero, lo que suma entre 100ms y 3s según el runtime y la memoria asignada.

Variantes

Plataforma	Runtime	Tipos de trigger	Cold Start
AWS Lambda	Python, Node, Java, Go, Ruby	HTTP, S3, SNS, SQS, EventBridge, Cron	100ms–1s
Cloud Functions	Node, Python, Go, Java	HTTP, Pub/Sub, Storage, Firestore, Cron	200ms–2s
Azure Functions	Node, Python, Java, C#	HTTP, Blob, Queue, Event Grid, Timer	200ms–3s

Lo que funciona

• Mantén las funciones pequeñas y enfocadas: una función por responsabilidad; compón workflows complejos con step functions.
• Minimiza el tamaño del paquete de despliegue: quita dependencias innecesarias para reducir el cold start.
• Usa concurrencia provisionada en rutas sensibles a latencia: contenedores precalentados para el camino crítico.
• Guarda el estado fuera: las funciones son stateless; DynamoDB, Redis o Firestore para persistencia.
• Configura memoria y timeout con criterio: poca memoria causa OOM; demasiada desperdicia dinero (y Lambda escala la CPU con la memoria).

Errores Comunes

• Guardar estado en el contenedor: las variables locales se pierden entre invocaciones; el contenedor puede reutilizarse, pero no cuentes con ello.
• Ignorar los cold starts: las APIs síncronas de cara al usuario sufren esa latencia extra.
• Sobreaprovisionar memoria: Lambda asigna CPU proporcional a la memoria; busca el punto justo.
• No manejar fallos parciales: el procesamiento por lotes debe reintentar sin duplicar trabajo.
• Amarrarse a un vendor: capas de abstracción (Serverless Framework, SAM) facilitan la portabilidad.

Avanzado: Mitigación de Cold Start

# AWS Lambda: inicializa fuera del handler para reutilizar conexiones
import json
import boto3

# Esto corre solo en cold start — se reutiliza entre invocaciones
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('users')

def handler(event, context):
    # El handler se mantiene delgado — las conexiones ya están calientes
    user_id = event['pathParameters']['id']
    response = table.get_item(Key={'id': user_id})
    return {
        'statusCode': 200,
        'body': json.dumps(response.get('Item', {}))
    }

Inicializa conexiones de base de datos, clientes HTTP e imports pesados fuera del handler. La plataforma reutiliza el contenedor entre invocaciones, así que esas inicializaciones corren una sola vez en cold start y persisten. El cuerpo del handler queda mínimo: procesa el evento y devuelve.

Avanzado: Orquestación con Step Functions

{
  "StartAt": "ValidateOrder",
  "States": {
    "ValidateOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123:function:ValidateOrder",
      "Next": "CheckInventory"
    },
    "CheckInventory": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123:function:CheckInventory",
      "Next": "ProcessPayment"
    },
    "ProcessPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123:function:ProcessPayment",
      "End": true
    }
  }
}

Step Functions encadena invocaciones Lambda con reintentos, manejo de errores y gestión de estado integrados. Cada paso se reintenta de forma independiente. Usa estados Choice para branching condicional, Parallel para ejecución concurrente y Map para fan-out.

Avanzado: Concurrencia Provisionada

# AWS CLI: configurar concurrencia provisionada
aws lambda put-provisioned-concurrency-config \
  --function-name my-api \
  --qualifier production \
  --provisioned-concurrent-executions 10

La concurrencia provisionada mantiene entornos calientes listos para responder. Configúrala en endpoints sensibles a latencia donde el cold start es inaceptable, y vigila la utilización — si la capacidad queda ociosa, redúcela. Para tráfico con picos, combínala con escalado on-demand.

Avanzado: Arquitectura por Eventos

import json
import boto3

s3 = boto3.client('s3')
sns = boto3.client('sns')

def handler(event, context):
    # Disparada por una subida a S3
    for record in event['Records']:
        bucket = record['s3']['bucket']['name']
        key = record['s3']['object']['key']

        # Procesar el archivo subido
        response = s3.get_object(Bucket=bucket, Key=key)
        content = response['Body'].read().decode('utf-8')

        # Publicar el resultado a SNS
        sns.publish(
            TopicArn='arn:aws:sns:us-east-1:123:processing-complete',
            Message=json.dumps({
                'file': key,
                'size': len(content),
                'lines': content.count('\n')
            })
        )

    return {'statusCode': 200, 'body': json.dumps({'processed': len(event['Records'])})}

Las funciones por eventos responden a eventos de la nube: subidas a S3, DynamoDB streams, mensajes de SQS, notificaciones SNS o schedules de EventBridge. Cada evento trae registros que tu handler procesa de forma independiente. Diseña handlers idempotentes porque las fuentes pueden entregar duplicados, y usa partial batch responses (Lambda) para reportar qué registros fallaron y deben reintentarse.

Avanzado: Respuestas Parciales por Lotes

SQS entrega mensajes por lotes — si un registro falla, el lote entero se reintenta salvo que indiques lo contrario. Reportar los fallos por registro le dice a Lambda que reintente solo los rotos:

import json

def handler(event, context):
    failed = []

    for record in event['Records']:
        try:
            process(record)  # tu lógica de negocio por mensaje
        except Exception:
            # Acumula el messageId fallido — el resto queda consumido
            failed.append({"itemIdentifier": record['messageId']})

    # Solo los items listados vuelven a la cola (y luego a la DLQ)
    return {"batchItemFailures": failed}

El contrato: el handler devuelve batchItemFailures con los messageId que deben reintentarse; todo lo no listado cuenta como consumido. Sin esto, un registro envenenado arrastra el lote completo — hasta maxReceiveCount veces antes de que la DLQ lo vea.

Avanzado: Desarrollo Local

# template.yaml — AWS SAM desarrollo local
Resources:
  ProcessUpload:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: python3.11
      Events:
        Upload:
          Type: S3
          Properties:
            Bucket: uploads
            Events: s3:ObjectCreated:*

# Ejecutar en local:
# sam local start-api
# sam local invoke ProcessUpload --event events/s3-upload.json
# sam local generate-event s3 --bucket uploads --key data.csv > events/s3-upload.json

AWS SAM CLI, Azure Functions Core Tools y el emulador de Cloud Functions ofrecen entornos de ejecución locales. Genera eventos de muestra con sam local generate-event para probar la lógica del handler sin desplegar, y usa sam local start-api para probar funciones HTTP con curl o Postman. Aun así, corre un test de integración final en la nube — los emuladores no replican todos los comportamientos de la plataforma.

Cuándo Evitar

• Computaciones de larga duración: tareas que superan los 15 minutos (Lambda) necesitan cómputo por contenedores (ECS, Cloud Run, EKS).
• Aplicaciones con estado: juegos en tiempo real, servidores WebSocket o streaming necesitan conexiones persistentes.
• Invocaciones de alta frecuencia: si tu función corre más de 1000 veces por segundo, un servidor siempre activo puede salir más barato.
• Dependencias complejas: librerías nativas grandes o runtimes propios aumentan el cold start y la complejidad del despliegue.

Troubleshooting

• Cold start alto: sube la concurrencia provisionada, reduce el paquete y evita inicializar clientes pesados por invocación.
• La función hace timeout: revisa dependencias downstream, asignación de memoria y lógica de reintentos. Sube el timeout solo después de optimizar el código.
• Estado perdido entre invocaciones: las funciones serverless son stateless — persiste el estado en una base de datos, caché o cola durable.
• Paquete de despliegue demasiado grande: excluye dependencias de desarrollo y assets sin uso.
• Problemas de orden de eventos: muchas fuentes son at-least-once y sin orden. Diseña para idempotencia y secuenciación explícita.

Véase También

• Companion ejecutable — handler Lambda, función GCF, template SAM y evento S3 de muestra.
• Documentación de AWS Lambda — handlers, concurrencia provisionada, partial batch responses.
• Desarrollo local con AWS SAM — sam local invoke y generación de eventos.
• Functions Framework de Google Cloud — el contrato de @google-cloud/functions-framework.
• Azure Functions para Java — anotaciones como @HttpTrigger del ejemplo.
• Guía Completa de Arquitectura Serverless — la guía extensa compañera en este sitio.