Llegamos a ustedes gracias a:



Reportajes y análisis

El lado oscuro de DevOps: Prevenir es estar preparados

[31/10/2018] DevOps es una filosofía organizacional cada vez más popular que fomenta la colaboración entre el personal de desarrollo y operaciones -tal vez incluso combinándolos en un solo departamento-, y prescribe la integración constante y la entrega continua (CI/CD) del nuevo código, con funciones de software siendo implementadas de forma incremental cada pocos días o semanas, en lugar de desplegarlas como enormes actualizaciones monolíticas. En teoría, hace que el desarrollo sea más ágil y reduce los conflictos internos.

Por supuesto, la teoría no siempre funciona en la práctica. Hablamos con personas que han ayudado a desplegar DevOps en el mundo real para descubrir el lado oscuro de esta filosofía -tanto los problemas inherentes a él, como las formas en que los implementadores a menudo se quedan cortos o se equivocan. Esperamos que estos cuentos de precaución lo ayuden a iniciar cualquier lanzamiento con los ojos abiertos.

DevOps es más que un conjunto de herramientas

Ernest Mueller, en el sitio Agile Admin, define lo que él describe como "herramientas DevOps":

Herramientas que utilizaría en la comisión de estos principios. En el mundo de DevOps ha habido una explosión de herramientas en el lanzamiento (jenkins, travis, teamcity), gestión de la configuración (títere, chef, ansible, cfengine), orquestación (zookeeper, noah, mesos), monitoreo, virtualización y contenedorización (AWS, OpenStack, vagrant, Docker), y muchos más. Mientras que, al igual que con Agile, es incorrecto decir que una herramienta es "una herramienta DevOps" en el sentido de que mágicamente le traerá DevOps, ciertamente se están desarrollando herramientas específicas con el objetivo expreso de facilitar los principios, métodos y prácticas anteriores, y una comprensión holística de DevOps debería incorporar esta capa.

Desafortunadamente, tratar a estas u otras herramientas como un tótem que "mágicamente le traerá DevOps" es exactamente lo que hacen muchos departamentos, sin hacer un esfuerzo por cambiar los procesos o la mentalidad. "Mike", que trabajó en la oficina del CTO de una empresa de tecnología de tamaño mediano durante su intento de cambio a DevOps, describe este tipo de visión de "culto del cargo" de DevOps. "Voy a culpar a la limitada visión del ingeniero por esto", señala, "porque los ingenieros de software analizan los problemas con las soluciones de software. Nosotros tratamos a DevOps como un conjunto de tecnologías que se instalarían en muchas aplicaciones. Esto es totalmente erróneo, es muy difícil elegir por dónde empezar. Compramos copias de The Phoenix Project para todos los que quisieran una. Tuvimos lecciones de 'almuerzo y aprendizaje' sobre Ruby y Chef. Ejecutamos hackathons y, de hecho, obtuvimos las mejores calificaciones en proyectos de infraestructura.

Resultó que la transición de DevOps de Mike estaba plagada de fallas, y atribuye gran parte de la culpa a este fracaso original de comprender en qué consistía realmente el proyecto en el que se estaba embarcando. "Si DevOps no es software, ¿qué es?" pregunta. "Mirando hacia atrás me siento tonto por no darme cuenta. DevOps es una cultura y cambiarla es una de las cosas más difíciles que puede hacer una organización. Las personas -y quizás los ingenieros en particular- son naturalmente desafiantes y no aceptan fácilmente los edictos que vienen de lo alto. La cultura debe ser cultivada desde adentro por buenos gestores, que son difíciles de encontrar en las organizaciones de software, añade.

No todos van a estar a bordo

Y eso nos lleva a nuestro próximo lado oscuro de DevOps. El sueño es que su personal técnico se sume con entusiasmo a la nueva filosofía y forma de hacer las cosas que DevOps conlleva. La realidad es que el cambio es difícil, y muchas personas no ven nada malo en el trabajo que ya están haciendo y en la forma en la que lo hacen. Cody Swann es el CEO de Gunner Technology, una firma de desarrollo de software que ayuda a las organizaciones del sector público y privado a cambiarse a DevOps -y lo ha visto todo, si de resistencia se trata -como algunos empleados tomando medidas activas para hacer la transición lo más difícil posible. Por ejemplo, en una asignación, los empleados cuestionaron la viabilidad de la nueva infraestructura que estaban proponiendo. "El equipo de operaciones intentó demostrar que los microservicios son una moda", señala, "y no son sostenibles para proyectos más grandes porque son muy difíciles de mantener y que JavaScript no puede escalar".

Las cosas no necesariamente mejoraron a medida que pasaron a la implementación. "Estábamos desmontando una enorme infraestructura .NET monolítica en microservicios de JavaScript basados en AWS Lambda", comenta. "Parte de esto incluía la migración de datos de Oracle a una solución DynamoDB/Elasticsearch". ¿Qué se puede sacar de todo eso? "El equipo de operaciones tomó la posición de que era imposible otorgarnos acceso a Oracle para migrar los datos. Obviamente, las excusas fueron inventadas -afirmaron que la base de datos solo estaba disponible para direcciones IP internas, por ejemplo. Finalmente, configuramos una conexión de enlace VPN desde AWS para migrar los datos, pero hubo una gran cantidad de rechazo al hacerlo".

En la transición de Mike, las cosas empeoraron aún más, porque terminaron desafiando el sentido de identidad profesional de algunos empleados. "En una cultura DevOps local, el dolor de las malas implementaciones y las fallas de producción lo sienten directamente los ingenieros que construyeron el sistema, comenta. "En un enfoque tradicional de dos equipos, las operaciones se realizan solas para corregir los errores de producción. Les gusta esto. Arreglar un error de producción y devolver el servicio a un estado completamente funcional es algo legendario. El solo acto de que alguien diga, 'Pon a Gary al teléfono, él es el único que puede arreglar esto', y luego ser Gary, y en realidad arreglarlo, es la mayor avalancha de endorfinas y sensación de satisfacción con el trabajo que la mayor parte de los geeks de computadoras nunca han tenido, añade.

Pero la transición a DevOps, cualesquiera que sean sus otros beneficios, "iba a eliminar todo esto", explica Mike. "Así que los administradores del sistema fueron a otro lugar para obtener su solución. Además, sin centros de datos y cosas funcionando en la nube, los ingenieros de redes no tenían mucho que hacer. Podrían volver a capacitarse, o podrían ir a otro lado". ¿El resultado? "La mitad del equipo de operaciones renuncia".

Los intentos de conseguir que el personal restante construya los marcos necesarios para CI/CD también tuvieron problemas. "Resulta que a los programadores de telecomunicaciones de Java de la vieja escuela no les gusta escribir Ruby", explica Mike. "Son altamente especializados, hacen su trabajo muy bien y no necesariamente tienen o no quieren la amplia variedad de habilidades necesarias para escribir instaladores idempotentes en otro idioma. Pasamos un montón de tiempo tratando de motivar a las personas dándoles la propiedad de sus aplicaciones desde los diseños iniciales hasta el despliegue de producción. Mientras que algunas personas disfrutaron de este nuevo enfoque holístico y adoptaron la mentalidad de DevOps fácilmente, la mayor parte de ellos quería trabajar en lo que eran buenos".

La seguridad, como siempre, es un problema

DevOps puede no ser más inseguro que otras filosofías organizacionales, pero su implementación puede causar problemas de seguridad de formas nuevas y emocionantemente diferentes. "Con la integración continua y la entrega continua (CI/CD) como el principal impulsor en DevOps, una gran parte de las buenas prácticas de seguridad a menudo son automatizadas o excluidas del proceso, simplemente por el impacto que tiene en la velocidad de los lanzamientos de software", explica Davy Hua, director de DevOps para ShiftLeft. "Como resultado, aumentar la velocidad de los lanzamientos, a menudo, producirá un código incorrectamente revisado, lo que puede conducir a una pérdida inadvertida de datos confidenciales para el registro de puntos finales o heredar vulnerabilidades de bibliotecas de software de terceros, como fue el caso con la violación de Equifax".

"Ya sea que la aplicación sea un monolito o esté dividida en varios microservicios, las complejidades entre los flujos de datos requieren mucha comprensión y conocimiento para implementar un programa de seguridad efectivo", continúa Hua. "Unir las complejidades con la restricción de tiempo, otro factor para acelerar los lanzamientos, dará lugar a un cierto nivel de descuido cuando se trata de la ejecución de la seguridad".

Igor Livshitz, director de gestión de productos en GuardiCore, considera que la seguridad se está convirtiendo en un problema particular en DevOps cuando es "integrado en diferentes puntos de acceso del proceso DevOps en vez de ser un subproducto posterior a la implementación".

"En el mundo actual de instancias de corta duración, microservicios e infraestructuras híbridas, cualquier punto de control basado en humanos no puede mantenerse", explica. "Por lo tanto, el control de la política es transferida a los desarrolladores como parte de un modelo de responsabilidad compartida. Estos se encargan de describir la política necesaria que se debe poner en acción para su aplicación y, los administradores de seguridad de la red pueden revisarla y también aplicar herramientas de auditoría y monitoreo para garantizar que no haya infracciones de política o cumplimiento. De esta manera, todas las partes están contentas: DevOps y los desarrolladores pueden moverse rápidamente sin esperar a que les den luz verde y que los administradores de seguridad consigan políticas estrictas creadas por los propietarios de las aplicaciones que solo necesitan ser auditadas.

Sin embargo, con demasiada frecuencia, este escenario ideal no se desarrolla en la vida real. "Todo esto se puede romper si hay una falta de confianza entre la seguridad y las funciones de DevOps en la organización. En los casos en que lo hemos encontrado, los dos son generalmente parte de unidades de negocios separadas y han estado trabajando en ello por años -la parcialidad está arraigada en el ADN de la compañía. La desconfianza puede haberse originado en un incidente de seguridad que ocurrió debido a una falta de conocimiento de una o ambas partes que llevó a la inactividad de las aplicaciones o servicios debido al "bloqueo excesivo" por parte de los equipos de seguridad". Para Livshitz, la clave para evitar esto es generar confianza entre los equipos e "integrar los controles de seguridad necesarios como parte del ciclo DevOps, controles que deben ser definidos por los equipos de seguridad. Estos deben ser capaces de hacer auditorías y monitorear todo lo que tenga que ver con la violación de la política dentro de esas aplicaciones.

Muévase rápido, pero no demasiado rápido

El punto principal del cambio a DevOps es que termina produciendo actualizaciones de software útiles más rápidamente. No obstante, con frecuencia los equipos piensan que su cambio a DevOps debería ir igual de rápido -con resultados desastrosos, especialmente si el cambio cultural de la fuerza laboral no tiene la oportunidad de seguir el ritmo. El resultado puede ser una especie de tienda Frankenstein mitad DevOps. Ed Price, director de cumplimiento en Devbridge Group, da un ejemplo de algunas señales de advertencia: "Si las empresas siguen viendo migraciones de código manual y ponen manualmente el código en producción. Si aún dependen de un equipo de entornos. Si no ven una unidad, regresión o pruebas de rendimiento automatizadas integradas en su canal de CI para evitar que el código llegue al mercado que aún no está listo".

También toma tiempo conseguir la combinación de personal que necesita para un buen equipo de DevOps. Es posible que no se encuentre con el escenario que describimos anteriormente en el que la mitad de su personal renuncia, pero eso no significa que simplemente meta a todos en la mezcla y espere que funcione. "Es común que las organizaciones identifiquen a las estereotipadas 'estrellas de rock' -los miembros de alto rendimiento del equipo, que son seleccionados para cualquier nueva iniciativa", señala Justin Rodenbostel, vicepresidente de desarrollo de aplicaciones de código abierto en SPR. "Sin embargo, la creación de equipos basados estrictamente en la destreza técnica o la experiencia en materia empresarial, puede ser contraproducente si no se consideran otras habilidades como la colaboración y la comunicación".

Construir para el crecimiento

Si hay una lección que aprender de todo esto, es que las personas son las más importantes para determinar si su proyecto DevOps va al lado oscuro o a la luz. "Favorecer a las personas que tienen una mentalidad de 'estado estable', en lugar de entender lo que significa construir DevOps desde cero", señala Ryan Duguid, Chief Evangelist de Nintex. "Cuando esto sucede, los equipos terminan con una ingeniería excesiva, un gasto descomunal o una sofisticación demasiado difícil de manejar. Tiene que tener personas que puedan venir y decir 'Ok, ¿qué se necesita aquí?' no 'Esto es lo que hice en mi último trabajo'. Si es una empresa de estado estable, tiene sentido contratar personas de estado estable. Sin embargo, si está comenzando el viaje, necesita un talento que comprenda, que haya construido DevOps desde cero y sepa cómo regresar a lo básico. "La lección para los novatos de DevOps: asegúrense de construir la cultura correcta desde cero, y aprendan a caminar antes de intentar volar.