Ingeniería de plataformas y plataformas internas para desarrolladores

El problema que resuelven las plataformas

En 2006, el director de tecnología de Amazon, Werner Vogels, resumió el modelo operativo de su empresa como tú lo construyes, tú lo operas (you build it, you run it): el equipo que escribe un servicio también lo despliega, lo monitoriza y lo corrige. La idea pasó a ser central en DevOps y en los microservicios, y funciona: los equipos que operan su propio software sienten las consecuencias de sus decisiones de diseño y las corrigen. Pero el conjunto de herramientas nativas de la nube descrito en este capítulo es amplio. Un equipo de producto que hoy deba construir, operar y proteger un servicio puede necesitar entender imágenes de contenedor, objetos de Kubernetes, infraestructura como código, pipelines, observabilidad, gestión de secretos, políticas de red, análisis de la cadena de suministro y controles de costos, antes de escribir una sola línea de lógica de negocio.

Cuando cada equipo resuelve todo esto por su cuenta, ocurren tres cosas. El esfuerzo se duplica, porque diez equipos escriben diez pipelines ligeramente distintos. La calidad varía, porque algunos equipos cifran sus bases de datos y configuran copias de seguridad y otros lo olvidan. Y el tiempo que los equipos de producto dedican a la infraestructura es tiempo que no dedican al producto. La ingeniería de plataformas es la respuesta: un equipo dedicado construye una plataforma interna para desarrolladores (IDP) que empaqueta estas capacidades para que los equipos de producto puedan usarlas mediante autoservicio.

El artículo de Evan Bottcher de 2018 en martinfowler.com ofrece una descripción muy citada: una plataforma digital es una base de API, herramientas, servicios, conocimiento y soporte de autoservicio, organizada como un producto interno atractivo. Cada parte de esa descripción importa. Autoservicio significa que no hay tickets para las necesidades rutinarias. Conocimiento y soporte significa documentación y personas, no solo software. Atractivo significa que los equipos eligen usarla porque es mejor que hacer el trabajo ellos mismos. Producto interno significa que se gestiona como un producto, con clientes, y no como un proyecto o un centro de costos.

Una IDP no es un único producto. Suele ser una integración de herramientas existentes (un sistema de CI, un controlador de GitOps, los servicios gestionados de un proveedor de nube, una pila de observabilidad, un almacén de secretos) detrás de interfaces coherentes y valores predeterminados razonables. El trabajo distintivo del equipo de plataforma es elegirlas, integrarlas, documentarlas y darles soporte, y diseñar la experiencia de usarlas, no escribir un nuevo orquestador.

Caminos dorados y caminos pavimentados

Lo más valioso que puede ofrecer una plataforma joven es un camino dorado (golden path): una forma opinada, respaldada y documentada de realizar de extremo a extremo una tarea habitual, como crear un servicio nuevo y llevarlo a producción. Spotify popularizó el término (su blog de ingeniería describió sus caminos dorados en 2020); Netflix habla del camino pavimentado (paved road). La metáfora es precisa. Un camino pavimentado es la ruta más fácil, y se mantiene, pero aún puedes salirte de él y circular campo a través si tienes una buena razón; simplemente no cuentas con el soporte del camino.

Un buen camino dorado tiene cinco propiedades. Es de extremo a extremo: lleva a un equipo desde un repositorio vacío hasta un servicio monitorizado en producción, no solo a través de un paso. Es opinado: toma las decisiones comunes (versiones del lenguaje, formato de logging, estrategia de despliegue, valores predeterminados de la base de datos) para que los equipos no tengan que tomarlas. Es opcional: los equipos con necesidades poco habituales pueden abandonarlo, lo que obliga al equipo de plataforma a ser honesto sobre si el camino es realmente mejor. Está respaldado: cuando falla, el equipo de plataforma lo arregla. Y está en evolución: los servicios creados a partir de la plantilla del año pasado reciben actualizaciones, en lugar de quedarse congelados en la versión con la que empezaron.

Backstage y los portales para desarrolladores

Un portal para desarrolladores es la puerta de entrada de muchas plataformas. El más conocido es Backstage, creado dentro de Spotify, publicado como código abierto en marzo de 2020, aceptado por la Cloud Native Computing Foundation (CNCF) como proyecto sandbox en septiembre de 2020 y promovido a incubación en marzo de 2022. Sus funciones principales son un catálogo de software, en el que cada servicio, sitio web, biblioteca, API y recurso se registra con su responsable y sus relaciones; las plantillas de software, que generan proyectos nuevos a partir de plantillas de caminos dorados; TechDocs, que publica la documentación escrita en Markdown junto al código; y un amplio ecosistema de plugins que muestran pipelines, el estado de Kubernetes, los costos y los incidentes junto a cada entrada del catálogo.

Cada componente se describe a sí mismo en un pequeño archivo guardado en su propio repositorio, de modo que la información sobre su responsable vive con el código y se revisa como código:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: restaurant-ratings
  description: Stores and serves customer ratings of restaurants
  tags: [python, http]
spec:
  type: service
  lifecycle: production
  owner: team-restaurants
  system: restaurant-discovery
  providesApis: [ratings-api]
  dependsOn: [resource:ratings-db]

Dos advertencias. Backstage es un framework que una organización ensambla y opera, y que normalmente requiere ingenieros que conozcan TypeScript y React; además, la calidad de sus plugins es variable. Existen servicios de Backstage gestionados y portales comerciales para los equipos que no quieren operarlo. Y, sobre todo, un portal no es una plataforma. Un portal precioso delante de procesos manuales basados en tickets solo muestra la cola de forma más atractiva. Empieza por las capacidades y el camino dorado; añade un portal cuando haya detrás lo suficiente como para que merezca la pena encontrarlo.

La plataforma como producto

La idea más importante de la ingeniería de plataformas es que la plataforma es un producto y los desarrolladores que la usan son sus clientes. Eso implica un gerente de producto o un líder de plataforma que sea dueño de la hoja de ruta; investigación de usuarios (entrevistas, observar a un equipo mientras crea un servicio, encuestas) antes de construir; documentación e incorporación tratadas como funcionalidades; objetivos de nivel de servicio publicados para la propia plataforma; políticas de versionado y de retirada para que los equipos puedan planificar; y, sobre todo, una adopción que se gane en lugar de imponerse. Si los equipos evitan la plataforma, eso es una señal del mercado, no insubordinación.

Team Topologies (Matthew Skelton y Manuel Pais, 2019), tratado en la sección 11.5, aporta el modelo organizativo. Un equipo de plataforma existe para reducir la carga de los equipos alineados al flujo, los que están alineados con un flujo de cambio del negocio, como los pedidos o el despacho de repartidores, e interactúa con ellos principalmente en modo X como servicio (X-as-a-Service): una oferta clara y de autoservicio que requiere poca colaboración. El modo de colaboración se usa de forma deliberada y breve, por ejemplo al diseñar una capacidad nueva con uno o dos equipos pioneros. Skelton y Pais también acuñaron la plataforma viable más delgada (thinnest viable platform): la plataforma más pequeña que ayuda de verdad, que para una organización pequeña puede ser una página wiki bien escrita con los servicios aprobados y una plantilla de pipeline compartida.

Esto también significa que la plataforma debe hacer que la ley de Conway juegue a su favor: las interfaces de la plataforma se convierten en los límites entre el equipo de plataforma y cada equipo de producto, así que deben ser estables, documentadas y estrechas, como cualquier buena abstracción.

Autoservicio con guardrails

El autoservicio elimina la cola; los guardrails (salvaguardas) lo mantienen seguro. La diferencia con los controles tradicionales está en dónde se produce la comprobación. Una compuerta (gate) es una persona que debe aprobar una solicitud, como un comité asesor de cambios o un administrador de bases de datos que revisa un ticket. Un guardrail es un límite automático que deja pasar todo lo que cumple la política y bloquea o señala lo que no, en el momento de la solicitud. Los guardrails suelen escribirse como política como código (presentada en la sección 10.4) y se aplican en los pipelines, en los controladores de admisión y en las políticas de organización de la nube.

Los buenos guardrails comparten tres propiedades: dan un mensaje claro que explica qué se ha bloqueado y cómo corregirlo; se versionan y se prueban como código, con un periodo de avisos antes de que una regla nueva empiece a bloquear; y vienen con una vía documentada para las excepciones justificadas, porque un guardrail sin vía de excepción vuelve a convertirse en una compuerta la primera vez que se equivoca.

Reducir la carga cognitiva, no ocultarlo todo

Team Topologies toma la idea de carga cognitiva de la investigación educativa de John Sweller y distingue tres tipos. La carga intrínseca es inherente a la tarea, como entender cómo funcionan las tarifas de reparto. La carga extrínseca procede del entorno, como recordar los doce pasos para solicitar una base de datos. La carga pertinente (germane) es el esfuerzo de aprendizaje que facilita el trabajo futuro, como entender el dominio con más profundidad. Una plataforma debe eliminar la carga extrínseca para que los equipos puedan dedicar su atención limitada a la carga intrínseca y la pertinente de su propio dominio.

Eso no significa ocultarlo todo. Un equipo que opera su servicio sigue necesitando entender cómo se comporta en producción: su uso de recursos, sus modos de fallo, su latencia y sus costos. Las abstracciones que ocultan demasiado tienen fugas en el peor momento, durante un incidente, cuando el equipo descubre que no puede ver los logs o no sabe en qué nivel de base de datos está. Las buenas plataformas son transparentes: proporcionan valores predeterminados razonables e interfaces sencillas, y a la vez permiten a los equipos mirar por debajo y sustituir esos valores cuando lo necesitan.

Medir si la plataforma funciona

El valor de una plataforma se refleja en los resultados de otros equipos, así que sus medidas deben mirar ahí. Las medidas útiles se agrupan en cuatro grupos, y un conjunto equilibrado toma al menos una de cada uno.

El marco SPACE, publicado en ACM Queue en 2021 por Nicole Forsgren, Margaret-Anne Storey y colegas de GitHub, Microsoft Research y la Universidad de Victoria, advierte que la productividad de los desarrolladores no puede capturarse con un único número. Nombra cinco dimensiones: satisfacción y bienestar, desempeño, actividad, comunicación y colaboración, y eficiencia y flujo. Recomienda medir varias dimensiones a la vez, incluida al menos una medida de percepción, como una encuesta, y no juzgar nunca a las personas por recuentos de actividad como los commits o las líneas de código.

Las pruebas sobre las plataformas son alentadoras, pero no incondicionales. El informe Accelerate State of DevOps de DORA de 2024 concluyó que los usuarios de plataformas internas para desarrolladores declaraban una productividad individual alrededor de un 8% mayor y un desempeño del equipo un 10% mayor, pero el rendimiento (throughput) de entrega de software y la estabilidad de los cambios eran un 8% y un 14% menores. El informe ofrece posibles explicaciones, como los traspasos adicionales y los pasos que añade la propia capa de plataforma, y la lección para los arquitectos es medir los resultados de entrega además de la satisfacción, y esperar un bajón mientras la plataforma madura.

Riesgos y modos de fallo

Las iniciativas de plataforma fracasan de maneras reconocibles. La más común es construir una plataforma que nadie quiere: un equipo pasa un año construyendo una ambiciosa plataforma de uso general, la lanza y descubre que los equipos de producto ya tienen soluciones que funcionan y no tienen tiempo para migrar. Empezar con algo delgado, con usuarios reales y un único camino dorado, es el antídoto. La segunda es el equipo de operaciones con otro nombre: a un equipo de infraestructura se le cambia la etiqueta a equipo de plataforma, pero sigue trabajando con una cola de tickets, de modo que no cambia nada salvo los cargos. Si las solicitudes rutinarias siguen necesitando un ticket y una persona, todavía no es una plataforma.

Otros riesgos son imponer la adopción, lo que elimina la retroalimentación que mantiene útil una plataforma; el exceso de abstracción, en el que una capa de desarrollo propio oculta tan completamente las herramientas subyacentes que los equipos no pueden depurarla ni ampliarla y el equipo de plataforma se convierte en un cuello de botella para cada cambio; descuidar la larga cola de servicios creados a partir de plantillas antiguas; y que la plataforma se convierta en un punto único de fallo cuya caída detiene todos los despliegues. Por el contrario, una organización pequeña puede no necesitar ningún equipo de plataforma: unas pocas plantillas compartidas mantenidas por voluntarios pueden ser la plataforma viable más delgada durante años.