¿DevOps está muerto?
El surgimiento de la ingeniería de plataformas
Alguna vez te has preguntado por qué, a pesar de tanto inversión en DevOps, algunas empresas todavía enfrentan tantos problemas para implementar prácticas ágiles de desarrollo y entrega de software? ¿Por qué en algunas organizaciones el ciclo de vida del software sigue siendo un campo minado, lleno de cuellos de botella y puntos de dolor tanto para los desarrolladores como para los equipos de operaciones?
Últimamente, hemos visto surgir un nuevo concepto: la Ingeniería de Plataformas. Muchos dicen que esto es solo un nuevo nombre para el buen y viejo DevOps, mientras que otros argumentan que representa una evolución natural y necesaria. ¿Qué está pasando realmente? ¿Ha muerto el DevOps? ¿O simplemente estamos presenciando la próxima fase de su evolución?
Exploraremos este fascinante tema y entenderemos qué significa realmente la ingeniería de plataformas, cómo se diferencia del DevOps tradicional y por qué deberías prestar atención a esta tendencia que, según Gartner, será adoptada por alrededor del 80% de las grandes organizaciones de ingeniería de software para 2026.
Una breve historia del desarrollo de software operativo
Para entender dónde estamos, necesitamos saber de dónde venimos. Retrocedamos en el tiempo y hagamos un rápido repaso:
SysAdmin negando un deploy a un dev junior
La era del SysAdmin (finales de los 90 y principios de los 2000)
¿Recuerdan los tiempos en que teníamos un único guardián para todas las operaciones de infraestructura? El famoso SysAdmin era el portero que controlaba el acceso a todo. Si un desarrollador necesitaba hacer algo relacionado con la infraestructura, tenía que pasar por este guardián.
Este era el famoso enfoque de "lanzar por encima del muro": los desarrolladores escribían el código y, cuando terminaban, lo lanzaban por encima del muro para que el equipo de operaciones lo implementara y gestionara. Inevitablemente, esto resultaba en experiencias frustrantes para ambos lados del muro.
Era común ver a los desarrolladores terminar sus aplicaciones y actualizar vía FTP, editando archivos PHP directamente en el servidor con FileZilla, provocando esa ansiedad del hot deploy. ¡Qué nostalgia para algunos y trauma para otros!
FireFTP en los años 2000
La revolución DevOps (mediados de los 2000 hasta hoy)
Cuando la nube comenzó a ganar fuerza, con AWS surgiendo en 2006, el concepto DevOps comenzó a establecerse como el nuevo estándar de oro para los equipos de ingeniería. DevOps prometía unir el desarrollo y las operaciones, creando una cultura de colaboración y automatización que aceleraría la entrega de software.
"Tú construyes, tú ejecutas" se convirtió en el mantra, y la división tradicional entre desarrollo y operaciones comenzó a disolverse en muchas organizaciones. Esto trajo mejoras significativas en áreas como la escalabilidad, disponibilidad y operatividad, pero también aumentó significativamente la complejidad del día a día.
De repente, los ingenieros necesitaban dominar 10 herramientas diferentes, gráficos Helm, módulos Terraform y mucho más solo para implementar y probar un simple cambio de código en uno de los muchos entornos de su configuración de microservicios en varios clusters.
¿Dónde falló el DevOps?
El problema es que, a lo largo de esta evolución de la cadena de herramientas, la industria decidió de alguna manera que la división del trabajo, que ha demostrado ser exitosa en prácticamente todos los demás sectores de la economía global, no era una buena idea para el desarrollo de software. En cambio, el paradigma DevOps fue defendido como el camino para alcanzar una configuración de alto rendimiento.
La idea era noble: los desarrolladores deberían ser capaces de implementar y ejecutar sus aplicaciones y servicios de punta a punta. Sin embargo, para la mayoría de las empresas, este enfoque es bastante irrealista. Aunque funciona bien para organizaciones avanzadas como Google, Amazon o Airbnb, está lejos de ser trivial replicar el verdadero DevOps en la práctica para la mayoría de los otros equipos.
La razón principal es que es poco probable que la mayoría de las empresas tengan acceso al mismo conjunto de talentos y al mismo nivel de recursos que pueden invertir solo en la optimización de flujos de trabajo y experiencias de desarrollador.
Los antipatrones del DevOps
Lo que tiende a suceder cuando una organización de ingeniería común intenta implementar el verdadero DevOps es que emerge una serie de antipatrones. Un ejemplo clásico es lo que sucede en muchos equipos de desarrollo cuando la organización decide implementar DevOps y eliminar una función o equipo formal de operaciones.
Los desarrolladores (normalmente los más experimentados) terminan asumiendo la responsabilidad de gestionar entornos, infraestructura, etc. Esto lleva a una configuración donde las "operaciones sombra" son realizadas por los mismos ingenieros cuyo trabajo en términos de codificación y desarrollo de productos es más valioso.
Todos pierden en este escenario. El ingeniero senior ahora es responsable de la configuración y necesita resolver solicitudes de colegas más junior. La organización en general está utilizando incorrectamente algunos de sus recursos más caros y talentosos y no puede enviar recursos con la misma velocidad y fiabilidad.
Estudios del sector confirman esta realidad. Una encuesta reciente mostró que en el 44% de las organizaciones de bajo rendimiento, algunos desarrolladores realizan tareas de DevOps por su cuenta y ayudan constantemente a colegas menos experimentados. Compare esto con las organizaciones de alto rendimiento, donde el 100% ha implementado con éxito un verdadero enfoque de "tú construyes, tú ejecutas".
Sistema de tickets usado en los años 2000
El ticket office: síntoma de un problema mayor
Un síntoma claro de que su organización está sufriendo estos antipatrones es lo que muchos llaman "ticket office": la necesidad de abrir innumerables tickets para poder hacer cualquier cosa relacionada con la infraestructura o la implementación.
¿Has trabajado en una empresa donde, para cada nueva aplicación o cambio de infraestructura, era necesario completar varios formularios diferentes? ¿Donde si elegías la plantilla incorrecta, recibías un correo electrónico diciendo: "Abriste el ticket incorrecto, por favor abre uno nuevo utilizando el formulario correcto"?
Este enfoque de ticket office es una señal clara de que algo no está funcionando bien en la cultura DevOps de una organización. Crea cuellos de botella, frustra a los desarrolladores e impide la entrega rápida de valor a los usuarios finales.
El surgimiento de la Ingeniería de Plataformas
Entonces, ¿cuál es la diferencia entre organizaciones de bajo y alto rendimiento? ¿Cómo garantizan los mejores equipos que sus desarrolladores puedan ejecutar sus aplicaciones y servicios sin la necesidad constante de ayuda de colegas senior?
La respuesta: tienen un equipo de plataforma construyendo una Plataforma Interna para Desarrolladores (IDP - Internal Developer Platform). El Informe State of DevOps 2020 de Puppet muestra claramente la correlación entre el uso de plataformas internas y el grado de evolución de DevOps en las organizaciones.
La Ingeniería de Plataformas se define como la disciplina de diseño y construcción de cadenas de herramientas y flujos de trabajo que permiten recursos de autoservicio para organizaciones de ingeniería de software en la era nativa de la nube. Los ingenieros de plataforma proporcionan un producto integrado, a menudo denominado "Internal Developer Platform", que cubre las necesidades operativas de todo el ciclo de vida de una aplicación.
Backstage IDP
Internal Developer Platform (IDP)
Una IDP engloba una variedad de tecnologías y herramientas, integradas de manera que reducen la carga cognitiva de los desarrolladores, manteniendo el contexto esencial y las tecnologías subyacentes. Ayuda a las operaciones a estructurar su configuración y permitir el autoservicio de los desarrolladores.
Las mejores organizaciones de ingeniería configuran equipos internos de plataforma que construyen estas IDP. Al utilizar estas plataformas, los desarrolladores pueden elegir el nivel correcto de abstracción para ejecutar sus aplicaciones y servicios, dependiendo de su preferencia.
Por ejemplo, si a un desarrollador le gusta trabajar con gráficos Helm, archivos YAML y módulos Terraform, genial, puede hacerlo. Si es un desarrollador frontend junior que no le importa si la aplicación se ejecuta en EKS, fantástico, puede simplemente autoservirse un entorno que viene totalmente provisionado con todo lo que necesita para implementar y probar su código, sin preocuparse de dónde se ejecuta.
Caminos dorados y carreteras pavimentadas
La ingeniería de plataformas busca crear "caminos dorados" y "carreteras pavimentadas" para los desarrolladores. Pero, ¿qué significa esto en la práctica?
La mayoría de las configuraciones de CI/CD hoy en día se centran simplemente en la actualización de imágenes. El CI las construye, actualiza la ruta de la imagen en las definiciones, y listo. Esto cubre la mayoría de los casos de uso de implementación. Pero las cosas comienzan a complicarse y a tomar más tiempo cuando necesitamos hacer algo más allá de este flujo de trabajo básico, como:
- Añadir variables de entorno y cambiar configuraciones
- Añadir servicios y dependencias
- Hacer rollback y depurar
- Crear un nuevo entorno
- Refactorizar
- Añadir/cambiar recursos
- Aplicar RBAC (control de acceso basado en roles)
La lista continúa. La ingeniería de plataformas consiste en conectar todo esto a una carretera pavimentada. En lugar de dejar que todos operen todo y tengan que comprender toda la cadena de herramientas para hacerlo, los ingenieros de plataforma proporcionan el pegamento para conectar todo en una experiencia consistente de autoservicio.
¿Cuándo tiene sentido la ingeniería de plataformas?
Un error común es que la ingeniería de plataformas es algo que solo tiene sentido en equipos grandes. Y aunque si tu equipo está compuesto por 5 desarrolladores, un equipo de plataforma y una IDP son ciertamente exagerados, una vez que tu organización crece más allá de la marca de 20-30 desarrolladores, una Internal Developer Platform es probablemente algo que deberías considerar, más temprano que tarde.
Existen innumerables historias de equipos que pospusieron la construcción de una IDP durante mucho tiempo y tuvieron que sufrir dificultades innecesarias. Por ejemplo, imagina que tu único contratado DevOps deja la empresa y toda tu organización no puede hacer deploy durante semanas.
Principios de la Ingeniería de Plataformas
Muchas organizaciones están despertando a los beneficios de las Internal Developer Platforms y del autoservicio del desarrollador. Para citar el Informe State of DevOps 2021 de Puppet, "La existencia de un equipo de plataforma no desbloquea inherentemente una evolución DevOps más alta; sin embargo, los grandes equipos de plataforma amplían los beneficios de las iniciativas DevOps."
Aquí hay algunos principios útiles que son un hilo conductor común entre los equipos de plataforma exitosos y las organizaciones orientadas al autoservicio:
Misión y rol claros
El equipo de plataforma necesita una misión clara. Un ejemplo: "Construir flujos de trabajo confiables que permitan a los ingenieros interactuar de manera independiente con nuestra configuración y autoservirse la infraestructura que necesitan para ejecutar sus aplicaciones y servicios."
Sea lo que sea que tenga más sentido para tu equipo, asegúrate de que esté definido desde el principio. También es extremadamente importante establecer un rol claro para el equipo de plataforma, que no debe ser visto como otro help desk que crea entornos bajo demanda, sino como un equipo de producto dedicado que sirve a los clientes internos.
Trata tu plataforma como un producto
Ampliando el enfoque en el producto, el equipo de plataforma necesita estar orientado por una mentalidad de producto. Deben concentrarse en lo que proporciona valor real a sus clientes internos, los desarrolladores de aplicaciones, basándose en el feedback que reciben. Asegúrate de que envíen recursos basados en este ciclo de feedback y no se distraigan jugando con una nueva tecnología brillante que acaba de salir.
Enfócate en problemas comunes
Los equipos de plataforma evitan que otros equipos internos reinventen la rueda, abordando problemas compartidos repetidamente. Es fundamental descubrir cuáles son estos problemas comunes: comienza por comprender los puntos de dolor de los desarrolladores y las áreas de fricción que causan lentitud en el desarrollo. Esta información puede recopilarse tanto cualitativamente a través de feedback de los desarrolladores como cuantitativamente, observando los KPIs de ingeniería.
El pegamento es valioso
A menudo, los equipos de plataforma son vistos como un centro de costos puro, porque no envían ningún recurso real del producto al usuario final. Después de todo, solo están pegando nuestros sistemas. Esta es una perspectiva muy peligrosa y, por supuesto, este pegamento es extremadamente valioso.
Los ingenieros de plataforma necesitan abrazar y anunciar internamente su propuesta de valor. Una vez que hayas diseñado los caminos dorados y las carreteras pavimentadas para tus equipos, el principal valor que creas como equipo de plataforma es ser el pegamento adhesivo que une la cadena de herramientas y garantiza un flujo de trabajo de autoservicio sin problemas para tus ingenieros.
No reinventes la rueda
De la misma manera que los equipos de plataforma deben evitar que otros equipos dentro de la organización reinventen la rueda y encuentren nuevas soluciones creativas para los mismos problemas, deben evitar caer en la misma falacia. No importa si tu solución CI/CD casera es superior hoy en día, los proveedores comerciales eventualmente la alcanzarán.
Los equipos de plataforma siempre deben preguntarse cuál es su diferencial. En lugar de construir alternativas internas a un sistema de CI o a un panel de métricas y competir con empresas que tienen 20 o 50 veces su capacidad, deben concentrarse en las necesidades específicas de su organización y adaptar soluciones listas para usar a sus necesidades.
La organización de ingeniería moderna
Según el Informe State of DevOps 2021 de Puppet, "las organizaciones altamente evolucionadas tienden a seguir el modelo Team Topologies".
Publicado en 2019, el libro Team Topologies de Matthew Skelton y Manuel Pais se ha convertido en uno de los planes más influyentes para las configuraciones modernas de equipos en organizaciones de ingeniería exitosas. Según su plan, existen cuatro topologías fundamentales alrededor de las cuales los equipos deben estructurarse:
- Equipo alineado con el flujo: alineado con un flujo de trabajo de un segmento del dominio de negocio, trabajan en la lógica de negocio principal.
- Equipo facilitador: ayuda a los equipos alineados con el flujo a superar obstáculos y detecta las capacidades faltantes.
- Equipo de subsistema complejo: se forma cuando se necesita experiencia matemática/técnica significativa.
- Equipo de plataforma: proporciona una plataforma interna convincente para acelerar la entrega por parte de los equipos alineados con el flujo.
Como se ilustra en el modelo, el equipo de plataforma es transversal a todos los demás, garantizando un flujo de trabajo de autoservicio fluido, desde el código hasta la producción.
¿Por qué está surgiendo ahora la Ingeniería de Plataformas?
Pero, ¿por qué está ganando tanta fuerza ahora este enfoque? Varios factores contribuyen a esto:
1. La creciente complejidad de la nube nativa
A medida que las organizaciones adoptan arquitecturas de microservicios y tecnologías nativas de la nube, la complejidad de las operaciones de desarrollo aumenta exponencialmente. Los desarrolladores tienen que lidiar con contenedores, orquestación, redes, seguridad y mucho más.
2. La escasez de talento DevOps
Existe una escasez significativa de profesionales con experiencia en DevOps e infraestructuras en la nube. La ingeniería de plataformas permite que las organizaciones aprovechen mejor estos recursos escasos, creando soluciones reutilizables que benefician a toda la organización.
3. La presión por velocidad y calidad
Las empresas enfrentan una presión constante para entregar software más rápidamente, sin comprometer la calidad o la seguridad. La ingeniería de plataformas promete acelerar el desarrollo sin sacrificar estos aspectos críticos.
4. La necesidad de normalización a gran escala
A medida que las organizaciones crecen, la necesidad de normalización se vuelve más apremiante. La ingeniería de plataformas ofrece una forma de imponer estándares sin crear cuellos de botella en el proceso de desarrollo.
¿Ha muerto el DevOps?
Volviendo a nuestra pregunta original: ¿ha muerto el DevOps? La respuesta corta es: no, definitivamente no.
El DevOps no está muerto, está evolucionando. La ingeniería de plataformas no es un reemplazo del DevOps, sino una evolución natural que aborda algunas de las limitaciones prácticas de la implementación del DevOps en las organizaciones del mundo real.
El DevOps estableció los fundamentos: cultura de colaboración, automatización, medición y compartir (CAMS). La ingeniería de plataformas construye sobre estos fundamentos, proporcionando un marco más definido y sostenible para implementar estos principios a escala.
En esencia, la ingeniería de plataformas es la maduración del DevOps de una filosofía a un marco operativo. Proporciona una estructura clara para las organizaciones que desean los beneficios del DevOps sin exigir que cada desarrollador se convierta en un experto en todas las herramientas y tecnologías involucradas.
La transición a la Ingeniería de Plataformas
Si estás considerando la transición a la ingeniería de plataformas, aquí hay algunos pasos a considerar:
1. Evalúa tu madurez actual
Comienza identificando dónde está tu organización hoy en términos de capacidad de plataforma. Puedes utilizar el Modelo de Capacidad de Ingeniería de Plataformas para delinear dónde se encuentra tu organización en capacidades como inversión, adopción, gobernanza, aprovisionamiento y gestión, interfaces y medición/feedback.
2. Identifica tus objetivos
Define claramente lo que esperas lograr con la ingeniería de plataformas. Esto puede incluir:
- Aumentar la calidad de la aplicación, reducir errores y problemas durante el lanzamiento
- Mejorar la seguridad, reducir el número de incidentes de seguridad
- Disminuir el riesgo a través de una mejor conformidad
- Acelerar el tiempo para entregar valor al negocio
- Reducir los costos de desarrollo u operaciones
3. Construye tu equipo
Para que la ingeniería de plataformas tenga éxito, necesitas un equipo dedicado. Este equipo debe tener una combinación de habilidades, incluyendo desarrollo, operaciones, seguridad y una fuerte mentalidad de producto.
4. Comienza pequeño
No intentes resolver todos los problemas de una vez. Comienza con una "plataforma viable más delgada" (TVP - Thinnest Viable Platform) y crece a partir de ahí. Concéntrate en resolver los problemas más urgentes que tus desarrolladores enfrentan.
5. Cultiva la cultura correcta
La ingeniería de plataformas requiere una cultura organizacional que valore tanto la autonomía como la estandarización. Esto puede requerir cambios en la forma en que los equipos interactúan y cómo se mide el éxito.
En fin...
La ingeniería de plataformas representa una evolución significativa en la forma en que pensamos el desarrollo y la implementación de software. Aborda muchas de las dificultades prácticas que las organizaciones enfrentan al intentar implementar DevOps a escala, proporcionando un marco más tangible y operativo.
El DevOps no ha muerto: sus principios fundamentales de colaboración, automatización, medición y compartir son más relevantes que nunca. La ingeniería de plataformas es simplemente una manifestación más madura de estos principios, adaptada a las realidades de las organizaciones modernas de software.
A medida que la complejidad del desarrollo de software continúa aumentando, la ingeniería de plataformas probablemente se volverá aún más importante. Las organizaciones que adoptan este enfoque estarán ahora bien posicionadas para enfrentar los desafíos del mañana.
Entonces, ¿ha muerto el DevOps? No, simplemente ha crecido y madurado en la forma de la ingeniería de plataformas, preparándonos para el próximo capítulo en la evolución continua de cómo construimos y entregamos software.
Después de todo, como diría un viejo sysadmin, "la única constante en TI es el cambio". Y el cambio, en este caso, es definitivamente para mejor.
