[26/08/2022] Con el trabajo de desarrollo de software cada vez más complejo, podría ser el momento de que los especialistas en desarrollo y operaciones se separen una vez más. ¿Pero puede hacerse sin repetir los errores del pasado?
Devops surgió de la mano del auge de las metodologías ágiles y la computación en la nube a finales de la década del 2000, cuando el software empezó a comerse el mundo. El término devops, una combinación de "desarrollo" y "operaciones", pretendía reunir a los dos grupos que antes estaban separados y que eran responsables de la creación y el despliegue del software. También coincidió, o incluso impulsó inadvertidamente, la necesidad de que los ingenieros de software estrecharan sus bucles de retroalimentación con el usuario y enviaran actualizaciones a producción con mayor frecuencia.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Mientras que muchas organizaciones aprovecharon esta oportunidad para reunir a dos conjuntos de especialistas para resolver problemas comunes a velocidades antes imposibles, otras tomaron el aumento de devops como una licencia para que los desarrolladores se responsabilizaran de las tareas de operaciones, y trataron de construir un súper equipo de desarrolladores full-stack semi mítico.
"Los desarrolladores no quieren ocuparse de las cuestiones operativas, en su mayor parte", tuiteó la autora de Devops for Dummies y responsable de la participación de la comunidad en Amazon Web Services, Emily Freeman.
Freeman dio claramente en el clavo, con cientos de respuestas de desarrolladores que tampoco querían hacer operaciones.
"Soy un desarrollador y no quiero ocuparme de las operaciones", respondió Scott Pantall, un ingeniero de software de la empresa de comida rápida Chipotle.
"Los devs y los ops deberían trabajar estrechamente, pero con roles diferenciados. La empatía entre los equipos es el verdadero punto", opinó Andrew Gracey, evangelista de desarrolladores en SUSE.
Aunque el concepto de desplazar más preocupaciones operativas y de seguridad "hacia la izquierda" y hacia el dominio de los desarrolladores de software tiene claramente sus méritos, también tiene el potencial de crear un peligroso cuello de botella.
"Si se arrastra a los desarrolladores a demasiadas áreas diferentes, se acaba disparando en el pie. Son conjuntos de habilidades diferentes", sostiene James Brown, jefe de producto del especialista en almacenamiento Kubernetes, Ondat.
O como dijo Nick Durkin, CTO de campo en Harness: "La gente está empezando a darse cuenta de que no contrataríamos a un electricista para hacer nuestra fontanería".
Un aumento "masivo" de las responsabilidades
Mientras que el número de desarrolladores de software empresarial nunca ha sido tan alto, la experiencia especializada de las operaciones técnicas se ha desvanecido un poco en el fondo, incluso cuando sus cargas de trabajo han aumentado.
Como escribió el año pasado Mathew Duggan, ingeniero de devops y antiguo administrador de sistemas, aunque los operadores "seguían teniendo todas las responsabilidades que teníamos antes, asegurando que la aplicación estuviera disponible, supervisada, segura y cumpliera con las normas", también se les ha encomendado la tarea de construir y mantener pipelines de entrega de software, "sentando las bases para potenciar el desarrollo para sacar el código de forma rápida y segura sin que nosotros nos involucremos".
Estas responsabilidades en expansión implicaron un esfuerzo de reciclaje masivo, donde las habilidades de ingeniería de la nube y de infraestructura como código se volvieron primordiales.
"En mi opinión, la situación nunca ha sido más sombría", escribió Duggan. "Desarrollo se ha visto completamente abrumado con un aumento masivo del alcance de sus responsabilidades (RIP QA), pero también con expectativas poco realistas por parte de la dirección en cuanto a la velocidad".
Esa presión puede estar empezando a notarse.
"Es increíblemente desafiante construir una organización que logre este nivel de armonía iterativa que dure un período sostenible", escribió Tyler Jewell, director gerente de Dell Technologies Capital en una nota de investigación. "A medida que los sistemas crecen en complejidad y aumenta la retroalimentación del usuario final, se vuelve cada vez más difícil para un humano razonar sobre el impacto que un cambio podría tener en el sistema".
Reconocer el problema
Puede que la situación no sea tan desesperada como creen Duggan y otros, aunque puede requerir un reajuste significativo de los equipos de ingeniería y sus responsabilidades.
"La intención no es hacer recaer la carga sobre el desarrollador, sino que se trata de dotar a los desarrolladores de la información adecuada en el momento oportuno", anota Durkin, de Harness. "No quieren configurarlo todo, pero sí quieren la información de esos sistemas en el momento adecuado para que los equipos de operaciones y seguridad e infraestructura puedan trabajar adecuadamente. Los desarrolladores no deberían preocuparse a menos que algo se rompa".
Nigel Simpson, ex director de estrategia tecnológica empresarial de Walt Disney Company, quiere que las empresas "reconozcan este problema y trabajen para que los desarrolladores dejen de preocuparse por el funcionamiento de la maquinaria y vuelvan a crear software, que es lo que mejor saben hacer".
Es importante recordar que devops es un continuo y que su implementación variará de una organización a otra. El hecho de que los desarrolladores puedan hacer algunas operaciones ahora no significa que siempre deban hacerlo.
"El control de los desarrolladores sobre la infraestructura no es una propuesta de todo o nada", escribe Lydia Leong, analista de Gartner. "La responsabilidad puede dividirse a lo largo del ciclo de vida de la aplicación, de modo que se pueden obtener beneficios de usted lo construye, usted lo ejecuta' sin necesariamente lanzar en paracaídas a sus desarrolladores a un desierto indómito y desconocido, y desearles suerte para que sobrevivan porque ya no es 'un problema del equipo de infraestructura y operaciones'".
En otras palabras, "está perfectamente bien permitir a sus desarrolladores un acceso total de autoservicio a los entornos de desarrollo y pruebas, y la capacidad de construir infraestructura como plantillas de código para la producción, sin hacerlos totalmente responsables de la producción", escribe Leong.
Como lo ve Brown en Ondat, la orquestación de contenedores con Kubernetes está surgiendo como la capa entre estos dos equipos, separando las preocupaciones para que los desarrolladores puedan centrarse en su código, y las operaciones puedan asegurar que la infraestructura subyacente y los pipelines estén optimizadas para ejecutarlo. "No rebobinemos hasta que esos equipos no se hablen entre sí", señala Brown.
De hecho, según el informe "State of Kubernetes in 2022" de VMware, el 54% de los 776 encuestados dijo que una mejor eficiencia de los desarrolladores era una razón clave para adoptar Kubernetes, y más de un tercio (37%) dijo que quería mejorar la eficiencia de los operadores.
"No caiga en la falacia de intentar que todo el mundo sea un experto", escribe Kaspar von Grunberg, fundador de Humanitec, en su boletín electrónico. "En los equipos de alto rendimiento, hay pocos expertos de alto perfil en Kubernetes, y hay un alto nivel de abstracción para mantener la carga cognitiva baja para todos los demás".
El devops ha muerto
Si la era del devops está realmente llegando a su fin, o incluso si el brillo está empezando a desaparecer, ¿qué viene después?
La ingeniería de fiabilidad del sitio (SRE, por sus siglas en inglés), que surgió de Google cuando sufrió sus propios dolores de crecimiento relacionados con devops, ha demostrado ser una solución popular.
"Fundamentalmente, es lo que ocurre cuando se pide a un ingeniero de software que diseñe una función de operaciones", suele decir Ben Treynor, vicepresidente de ingeniería de Google y padrino de la SRE.
Tomemos como ejemplo las dos grandes instituciones financieras, Vanguard y Morgan Stanley, que han tenido dificultades para equilibrar las responsabilidades de desarrollo y operaciones en su transición hacia prácticas más nativas en la nube.
La inserción de una manta de seguridad de SER, tanto a nivel de operaciones centrales como dentro de los equipos de desarrolladores individuales, ha ayudado a ambas empresas a construir la confianza de que están logrando el equilibrio adecuado entre la velocidad de los desarrolladores y la estabilidad operativa.
Sin embargo, la función de SRE también ha suscitado algunas críticas. Establecer los principios de la SRE "a veces se malinterpreta como un cambio de marca del equipo de operaciones", como observó Trevor Brosnan, jefe de devops y arquitectura tecnológica empresarial de Morgan Stanley.
"Es un problema con matices que hay que resolver", sostiene Christina Yakomin, ingeniera de fiabilidad de sitios en Vanguard. "Introducir la SRE hace que la gente sienta que estamos aislando a ops de nuevo en ese papel". En su lugar, Yakomin quiere animar a los desarrolladores de Vanguard y a los especialistas en operaciones a compartir la responsabilidad de la seguridad, y asegurarse de que los equipos con plataformas compartidas asuman toda la responsabilidad operativa de las mismas.
Viva la ingeniería de plataformas
La idea de la plataforma interna para desarrolladores, o la disciplina de la ingeniería de plataformas, también ha surgido como una forma de que las organizaciones proporcionen a los desarrolladores las herramientas que necesitan, junto con las barandillas organizativas adecuadas para que los desarrolladores puedan hacer su mejor trabajo.
Una plataforma interna para desarrolladores suele estar formada por las API, las herramientas, los servicios, los conocimientos y el apoyo que los desarrolladores necesitan para poner su código en producción, combinados en una plataforma estándar de la empresa que es mantenida por un equipo dedicado de especialistas, o propietarios de productos.
"Devops ha muerto, larga vida a la ingeniería de plataformas", tuiteó el ingeniero de software y comentarista de devops, Sid Palas. "A los desarrolladores no les gusta lidiar con la infra, las empresas necesitan controlar su infra a medida que crecen. La ingeniería de plataforma permite que estos dos hechos coexistan".
Brandon Byars, jefe de tecnología de la consultora de software Thoughtworks, dice que a menudo "ve que esa división funciona bien en los equipos de ingeniería de plataformas, que buscan eliminar la fricción para los desarrolladores, mientras les dan diales para girar". Sin embargo, añade, "donde no funciona bien es pidiendo a los desarrolladores que hagan todo ese trabajo sin experiencia centralizada y apoyo de herramientas".
El acto de equilibrio entre los equipos de desarrollo de software y los de operaciones será familiar para cualquier organización que haya trabajado para implementar los principios de devops en sus equipos de ingeniería. También es un acto de equilibrio que se está convirtiendo cada vez más en la cuerda floja en la era de la complejidad nativa de la nube.
Basado en el artículo de Scott Carey (InfoWorld) y editado por CIO Perú
Puede ver también: