Airframe en diez minutos

Airframe es una forma de operar infraestructura en la nube para muchos equipos de producto en la que nadie construye nada a mano en una consola y nadie tiene acceso de administrador permanente. Un equipo describe lo que quiere en archivos, reglas escritas como código revisan cada cambio, y los pipelines hacen el trabajo. Esta página sigue a un producto durante toda su vida, desde el día en que un equipo lo pide hasta el día en que se elimina.

Los ejemplos vienen de una organización de demostración, una tienda en línea ficticia, y de su producto de pedidos. Las palabras en negrita son las que explica el glosario.

1. Un equipo quiere un producto nuevo

En muchas empresas, un equipo que necesita un servicio nuevo llena un formulario o abre un ticket, y espera mientras alguien crea a mano los proyectos en la nube, un repositorio de código, las reglas de red y los paneles. Cada uno de esos pasos es una oportunidad para un error, y después nadie puede ver con facilidad por qué las cosas quedaron configuradas así.

En Airframe nadie hace esos pasos a mano. El equipo lo pide cambiando un archivo, y la plataforma hace el resto.

2. Escribe un archivo en el catálogo

El catálogo es un repositorio git de pequeños archivos YAML que describen la organización: cómo divide su trabajo en recorridos, dominios y contextos, qué equipos y personas existen, y qué productos tienen a su cargo.

Para crear el producto de pedidos, el equipo agrega un archivo, products/shop.store.ordering.orders.yaml. Dice qué equipo es dueño del producto, qué pila usa (Java, Node o Python), qué tan crítico es, qué tan rápido debe recuperarse de una falla, y su presupuesto mensual en dólares estadounidenses. Ese archivo es todo el pedido.

3. Las reglas lo revisan y los responsables lo aprueban

El archivo nuevo llega como un merge request, como todo cambio en Airframe. El pipeline del catálogo lo revisa contra el esquema del catálogo y sus reglas de coherencia, por ejemplo, que el equipo dueño pertenezca de verdad al contexto del producto.

Después, las personas aprueban para qué es el cambio. El propio catálogo dice quién es responsable de qué: un producto nuevo lo aprueba su equipo o los líderes de su contexto o de su dominio. Un servicio llamado la compuerta de aprobación lee esas reglas de propiedad y aprueba el merge request solo cuando las personas correctas ya lo aprobaron. La aprobación del propio autor nunca cuenta.

4. Los pipelines construyen todo

Después del merge, el pipeline del catálogo inicia una cadena de reconciliadores: trabajos automáticos que leen el catálogo y hacen que el mundo real coincida con él. Entre todos crean:

• dos proyectos de Google Cloud para el producto, uno de producción y otro para todo lo demás, cada uno con sus propias identidades de pipeline;
• un repositorio de código, generado desde la plantilla del golden path para la pila elegida;
• paneles para el servicio del producto, sus objetivos de confiabilidad y su costo;
• un nombre de host detrás de inicio de sesión único, una vez que el primer pipeline del producto lo desplegó.

Los paneles viven en un único stack de Grafana Cloud, adonde también llegan los registros, las métricas y las trazas del producto; observabilidad sigue ese camino.

Una nota en el merge request ya integrado sigue la cadena mientras avanza, para que el equipo vea cómo se construye su producto. Un paso queda aparte a propósito: un producto nuevo solo funciona cuando sus proyectos se vinculan a la facturación, lo que es su propio merge request en el repositorio landing-zone.

5. El equipo cambia su producto con merge requests

Desde ese momento, el equipo trabaja en su propio repositorio, que contiene la aplicación, su infraestructura como código Terraform y su pipeline. Cada cambio es un merge request, y cada merge request pasa por los mismos pasos:

• trabajos que el equipo no puede quitar revisan el cambio, entre ellos el paquete de políticas: reglas probadas que rechazan, por ejemplo, un bucket de almacenamiento abierto a internet;
• los responsables del producto lo aprueban, y después la compuerta de aprobación también;
• el ejecutor, un pipeline de confianza que la compuerta inicia en el runner de confianza de la plataforma, planifica el cambio con las identidades propias del producto: calcula exactamente qué haría el cambio en la nube y cuánto costaría cada mes;
• el ejecutor también despliega una vista previa del cambio, una copia de corta duración del producto en su propio nombre de host, para que quienes revisan la prueben antes del merge;
• una verificación mantiene cerrado el merge mientras ese costo supere el presupuesto del producto.

Una vez integrado, el pipeline de la rama principal aplica el cambio. Nadie ejecuta un comando contra la nube desde una laptop. El merge también publica la página del producto en el catálogo de arquitectura, un mapa de cada producto, sus eventos y sus responsables.

6. Nadie tiene acceso de escritura permanente

Las cuentas de uso diario de las personas pueden ver la infraestructura de producción, pero no cambiarla; la única excepción, muy acotada, es agregar una versión nueva de uno de los secretos de su producto. Los pipelines reciben identidades de corta duración mediante la federación de identidades de carga de trabajo: un trabajo demuestra a qué repositorio pertenece, en qué entorno despliega y si su rama está protegida, y solo el trabajo correcto recibe la identidad correcta.

Cuando una persona de verdad necesita cambiar algo a mano, pide una concesión de Privileged Access Manager: con tiempo limitado, registrada y, para los roles administrativos, aprobada por otro miembro del equipo de plataforma. Nadie puede crear una clave de cuenta de servicio, la contraseña de larga duración de una cuenta de máquina, para ningún proyecto de la organización de demostración.

7. Un agente de código trabaja con los mismos controles

Airframe se diseñó desde el principio con un agente de código como colaborador. Las skills del repositorio platform-skills le enseñan a un agente de código los patrones de la plataforma, y airframe validate ejecuta en una laptop la mayor parte de la validación del merge request, para que un agente de código corrija sus errores antes de abrir un merge request.

Después, el merge request del agente de código pasa exactamente por los mismos controles que el de una persona. La aprobación que permite integrarlo debe venir de una persona con nombre en el catálogo que no escribió el cambio.

8. Cuando el producto se retira, lo dice el mismo archivo

Terminar un producto también es un cambio en su archivo del catálogo. Cambiar su estado a retiring saca sus servicios del borde compartido, así que dejan de responder en sus nombres de host, y los lleva a cero instancias, pero conserva sus datos. Después de la fecha de retiro escrita en la entrada, removed elimina sus proyectos y su repositorio. Cada cambio de estado necesita dos aprobadores además del autor.

El nombre nunca se reutiliza: un producto eliminado deja una lápida en el catálogo, así que un producto nuevo no puede tomar su nombre en el mismo dominio. El producto de pedidos de la organización de demostración está en retiro hoy.

Por dónde seguir

• El glosario define cada término de esta página en una o dos oraciones.
• La sección de Conceptos profundiza un nivel en cada idea: el catálogo, los reconciliadores, las identidades y el acceso, la compuerta de aprobación y el ejecutor, las políticas como código, las versiones de la plataforma, las vistas previas, la observabilidad y el catálogo de arquitectura.
• Cómo funciona sigue paso a paso la vida de un producto y el camino de un cambio, con los tiempos medidos por la propia plataforma.
• Las nueve páginas de “por qué” explican lo que distingue a Airframe, cada una con el mecanismo que lo hace cierto: empieza por autoservicio por merge request y cero privilegios permanentes.