Detrás de escena con Lakebase, parte 3

En la primera parte de esta serie, ejecutar Backstage en Databricks Lakebase nos ofreció la ramificación de bases de datos en un segundo. Por su parte, en la segunda parte, Unity Catalog absorbió esa base de datos operativa en el plano de gobernanza empresarial.

Pero aquí está el beneficio que realmente transforma la estructura de la organización.

En un stack normal, responder a '¿quién es el propietario de la infraestructura que eleva nuestro gasto en la nube y cuánto costó?' cruza dos fronteras. El gráfico de propiedad reside en Backstage (gestionado por ingeniería de plataformas), mientras que los datos de costos residen en un data warehouse (gobernado por el equipo de datos). Responder a esta pregunta requiere una canalización ETL, un ticket de Jira o un hilo de Slack.

La separación del cómputo hace viable el uso compartido

La razón por la que un analista de FinOps puede ejecutar consultas analíticas masivas contra el mismo almacenamiento subyacente sin afectar al portal activo es que Lakebase aísla el cómputo por carga de trabajo.

Backstage obtiene su propio entorno de cómputo aislado y con escalado automático. Durante el uso normal del portal, las consultas del catálogo se ejecutaron en 55-65 ms de extremo a extremo, y las búsquedas tardaron de dos a cuatro milisegundos. Dado que su aplicación web y sus cargas de trabajo analíticas no compiten por el mismo clúster de cómputo, finalmente pueden compartir de forma segura el mismo sustrato de datos.

La solución alternativa: autenticación de Lakehouse Federation

Para unir los datos en vivo de Postgres con nuestros datos analíticos de facturación, utilizamos Databricks Lakehouse Federation. Sin embargo, el conector de Postgres de Lakehouse Federation actualmente solo admite credenciales estáticas de usuario y contraseña. Dado que Lakebase autentica las identidades de las aplicaciones a través de JWT de OAuth, el motor de federación necesita una ruta de autenticación paralela.

La solución alternativa consiste en crear un rol nativo de Postgres con autenticación SCRAM-SHA-256, conectado a la federación de forma independiente de la identidad de OAuth que utiliza la aplicación:

Ahora está gestionando dos rutas de autenticación para la misma base de datos.

La unión de FinOps

Con el catálogo externo activo, un analista de FinOps puede escribir una sola consulta que extraiga el nombre del recurso de Backstage directamente de la tabla operativa de Postgres y lo una con las propias filas de facturación de Lakebase en system.billing.usage:

Resultado real:

El lado izquierdo de esa fila proviene directamente del catálogo activo de Postgres en Backstage; el lado derecho proviene de una tabla de facturación del sistema de Unity Catalog. Históricamente, estas dos cosas nunca han estado en el mismo motor SQL, y ahora se unen con cero movimiento de datos.

¿Por qué no usar simplemente ETL?

Un escéptico podría preguntar por qué no usamos simplemente un script de Python para sincronizar una instancia de RDS con una tabla Delta una vez por hora.

La respuesta es la ramificación. Cuando un desarrollador crea un clon de base de datos efímero en un segundo para probar un PR, tendría que aprovisionar dinámicamente nuevas canalizaciones ETL solo para obtener visibilidad de costos en ese entorno de prueba temporal. Con Lakebase, en el momento en que se crea la rama, sus datos de facturación y propiedad se pueden consultar de inmediato. (En esta POC, la rama de prueba eliminada recibió de forma automática e independiente la atribución de 0.0107 DBU).

Operacionalizar la convergencia

Esta serie de tres partes comenzó con una rama de base de datos de un segundo, pasó por la gobernanza unificada y llegó hasta aquí: una sola consulta SQL que une los datos de propiedad operativa con los datos de facturación en la nube sin canalizaciones entre ellos. Esa es la prueba de que la convergencia funciona técnicamente. La pregunta que los profesionales se harán a continuación es: ¿qué se necesita para operacionalizar esto?

De esta POC surgieron dos aspectos destacados que vale la pena mencionar para los equipos que planean seguir este camino.

La brecha de autenticación de la federación

La solución alternativa de Lakehouse Federation que describimos (un rol nativo de Postgres con credenciales estáticas conectado de forma independiente de la identidad de OAuth que utiliza la aplicación) es el enfoque correcto hoy en día. Cada equipo que desee unir sus datos operativos de Lakebase con tablas analíticas en Unity Catalog deberá configurar esta ruta de autenticación paralela. De todos modos, la federación probablemente no debería ejecutarse como el usuario de su aplicación, por lo que la separación tiene una ventaja de seguridad, pero la rotación de contraseñas depende de usted. Para los equipos que adopten este patrón, los pasos se pueden empaquetar en un script reutilizable: generar una contraseña segura, crear el rol con permisos de solo lectura, conectar la conexión, crear el catálogo externo. Configuración única, solo unos minutos una vez que se conoce el patrón. El soporte nativo para JWT de OAuth en la federación eliminaría por completo esta solución alternativa.

Visibilidad del costo de las ramas para los equipos de desarrollo

La unión de FinOps responde a la pregunta de la plataforma: ¿cuánto cuesta esta infraestructura y quién es su propietario? Pero los mismos datos de facturación cuentan una segunda historia que les importa a los gerentes de ingeniería: ¿cuánto cuesta el proceso de desarrollo en sí?

En el flujo de trabajo de ramificación de la primera parte, cada pull request crea una rama de CI efímera y cada desarrollador tiene su propia rama de características. Estas aparecen como elementos de línea independientes en system.billing.usage, desglosados por branch_id y endpoint_id. Un gerente de ingeniería puede ver exactamente cuánto cómputo consumió la ramificación de desarrollo/prueba de su equipo en un sprint en comparación con la producción, y tomar decisiones informadas sobre las políticas de ciclo de vida de las ramas.

La clave es que las ramas efímeras también deben tratarse como efímeras en los datos de facturación. Las ramas de CI creadas con un TTL corto expiran automáticamente si la limpieza falla por cualquier motivo: un push directo a main, un error de flujo de trabajo o un evento omitido. Sin controles de ciclo de vida, las ramas huérfanas pueden acumularse silenciosamente, cada una con un endpoint de cómputo activo que factura al proyecto. La rama de prueba costó 0.0107 DBU. Eso es insignificante. Treinta ramas huérfanas ejecutándose durante un mes no lo son.

El punto no es que la ramificación sea costosa; se trata de una ganancia de costo frente a productividad. Cuando un equipo elimina dos días de tiempo de espera del entorno por sprint y deja de mantener entre el 20 y el 30 % de su base de código en objetos simulados, los 0.0107 DBU por rama no son un elemento de línea que deba gestionarse: es la inversión en productividad más barata que el equipo haya realizado jamás. Y a diferencia de la mayoría de las inversiones en productividad, esta es medible: la infraestructura le indica exactamente cuánto costó, por rama, por desarrollador y por sprint. Esa es una conversación que la mayoría de los equipos de ingeniería nunca han podido tener con su base de datos.

Qué viene a continuación

Antes de terminar, hay un punto más en la historia de FinOps que vale la pena destacar. Los endpoints de Lakebase se escalan a cero. Cuando no se realizan consultas en una rama, su cómputo se suspende y la facturación se detiene. La cifra de 0.0107 DBU es el costo de una rama que se ejecutó, no el costo de una rama que existe; una flota de ramas efímeras inactivas entre ejecuciones de prueba no aporta ningún costo.

A lo largo de esta serie, demostramos que la infraestructura funciona: una aplicación real, benchmarks reales, gobernanza real y datos de costos reales. Por nuestra parte, Databricks y Thoughtworks están trabajando de la mano para llevar esto de una POC a la práctica: equipos de desarrollo reales, sprints reales y mediciones de velocidad reales. La limitación que mantuvo a los datos operativos y analíticos en mundos separados durante treinta años se está disolviendo.

Hay una conclusión clave para el lunes por la mañana en cada entrega de esta serie. Cree una rama para su próxima migración en un esquema real. Reescriba una suite con muchos mocks en una rama. Combine sus datos de facturación con su gráfico de propiedad. Los equipos que den el primer paso definirán lo que viene a continuación.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original