Escrito por: Nubank Editorial

En una charla presentada por Katharine Luiza, Engineering Manager en Nubank, durante el 37º Meetup del CNCF, realizado en la oficina de Nu, en São Paulo, un tema apareció repetidamente como pieza central de la escalabilidad de la infraestructura de Nu: el ownership distribuido. 

En lugar de concentrar la responsabilidad operativa en un único equipo de plataforma, el modelo adoptado por Nubank transforma la infraestructura en un compromiso compartido entre la ingeniería de producto, la automatización y la gobernanza.

Este enfoque sostiene una operación que hoy ejecuta más de 21 mil databases en producción distribuidos entre Brasil, México y Colombia. Y quizás lo más sorprendente sea que la gestión de ese ecosistema la realizan apenas cinco ingenieros directamente responsables de la capa de databases. 

Aun así, el entorno mantiene métricas de estabilidad extremadamente altas, incluyendo más de seis meses sin crashes de infraestructura y cero incidentes críticos relacionados con databases en los últimos 12 meses.

Pero el punto central está en la forma en que la responsabilidad sobre la infraestructura fue rediseñada para escalar junto con el crecimiento de la empresa.

El problema real no es provisionar infraestructura

Crear recursos en la nube nunca fue exactamente el desafío más difícil. Al fin y al cabo, las herramientas de Infrastructure as Code hicieron el provisionamiento relativamente simple: cualquier equipo puede declarar infraestructura, abrir un pull request y poner nuevos recursos en producción rápidamente.

Sin embargo, a medida que las plataformas crecen, las databases se multiplican, los productos evolucionan y los squads cambian de estructura, comienzan a surgir recursos sin un contexto claro. Algunos siguen activos, consumiendo capacidad, pero nadie sabe exactamente para qué sirven. Otros incluso tienen algún historial conocido, pero ya perdieron el vínculo con los equipos que originalmente los crearon. 

En muchos casos, existe un costo operativo y financiero asociado a recursos que ya nadie monitorea activamente. En Nubank, categorizamos este escenario en tres patrones principales:

  • Los “zombis” son recursos activos en producción cuyo propósito ya no se conoce. Siguen ejecutándose, consumiendo capacidad y potencialmente almacenando datos importantes, pero nadie sabe exactamente qué sistema depende de ellos.
  • Los “huérfanos” aún tienen algún contexto identificable, pero ya perdieron cualquier ownership claro. Existe una idea de lo que hacen, pero no hay un equipo asumiendo responsabilidad sobre ellos.
  • Y existe además una tercera capa: recursos sin un centro de costo claramente asociado, lo que dificulta la gobernanza financiera y la planificación de capacidad.

El problema, por lo tanto, era garantizar una visibilidad continua sobre el ciclo de vida de esos recursos.

Descubre las oportunidades

El ownership como parte de la arquitectura

La solución comenzó por un cambio cultural importante: pasamos a exigir ownership para que nuevas infraestructuras pudieran existir.

En Nubank, cualquier equipo puede provisionar databases usando infraestructura declarativa, pero ningún recurso sube sin información obligatoria de ownership. Obligatoriamente, todo pull request necesita declarar:

  • el nombre del recurso;
  • el equipo responsable;
  • el owner;
  • y la configuración deseada para ese entorno.

Cuando el ownership deja de ser una convención informal y pasa a ser un requisito estructural del provisionamiento, la infraestructura deja de ser responsabilidad exclusiva del equipo de plataforma. El equipo que crea el recurso también se vuelve responsable de entender cómo crece el recurso, cuánto consume, qué métricas importan y cuándo debería dejar de existir.

Esto crea un modelo más sostenible de escalabilidad, porque la responsabilidad operativa se distribuye entre los propios equipos de producto.

El papel de la plataforma, entonces, pasa a exigir menos operación manual y más construcción de sistemas capaces de automatizar la gobernanza, la visibilidad y el lifecycle management.

Un ecosistema diseñado para la automatización

Este modelo funciona porque existe una capa fuerte de automatización sosteniendo todo el ciclo de vida de la infraestructura.

Este proceso comienza en un repositorio declarativo llamado Nimbus, en el cual los equipos describen los recursos que desean provisionar.

A partir de ahí, entra un sistema interno apodado “Sorting Hat”. Su función es decidir automáticamente dónde debe asignarse cada recurso dentro de la infraestructura de la empresa.

Esta decisión considera múltiples reglas, como la afinidad entre workloads, la capacidad disponible, los límites de cuentas, la distribución de recursos, las reglas corporativas y las necesidades futuras de escalabilidad.

Después de la asignación, otro componente llamado Penseira pasa a rastrear continuamente esos recursos. Su papel es mantener un inventario vivo de la infraestructura y acompañar no solo lo que fue declarado, sino lo que realmente sigue activo.

Esta distinción se volvió importante porque el equipo percibió que “infraestructura provisionada” e “infraestructura utilizada” eran cosas completamente diferentes. En este contexto, no todo recurso creado sigue ejerciendo su función real con el paso del tiempo.

Cuando el lifecycle management se vuelve parte de la plataforma

Con ownership distribuido y observabilidad continua implementados, el siguiente paso fue automatizar decisiones relacionadas con el ciclo de vida de los recursos.

Fue así como surgieron sistemas internos orientados específicamente a la detección, el archivado y la eliminación segura de bases de datos inactivas.

El primero de ellos recibió el nombre de Memento Mori: un sistema que cruza métricas operativas, datos de inventario, ownership y señales reales de uso para identificar recursos potencialmente inactivos. Monitorea lectura, escritura, tráfico, operaciones de entrada y salida de datos e incluso cambios organizacionales en los equipos responsables de los recursos.

Cuando una database parece abandonada, el sistema comienza a notificar automáticamente a las personas responsables vía Slack.

El verdadero objetivo, sin embargo, es reforzar la responsabilidad operativa. El equipo responsable recibe contexto, métricas y evidencias suficientes para decidir conscientemente qué hacer.

Hoy, la tasa de aprobación de archivado de esos recursos ronda el 89%.

Automatizar la eliminación exige automatizar la seguridad

Detectar recursos inactivos era solo la mitad del problema. La otra mitad era garantizar que la eliminación ocurriera sin riesgo operativo ni regulatorio, y aquí es donde entra otro sistema interno: Reducto.

El proceso de eliminación implica mucho más que simplemente borrar databases. Como Nubank opera en múltiples países y en un entorno altamente regulado, distintas reglas de retención deben respetarse según la localidad y el tipo de producto.

En Brasil, por ejemplo, determinados backups deben permanecer almacenados hasta por diez años. En Colombia, las exigencias son diferentes. Y en México, a su vez, los períodos varían según el producto financiero involucrado.

Cuando entra en acción, Reducto automatiza todo ese flujo, ocupándose del:

  • archivado;
  • creación de backups;
  • retención;
  • validación;
  • y eliminación segura.

Incluso después del archivado, existe aún una ventana de seguridad de aproximadamente 35 días antes de la eliminación definitiva del recurso. Esto evita problemas con workloads esporádicos o sistemas ejecutados con baja frecuencia.

Otro punto crítico es la validación continua de los backups, porque existe una premisa importante en este proceso: un backup sin restore no es un backup. Por eso, los flujos incluyen pruebas frecuentes de recuperación para garantizar que los datos realmente puedan restaurarse si es necesario.

El resultado es un ciclo altamente automatizado que no renuncia a la seguridad operativa. Desde la implementación completa de este proceso, no registramos incidentes relacionados con eliminaciones automatizadas.

Escalar infraestructura es escalar responsabilidad

Cuando las plataformas crecen rápidamente, el desafío pasa a ser mantener el contexto operativo sobre miles de componentes distribuidos entre diferentes productos, equipos y requisitos regulatorios. Sin visibilidad continua, ownership claro y un lifecycle management consistente, la infraestructura inevitablemente acumula complejidad invisible.

La combinación entre infraestructura declarativa, automatización y ownership distribuido permitió que Nu creara un entorno donde miles de bases de datos pueden gestionarse con un alto grado de confiabilidad sin depender de burocracia ni de operación manual constante. En lugar de ampliar indefinidamente el equipo responsable de la plataforma, el foco pasó a ser construir sistemas capaces de distribuir la responsabilidad de forma segura y observable entre toda la ingeniería.

Este modelo también cambia la relación entre los equipos de producto y la infraestructura. Cuando el ownership pasa a existir directamente en el provisionamiento, en las métricas y en las decisiones automatizadas de la plataforma, la infraestructura se vuelve más sostenible a escala. 

Al final, el desafío de operar más de 21 mil databases no se resolvió con más control centralizado, sino creando mecanismos que vuelven la responsabilidad y la gobernanza una parte natural del propio sistema. 

Descubre las oportunidades