Cerramos el Capítulo 31 (y la Parte VII) con la idea que ata todo el Platform Engineering: tratar los módulos de Terraform como un producto interno. A lo largo del libro hemos visto los módulos como bloques técnicos reutilizables (Capítulo 18). Ahora damos el salto de mentalidad que distingue a las organizaciones más maduras: dejar de ver los módulos como «código que comparto» y empezar a verlos como un producto con clientes (los demás desarrolladores), que se diseña, cuida y mejora pensando en ellos. Este cambio de mentalidad es la esencia del Platform Engineering.

Recuerda los módulos de Terraform (Capítulo 18): paquetes reutilizables de infraestructura que defines una vez y usas muchas. Vimos su anatomía (subcapítulo 18.1), sus variables y outputs (subcapítulo 18.2), su versionado con Git tags (subcapítulo 18.4)... Técnicamente, ya sabes crearlos. Lo que añade este subcapítulo no es técnica, sino mentalidad: cómo pensar en esos módulos cuando son la base de una plataforma que usan muchos equipos.

La diferencia clave entre una organización inmadura y una madura está en cómo trata sus módulos:

Tratar los módulos como un producto interno significa aplicarles la misma mentalidad que se aplica a un producto que vendes a clientes: pensar en la experiencia de quien lo usa, cuidar la calidad, documentarlo bien, darle soporte y mejorarlo continuamente. Tus «clientes» son los demás desarrolladores de la empresa.

Analogía: la diferencia es como entre dejar herramientas tiradas en un cobertal común y gestionar una buena ferretería. En el cobertal, cada uno tira sus herramientas; las encuentras como puedes, no sabes si funcionan, nadie las mantiene. En una ferretería bien gestionada, los productos están organizados, etiquetados, con instrucciones, alguien se asegura de que funcionen y de tener lo que la gente necesita, y te atienden si tienes dudas. Tratar los módulos como producto es pasar del cobertal a la ferretería: pensar de verdad en quien va a usarlos.

El módulo debe ser fácil de usar para alguien que no es experto: parámetros claros, valores por defecto sensatos, una interfaz sencilla. Te pones en la piel de quien lo va a usar y le facilitas la vida. Un buen golden path (subcapítulo 31.1) nace de un módulo diseñado pensando en su usuario.

El módulo viene con documentación clara: qué hace, cómo se usa, ejemplos. Sin buena documentación, un módulo es difícil de adoptar (recuerda lo importante que es la documentación, ya lo vimos con los módulos en la Parte IV). Un producto sin manual no se vende.

Recuerda el versionado (subcapítulo 18.4): los módulos-producto se versionan con cuidado, de modo que los cambios no rompan a quien los usa por sorpresa. Si vas a hacer un cambio importante, lo comunicas y lo gestionas como una nueva versión, igual que un producto serio gestiona sus actualizaciones. Esto da confianza a los equipos para depender de tus módulos.

Los módulos-producto se prueban (recuerda el testing de infraestructura, Capítulo 21, y el contract testing de módulos, subcapítulo 21.4) para garantizar que funcionan bien. Un producto de calidad es fiable; si tus módulos fallan, los equipos pierden la confianza y vuelven a hacerlo todo por su cuenta.

Hay alguien (el equipo de plataforma) que da soporte a los usuarios del módulo y recoge su feedback para mejorarlo. Como un producto, evoluciona escuchando a sus usuarios: qué les falta, qué les cuesta, qué necesitan.

Este cambio de mentalidad es, en realidad, el corazón de todo el Platform Engineering (Capítulo 31). Una Internal Developer Platform no es solo «herramientas»; es un producto interno que el equipo de plataforma ofrece a los desarrolladores como si fueran sus clientes. Los golden paths (subcapítulo 31.1), el Service Catalog (subcapítulo 31.2) y Backstage (subcapítulo 31.3) solo funcionan de verdad si detrás hay esta mentalidad de producto: cuidar la experiencia, la calidad y la mejora continua.

Sin esta mentalidad, una plataforma interna se convierte en otro montón de herramientas que nadie quiere usar. Con ella, se convierte en algo que los equipos adoptan encantados porque de verdad les facilita el trabajo.

Ejemplo del mundo real: dos empresas crean módulos de Terraform para sus equipos. La primera los trata como «código compartido»: los sube a un repositorio sin documentación, los cambia sin avisar (rompiendo a otros equipos) y nadie da soporte. Resultado: los equipos no se fían de esos módulos, prefieren hacer su propia infraestructura, y la plataforma fracasa. La segunda empresa los trata como producto interno: cada módulo está bien documentado con ejemplos, versionado con cuidado (los cambios nunca rompen por sorpresa), probado, y el equipo de plataforma da soporte y recoge feedback para mejorarlos. Resultado: los equipos adoptan los módulos encantados porque les ahorran trabajo y son fiables; la plataforma triunfa, y la empresa gana velocidad y consistencia. La misma técnica (módulos), pero la mentalidad de producto marcó la diferencia entre el éxito y el fracaso.

• El salto de las organizaciones maduras no es técnico, sino de mentalidad: tratar los módulos de Terraform como un producto interno, no como simple «código compartido». Tus clientes son los demás desarrolladores.
• Es la diferencia entre herramientas tiradas en un cobertal y una ferretería bien gestionada (organizada, con instrucciones, mantenida, con atención al cliente).
• Tratar los módulos como producto implica: pensar en la experiencia del usuario (fáciles de usar), documentación de calidad (con ejemplos), versionado cuidado (cambios sin romper, con confianza, Cap. 18.4), calidad y testing (fiables, Cap. 21), y soporte + feedback (mejora continua escuchando al usuario).
• Esta mentalidad de producto es el corazón del Platform Engineering: una Internal Developer Platform (con sus golden paths, Service Catalog y Backstage) solo triunfa si se trata como un producto cuidado para sus clientes. Sin ella, la plataforma fracasa; con ella, los equipos la adoptan encantados.

¡Has completado el Capítulo 31 y, con él, toda la Parte VII (Arquitecturas de referencia y patrones expertos)! Has alcanzado un nivel de madurez que pocos dominan: Well-Architected, serverless a escala, plataformas de datos, multi-cuenta y Platform Engineering. Ya solo queda la Parte VIII: El camino después del libro, que te guiará en tu desarrollo profesional. Empezamos en el Capítulo 32 con las certificaciones de AWS.