La semana pasada anunciaba que iba a escribir un libro. Pues ya estoy a tope con él —a pesar del poco tiempo del que dispongo cada día. Esta última semana le he estado dando varias vueltas al índice del libro, y creo que ya lo tengo más o menos claro. El tema de las plataformas es muy amplio, y es fácil volverse loco intentando abarcarlo todo. Por eso, creo que lo mejor no es escribir un libro introductorio, sino uno de nivel intermedio que asuma algunos conocimientos previos. No pretende ser un libro para principiantes, pero tampoco un tratado académico infumable. Es decir, que se espera que el lector tenga cierto bagaje técnico.
Un equipo de Platform Engineering existe por necesidad de los equipos de desarrollo, cuyo enfoque debe ser el de entregar valor a los usuarios. Si a los equipos de desarrollo se les hace responsables de todo (desarrollo, infraestructura, operaciones, soporte), aumentas su carga cognitiva, lo que los vuelve menos productivos y les hace perder el foco en lo que realmente importa: entregar valor a los usuarios.
Los equipos tradicionales de infraestructura y operaciones han funcionado más o menos bien durante años, pero la complejidad de las infraestructuras actuales y la velocidad de cambio hacen que a ese modelo se le vean las costuras cuando lo sobrecargas. Si añades una nueva funcionalidad o un nuevo componente a la arquitectura, tienes que entrenar al equipo de operaciones sobre cómo gestionarlo. A medida que la infraestructura crece en complejidad, el equipo de operaciones se convierte en un cuello de botella, y formar a gente para dicho equipo cada te irá costando más. Por eso lo que se replantea siempre es en distribuir la carga de responsabilidades, en lugar de centralizar.a
De esta problemática nace la cultura DevOps, que busca volver a la casilla de salida: que los equipos de desarrollo sean responsables de todo el ciclo de vida del software.
“You build it, you run it.”
— Werner Vogels, CTO de Amazon
Pero esto no es posible en la mayoría de las organizaciones, porque los equipos de desarrollo no tienen ni el tiempo ni las habilidades necesarias para gestionar infraestructuras complejas. Por lo tanto, necesitamos simplificar y abstraer la infraestructura y los servicios que los equipos de desarrollo requieren para hacer su trabajo.
Aquí es donde entra en juego Platform Engineering para crear una plataforma interna para que permite a los desarrolladores ser autosuficientes y más productivos. Este equipo es el puente entre desarrollo y operaciones. Pavimentan el camino hacia producción. Su misión es crear una plataforma que se adapte a las necesidades de los equipos de desarrollo y que les permita ser autosuficientes. Es decir, que no dependan de un tercer equipo cada vez que necesiten una nueva base de datos o una máquina virtual (golden paths). Esta plataforma debe ser segura, robusta, escalable y multi-tenant. Debe ofrecer una excelente experiencia de desarrollador (DevEx) y abstraer la complejidad de la infraestructura subyacente.
El objetivo de este libro será el de poner el foco precisamente en esa parte: tratar la plataforma como un producto, cuyos clientes son los equipos de desarrollo. Este “producto” se compone de un conjunto de servicios, herramientas, módulos, plantillas y buenas prácticas que facilitan el desarrollo, despliegue y operaciones de aplicaciones.
No es un libro sobre cómo crear el próximo Heroku o Netlify —que son plataformas de propósito general—, sino sobre cómo construir plataformas internas.
El índice del libro es (de momento) el siguiente:
Introducción
Plataforma como producto
Infraestructura como código
Estrategias de segmentación
Autoservicio
CI/CD
Observabilidad
Servicios de seguridad
Portales de desarrolladores
Los capítulos 1 y 2 son de contexto histórico y la proposición de crear y gestionar una plataforma como un producto. Los capítulos 3, 4 y 5 son los pilares básicos que considero debe ofrecer cualquier plataforma: que se gestione programáticamente, que esté correctamente segmentada (por región, por entornos, por equipo, etc.) y un diseño enfocado al autoservicio, que los desarrolladores no dependan de terceros equipos. Y los capítulos 6, 7, 8 y 9 cubren los servicios esenciales que toda plataforma debe ofrecer.
Creo que con este enfoque el libro será más manejable y cubrirá los aspectos fundamentales.
¿Qué te parece? ¿Crees que me dejo algo importante? ¿O hay algo que no debería incluir? Te leo en los comentarios.
¡Ah! Y el nombre del libro ya lo tengo. Y el primer capítulo ya casi está. El fin de semana del puente ha estado bien aprovechado. Ya estoy más cerca de publicar el programa de early adopters.
¡Muchas gracias por leerme!