Cerramos la Parte VII con el Capítulo 31: Platform Engineering e Internal Developer Platform, una disciplina muy actual que representa la cima de la madurez en infraestructura. La idea: en vez de que cada equipo de desarrollo tenga que aprender y configurar toda la infraestructura por su cuenta, un equipo especializado construye una plataforma interna que se lo da hecho de forma fácil y segura. Empezamos por el concepto fundamental de esta disciplina: los golden paths (caminos dorados), apoyados en Terraform.

Imagina una empresa con muchos equipos de desarrollo. Cada uno necesita infraestructura: redes, bases de datos, servidores, pipelines... Sin una plataforma común, cada equipo tiene que:

Esto tiene problemas graves: se duplica muchísimo trabajo, cada equipo hace las cosas distinto (inconsistencia), y los desarrolladores —expertos en su aplicación, no necesariamente en infraestructura— pueden cometer errores de seguridad o de diseño. Además, se distraen de lo que de verdad aportan valor: su producto.

Analogía: es como si en una empresa cada empleado tuviera que construirse su propio ordenador, instalar el sistema operativo y configurar la red antes de poder trabajar. Sería un desperdicio enorme de tiempo, cada uno lo haría diferente, y muchos lo harían mal. Lo lógico es que un equipo de IT prepare ordenadores estándar, listos para usar y seguros, y cada empleado se centre en su trabajo. El Platform Engineering aplica esa misma idea a la infraestructura cloud.

El Platform Engineering (ingeniería de plataformas) es la disciplina de construir una plataforma interna que facilita a los equipos de desarrollo crear y gestionar su infraestructura de forma fácil, rápida y segura, sin tener que ser expertos en todos los detalles. Un equipo de plataforma construye «herramientas y caminos» que los demás equipos usan.

El objetivo: que los desarrolladores puedan autoservirse la infraestructura que necesitan (recuerda el self-service de la nube, subcapítulo 1.2) de forma sencilla y segura, centrándose en su producto en lugar de en los detalles de infraestructura.

La pieza central del Platform Engineering es el golden path (camino dorado): una forma recomendada, fácil y bien diseñada de hacer algo, que el equipo de plataforma prepara para que los desarrolladores la sigan. Es el «camino preparado» que lleva a buen resultado sin esfuerzo y sin riesgos.

Un golden path no obliga (los equipos podrían salirse si tienen una necesidad especial), pero es tan fácil y bueno que la mayoría lo sigue encantada. Hace que lo correcto sea también lo más cómodo.

Analogía: un golden path es como un sendero bien señalizado y pavimentado en una montaña. Podrías subir campo a través (hacerlo todo por tu cuenta), pero es difícil, arriesgado y fácil perderse. El sendero dorado está preparado, es seguro y te lleva directo a la cima con el mínimo esfuerzo. La mayoría lo toma porque es, simplemente, la mejor forma de llegar. El equipo de plataforma «pavimenta» esos senderos para las necesidades comunes.

Aquí conecta con todo lo que sabes. Los golden paths de infraestructura se construyen, típicamente, sobre Terraform y módulos (Capítulo 18). El equipo de plataforma crea módulos bien diseñados, seguros y conformes que encapsulan las buenas prácticas, y los ofrece a los desarrolladores como golden paths:

Recuerda los módulos (Capítulo 18) y la idea de módulos como producto interno (que veremos en el subcapítulo 31.4): el equipo de plataforma actúa como un equipo de producto cuyos «clientes» son los demás desarrolladores, y cuyo «producto» son estos golden paths. Toda la disciplina de módulos, versionado (subcapítulo 18.4) y testing (Capítulo 21) que aprendiste se aplica aquí para crear caminos dorados de calidad.

Los golden paths sobre Terraform aportan tres grandes beneficios a la vez:

• Velocidad: los desarrolladores obtienen su infraestructura en minutos, sin tener que aprenderlo todo ni configurarlo desde cero.
• Seguridad y buenas prácticas «de serie»: como el camino lo diseñó el equipo experto, la infraestructura sale segura y bien hecha por defecto, sin que el desarrollador tenga que ser un experto en seguridad.
• Consistencia: todos los equipos que usan el mismo golden path obtienen infraestructura coherente, lo que facilita mantener y gobernar todo.

Ejemplo del mundo real: una empresa con 15 equipos de desarrollo monta un equipo de Platform Engineering. Este crea golden paths sobre Terraform: por ejemplo, un módulo «servicio web estándar» que, con solo indicar el nombre y unos pocos parámetros, despliega una aplicación con balanceo de carga, autoescalado, logs, seguridad y copias ya configurados según las mejores prácticas de la empresa. Antes, montar todo esto le llevaba a cada equipo días (y a veces lo hacían mal). Ahora, un desarrollador lo tiene en minutos, sin ser experto en infraestructura, y sale seguro y consistente con el resto. Los 15 equipos van más rápido, cometen menos errores y la empresa mantiene el control. Los desarrolladores se centran en su producto, que es lo que aporta valor.

• Sin una plataforma común, cada equipo reinventa la rueda con la infraestructura: trabajo duplicado, inconsistencia y riesgo de errores de seguridad, distrayéndose de su producto. Como si cada empleado tuviera que construirse su propio ordenador.
• El Platform Engineering es la disciplina de construir una plataforma interna que facilita a los equipos crear y gestionar su infraestructura de forma fácil, rápida y segura, sin ser expertos en todo (autoservicio).
• Un golden path (camino dorado) es la forma recomendada, fácil y bien diseñada de hacer algo, preparada por el equipo de plataforma. No obliga, pero es tan buena y cómoda que la mayoría la sigue: hace que lo correcto sea también lo más fácil. Como un sendero señalizado y pavimentado hacia la cima.
• Los golden paths de infraestructura se construyen sobre Terraform y módulos (Cap. 18): el equipo experto crea módulos seguros y conformes que los desarrolladores usan con pocos parámetros.
• Aportan velocidad (infraestructura en minutos), seguridad y buenas prácticas de serie, y consistencia entre equipos.

En el siguiente subcapítulo veremos una herramienta de AWS para ofrecer este tipo de recursos preaprobados de forma autoservicio: el Service Catalog.