La gestión de infraestructura a escala empresarial, especialmente en sectores regulados como el financiero, presenta desafíos inherentes de complejidad, cumplimiento y velocidad. La proliferación de servicios y la necesidad de agilidad chocan con los procesos manuales y la falta de estandarización, resultando en largos ciclos de aprovisionamiento y altos costos operativos. Este problema fundamental de la computación distribuida y la gestión de sistemas se agrava con la adopción de múltiples proveedores de nube y la diversidad de cargas de trabajo.
La ingeniería de plataformas emerge como una solución para abstraer esta complejidad, ofreciendo una capa de autoservicio que encapsula las mejores prácticas arquitectónicas y de seguridad. Al estandarizar la forma en que los equipos de desarrollo consumen la infraestructura, se busca desacoplar la lógica de negocio de las complejidades operativas subyacentes, permitiendo a los desarrolladores enfocarse en la creación de valor. La adopción de principios declarativos y el modelo GitOps son clave para lograr consistencia y auditabilidad en este entorno dinámico.
La relevancia actual de este enfoque radica en la creciente demanda de velocidad y la necesidad de gestionar entornos híbridos y multi-nube de manera eficiente. La capacidad de aprovisionar infraestructura de forma programática y conforme a políticas es crucial para escalar operaciones, reducir la fricción en el desarrollo y mitigar riesgos de seguridad y cumplimiento en organizaciones con cientos de sistemas y miles de desarrolladores.
Arquitectura del Sistema
La plataforma Catalyst de Santander se articula alrededor de un clúster de control plane basado en Amazon Elastic Kubernetes Service (EKS). Este clúster actúa como el orquestador central, gestionando el ciclo de vida de los recursos de infraestructura. En su núcleo, Crossplane es el componente fundamental, funcionando como un provisionador universal de recursos. Crossplane extiende la API de Kubernetes para permitir la gestión declarativa de recursos externos a Kubernetes, como bases de datos, buckets de almacenamiento o servicios de IA, a través de Custom Resource Definitions (CRDs) y Compositions. Esto permite a Santander definir y aprovisionar infraestructura de manera consistente en múltiples proveedores de nube.
El control plane de Catalyst integra tres componentes principales. Primero, los 'Data Plane Claims', gestionados por ArgoCD, implementan el concepto de GitOps. ArgoCD sincroniza continuamente el estado deseado de las aplicaciones y sus configuraciones de infraestructura (definidas en Git) con el estado real de los clústeres, asegurando la consistencia y facilitando la entrega continua. Segundo, un 'Policies Catalog' centraliza las políticas de cumplimiento y seguridad, utilizando Open Policy Agent (OPA). OPA permite definir políticas declarativas que se aplican en tiempo de ejecución para validar solicitudes de aprovisionamiento y configuraciones, garantizando que todos los servicios cumplan con las normativas internas y externas. Tercero, un 'Stacks Catalog' proporciona una biblioteca de definiciones de recursos compuestos y Compositions de Crossplane, permitiendo la creación rápida y estandarizada de entornos complejos, encapsulando patrones arquitectónicos pre-aprobados.
El frontend de la plataforma es un portal de desarrolladores interno que ofrece una interfaz unificada para todas las necesidades de aprovisionamiento y gestión de recursos. Este portal abstrae la complejidad subyacente de Kubernetes, Crossplane, ArgoCD y OPA, presentando una experiencia de autoservicio simplificada. La arquitectura permite la creación de 'stacks' de aplicaciones completas, desde agentes de IA generativa que integran Amazon Bedrock y S3, hasta plataformas de datos modernas con Databricks y AWS Step Functions para orquestación de flujos de trabajo, todo gestionado de forma declarativa y automatizada.
Flujo de Aprovisionamiento de Infraestructura con Catalyst
- 1 Developer Portal Desarrollador solicita un stack de infraestructura predefinido.
- 2 Control Plane (EKS) Recibe la solicitud y la procesa.
- 3 Stacks Catalog Identifica la Composition de Crossplane para el stack solicitado.
- 4 Crossplane Crea Custom Resources (CRs) que representan los recursos cloud deseados.
- 5 Policies Catalog (OPA) Valida los CRs contra políticas de seguridad y cumplimiento.
- 6 Crossplane Providers Traduce los CRs a llamadas API específicas del proveedor cloud (ej. AWS).
- 7 Cloud Provider API Aprovisiona los recursos de infraestructura (ej. S3, EKS, Bedrock).
- 8 ArgoCD Sincroniza continuamente el estado del data plane con el repositorio Git.
| Capa | Tecnología | Justificación |
|---|---|---|
| orchestration | Amazon EKS | Plano de control principal para orquestar todos los componentes y flujos de trabajo de la plataforma Catalyst. vs Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), OpenShift |
| orchestration | Crossplane | Provisionador universal de recursos, gestiona recursos en múltiples proveedores cloud de forma consistente y declarativa. vs Terraform, AWS CloudFormation, Pulumi Uso de Compositions para definir stacks de recursos compuestos. |
| orchestration | ArgoCD | Herramienta de entrega continua para la sincronización y despliegue de stacks de aplicaciones y configuraciones, aplicando el concepto GitOps. vs Flux CD, Spinnaker |
| security | Open Policy Agent (OPA) | Motor de políticas para asegurar el cumplimiento y la seguridad en todas las operaciones, validando solicitudes de aprovisionamiento. vs Kyverno, Gatekeeper Catálogo centralizado de políticas. |
| storage | Amazon S3 | Almacenamiento de datos para diversas cargas de trabajo, incluyendo agentes de IA generativa. vs Azure Blob Storage, Google Cloud Storage |
| security | AWS Key Management Service (KMS) | Gestión de claves criptográficas para asegurar los datos. vs HashiCorp Vault, Azure Key Vault |
| compute | Amazon Bedrock | Consumo de modelos fundacionales para agentes de IA generativa. vs OpenAI API, Google AI Platform |
| data-processing | Databricks | Integración para la plataforma de datos moderna, habilitando análisis y procesamiento de datos. vs AWS Glue, Apache Spark en EMR |
| orchestration | AWS Step Functions | Orquestación de flujos de trabajo y migración de procesos legacy, con patrones de reintento y manejo de errores. vs Apache Airflow, Prefect |
Trade-offs
Ganancias
- ▲▲ Tiempo de aprovisionamiento de infraestructura
- ▲ Estandarización y cumplimiento
- ▲ Eficiencia operativa (reducción de tickets)
- ▲ Agilidad en el desarrollo y despliegue
Costes
Fundamentos Teóricos
El problema de la gestión de la configuración y el aprovisionamiento de recursos en sistemas distribuidos ha sido un tema recurrente en la investigación de sistemas operativos y bases de datos. La idea de un 'estado deseado' y un 'controlador' que trabaja para alcanzarlo tiene raíces en los sistemas de control y en la teoría de la computación declarativa. Conceptos como la 'eventual consistencia' y los 'sistemas auto-sanadores' (self-healing systems) son fundamentales en la operación de plataformas como Catalyst.
La adopción de GitOps, con su énfasis en la declaración del estado deseado en un repositorio de control de versiones, se alinea con los principios de la 'infraestructura como código' (Infrastructure as Code - IaC), popularizada por herramientas como Terraform y CloudFormation. Este enfoque busca la reproducibilidad y la auditabilidad, principios que se remontan a la gestión de configuraciones en sistemas operativos y al control de versiones de software. La utilización de Kubernetes como plano de control para recursos externos, a través de Crossplane, extiende el modelo declarativo de Kubernetes más allá de los contenedores, aplicando patrones de control de bucle cerrado (control loop) a la infraestructura en general, un concepto bien establecido en la ingeniería de sistemas.