Elogio fúnebre para DevOps

El concepto y la historia de DevOps

• DevOps es un concepto introducido alrededor de 2007, con el objetivo de eliminar la separación entre las personas que administran hardware y las que escriben software
• Al principio, fue un intento de aumentar la seguridad de los despliegues de código imitando procedimientos e ideas de la NASA
• En ese momento, el proceso de despliegue de software era el siguiente:
  • El equipo de desarrollo preparaba una versión del software del servidor, el equipo de QA la probaba y luego se desplegaba al cliente
  • El equipo de operaciones recibía un playbook con los cambios del software y cómo responder si surgían problemas
  • Las actualizaciones se desplegaban gradualmente dentro del centro de datos mientras se monitoreaban
  • Se fijaba una fecha de despliegue y se monitoreaba después del despliegue

Los problemas de DevOps

• DevOps era muy intensivo en trabajo
• Requería colaboración entre el equipo de desarrollo, el equipo de QA, redactores técnicos y el equipo de operaciones
• El despliegue de funcionalidades era lento y se priorizaban las actualizaciones importantes
• Muchas organizaciones adoptaron DevOps por las siguientes razones:
  • No era fácil reemplazar al personal técnico
  • Contratar era difícil y costoso
  • Los vendors de SaaS reducían la complejidad
  • Se enfatizaban las ventajas de las plataformas en la nube
  • Los desarrolladores estaban molestos porque pequeños cambios tardaban mucho en desplegarse

Cómo era realmente DevOps

• DevOps tenía como objetivo integrar al equipo de desarrollo y al equipo de operaciones en un solo equipo
• Se despidió al equipo de QA, y el período de pruebas internas se redujo gracias a despliegues rápidos y retroalimentación veloz
• A veces DevOps se confunde con el SRE de Google, pero SRE tiene un enfoque más estructurado y estricto
• El proceso real de DevOps era el siguiente:
  • Un desarrollador crea una rama en git y agrega una funcionalidad
  • Abre un PR y, después de que un compañero lo revisa, se fusiona en main
  • El sistema de CI/CD inicia la compilación y hace push del contenedor al registro
  • El sistema de CD notifica a los servidores sobre una nueva release y monitorea si el despliegue fue exitoso
  • Se monitorean los cambios posteriores al despliegue mediante métricas de reconocimiento de release

Factores del fracaso de DevOps

• Los desarrolladores probaban en entornos locales y desplegaban en servidores Linux, lo que generaba pequeñas diferencias
• Como el equipo de operaciones no monitoreaba el despliegue, era difícil resolver problemas
• Los desarrolladores carecían de conocimiento sobre la operación de sistemas
• La introducción de contenedores resolvió algunos problemas, pero la complejidad operativa seguía presente

La introducción de los contenedores y sus límites

• Los contenedores resolvieron el problema de "en mi máquina sí funciona"
• Simplificaron los componentes de configuración de los servidores Linux
• Problemas que aún permanecían
  • Operar: mantenimiento de infraestructura, upgrades, etc., que requieren especialización
  • Observar: dificultad para construir y administrar sistemas de monitoreo complejos
  • Retroalimentación continua: deficiencias en el manejo de la retroalimentación interna
  • Descubrir: falta de intercambio de conocimiento entre equipos
  • Planificar: dificultad para establecer una planificación centralizada

La aparición de Platform Engineering

• Platform Engineering es un concepto posterior a DevOps: en lugar de que el equipo de desarrollo entienda la operación de la plataforma y resuelva problemas, un equipo de plataforma se encarga de ello
• Este enfoque separa con claridad las responsabilidades entre el equipo de desarrollo y la operación de la plataforma, dejando más claro el reparto de roles, pero sigue requiriendo muchas habilidades técnicas
• Tanto los desarrolladores como el equipo de operaciones tienen que hacer más trabajo

Conclusión

• Está creciendo la tendencia a buscar herramientas simples y no atadas a una plataforma dentro del espacio de infraestructura
• Muchas organizaciones están abandonando tecnologías complejas como Kubernetes y volviendo a workflows más simples
• Platform Engineering no es una solución universal, y las organizaciones deben distinguir entre lo que realmente necesitan y lo que no
• Se deben conservar las ventajas del enfoque DevOps mientras se pone el foco en la simplificación y la estabilidad

Opinión de GN⁺

1. La evolución de DevOps y su situación actual muestran bien el cambio de tendencias en la industria tecnológica. Resulta interesante reconocer la brecha entre los objetivos ideales iniciales y la realidad, y el proceso de buscar un enfoque práctico

2. La transición hacia platform engineering parece ser un intento de reconocer los límites de DevOps y buscar nuevas soluciones. Sin embargo, tampoco es una solución perfecta, y hará falta un enfoque personalizado según el tamaño y las características de cada organización

3. A medida que aumenta la complejidad de las tecnologías cloud native y de la arquitectura de microservicios, se está reevaluando la simplicidad y la estabilidad. Esto sugiere que, al elegir tecnología, deben considerarse aún más el valor de negocio y la eficiencia operativa

4. Los cambios en DevOps y platform engineering enfatizan la importancia del aprendizaje continuo y la adaptación en el desarrollo y la operación de software. Los profesionales técnicos deberán desarrollar no solo el aprendizaje sobre nuevas herramientas y metodologías, sino también la capacidad de equilibrar los requisitos de negocio con la complejidad técnica

5. Se espera que, en el futuro, las formas de desarrollar y operar software adopten enfoques más flexibles y situacionales. En lugar de que grandes organizaciones y startups pequeñas sigan el mismo método, se fortalecerá la tendencia a elegir los procesos y herramientas óptimos según la situación de cada una

[kaydash]

Bastante a menudo
los directivos
esperan que con solo adoptar el concepto de DevOps
aparezca una gran innovación sin esfuerzo
sin importar si se trata de empresas grandes o pequeñas
ese es el pensamiento equivocado de las empresas anticuadas

[GN⁺]

Opinión de Hacker News

• La clave es enfocarse en "build, test, deploy" en el diagrama del "ciclo de devops"

  • Se puso el énfasis en la velocidad y no se tomó en cuenta la excelencia en ingeniería
  • Despidieron al equipo de operaciones y reestructuraron QA
  • Todos los equipos terminaron teniendo una rotación de guardias
  • Se introdujeron cambios caóticos en el sistema por beneficios a corto plazo
  • Después de unos meses, cada cambio empezaba a causar problemas
  • Las herramientas de devops eran útiles, pero costosas y frustrantes
  • Los desarrolladores nuevos no conocen devops, pero sí saben de contenedores

• Es una opinión basada en los problemas que enfrentó un equipo de devops

  • Debería ser posible agregar nuevos servicios y administrar la infraestructura de forma segura
  • Devops se volvió el estándar, y ya no se necesita trabajo manual de administrador de sistemas

• Las críticas a Kubernetes están equivocadas

  • Kubernetes es un gran ejemplo de excelente ingeniería de software, tiene buen soporte y corre en todas partes
  • Es mejor aprender Kubernetes que usar scripts de bash al azar

• Devops consiste en eliminar barreras para facilitar el despliegue de software

  • Los despliegues diarios ayudan a entregar código de mayor calidad
  • Es importante tener la opción de desplegar solo cuando el código esté listo
  • Los lanzamientos mensuales generan presión y pueden llevar a decisiones ineficientes

• Devops es una filosofía, no una metodología

  • El objetivo es integrar operaciones en el SDLC
  • La nube hizo esto más fácil
  • La aparición de equipos de "DevOps" distorsionó la filosofía original

• Eso de "romper los silos" desde liderazgo es casi algo ceremonial

  • La autoridad sin responsabilidad no funciona
  • El mejor talento de devops disfruta reemplazarse a sí mismo con código
  • Las herramientas de devops son maduras y están bien documentadas
  • Un desarrollador que no aprende Kubernetes es como un desarrollador que no conoce comandos de Linux

• Si los usuarios pueden ser testers, entonces deberían serlo

  • Solo hay un problema económico
  • Si hay muchos clientes, se puede dejar que los usuarios prueben; si hay pocos, hay que probar directamente

• Los equipos de plataforma solo son viables en grandes empresas

  • Las pymes tienen escasez de personal de devops, así que deben asumir estrés y riesgo
  • La ausencia de un equipo de plataforma causa muchos problemas

• Devops es una filosofía, no una metodología

  • La experiencia en equipos en silos demuestra la necesidad de devops
  • Devops permite que los equipos entiendan y desplieguen por completo un proyecto

• Devops tiene buenas intenciones

  • Los ciclos rápidos de retroalimentación son importantes para la velocidad de desarrollo
  • Hay que encontrar la solución óptima para la organización y el producto