FinOps y arquitectura cloud

📐 Fundamento

Principios FinOps:

1. Visibilidad — todos pueden ver cuánto cuesta su servicio.
2. Responsabilidad — los equipos son dueños de sus costos.
3. Optimización continua — no es un proyecto único, es un proceso.
4. Decisiones basadas en datos — antes de optimizar, medir.

Estrategias de optimización:

1. Right-sizing — usar el tamaño correcto:

Antes: instancia t3.xlarge (4 vCPU, 16 GB) usando solo 30% CPU y 4 GB RAM.
Después: t3.large (2 vCPU, 8 GB) → mitad de costo, mismo rendimiento.

Herramientas: AWS Compute Optimizer, GCP Recommender.

2. Modelos de pricing:

3. Auto-scaling agresivo:

# En lugar de: instance_type = "t3.xlarge", count = 10 (siempre)
# Hacer: 
resource "aws_autoscaling_group" "api" {
  min_size     = 2    # noche
  max_size     = 20   # picos del mediodía
  
  # Escalar basado en CPU
  target_tracking_scaling_policy {
    target_value = 60.0  # mantener CPU promedio en 60%
  }
}

4. Apagar lo que no se usa:

• Dev/staging fuera de horario laboral (apagar 12 horas/día = 50% menos costo).
• Snapshots viejos (cuestan storage).
• Volúmenes EBS no asociados a instancias.
• Load balancers sin tráfico.
• Elastic IPs no usadas.

# Lambda que apaga instancias dev a las 7 PM, las prende a las 7 AM
import boto3
ec2 = boto3.client('ec2')

def apagar_dev(event, context):
    instancias = ec2.describe_instances(
        Filters=[{'Name': 'tag:Environment', 'Values': ['dev', 'staging']}]
    )
    ids = [i['InstanceId'] for r in instancias['Reservations'] for i in r['Instances']]
    if ids:
        ec2.stop_instances(InstanceIds=ids)

5. Optimizar storage:

• S3 Storage Classes: Standard → Infrequent Access (datos > 30 días) → Glacier (archivo > 90 días).
• Lifecycle rules automáticas:

resource "aws_s3_bucket_lifecycle_configuration" "facturas" {
  bucket = "la-esquina-facturas"
  
  rule {
    id     = "archivar-viejas"
    status = "Enabled"
    
    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }
    transition {
      days          = 90
      storage_class = "GLACIER"
    }
    expiration {
      days = 2555  # eliminar después de 7 años (compliance)
    }
  }
}

6. Cuidado con el data transfer:

• Tráfico SALIENDO de AWS a internet cuesta $0.09/GB.
• Entre regiones también cuesta.
• Mantener tráfico dentro de la misma región y AZ cuando sea posible.
• Cloudfront cachea → reduce data transfer del origen.

Visibilidad:

• AWS Cost Explorer — visualizar gastos por servicio, tag, etc.
• AWS Budgets — alertas cuando se acerca al límite.
• Tagging — cada recurso debe tener tags Environment, Team, Project. Permite agrupar costos.

# Política: todos los recursos deben tener tags
default_tags = {
  tags = {
    Environment = var.env
    Team        = "platform"
    Project     = "la-esquina"
    CostCenter  = "engineering"
    ManagedBy   = "terraform"
  }
}

📐 Fundamento

AWS publica el Well-Architected Framework: 6 pilares para evaluar cualquier arquitectura cloud.

1. Operational Excellence:

• IaC (Terraform, CloudFormation).
• Procesos automatizados (CI/CD).
• Monitoreo y observabilidad.
• Postmortems sin culpa, mejora continua.

2. Security:

• Identity (IAM, mínimo privilegio).
• Detective controls (CloudTrail, GuardDuty).
• Infrastructure protection (VPC, Security Groups, WAF).
• Data protection (cifrado at-rest y in-transit).
• Incident response.

3. Reliability:

• Diseño multi-AZ (alta disponibilidad).
• Multi-region para disaster recovery.
• Monitoreo de health, auto-recovery.
• Testing de recuperación.
• Backups y restore probados.

4. Performance Efficiency:

• Elegir el tipo de instancia correcto.
• Usar caché (ElastiCache, CloudFront).
• Bases de datos optimizadas.
• Monitoreo de performance.
• Load testing.

5. Cost Optimization:

• (Toda la sección anterior).

6. Sustainability (agregado en 2021):

• Elegir regiones con energía renovable.
• Right-sizing reduce desperdicio energético.
• Auto-shutdown de recursos no usados.
• Architectures more efficient = menos huella de carbono.

Well-Architected Tool: AWS provee una herramienta gratuita que te hace preguntas y te da un reporte con áreas de mejora.

5.3 Alta disponibilidad y Disaster Recovery

Conceptos clave:

• RTO (Recovery Time Objective): ¿en cuánto tiempo debe recuperarse el sistema después de un desastre?
• RPO (Recovery Point Objective): ¿cuánta pérdida de datos es aceptable?

Multi-AZ vs Multi-Region:

• Multi-AZ: réplicas en múltiples AZs de la misma región. Sobrevive falla de datacenter. Latencia entre réplicas: < 5ms.
• Multi-Region: réplicas en regiones distintas. Sobrevive falla de región completa. Más complejo, más caro.

Ejemplo: RDS Multi-AZ:

resource "aws_db_instance" "postgres" {
  multi_az = true   # AWS mantiene una réplica síncrona en otra AZ automáticamente
  # Failover automático en < 60 segundos si la primaria falla
}

Backup strategy 3-2-1:

• 3 copias de los datos.
• 2 medios diferentes.
• 1 copia off-site (otra región o cuenta).

# AWS Backup: políticas centralizadas
resource "aws_backup_plan" "diario" {
  rule {
    rule_name         = "daily-backup"
    schedule          = "cron(0 5 ? * * *)"  # 5 AM UTC diario
    target_vault_name = aws_backup_vault.main.name
    
    lifecycle {
      delete_after = 30  # retener 30 días
    }
    
    copy_action {
      destination_vault_arn = aws_backup_vault.dr.arn  # copia a otra región
      lifecycle {
        delete_after = 365
      }
    }
  }
}

📐 Fundamento

Estrategias respecto al lock-in:

1. Single-cloud, abrazar el lock-in:

• Usar todos los servicios managed (Lambda, DynamoDB, SNS, etc.).
• Velocidad de desarrollo máxima.
• Lock-in alto pero costo de migración aceptado.
• Más común en startups y empresas medianas.

2. Multi-cloud por servicio:

• Workloads en cloud A, BI en cloud B, ML en cloud C.
• Aprovecha las fortalezas de cada uno.
• Más complejo (gestión de múltiples cuentas, equipos especializados).

3. Multi-cloud verdadero (mismo workload en múltiples clouds):

• Usar solo herramientas portables: Kubernetes, PostgreSQL, Redis.
• Resiliencia ante caída de un cloud completo.
• Mayor complejidad operacional.
• Solo justificable para regulaciones o servicios críticos enormes.

Cuando tiene sentido multi-cloud:

• Compliance que requiere redundancia (banking, healthcare).
• Ya tenés presencia en múltiples clouds por adquisiciones.
• Negociación de precios contra proveedores.

Cuando NO tiene sentido:

• "Por si acaso" — agrega complejidad sin beneficio claro.
• Para startups — la velocidad es más importante.

Herramientas multi-cloud:

• Kubernetes — corre en cualquier cloud.
• Terraform — mismo lenguaje para AWS/GCP/Azure.
• Crossplane — Kubernetes-native multi-cloud control plane.
• CockroachDB / Yugabyte — DBs distribuidas multi-cloud.

Patrón anti lock-in: hexagonal architecture:

# Interfaz portable
class FileStorage(Protocol):
    def upload(self, key: str, data: bytes) -> str: ...
    def download(self, key: str) -> bytes: ...

# Implementación AWS
class S3Storage:
    def upload(self, key: str, data: bytes) -> str:
        s3.put_object(Bucket=bucket, Key=key, Body=data)
        return f"s3://{bucket}/{key}"

# Implementación GCP
class GCSStorage:
    def upload(self, key: str, data: bytes) -> str:
        storage_client.bucket(bucket).blob(key).upload_from_string(data)
        return f"gs://{bucket}/{key}"

# El código de negocio solo conoce la interfaz
def crear_factura(storage: FileStorage, datos: dict):
    pdf = generar_pdf(datos)
    return storage.upload(f"facturas/{datos['id']}.pdf", pdf)

Migrar de AWS a GCP: cambiar la implementación, no el código de negocio.