Caso de Estudio
Una firma de wealth management necesitaba que su equipo de desarrollo pudiera desplegar aplicaciones en contenedores sobre Azure de forma rápida y autónoma, sin darle acceso a la infraestructura. Los perfiles junior y mid no debían tocar Terraform ni operar recursos de Azure directamente, pero tampoco podían quedar bloqueados esperando al equipo de infraestructura. Hasta ese momento, cada aplicación se desplegaba de forma manual y caso por caso desde el portal de Azure, sin estado declarativo ni releases versionadas — lo que dejaba entornos inconsistentes y ningún registro auditable de qué versión corría dónde, un problema serio para una firma financiera con exigencias reales de gobernanza.
Renaiss construyó una plataforma Azure privada, multi-entorno y self-service, apoyada en tres piezas: un catálogo declarativo en YAML, una librería de módulos Terraform sobre Azure Verified Modules, y un CI/CD deliberadamente desacoplado. El catálogo es la frontera entre equipos: el desarrollador declara su aplicación en un archivo YAML y abre un pull request, sin escribir Terraform ni entrar al portal de Azure; del otro lado, Terraform resuelve la configuración y materializa los recursos, manteniendo el ownership de la infraestructura del lado del equipo de plataforma.
GitHub Actions construye y valida; Azure DevOps despliega — con un único punto de acoplamiento entre ambos, un webhook de Azure Container Registry. Toda la topología es privada de punta a punta, con secretos resueltos vía Key Vault y managed identity, y observabilidad integrada con Datadog.
Agregar una aplicación pasó de ser un proceso manual coordinado entre equipos a un YAML y un pull request. El desarrollador nunca toca Terraform ni opera Azure directamente, y tampoco depende del equipo de infraestructura para avanzar. La plataforma quedó reproducible y auditable: los entornos se construyen con el mismo código, los despliegues son por artefacto versionado, y el click-ops salió por completo del flujo — sin resignar la seguridad ni la gobernanza que exige una firma financiera regulada.
Agregar una aplicación nueva pasó de requerir coordinación manual con infraestructura a ser un YAML y un PR.
Todos los cambios de infraestructura quedan versionados y revisables por PR — nada se aplica manualmente desde el portal.
Toda la plataforma opera dentro de una red virtual, sin recursos expuestos públicamente y con secretos gestionados vía Key Vault.
GitHub Actions y Azure DevOps se comunican solo por un webhook, permitiendo reemplazar cualquiera de los dos sin tocar el otro.
Dev y producción se construyen con el mismo código declarativo, eliminando la divergencia entre entornos.
Cada despliegue queda asociado a un artefacto versionado, permitiendo saber qué corre dónde y revertir de forma controlada.
Diagnóstico del límite entre equipos
Identificamos que el desafío real no era técnico sino organizacional: encontrar dónde trazar la frontera entre lo que un desarrollador puede pedir y lo que el equipo de plataforma controla.
Diseño del catálogo declarativo
Construimos un catálogo en YAML donde cada aplicación se declara con sus entornos, resuelto por Terraform con una precedencia de configuración clara y consistente.
Módulos Terraform sobre AVM
Desarrollamos una librería de módulos propios sobre Azure Verified Modules, con separación estricta entre módulos y entornos, y estado remoto versionado.
Topología de red privada
Diseñamos una arquitectura completamente privada, con VNet, subnets segmentadas, Private DNS y APIM como único punto de entrada a los servicios.
CI/CD desacoplado
Implementamos GitHub Actions como build runner y Azure DevOps como orquestador de despliegue, conectados únicamente por un webhook de Azure Container Registry.
Documentación por audiencia y traspaso
Entregamos documentación seccionada: una superficie para el equipo de desarrollo, acotada al flujo de catálogo, y otra para el equipo de infraestructura con la operación real.
Trabajamos sobre todo con bancos y empresas del mercado de capitales en proyectos de modernización tecnológica: infraestructura, sistemas core e incorporación de IA a procesos reales. También tomamos proyectos de otros sectores cuando la exigencia técnica es la misma — varios de los casos de esta sección lo son. En todos los casos, entramos como equipo técnico senior embebido, no como una mesa de soporte tercerizada.
Tenemos base en Rosario, Argentina, y trabajamos con clientes en toda Latinoamérica. Eso significa conocimiento directo del contexto regulatorio y operativo de la región — por ejemplo la normativa del BCRA para fintechs argentinas — y coordinación en el mismo huso horario, sin la fricción de trabajar con un equipo a 10 horas de diferencia.
Nuestro trabajo está en la intersección de infraestructura cloud, arquitectura de aplicaciones e IA: diseño de arquitectura cloud-native, automatización de infraestructura, plataformas, pipelines de datos e integración de GenAI. No hacemos soporte cloud genérico — construimos y operamos sistemas que necesitan escalar.
Nuestra mayor profundidad es en AWS. También trabajamos con Azure y GCP según el stack que ya tenga el cliente — el objetivo siempre es adaptarnos a tu entorno, no imponer un proveedor.
Sí — es uno de los problemas en los que más trabajamos. Modernizar una aplicación suele implicar alguna combinación de: separar un monolito en servicios, migrar a infraestructura cloud-native, reemplazar dependencias obsoletas o mejorar el pipeline de CI/CD para que el equipo entregue más rápido. Siempre arrancamos con un diagnóstico técnico antes de recomendar un camino.
© 2026 - Renaiss, hecho con cariño
