¿Por qué necesito leer este libro?
Porque Platform Engineering ofrece una visión clara y práctica sobre cómo construir plataformas internas que realmente empoderen a los equipos de desarrollo, mejoren la eficiencia operativa y escalen con el crecimiento de tu organización. Con la experiencia combinada de Camille Fournier e Ian Nowland, este libro te ayuda a evitar errores comunes, entender qué hace valiosa a una plataforma y cómo liderar equipos técnicos hacia soluciones sostenibles, reutilizables y centradas en el usuario interno. Es una lectura esencial si quieres que tu equipo construya más rápido, con menos fricción y mayor impacto.
Las plataformas nacen de los desafíos modernos en la ingeniería de software a escala. Los equipos deben gestionar ecosistemas tecnológicos cada vez más diversos y cambiantes, sin sacrificar disponibilidad ni desempeño. Esta presión llevó a la necesidad de crear soluciones reutilizables y eficientes que reduzcan complejidad sin ralentizar la innovación.
“Las plataformas son los cimientos de APIs self-service, herramientas, servicios, conocimiento y soporte que se disponen como un producto interno muy interesante. Equipos de aplicación autónomos pueden hacer uso de la plataforma para la entrega de funciones de producto más rápido y con menor coordinación.”
— Evan Bottcher, 2018
Es la disciplina dedicada al diseño, construcción y operación de plataformas. Su propósito: manejar la complejidad técnica para acelerar el negocio.
⚖️ Leverage (influencia)
El trabajo de unos pocos ingenieros en una plataforma puede tener un impacto positivo en toda la organización. Esto se logra aumentando la productividad de los equipos de aplicación y evitando esfuerzos duplicados.
Ver la plataforma como un producto significa adoptar un enfoque centrado en el cliente interno (los desarrolladores), guiando el desarrollo de funcionalidades con base en sus necesidades reales.
🧠 Un poco de historia: ¿cómo llegamos a este punto?
Aunque la industria ha evolucionado mucho en cuanto a herramientas e infraestructura en los últimos 25 años, los costos de mantener sistemas complejos han crecido. Las aplicaciones son más fáciles de construir, pero más difíciles de operar. Y a medida que escalan, se vuelven más lentas… como caminar en un pantano.
Según Jossi Koskinen, entre el 60 y 75% del costo de un software ocurre después de su lanzamiento inicial, y gran parte se va en mantenimiento y migraciones.
💥 Cambio #1: Explosión de opciones
La llegada de la nube pública trajo una avalancha de alternativas. Los desarrolladores buscaban independencia, rapidez y menos fricción con equipos de infraestructura. Sin embargo, la diversidad trajo consigo complejidad, riesgos de seguridad y costos ocultos.
⚙️ Cambio #2: Nuevas necesidades operativas
Este nuevo ecosistema exigía no solo nuevas herramientas, sino también nuevos roles. Apareció el movimiento DevOps, con una cultura centrada en colaboración y automatización. Más adelante, Google presentó SRE (Site Reliability Engineering) como su forma de garantizar confiabilidad en producción. Aunque fue revolucionario, fuera de Google ha sido difícil de replicar con éxito.
Site reliability engineering (SRE)
En 2004 Google cambió de Operations Engineering a algo llamado Site Reliability Engineering. En 2015, durante el ascenso de la popularidad de DevOps, Google publicó un libro sobre sus prácticas,
Site Reliability Engineering: How Google Runs Productions Systems. Lo que causó furor entre aquellos que habian adoptado DevOps y estaban teniendo dificultades con las complejidades de ésta práctica. Se pensó que el SRE sería la solución mágica que la industria necesitaba para balancear las necesidades operacionales y de desarrollo. Sin embargo, no ha tenía un éxito generalizado fuera de Google, demasiados procesos apegados a su cultura y capital internos. Paradójicamente estos bloqueantes son explicados por el director antiguo de SRE de Google, Dave O’Connor, quien después de un par de temporadas fuera de Google escribió un post en 2023 titulado “
6 Razones por las que no necesidad un equipo SRE“
Las plataformas permiten:
Reducir la cantidad de tecnologías primitivas (por ejemplo, herramientas OSS) sin sacrificar flexibilidad.
Disminuir el acoplamiento entre equipos y herramientas, al ofrecer abstracciones reutilizables.
Centralizar migraciones, encapsulando tecnologías y exponiéndolas a través de APIs internas. Y mejorarando la observabilidad, controlando qué se usa y cómo se usa en la organización.
Empoderar a los developers, permitiéndoles operar lo que construyen, sin cargar con la complejidad operativa de fondo.
Un ejemplo clásico es Terraform: en vez de que cada equipo gestione su propia infraestructura, la plataforma puede encargarse de abstraer esa complejidad y ofrecer una experiencia más alineada con las necesidades reales de los equipos.
Se mencionan cuatro enfoques que son populares y traen valor a la organización, pero debido a los sesgos de su rol, no es común que estén aptos para la tarea de crear plataformas. Por lo tanto, la ingeniería de plataformas promueve que estos grupos de ingenieros salgan de los silos y trabajen en equipos con una misión más amplia para crear plataformas que provean un balance. Incluyendo a los equipos de:
Infraestructura, balancear las capacidades de infraestructura y las simplicidades centradas en el desarrollador.
DevTools, balancear la experiencia de desarrollo con la experiencia de soporte en producción.
DevOps, balancear la cohesión idónea por aplicación con un software más general para dar soporte a muchas más aplicaciones.
SRE, balancear la fiabilidad con otros atributos de sistema como agilidad de funciones, eficiencia de costos, seguridad y desepeño
La ingeniería de plataformas une estos mundos. Promueve equipos más integrados, con misiones claras y un foco en construir soluciones escalables, mantenibles y centradas en el usuario interno.
¿Te interesa este tema? ¡Estoy escribiendo un resumen por cada capítulo!
Puedes seguirme para más artículos sobre platform engineering, DevOps y arquitectura moderna.
