Serverless - Andres Rios Macias

00 /

¿Qué es Serverless?

Serverless es un modelo de ejecución en la nube donde el proveedor gestiona completamente la infraestructura subyacente: servidores, sistemas operativos, parches, escalado y alta disponibilidad. El desarrollador solo escribe y despliega código — funciones o aplicaciones — sin preocuparse por dónde o en qué máquina corre.

El nombre puede ser engañoso: los servidores sí existen, simplemente son invisibles para el desarrollador. Lo que desaparece es la responsabilidad de gestionarlos. El modelo de facturación cambia radicalmente: en lugar de pagar por servidores encendidos 24/7, pagas solo por el tiempo de ejecución real de tu código, medido en milisegundos.

Definición técnica Serverless = FaaS (Function as a Service) + BaaS (Backend as a Service). FaaS es el modelo de ejecución por evento (Lambda). BaaS son los servicios gestionados que reemplazan la infraestructura propia: DynamoDB en lugar de tu propio MySQL, S3 en lugar de tu propio NFS, Cognito en lugar de tu propio servidor de autenticación.

01 /

AWS Lambda

AWS Lambda es el servicio FaaS de Amazon y el núcleo de la arquitectura serverless en AWS. Permite ejecutar funciones en respuesta a eventos sin aprovisionar ni gestionar servidores. Lambda soporta múltiples runtimes: Python, Node.js, Java, Go, Ruby, .NET y runtimes personalizados via Lambda Layers.

Timeout máximo 15 minutos por invocación

Memoria 128 MB – 10,240 MB (más memoria = más vCPU proporcional)

Concurrencia 1,000 ejecuciones simultáneas por región (límite ajustable)

Tamaño del paquete 50 MB (ZIP directo) / 250 MB (descomprimido) / 10 GB (imagen de container)

Precio $0.20 por 1M de solicitudes + $0.0000166667 por GB·segundo

Tier gratuito 1M solicitudes/mes + 400,000 GB·segundos/mes — permanente

Ejemplo — función Lambda en Python

import json
import boto3
from datetime import datetime

def lambda_handler(event, context):
    """
    Handler principal — punto de entrada de Lambda.
    'event': datos del trigger (dict)
    'context': metadatos de ejecución (timeout, request_id, etc.)
    """
    # Extraer datos del evento
    body = json.loads(event.get('body', '{}'))
    user_id = body.get('user_id')

    # Lógica de negocio
    result = {
        'user_id': user_id,
        'processed_at': datetime.utcnow().isoformat(),
        'status': 'ok'
    }

    # Tiempo restante antes del timeout
    ms_remaining = context.get_remaining_time_in_millis()
    print(f"Tiempo restante: {ms_remaining}ms")

    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'application/json'},
        'body': json.dumps(result)
    }

02 /

¿Cómo funciona Lambda?

Cuando se dispara un evento que tiene Lambda como destino, AWS asigna un execution environment: un microVM aislado (basado en Firecracker) con el runtime seleccionado, el código de la función y las variables de entorno. Lambda ejecuta el handler, captura el resultado y devuelve la respuesta al invoker.

Si llegan múltiples eventos simultáneamente, Lambda lanza múltiples instancias en paralelo de forma automática — hasta el límite de concurrencia configurado. AWS gestiona completamente este escalado: no hay configuración de auto-scaling groups ni load balancers.

Evento (trigger) → Lambda Service → Execution Environment → Init (si cold start) → Handler(event, ctx) → Respuesta / log

Lifecycle del execution environment Después de ejecutar la función, AWS mantiene vivo el environment por un período (típicamente 5–15 min). Si llega otro evento antes de que expire, reutiliza el mismo environment — esto es un warm start y es significativamente más rápido que un cold start. Cualquier estado en memoria (conexiones a BD, variables globales) persiste entre invocaciones del mismo environment.

03 /

Triggers — ¿qué puede activar Lambda?

Lambda es una arquitectura completamente event-driven: la función solo corre cuando algo la dispara. AWS ofrece integraciones nativas con decenas de servicios como triggers:

🪣

S3 Events

ObjectCreated, ObjectRemoved. Útil para procesar archivos al subirse — ETL, resize de imágenes, validaciones.

📨

API Gateway

HTTP/REST/WebSocket requests. Lambda como backend de APIs sin servidor — el patrón más común en producción.

📡

Kinesis / SQS

Procesa batches de mensajes o eventos de streaming. Lambda lee del stream o queue en polling automático.

🗄️

DynamoDB Streams

Reacciona a cambios en tablas DynamoDB (INSERT, MODIFY, REMOVE). Ideal para sincronización y auditoría.

🕐

EventBridge / CloudWatch

Cron expressions para tareas programadas. Reemplaza los cronjobs de servidor con Lambda + EventBridge Rules.

📣

SNS

Fan-out: un mensaje en SNS puede disparar múltiples Lambdas en paralelo. Patrón pub/sub sin servidor.

Ejemplo — Lambda con trigger de S3 (procesar CSV al subirse)

import boto3, csv, io, json

s3 = boto3.client('s3')

def lambda_handler(event, context):
    # S3 puede enviar múltiples records en un evento
    for record in event['Records']:
        bucket = record['s3']['bucket']['name']
        key    = record['s3']['object']['key']

        # Solo procesar archivos CSV
        if not key.endswith('.csv'):
            continue

        obj  = s3.get_object(Bucket=bucket, Key=key)
        body = obj['Body'].read().decode('utf-8')
        reader = csv.DictReader(io.StringIO(body))

        rows = [row for row in reader]
        print(f"Procesadas {len(rows)} filas de {key}")

        # Guardar resultado como JSON en otro bucket
        s3.put_object(
            Bucket='processed-bucket',
            Key=key.replace('.csv', '.json'),
            Body=json.dumps(rows)
        )

04 /

Cold starts — el talón de Aquiles

Un cold start ocurre cuando Lambda no tiene un execution environment disponible y debe crear uno nuevo desde cero: inicializar el microVM, cargar el runtime, descargar el paquete de la función e inicializar las dependencias. Este proceso puede agregar entre 100ms y varios segundos de latencia antes de que el handler siquiera comience a ejecutar.

CAUSA

¿Cuándo ocurre un cold start?

Primera invocación después de un período sin tráfico, escalado horizontal a más concurrencia que environments activos, o después de un deploy nuevo que invalida los environments existentes.

IMPACTO

¿Qué factores lo empeoran?

Runtimes lentos (Java/C# vs Python/Node), paquetes de despliegue grandes, Lambda dentro de VPC (inicialización de ENI), y dependencias pesadas que tardan en importar.

SOLUCIÓN 1

Provisioned Concurrency

AWS mantiene N environments pre-inicializados y calientes. El cold start desaparece para esas invocaciones. Tiene costo adicional — solo úsalo en funciones críticas de latencia.

SOLUCIÓN 2

Optimización de paquete

Importa solo lo que necesitas (no `import boto3` completo si solo usas S3), usa Lambda Layers para dependencias compartidas y prefiere runtimes rápidos como Python o Node.js.

Regla práctica Para APIs con SLAs de latencia estrictos (<100ms p99), el cold start es un problema real. Para procesamiento batch, ETL, cron jobs o pipelines de datos donde la latencia no importa tanto, el cold start es irrelevante y no debe ser motivo para no usar Lambda.

05 /

Amazon API Gateway

API Gateway es el servicio de AWS para crear, publicar y gestionar APIs REST, HTTP y WebSocket a escala. Es el complemento natural de Lambda para exponer funciones como endpoints HTTP. Gestiona autenticación (IAM, Cognito, API Keys), throttling, CORS, transformación de requests/responses y despliegue en stages (dev/staging/prod).

Cliente HTTP → API Gateway → Autenticación → Lambda → DynamoDB / S3 → Response JSON

Ejemplo — definición de API con AWS SAM (template.yaml)

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  ApiFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.lambda_handler
      Runtime: python3.12
      MemorySize: 256
      Timeout: 30
      Environment:
        Variables:
          TABLE_NAME: !Ref UsersTable
      Events:
        GetUser:
          Type: Api
          Properties:
            Path: /users/{id}
            Method: GET
        CreateUser:
          Type: Api
          Properties:
            Path: /users
            Method: POST

  UsersTable:
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
        Name: id
        Type: String

06 /

AWS SAM — Serverless Application Model

SAM es el framework open-source de AWS para definir, construir y desplegar aplicaciones serverless como infraestructura como código (IaC). Es una extensión de CloudFormation con sintaxis simplificada para recursos Lambda, API Gateway, DynamoDB y Step Functions. Incluye SAM CLI para desarrollo local.

Comandos esenciales de SAM CLI

# Inicializar nuevo proyecto
sam init --runtime python3.12 --name mi-api

# Construir el paquete de despliegue
sam build

# Probar función localmente (simula Lambda)
sam local invoke ApiFunction --event events/test.json

# Levantar API local en puerto 3000
sam local start-api --port 3000

# Desplegar a AWS (primera vez, modo guiado)
sam deploy --guided

# Despliegues siguientes (usa configuración guardada)
sam deploy

# Ver logs de Lambda en tiempo real
sam logs -n ApiFunction --stack-name mi-api --tail

07 /

¿Cuándo usar Serverless?

IDEAL PARA

Serverless brilla en estos casos

APIs con tráfico variable o impredecible — ETL ligero activado por eventos (S3, SQS) — Cron jobs y tareas programadas — Webhooks y notificaciones — Procesamiento de archivos al subirse — Microservicios con bajo acoplamiento — MVPs y prototipos que necesitan escalar sin ops.

CONSIDERAR ALTERNATIVAS

Cuando Serverless no es la mejor opción

Procesos de larga duración (>15 min) — Cargas de trabajo de Big Data intensivas (usa EMR o Glue) — Aplicaciones con estado persistente en memoria — APIs con latencia p99 ultra estricta (<50ms) — Workloads con cómputo constante 24/7 (EC2 será más barato).

08 /

Serverless vs enfoques tradicionales

Característica	Serverless (Lambda)	EC2 / VM	Containers (ECS/EKS)
Gestión de infraestructura	Cero	Total	Parcial
Escalado automático	Instantáneo	Manual / ASG	Con configuración
Modelo de costo	Pay-per-use (ms)	Pay-per-hour (siempre)	Pay-per-hour (por task)
Cold starts	Sí (mitigable)	No aplica	Solo al inicio del task
Duración máxima por request	15 minutos	Sin límite	Sin límite práctico
Curva de aprendizaje	Baja	Media	Alta (Kubernetes)
Ideal para tráfico 24/7 alto	Costoso	Óptimo	Óptimo

── /

Resumen de comandos esenciales

#	Operación	Comando
01	Invocar Lambda directo	`aws lambda invoke --function-name MiFn out.json`
02	Ver logs recientes	`aws logs tail /aws/lambda/MiFn --follow`
03	Actualizar código	`aws lambda update-function-code --zip-file f.zip`
04	Listar funciones	`aws lambda list-functions`
05	Build SAM	`sam build`
06	Test local	`sam local invoke NombreFn --event e.json`
07	API local	`sam local start-api --port 3000`
08	Deploy a AWS	`sam deploy --guided`

Serverless —
arquitectura sin servidor

¿Qué es Serverless?

AWS Lambda

¿Cómo funciona Lambda?

Triggers — ¿qué puede activar Lambda?

Cold starts — el talón de Aquiles

Amazon API Gateway

AWS SAM — Serverless Application Model

¿Cuándo usar Serverless?

Serverless vs enfoques tradicionales

Resumen de comandos esenciales

Contact Me