El enfoque de desarrollo tradicional con DevOps ha marcado un hito en la historia del desarrollo de software al incentivar el trabajo colaborativo y permitiendo a los equipos de trabajo agilizar sus entregas de valor a través de la definición de pipelines deCI, Infraestructura, Delivery, Deployment y DR, entre otros. Sin embargo, esa agilidad ha venido a su vez con retos técnicos y carga congnitiva para los equipos de desarrollo que, para seguir el ritmo de la filosofía DevOps: “You build it, you run it”, deben aprender una serie de herramientas para garantizar la entrega de valor en el tiempo; entre ellas: IaC (Terraform/OpenTofu), Cloud-providers (AWS, Azure, etc), monitoreo (OpenTelemetry, Prometheus, Grafana), entre otros.
En busca de disminuir esa carga cognitiva e incrementar la propuesta de valor, se ha diseñado una estrategia de platform-engineering con un modelo de Gobierno GitOps basado en una arquitectura, tipo”hub-and-spoke”, que abstrae la lógica de negocio y centraliza configuraciones de seguridad y monitoreo en el hub (Manager-Cluster) que masifica hacia los diferentes spokes (o flujos de negocio), como se aprecia en la Figura 1.

Figura 1. Arquitectura de Gobierno GitOps tipo “hub-and-spoke”.
Como se aprecia en la Figura 1, la propuesta de valor de esta arquitectura se basa en el uso
conjunto de distintas herramientas:
- Terraform: como herramienta base de IaC que habilita la estructura base tanto del Manager-Cluster como de los diferentes flijos de negocio (Inversiones-Cluster, Credito-Cluster, etc).
- FluxCD: como agente de GitOps que supervisa las configuraciones establecidas en los repositorios.
o CloudManager repo: repositorio principal de configuraciones donde se especifica las configuraciones de forma declarativa, una sola vez, y lo masifica hacia todos los spokes.
- Businessflow repo: contiene la configuración declarativa de los microservicios de un flujo de negocio (e.g., Inversiones-Businessflow).
- App repo: contiene el código fuente y los manifiestos de un microservicio/desarrollo. Es mantenido por el equipo de desarrollo.
- Crossplane: herramienta que gestiona la configuración de CRDs (“Custom-Resource Definitions”) en Kubernetes para la gestión de artefactos pre-definidos por el equipo de infraestructura. Abstraen la dificultad técnica de habilitar recursos de infraestructura (como BDs, Colas de mensajería, cachés, etc).
- Helm Charts: controlador base de FluxCD para la gestión de instalación de herramientas en los clústers.

Además de la arquitectura provista, se emplearán experiencias de desarrollo basadas en Backstage, brindando lineamientos sobre su arquitectura y cómo incrementa los índices de experiencia del desarrollador (DevEx). Los asistentes del presente workshop experimentarán estos beneficios de primera mano y podrán participar en prácticas guiadas que les ayuden a tener una primera experiencia con estas herramientas para la gestión de sus proyectos y de sus recursos de infraestructura.