DevOps: ¿qué es realmente?

Hola a todos!

Hemos impreso el libro "Filosofía DevOps", y también planeamos hacer un nuevo libro sobre este tema.


Se han roto muchas copias sobre qué es y qué no es DevOps, así como la relación entre DevOps y la integración continua. Por lo tanto, le pedimos que hable de la manera más objetiva posible, ¿comparte el punto de vista del autor de hoy Adam Mackay (Adam Mackay) con respecto a la esencia de DevOps o, en su opinión, la imagen que propuso es algo incompleta o sesgada?

¡Leemos y comentamos!

He trabajado en el campo tecnológico toda mi vida, y justo ante mis ojos varias metodologías de desarrollo de software han madurado y se han formado. La mayoría de las ideas subyacentes se reducen a la optimización habitual de la productividad en el espíritu del sentido común y se toman prestadas de diferentes sectores de la economía. Hace unos años, todos querían pasar de un modelo de desarrollo en cascada a un desarrollo ágil y ágil. Recientemente fui a trabajar en una compañía progresista, donde están tratando de implementar DevOps. Esta compañía, Verifa, se ha adherido a Agile durante mucho tiempo y está tratando de extender las ventajas de este modelo no solo al desarrollo de software, sino también al negocio en general.

DevOps es una nueva palabra de moda en la industria del software. Este concepto combina muchas ideas sólidas sobre la integración de negocios y desarrollo, así como la formulación de una narrativa que nos permite hablar sobre el desarrollo, entrega y operación de software en un solo contexto.



DevOps es un enfoque en el que los ingenieros de desarrollo y los ingenieros administrativos participan juntos en todo el ciclo de vida de un producto de software, desde el diseño y desarrollo hasta el soporte completo del producto. Por lo tanto, DevOps está diseñado para eliminar la desunión tradicional, donde un equipo escribe el código, el otro lo prueba, el tercero se implementa y el cuarto es responsable de la operación.

Con DevOps, los empleados de sysadmin comienzan a utilizar, con el apoyo de los sistemas que se les han confiado, muchas de las técnicas que se han solucionado en el arsenal del desarrollador. En DevOps, la ingeniería de sistemas se construye exactamente como un flujo de tareas durante el desarrollo. Todos los recursos se ingresan en el sistema de contabilidad de origen y se cubren mediante pruebas apropiadas.

Tenemos varios temas clave de DevOps en nuestra empresa: valores, principios, métodos, prácticas y herramientas.



Valores

Cualquier ingeniero está encarcelado por encontrar una solución, y tal aspiración a veces se traduce en un rechazo de las nuevas tecnologías, una falta de voluntad para experimentar con cosas nuevas, que se expresa de diferentes maneras: desde el síndrome del "rechazo del desarrollo de otro" hasta los intentos contraproducentes para defender el nicho de uno. Para una verdadera transición a DevOps, estos prejuicios primero deben ser reconocidos y luego superados. Ninguna tecnología, ni Docker, Kubernetes o Amazon Web Services resolverán sus problemas si no comprende cuál es la propuesta de valor.



"¡De la mano amigos!" Instantánea de Rawpixel de Unsplash

Principios

Los principios de nuestra empresa se basan en el modelo Three Ways. Fue desarrollado por Gene Kim, autor de "Visible Ops" y "The Phoenix Project", y Mike Orzen, autor de "Lean IT". Recomendamos construir un entorno en el que se estimule el pensamiento sistémico, se fortalezcan los ciclos de retroalimentación y se inculque una cultura de experimentación y aprendizaje continuos.
Piensa constantemente en todo el sistema. Pregúntese: "¿Cómo se obtienen aún más bucles de retroalimentación?" El monitoreo, las métricas y el registro son tres de estos ciclos que ayudan a los administradores a participar en el diseño. En un entorno DevOps saludable, se estimulan los procesos que promueven la creación de ciclos de retroalimentación cortos y efectivos, ejemplos de tales procesos son la gestión de incidentes, el análisis objetivo de la autopsia, la transparencia ...



"Apretón de manos antes de MacBook Pro", una instantánea de rawpixel de Unsplash

Métodos

Gestión flexible

Flexible = simple. Divida su proyecto en pequeñas áreas de trabajo, construya, limite el límite de progreso, implemente bucles de retroalimentación y logre la visualización. Este es mi elemento favorito de cualquier proyecto; las técnicas de gestión flexible proporcionan un resultado más efectivo, incluida la mejora del rendimiento y la estabilidad del sistema; los empleados experimentan menos estrés en el trabajo y obtienen más satisfacción laboral.

Primero las personas, luego los procesos, luego las herramientas

Una de las primeras metodologías propuestas por los pioneros de DevOps se formula como “primero personas, luego procesos, luego herramientas”. En nuestra empresa, se recomienda que primero acuerde quién es responsable de una tarea de trabajo específica. Luego determinamos qué procesos son necesarios para resolver este problema. Después de eso, se seleccionan las herramientas necesarias para la implementación del proceso. En el papel, todo esto parece lógico, sin embargo, los ingenieros y gerentes a menudo sucumben al pegadizo "¡date prisa por conseguirlo!" de proveedores y en este caso están tratando de hacer exactamente lo contrario: comprar una herramienta y luego formar todo el flujo de tareas para ella.

Entrega continua

Este término está tan en boca de todos que a veces incluso se equipara erróneamente con DevOps. En principio, esta es la práctica de la programación dinámica y las pruebas de software, que proporcionan versiones rápidas de fragmentos muy pequeños, completos y listos para usar. En general, la entrega continua puede mejorar la calidad y la velocidad en general. La entrega continua es un componente clave del proyecto, que debe establecerse lo antes posible, el factor impulsor para la implementación exitosa de DevOps.

Gestión del cambio



En mi experiencia, existe una correlación directa entre qué tan bien se opera el sistema y cómo se organiza la gestión del cambio. Esto no significa que deba implementar el control tradicional, que ralentiza el desarrollo y es más probable que sea perjudicial que ayudar. En este caso, necesita una plataforma escalable y confiable para la entrega continua. Concéntrese en eliminar los artefactos frágiles, la reproducibilidad del proceso de construcción, la gestión de dependencias y la creación de un entorno propicio para la mejora continua.

Infraestructura en código (Configuración en código ... Todo en código)

Una de las revelaciones con las que la compañía actual me ha enriquecido es que cualquier sistema puede y debe interpretarse como código. Las especificaciones del sistema se ingresan en los sistemas de control de versiones y se revisan por pares. Usando mecanismos de implementación modernos, en particular, Docker y Kubernetes, puede construir, probar y crear automáticamente sistemas reales basados ​​en las especificaciones y administrarlos mediante programación. Este enfoque le permite compilar y ejecutar el sistema, y ​​no hacer las laboriosas muletas a largo plazo, que con el tiempo se vuelven muy difíciles de desarrollar.

Practica

En todas las organizaciones de TI anteriores donde trabajé, el enfoque de los proyectos fue: "escribamos algo ... y luego le indicaremos a alguien que lo pruebe y lo implemente". Este método no encaja bien con los planes. El tiempo cambia, y cuando el equipo de desarrollo pasa al siguiente proyecto, los costos operativos se vuelven insoportables.



"Montaña rusa bajo un cielo azul y nubes blancas", una instantánea de Priscilla Du Preez de Unsplash

En la organización actual, nos esforzamos por mantener a los desarrolladores al tanto del servicio que crearon y parcialmente responsables de su funcionamiento. El resultado son ciclos de retroalimentación más eficientes que ayudan al equipo a responder mucho más rápidamente no solo a los errores, sino también a las nuevas características y a garantizar que el producto se desarrolle en la dirección correcta.

Las herramientas

¡Amamos nuestras herramientas! Ayudan al ingeniero a programar, ensamblar, probar, empaquetar, liberar, configurar y rastrear sistemas y aplicaciones. Somos dueños de nuestras herramientas y conocemos toda la gama de soluciones que nos interesan, tanto de código abierto como comercial. Antes de que el paradigma DevOps comenzara a desarrollarse, la innovación y las herramientas estaban estancadas. Durante mucho tiempo utilicé las mismas herramientas que al principio de mi carrera (he estado programando desde 2000). Muchas de las herramientas utilizadas en DevOps son increíblemente versátiles y ayudan a organizar el ciclo de vida de servicio de una manera completamente nueva.



"Todo tipo de herramientas de carpintería en el taller" de la colección Barn Images de Unsplash

Debe decidir sobre herramientas confiables para DevOps. No existe una herramienta única para todas las ocasiones, necesita una línea completa, cuyo inventario se puede combinar teniendo en cuenta las necesidades existentes. Y dado que queremos que todo esto funcione en conjunto ... cualquier herramienta es tan útil como ayuda a todo nuestro sistema.

Debe elegir herramientas que funcionen bien con el resto de su inventario. Las herramientas deberían ayudar a automatizar cualquier trabajo. Deben ser fáciles de llamar desde la API o desde la línea de comandos. En principio, las herramientas que dependen mucho de la interfaz de usuario no se ajustan muy bien, incluso en herramientas bien integradas.

¿Qué sigue?

Descargue la imagen de la ventana acoplable y comience a experimentar. Bifurca el código de otra persona y comienza a construirlo. Implemente un servidor o clúster de servidores con Kubernetes. Entonces haces DevOps. Comience en su propia computadora y luego vaya a la nube.



"Un niño parado en las escaleras y buscando las nubes", filmado por Samuel Zeller de Unsplash

Cuando escuche por primera vez sobre el paradigma de "infraestructura en código" o "entrega continua", inmediatamente quiere decir "no, funciona de manera diferente con nosotros". Sin embargo, para tener éxito con DevOps, debe dominar gradualmente estas técnicas, no son tan complicadas. Durante muchos años, la industria ha utilizado métodos que son exactamente lo opuesto a DevOps, pero DevOps realmente funciona.