Introducción
Si tú lo construyes, tú lo operas.
Marta, directora de ingeniería en Mountain Lab, llega al trabajo un lunes por la mañana. Todavía con el café en la mano, abre su portátil y ve tres mensajes de Slack esperándola. Uno de Diego, su CTO. Otro de Javi, el tech lead del equipo de infraestructura. Y uno más del equipo de Payments, que lleva dos semanas esperando un entorno de staging.
Abre primero el mensaje de Diego.
“¡Buenos días, Marta! Tenemos que hablar sobre el equipo de infraestructura. Se les está acumulando el trabajo y se han convertido en un cuello de botella enorme. Están operando servicios en producción de los que no tienen ni idea, y son incapaces de ponerse al día con todo lo que los equipos de producto están desarrollando. Con la ronda de inversión que viene en Q2, nos queremos poner como objetivo triplicar el ritmo de features. Necesitamos una organización que escale mejor.”
Marta suspira. Joder, lo sabía. Lleva meses viendo las señales.
El equipo de infraestructura empezó con tres personas hace cuatro años, cuando Mountain Lab tenía apenas veinte personas. Ahora la empresa tiene casi cien desarrolladores organizados en doce equipos de producto, y el equipo de infra sigue siendo de seis personas. Cada semana reciben entre quince y veinte tickets: nuevos entornos, cambios en configuraciones, ajustes de permisos, investigación de incidentes, actualizaciones de dependencias críticas. Los tiempos de respuesta han pasado de horas a semanas.
Lee el mensaje de Javi.
“Marta, necesitamos hablar. El equipo está quemado. Ayer Carlos se pasó cuatro horas depurando un problema en el servicio de recomendaciones, un código que nunca ha visto. Resulta que el equipo de datos había cambiado la versión de Python sin decírnoslo. Mientras tanto, se nos acumularon diez tickets más. No podemos seguir así. O contratamos a diez personas más, o tenemos que darle una vuelta a como nos organizamos. Esto es insostenible.”
¡Diez personas más! Marta hace el cálculo mental: con el tiempo de onboarding, tardarían seis meses en ser productivos. Y para entonces, la empresa habrá crecido aún más. Es una carrera perdida.
Vuelve al mensaje de Diego y responde.
“¡Buenas! Claro, hablemos. ¿Qué tienes en mente?”
La respuesta llega enseguida.
“He estado leyendo sobre DevOps, SRE y Platform Engineering. Empresas como Spotify y Netflix han resuelto esto construyendo plataformas internas que permiten a los equipos auto-gestionarse. Los desarrolladores pueden desplegar sus servicios sin depender de un equipo centralizado. Creo que necesitamos algún modelo así de autoservicio. ¿Podrías darle una vuelta? Habla con Javi, que creo que él también ha estado mirando y tiene algunas ideas.”
Marta sonríe. Lleva semanas también dándole vueltas a esto mismo.
“¡Por supuesto! Hace poco vi una charla de Kelsey Hightower sobre la evolución de DevOps a Platform Engineering. La teoría me encaja. Pero casi que me preocupa más el cambio cultural. Dame una semana para analizar la situación y preparar una propuesta.”
Cierra Slack y abre su editor de texto. Empieza a escribir.
Los equipos de producto llevan semanas esperando cosas que deberían ser triviales. El equipo de Payments lleva catorce días esperando un entorno de staging. Catorce putos días por un entorno. Mientras esperan, el código se acumula sin testear en entornos potentes y están perdiendo momentum. Hay mucha presión para lanzar el nuevo sistema de pagos. A ver como le explican a Ana, la CEO, que hay retrasos por no disponer de máquinas para montar un entorno, después de todo el dinero que están invirtiendo.
Y luego está el marrón de operar servicios que no conoces. Recuerda la llamada de las 3 AM de la semana pasada. El servicio de recomendaciones palmado. Carlos intentando debugear un sistema que nunca había visto, despertando a Laura del equipo de datos para preguntarle qué demonios hacía ese servicio. “Es el motor de recomendaciones, usa embeddings de productos…”, explicaba Laura medio dormida. Pero Carlos necesitaba saber cosas más básicas: ¿qué base de datos usa? ¿cuáles son sus dependencias? ¿cómo se reinicia correctamente? Preguntas que Laura respondió en cinco minutos, pero que costaron treinta minutos de downtime y clientes cabreados al otro lado del atlántico.
El conocimiento está encerrado en las cabezas de los ingenieros y en runbooks obsoletos. Bueno, en realidad tres personas son las que saben realmente operar bien los servicios más clásicos. Marta revisa el calendario. Javi se va de vacaciones en dos semanas. Dos semanas completas sin él. ¿Quién coño va a poder hacer ese cambio crítico de configuración de red que solo él sabe hacer? Los runbooks que deberían documentar estos procesos están obsoletos desde hace años. Nadie tiene tiempo para actualizarlos cuando están constantemente apagando fuegos.
Y la inconsistencia. Marta abre el catálogo de infraestructura. Menudo caos. El equipo de Integrations usa Java, Ubuntu 20.04 y PostgreSQL 13. El equipo de Payments, Windows Server 2022 con SQL Server 2019. Algunos servicios tienen dashboards de monitoring configurados, otros ni siquiera escupen logs. Cada equipo pidió su infraestructura en momentos diferentes, a personas diferentes del equipo de infra, sin ningún tipo de criterio. El resultado: un desastre heterogéneo donde cada cambio es único porque nada es estándar.
Piensa en Javi y su equipo. Tres meses de guardia casi permanente. Apagando fuegos que no entienden. Haciendo trabajo manual y repetitivo que saben que debería estar automatizado. “En cuanto tenga un hueco, lo automatizo”, dice Javi cada semana. Pero ese hueco nunca llega. El siguiente fuego lleva ardiendo días.
Marta respira hondo. La solución no es contratar a diez personas más para infra. Hay que cambiar cómo funciona la organización. Necesitamos que los equipos de desarrollo se auto-gestionen, siempre dentro de unos límites de seguridad y estandarización de infraestructura. Tienen que asumir parte de la responsabilidad tanto del provisionamiento como del mantenimiento de los servicios en producción. Necesitamos que el equipo de infraestructura deje de ser un cuello de botella y se convierta en un habilitador. Que actúe más como un equipo de buenas prácticas y se encargue de simplificar la vida de los desarrolladores. Que estén ahí para dar soporte, más que para hacer el trabajo por ellos.
Pero ¿por dónde empezamos? ¿DevOps? ¿SRE? ¿Platform Engineering? ¿Cuál es la diferencia? ¿Cuáles son los pros y contras?
Tiene una semana para encontrar la respuesta.
Esta situación seguro que te resulta familiar. Si cambiamos los nombres de las personas mencionadas y sus perfiles, casi seguro que encaja muy bien en alguna empresa en la que hayas trabajado. No soy adivino, sino que esta situación es bastante común y es producto tanto de la rápida evolución de las tecnologías como de la forma de trabajar de las empresas. Pensamos que todo está ya inventado, pero cada día aparecen nuevas herramientas y nuevas prácticas que nos obligan a replantearnos cómo hacemos las cosas. Muchas veces son simples modas, pero otras veces llegan para quedarse.
Cuando una empresa es pequeña, es fácil gestionar todo lo que ocurre. La arquitectura es sencilla y estás enterado de lo que hacen otros equipos. Un equipo centralizado responsable de desplegar y operar los servicios en producción no va a tener problemas en correr esos servicios. Pero a medida que la empresa crece, la complejidad de los sistemas aumenta exponencialmente, y la comunicación entre equipos se vuelve más difícil. Los equipos de desarrollo quieren moverse rápido, mientras que el equipo de operaciones quiere estabilidad. También se hace más difícil formar a nuevos miembros del equipo de operaciones, debido a la magnitud y matices de los sistemas que tienen que aprender a gestionar.
A lo largo de los años, a medida que la tecnología ha ido evolucionando, hemos ido adoptando nuevas formas de trabajar. Siempre buscando acercar el desarrollo y operaciones de las aplicaciones. Esta fusión de responsabilidades ha llevado a la creación de nuevos roles y prácticas. En este capítulo, vamos a repasar el contexto histórico que nos ha traído hasta aquí, hasta la necesidad de escribir este libro que tienes entre tus manos. Esto nos ayudará a entender por qué Platform Engineering se ha convertido en una disciplina tan popular. Pero seguro que no será la última, dada la irrupción de la IA y los modelos generativos.
La era del sysadmin clásico
Desde los inicios de la informática, instalar y operar sistemas ha sido una parte fundamental del desarrollo de software. En los primeros días, los desarrolladores eran responsables de todo, desde escribir el código hasta desplegarlo y mantenerlo en producción. A medida que las aplicaciones crecían en complejidad, empezaron a surgir roles especializados, como administradores de sistemas y operadores. Curiosamente, mi primer título profesional fue un “Grado Superior en Administración de Sistemas Informáticos”, hace 25 años. En aquella época, existían dos grupos principales de profesionales de TI: los desarrolladores, que escribían el código, y los sysadmins (administradores de sistemas), que gestionaban los servidores y la infraestructura. Pero esta segregación se remonta a mucho más atrás, cuando los mainframes dominaban el panorama tecnológico.
Este modelo de trabajo es manual y reactivo. El escenario típico se puede resumir así:
- Un desarrollador necesita un servidor para sus aplicaciones
- Abre un ticket, o envía un email, a los sysadmins, con un código de proyecto en el que cargar el coste, una descripción del uso que va a tener el servidor y la aprobación de su manager
- Los sysadmins revisan el ticket. Si hay un servidor libre, ha tenido suerte, sino toca esperar a que se compre uno nuevo, lo que puede llevar semanas
- Los sysadmins instalan físicamente el hardware en el rack del centro de datos
- Los sysadmins instalan manualmente el sistema operativo desde CDs o imágenes
- Los sysadmins configuran manualmente las redes, firewalls, almacenamiento
- Los sysadmins instalan las dependencias necesarias (Java, Apache, bases de datos) siguiendo documentación que probablemente está desactualizada
- Los sysadmins entregan credenciales y acceso al desarrollador para que instale y configure su aplicación
Yo experimenté esto en primera persona en los años 2000, teniendo que planificar la capacidad por adelantado y solicitar al departamento de TI que asignara servidores para los proyectos. El proceso completo puede tardar fácilmente entre 2-4 semanas en el mejor caso. ¿Te resulta ineficiente y desesperante? Porque lo es. Y lo peor es que hay empresas que todavía funcionan exactamente así en 2025. Especialmente en sectores tradicionales con una infraestructura legacy antigua. Pero por suerte, cada vez son menos, porque este modelo tiene problemas sistémicos:
- Lentitud: Cada cambio requiere intervención humana coordinada y burocracia. Algo tan simple como aumentar la memoria de un servidor puede llevar días de aprobaciones y ventanas de mantenimiento.
- Inconsistencia: Es habitual que las configuraciones varíen entre entornos. Esto se debe a cambios manuales, errores humanos y documentación desactualizada. Los sysadmin hacen lo que se les ha pedido con la documentación que se les ha proporcionado. Pero sin el contexto adecuado, raramente van a cuestionar lo que se les pide.
- Rigidez: A medida que crecen las organizaciones, el equipo de operaciones se convierte en un cuello de botella. Contratar más sysadmins solo resuelve el problema temporalmente, porque la capacidad no escala linealmente.
- Silos de conocimiento: La documentación existe en teoría, pero en la práctica vive en la cabeza de los sysadmins. Es habitual que la documentación se quede desactualizada en el mismo instante en el que se escribe, especialmente en equipos con mucha carga de trabajo y poco disciplinados.
- Silos culturales: Desarrolladores y operadores trabajan en mundos separados, a menudo con objetivos contradictorios. Los desarrolladores quieren mover rápido y los operadores quieren estabilidad. Distintos equipos no necesariamente tienen que gestionarse de la misma manera.
Dicho esto, este modelo sí ofrece algunas ventajas: equipos altamente especializados con profundo conocimiento de infraestructura, control estricto sobre seguridad y cumplimiento, y experiencia en gestión de hardware especializado. Sin embargo, estos beneficios vienen al coste de la agilidad. La pregunta se convierte en si hay una mejor manera de equilibrar especialización con velocidad. No queremos cargar a los desarrolladores (todavía) con la responsabilidad completa de operar sus aplicaciones, pero sí queremos cerrar esa brecha entre desarrollo y operaciones. Los desarrolladores necesitan ganar visibilidad sobre cómo funcionan sus aplicaciones en producción.
Site Reliability Engineering
Mientras el resto de la industria lidiaba con los problemas tradicionales de operaciones, Google se enfrentaba a estos desafíos a escala diferente. A principios de los 2000s, Google estaba creciendo exponencialmente. El modelo tradicional de sysadmin simplemente no podía escalar para gestionar miles de servidores y servicios críticos que atendían millones de usuarios simultáneos.
En el año 2003, Ben Treynor Sloss, entonces VP de ingeniería en Google, propuso: ¿Qué pasa si tratamos las operaciones como un problema de software?. De su propuesta nacieron los equipos de Site Reliability Engineering (SRE). En lugar de contratar más sysadmins para gestionar más servidores, Google contrató ingenieros de software y les pidió que automatizaran el trabajo operacional. La propuesta era radical. Los SRE debían dedicar el 50% de su tiempo a trabajo operacional (incidentes, despliegues manuales, housekeeping) y el otro 50% a escribir código para automatizarlo.
SRE se basa en varios principios fundamentales:
Automatización: Si haces algo dos veces, automatízalo la tercera. Si un proceso requiere tocar más de 5 veces al año, automatízalo por completo.
Ingeniería antes que operaciones: Los SREs son ingenieros de software que se especializan en fiabilidad. Escriben código para resolver problemas operacionales.
Service Level Objectives (SLOs): En lugar de perseguir “100% de uptime” -que es imposible-, define objetivos cuantificables basados en lo que los usuarios realmente necesitan. Por ejemplo, un 99.9% de uptime significa 43 minutos de downtime permitido por mes.
Error budgets: Si tu SLO es 99.9%, tienes un 0.1% de “presupuesto de error”. Mientras estés dentro del presupuesto, el equipo de desarrollo puede trabajar más en nuevas funcionalidades y tomar más riesgos. Si te pasas de ese presupuesto, se frenan los cambios hasta recuperar la normalidad.
Blameless postmortems: Cuando algo falla -y algún momento fallará-, se analiza qué sistema y por qué falló, y no quiénes fueron los culpables.
Toil reduction: “Toil” es trabajo operacional manual, repetitivo, sin valor duradero. Lo que a nadie le gusta hacer. Los SREs identifican cuál es y automatizan todo lo posible para erradicarlos.
Google publicó un libro [Beyer, 2016], compartiendo estas prácticas con el mundo. Empresas de todo tipo adoptaron -y continúan adoptando- SRE como disciplina, porque está probado que tratar las operaciones como un problema de ingeniería escala mejor.
Sin embargo, la adopción de SRE viene con desafíos. La disciplina requiere un nivel de habilidades más alto. Los SREs necesitan ser ingenieros de software que también entiendan operaciones profundamente. Esto hace que la contratación sea difícil. Además, SRE tiene un enfoque específico: fiabilidad y disponibilidad de servicios en producción. Se enfoca en mantener sistemas funcionando, no necesariamente en mejorar la experiencia del desarrollador para producir mejor software. Digamos que SRE es un modelo que va desde las operaciones hacia el desarrollo, y no al revés. En el punto donde se encuentran con los equipos de desarrollo es donde aparece la fricción entre ambas disciplinas. Mientras desarrollo empuja cambios, SRE tiene que asegurarse de que esos cambios no comprometan los SLOs. Volvemos a tener dos equipos con intereses potencialmente opuestos. Uno quiere mover rápido, el otro quiere estabilidad. Así que una de las propuestas es embeber algunas prácticas de SRE dentro de los equipos de desarrollo. Es decir, continuar cerrando la brecha entre desarrollo y operaciones.
Para una comprensión más profunda de los principios y prácticas de SRE, consulta [Beyer, 2016][Beyer, 2018][Adkins, 2020] en el Apéndice A.
La cultura DevOps
Mientras Google desarrollaba SRE internamente -e, incluso, en secreto durante años-, otro movimiento emergía en la comunidad: DevOps. El término fue acuñado por Patrick Debois en 2009, y popularizado durante la primera “DevOpsDays” en octubre del mismo año, en Gante, Bélgica.
DevOps no es una herramienta o una tecnología específica. Es una revolución cultural y respuesta filosófica a los silos disfuncionales entre desarrollo y operaciones. El objetivo es eliminar las barreras entre estos dos mundos, y diferentes organizaciones han implementado esto de maneras distintas:
- Equipos cross-funcionales: Los equipos de desarrollo asumen responsabilidades operacionales para sus servicios. No hay un equipo de operaciones separado. Este es el modelo que Amazon pionerizó bajo el famoso principio de Werner Vogels: los desarrolladores que construyen el servicio también son responsables de operarlo en producción, incluyendo guardias on-call. Netflix sigue un enfoque similar.
- Operaciones embebidas: Los ingenieros de operaciones están integrados dentro de los equipos de desarrollo o trabajan muy estrechamente con ellos, pero mantienen su experiencia especializada. Los equipos colaboran desde el día uno en arquitectura, despliegue y operaciones. Como hacen los equipos de QA hoy en día.
- Equipos de plataforma centralizados: Que discutiremos en la siguiente sección sobre Platform Engineering.
Independientemente de la implementación específica, DevOps busca derribar el muro tradicional entre desarrollo y operaciones. Se acabó “tirar por encima del muro”.
Los principios fundamentales de DevOps son:
- Responsabilidad compartida: Los equipos que escriben el código son responsables de mantenerlo en producción. Se acabó el modelo de “desarrollo programa, operaciones sufre el resultado”.
- Colaboración: Ya sean equipos fusionados o separados, desarrollo y operaciones trabajan juntos desde el principio. Las decisiones de arquitectura consideran tanto funcionalidad como operabilidad.
- Automatización: No solo scripts, sino pipelines completos de CI/CD. Desde el commit hasta producción debería ser un proceso automatizado, reproducible, y auditable.
- Observabilidad: Instrumenta todo. Métricas, logs, trazas. Aprende de los datos, no de suposiciones. El feedback rápido de rendimiento y disponibilidad nos va a permitir mejorar continuamente.
- Experimentación: Fomenta una cultura de experimentos controlados. Fallar es aceptable si aprendes y mejoras el sistema. Los incidentes son oportunidades de aprendizaje, no motivos de castigo.
El surgimiento de la virtualización y la nube pública fue el catalizador perfecto para DevOps:
- AWS EC2 (2006): Infraestructura on-demand mediante APIs
- GitHub (2008): Colaboración en código y workflows
- Docker (2013): Contenedores que empaquetan aplicaciones con todas sus dependencias
- Terraform (2014): Infraestructura como código
- Kubernetes (2014): Orquestación de contenedores a escala
Con estas herramientas, ahora es posible provisionar infraestructura mediante código, no tickets o emails a equipos dedicados. Los equipos pueden desplegar cambios múltiples veces al día, no múltiples veces al año. Además, pueden deshacerse de la infraestructura que no necesitan, pagando solo por lo que usan. Esto ha democratizado el acceso a la infraestructura y ha empoderado a los desarrolladores, pero también los ha sobrecargado con nuevas responsabilidades.
Esta es un arma de doble filo. Por un lado, los desarrolladores tienen más control sobre sus aplicaciones y pueden iterar más rápido. Pero por otro lado, los desarrolladores no siempre tienen el conocimiento necesario para gestionar la infraestructura necesaria cuando sus aplicaciones se despliegan a gran escala. O entienden muy bien las repercusiones en el coste. Esto es un problema, porque las aplicaciones modernas son cada vez más complejas, con más abstracciones, y que requieren de unos conocimientos sólidos para diseñarlas y operarlas correctamente.
DevOps sigue siendo la cultura predominante en muchas empresas, pero presenta desafíos que se han vuelto más evidentes con el tiempo:
Ambigüedad: Pregunta hoy a 10 personas qué es DevOps y obtendrás 10 respuestas diferentes. ¿Es una cultura? ¿Un rol? ¿Un conjunto de herramientas? ¿Todo lo anterior? Esta confusión persiste.
Inconsistencia: Cada equipo, en una misma empresa, implementa DevOps de manera distinta. Un equipo usa Jenkins, otro CircleCI, otro GitLab para CI/CD. Un equipo despliega en AWS, otro en Kubernetes on-prem. Incluso cuando las herramientas sirven para el mismo propósito, la falta de estandarización crea un paisaje heterogéneo que es difícil de mantener y soportar a nivel organizacional.
Sobrecarga cognitiva: Se espera que los desarrolladores entiendan no solo su código, sino también Docker, Kubernetes, Terraform, AWS, redes, seguridad, observabilidad, regulaciones… La carga mental es insostenible, especialmente para equipos pequeños.
Reinventar la rueda: Más allá de elegir herramientas diferentes, cada equipo a menudo construye sus propias soluciones personalizadas desde cero. Todos necesitan pipelines de CI/CD, pero en lugar de usar templates compartidas o frameworks comunes, cada equipo escribe su propia lógica de pipeline. Todos necesitan monitorización, pero cada equipo configura sus propios dashboards y alerting. Todos necesitan gestión de secretos, pero cada equipo implementa su propio enfoque. Esta duplicación de esfuerzos no escala y genera sobrecostes enormes en tiempo y mantenimiento.
“DevOps engineer” es un antipatrón: Muchas empresas contratan “DevOps engineers” pensando que es un rol. Estos ingenieros frecuentemente se convierten en el equipo de infraestructura con un nombre más chachi. No traen la transformación cultural que DevOps promete.
¡Vaya! Parece que ahora nos hemos pasado de frenada. Hemos cerrado de golpe a la brecha entre desarrollo y operaciones, pero hemos creado nuevos problemas. Ahora necesitamos recular un poco, y buscar a alguien que se haga cargo de parte de las responsabilidades DevOps, con intención de estandarizar y homogeneizar la infraestructura y los servicios. Pero, ¿quién?
Para lecturas esenciales sobre la cultura DevOps, prácticas y transformación, consulta [Kim, 2013][Kim, 2016][Humble, 2010][Forsgren, 2018] en el Apéndice A.
Platform Engineering
La ingeniería de plataformas emerge como respuesta directa a las limitaciones -o confusiones- de DevOps y SRE. La idea central es poderosa y simple:
En lugar de pedirle a cada equipo que se convierta en experto en infraestructura, construyamos las herramientas y capacidades comunes una vez, correctamente, como un producto interno que todos puedan consumir mediante autoservicio.
Platform Engineering representa el estado del arte actual en cómo las organizaciones más avanzadas gestionan su infraestructura y DevEx.
Empresas pioneras como Spotify, Netflix, Airbnb, y Uber construyeron —y continúan evolucionando— plataformas internas sofisticadas que permiten a cientos de equipos de desarrollo desplegar aplicaciones de forma independiente, segura, y rápida. Estos no son proyectos de plataforma casuales. Estamos hablando de inversiones estratégicas con equipos dedicados que tratan la plataforma como un producto que lo adaptan a las necesidades de los equipos de desarrollo.
Spotify, por ejemplo, construyó “Backstage” internamente -ahora es una herramienta open source-, que es un portal de desarrollador para centralizar:
- Catálogo de servicios y APIs
- Templates para proyectos
- Documentación técnica
- Estado de despliegues
Netflix desarrolló también múltiples herramientas internas como Spinnaker (continuous delivery), Chaos Monkey (testing de resiliencia), y mantiene una plataforma completa que permite a los equipos desplegar servicios sin intervención de un equipo de infraestructura centralizado.
Platform Engineering no reemplaza DevOps o SRE, sino que los complementa. DevOps sigue siendo la cultura necesaria y transversal en todos los equipos de ingeniería. SRE también es necesario, pero está más integrado en los equipos de aplicaciones y la responsabilidad está compartida con el equipo de plataforma. Platform Engineering es el mecanismo que hace que todo esto sea escalable y sostenible. Las tres disciplinas coexisten y se refuerzan mutuamente en las organizaciones modernas.
Hoy, en 2025, la ingeniería de plataformas es una disciplina madura y reconocida. Conferencias como PlatformCon reúnen miles de asistentes. Empresas de todos los tamaños invierten activamente en equipos de plataforma.
Sin embargo, adoptar ingeniería de plataformas requiere inversión inicial significativa y compromiso organizacional. Hay un riesgo de sobreingeniería de una plataforma que los desarrolladores no adoptarán si no aborda verdaderamente sus necesidades. La realidad es heterogénea. Mientras que algunas empresas tech ya tienen plataformas sofisticadas, muchas organizaciones tradicionales todavía operan con modelos de sysadmin clásico o están en medio de su transformación DevOps. No existe un único “estado de la industria”. El encaje de cada modelo depende del contexto, cultura y necesidades específicas de cada organización. Por eso, la necesidad de este libro. Espero que al final del mismo, el lector esté en el camino correcto para construir o evolucionar su propia plataforma.
Para guías completas sobre ingeniería de plataformas, organización de equipos e implementación práctica, consulta [Fournier, 2023][Skelton, 2019][Salatino, 2023] en el Apéndice A.
Resumen
En este capítulo hemos recorrido la evolución histórica desde los sysadmins clásicos, pasando por SRE y DevOps, hasta llegar a Platform Engineering. Cada etapa ha surgido como respuesta a las limitaciones y desafíos de la anterior, adaptándose a las nuevas realidades tecnológicas y organizativas. La virtualización y la explosión de la nube pública han sido catalizadores en esta evolución. Han introducido nuevas formas de provisionar y gestionar infraestructura, pero también han traído nuevos desafíos.
Este emplazamiento histórico nos ayuda a entender el encaje de Platform Engineering en el panorama actual. El futuro permanece incierto, particularmente con la rápida evolución de la inteligencia artificial generativa que promete remodelar cómo construimos y operamos sistemas. Conceptos emergentes como vibe coding —donde la IA interpreta intención de alto nivel para generar infraestructura y código— siguen siendo especulativos y no probados a escala. Si estos se convertirán en mainstream o darán paso a otras abstracciones queda por verse. Lo que está claro es que la complejidad de los sistemas no va a disminuir, sino todo lo contrario. Estamos abocados a un aumento de la complejidad con más capas de abstracción.