¿Qué diablos es DevOps?

Una breve historia del tiempo

Para entender DevOps, tenemos que viajar en el tiempo a la vejez cuando no había nada más que programadores.

Como nos enseña el Tao:

Los programadores de antaño eran misteriosos y profundos. No podemos comprender sus pensamientos, así que todo lo que hacemos es describir su apariencia:

• Consciente, como un zorro cruzando el agua
• Alerta, como un general en el campo de batalla
• Amable, como una anfitriona saludando a sus invitados
• Simple, como bloques de madera sin tallar
• Opaco, como piscinas negras en cuevas oscuras

El programador dio a luz al lenguaje de máquina. El lenguaje máquina dio origen al ensamblador. El ensamblador dio a luz al compilador. Ahora hay miles de idiomas. Cada idioma tiene su propósito, por humilde que sea. Cada idioma expresa el Yin y el Yang del software. Cada idioma tiene su lugar dentro del software.

En ese momento, las oficinas de desarrollo de software se llamaban en su mayoría laboratorios y los programadores eran científicos. Para crear una buena aplicación, los programadores tenían que comprender completamente el problema que estaba resolviendo la aplicación. Tenían que saber dónde se usará la aplicación y qué tipo de sistema la ejecutará. En esencia, los programadores sabían todo acerca de su aplicación, desde la especificación, pasando por el desarrollo, hasta la implementación y el soporte.

Y luego la naturaleza humana entró en acción y comenzamos a pedir más. Más velocidad, más funciones, más usuarios, más de todo.

Al ser criaturas modestas, humildes y pacíficas, los programadores tenían muy pocas posibilidades de sobrevivir a ese estallido de usuarios necesitados que siempre pedían más. La mejor oportunidad para prevalecer era comenzar a evolucionar en diferentes direcciones y crear castas. Pronto, los programadores se extinguieron como antepasados ​​de nuevas razas llamadas desarrolladores, ingenieros de software, administradores de red, desarrolladores de bases de datos, desarrolladores web, arquitectos de sistemas, ingenieros de control de calidad y muchos más. Evolucionar rápidamente y adaptarse a los desafíos del mundo exterior se convirtió en parte de su ADN. La nueva casta podría evolucionar en cuestión de semanas. Los desarrolladores web se convirtieron en desarrolladores de back-end, desarrolladores de front-end, desarrolladores de PHP, desarrolladores de Ruby, desarrolladores de Angular… todo se estaba yendo al infierno.

Pronto todos olvidaron que venían del mismo padre, un Programador. Un científico simple y pacífico que solo quería hacer del mundo un lugar mejor. Comenzaron a pelear entre sí, alegando que cada uno de ellos es verdadero descendiente de "El Programador" y que su sangre es más pura que la de los demás.

Con el paso del tiempo, redujeron su interacción al mínimo y hablaron entre ellos solo cuando realmente tenían que hacerlo. Dejaron de celebrar el éxito de sus familiares lejanos y, finalmente, incluso dejaron de enviar una postal de vez en cuando.

Si solo buscaran en sus sentimientos, descubrirían que la chispa del Programador estaba en sus corazones, esperando brillar y traer paz a la galaxia.

En su carrera egoísta y egocéntrica por conquistar el mundo, los descendientes de programadores olvidaron el verdadero propósito de su trabajo: resolver problemas para sus clientes. Los clientes comenzaron a sentir el dolor de tal comportamiento cuando los proyectos se retrasaban, eran demasiado caros o incluso fracasaban.

De vez en cuando, brillaba una estrella brillante y alguien se inspiraba para tratar de hacer las paces entre Los Descendientes. Se les ocurrió Waterfall. Esta fue una idea brillante, ya que utilizó el hecho de que diferentes grupos de desarrolladores se comunicaban solo cuando era necesario. Cuando un grupo terminaba su parte del trabajo, se comunicaba con el siguiente grupo para enviar el trabajo a través del proceso y nunca lo miraba hacia atrás.

Esto funcionó por un tiempo, pero como de costumbre, los humanos (Clientes) querían más de nuevo. Querían participar más activamente en todo el proceso de creación de software, dar su opinión más a menudo y pedir cambios incluso cuando ya era demasiado tarde.

Los proyectos de software se volvieron tan propensos a fallar que se aceptaron como un estándar de la industria. Las estadísticas mostraron que más del 50% de los proyectos estaban fallando y parece que no había nada que hacer al respecto (ZDNet, CNet)

Cada generación tuvo algunas personas de mente abierta que sabían que todos estos grupos de desarrolladores tenían que encontrar una manera de trabajar juntos, comunicarse y ser flexibles para asegurar que sus clientes recibirían la mejor solución posible. Hay rastros de estos intentos ya en 1957, por parte de colegas del gran John Von Neumann. Sin embargo, tuvimos que esperar hasta principios de 2001 para comenzar la revolución, cuando una docena sucia creó un Manifiesto Ágil.

El Manifiesto Ágil se basa en doce principios:

1. Satisfacción del cliente mediante la entrega temprana y continua de software valioso
2. Bienvenido a los requisitos cambiantes, incluso en el desarrollo tardío
3. El software que funciona se entrega con frecuencia (semanas en lugar de meses)
4. Cooperación estrecha y diaria entre empresarios y desarrolladores.
5. Los proyectos se construyen alrededor de individuos motivados, en quienes se debe confiar
6. La conversación cara a cara es la mejor forma de comunicación (ubicación conjunta)
7. El software funcional es la principal medida del progreso
8. Desarrollo sostenible, capaz de mantener un ritmo constante
9. Atención continua a la excelencia técnica y al buen diseño
10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial
11. Equipos autoorganizados
12. Adaptación regular a las circunstancias cambiantes.

El manifiesto ágil fue el primer gran paso para llevar la paz a la Galaxia y restablecer el equilibrio en la Fuerza. Por primera vez en mucho tiempo, la conexión de todas las partes interesadas en el proceso de desarrollo de software se basó en la forma cultural y "humana", tanto como en la forma procesal y mecanizada. Las personas comenzaron a hablar entre sí, a reunirse regularmente e intercambiar ideas y comentarios todo el tiempo. Se dieron cuenta de que tenían mucho más en común de lo que pensaban, y los clientes se convirtieron en parte del equipo, no solo en un factor externo que se esperaba que enviara el dinero y no hiciera preguntas.

Todavía quedaban algunos obstáculos por superar, pero el futuro parecía más brillante que nunca. Ser ágil significa estar abierto y dispuesto a adaptarse a los cambios constantes. Sin embargo, con tantos cambios, es difícil mantenerse enfocado en el objetivo final y la entrega. Y así es como nació Lean Software Development.

Enganchados al LSD (juego de palabras) y arriesgándose a ser exiliados y marginados, algunos de los descendientes buscaron soluciones fuera de su casta y de la industria del software. Encontraron la salvación en las obras de un importante fabricante de automóviles. El sistema de producción de Toyota fue asombroso en su simplicidad y fue tan obvio que su manufactura esbelta se puede aplicar fácilmente al desarrollo de software.

Hay 7 principios de Lean:

1. Eliminar residuos
2. Calidad de construcción en
3. Crear conocimiento (amplificar el aprendizaje)
4. Diferir compromiso (decidir lo más tarde posible)
5. Entregar lo más rápido posible
6. Respetar a las personas (empoderar al equipo)
7. Optimizar el Todo

Agregados además de Agile, los principios Lean respaldaron la mentalidad y el enfoque en hacer las cosas correctas, al tiempo que fueron flexibles durante todo el proceso.

Una vez que Agile y Lean fueron adoptados por los equipos de desarrollo de software, solo fue necesario un paso más para aplicar todo el conjunto de principios a TI como un todo, ¡lo que finalmente nos llevó a DevOps!

Introduzca DevOps - Autopista de tres carriles

La visión de la vieja escuela de los equipos de desarrollo de software incluía analistas de negocios, arquitectos de sistemas, desarrolladores front-end, desarrolladores back-end, evaluadores, etc. La optimización del proceso de desarrollo de software, incluidos los principios ágiles y esbeltos, se centró principalmente en estos. Una vez que la aplicación estuvo "lista para la producción", se envió a "Operaciones", incluidos los ingenieros de sistemas, los ingenieros de lanzamiento, los administradores de bases de datos, los ingenieros de redes, los profesionales de seguridad, etc. La principal fuerza impulsora de DevOps es eliminar el gran muro entre Dev y Ops .

DevOps es el resultado de implementar principios Lean en todo el flujo de valor de TI. El flujo de valor de TI extiende el desarrollo a la producción, combinando todos los 'parientes lejanos' que descienden del programador original.

Gene Kim da la mejor explicación de las soluciones DevOps, y si no ha leído The Phoenix Project , le sugiero que se tome un tiempo y lo haga.

No debe contratar a un ingeniero de DevOps y DevOps no debe ser un departamento nuevo en su TI. DevOps es una cultura, una mentalidad y es parte de TI como un todo. No existen herramientas que conviertan su TI en una organización DevOps , y ningún nivel de automatización permitirá a sus equipos brindar el máximo valor a sus clientes.

DevOps generalmente se conoce como un método de tres vías, pero las veo como tres carriles de la misma carretera. Empiezas en el carril uno, luego aceleras y cambias al carril dos, y finalmente estás acelerando en el tercer carril.

• Carril uno: el rendimiento del sistema en su conjunto es el punto focal principal y se enfatiza sobre el rendimiento de cualquier elemento individual del sistema.

• Carril dos: asegúrese de que haya un bucle de retroalimentación constante enviado aguas arriba y que no se ignore

• Carril tres: fomentar los experimentos, la mejora constante y fallar rápido

Carril uno - Ponerse al día

Comprender la importancia de todo el sistema y priorizar correctamente los elementos de trabajo es lo primero que debe aprender una organización de TI al adoptar los principios de DevOps. Nadie en el flujo de valor de TI puede crear un cuello de botella y reducir el flujo de trabajo.

Asegurar un flujo de trabajo ininterrumpido es el objetivo final para todos los que participan en el proceso. Independientemente del rol que tenga una persona o un equipo, es imperativo que busquen lograr una comprensión profunda del sistema. Adoptar esta forma de pensar tiene un impacto directo en la calidad, ya que los defectos nunca se envían a la corriente porque causarían cuellos de botella.

Asegurarse de que el trabajo no se estanca no es suficiente. Una organización productiva siempre debe buscar aumentar el flujo. Existen numerosas metodologías para aumentar el flujo. Puede encontrar una solución en Theory Of Constraints, Six Sigma, Lean o Toyota Production System. Siéntase libre de elegir cualquiera de estos, crear el suyo propio o combinarlos.

A los principios de DevOps no les importa a qué equipo pertenece, si es arquitecto de sistemas, administrador de bases de datos, control de calidad o administrador de red. Las mismas reglas se aplican a todos, y se espera que todos sigan dos principios simples:

• Mantenga el flujo del sistema ininterrumpido
• Aumente y optimice el flujo de trabajo en todo momento

Carril dos - Prepárate

El flujo ininterrumpido del sistema es unidireccional y se espera que pase del desarrollo a las operaciones. En un mundo ideal, esto significa que el software se crea rápidamente con alta calidad, se implementa en producción y brinda valor a los clientes.

Sin embargo, DevOps no es una utopía, y si la entrega unidireccional fuera posible, el método de cascada sería suficiente. Evaluar los entregables y comunicar el flujo es muy importante para asegurar la calidad. El primer canal de comunicación "ascendente" que debe implementarse es Ops to Dev.

Chocar los cinco contigo mismo es fácil, pero pedir retroalimentación y dar retroalimentación es la forma de ver la imagen real. Es imperativo que cada pequeño paso aguas abajo sea seguido por una confirmación aguas arriba instantánea.

No importa cómo establezca el circuito de retroalimentación. Puede invitar a los desarrolladores a unirse a las reuniones del equipo de soporte o traer al administrador de la red a la planificación de sprint semanal. Mientras sus comentarios estén en su lugar, y los comentarios sean recogidos y manejados, su organización está acelerando por la autopista DevOps.

Carril tres - Warp 10

El carril rápido de DevOps no es para débiles de mente. Para subirse al carril rápido de DevOps, su organización debe ser lo suficientemente madura. Se trata de tomar riesgos y aprender del fracaso, experimentar continuamente y aceptar que la repetición y la práctica son el requisito previo para el dominio. Muy a menudo escuchará el término Kata, y esto es por una razón. El entrenamiento continuo y la repetición conducen al dominio porque hace que los movimientos complejos se conviertan en una rutina.

Pero antes de comenzar a combinar movimientos, es imperativo que primero domines cada paso individual.

“Lo que es apropiado para el Maestro no es apropiado para el novicio. Debes entender el Tao antes de trascender la estructura”.

DevOps Third Way/Fast Lane incluye asignar tiempo para la experimentación continua a diario, recompensar constantemente al equipo por asumir riesgos e introducir fallas en el sistema para aumentar la resiliencia.

Para asegurarse de que su organización no se derrumbe al implementar este tipo de medidas, debe crear circuitos de retroalimentación frecuentes entre todos los equipos, mientras se asegura de que todos los cuellos de botella estén claros y el flujo del sistema no se interrumpa.

La implementación de estas medidas hace que su organización esté alerta en todo momento y sea capaz de responder a los desafíos de manera rápida y efectiva.

Resumen: lista de verificación de la organización DevOps

Aquí hay una lista de verificación que puede usar para validar cómo DevOps habilita su organización de TI. Por favor, siéntase libre de comentar el artículo y agregar sus propios puntos.

• No hay muro entre el equipo de desarrollo y el equipo de operaciones. Ambos son parte del mismo proceso.
• El trabajo que se envía de un equipo a otro siempre se verifica y es de la mejor calidad.
• No hay “apilamiento” de trabajo y todos los cuellos de botella se manejan
• El equipo de desarrollo no utiliza el tiempo de Operaciones para sus actividades, porque la implementación y el mantenimiento son parte del mismo cuadro de tiempo.
• El equipo de desarrollo no entrega el código para la implementación a las 5:00 p. m. los viernes, lo que deja a operaciones para limpiar su trabajo durante el fin de semana.
• Los entornos de desarrollo están estandarizados y las operaciones pueden reproducirlos fácilmente y escalarlos a la producción.
• El equipo de desarrollo puede entregar nuevas versiones cuando las considere apropiadas y las operaciones pueden implementarlas fácilmente en producción.
• Hay líneas de comunicación claras entre todos los equipos.
• Todos los miembros del equipo tienen tiempo para experimentar y trabajar en la mejora del sistema.
• Los defectos se introducen (o simulan) y se tratan en el sistema de forma regular. Las lecciones aprendidas de cada experimento se documentan y comparten con todas las personas relevantes. El manejo de incidentes es una rutina y en su mayoría se maneja de una manera conocida

Conclusión

El uso de herramientas DevOps modernas como Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS, etc. no significa que esté aplicando los principios de DevOps. DevOps es una forma de pensar. Todos somos parte del mismo proceso, compartimos el mismo tiempo y entregamos valor juntos. Cada persona que participa en el proceso de entrega de software puede acelerar o ralentizar todo el sistema. Un error creado durante el desarrollo puede provocar la caída del sistema, así como la configuración incorrecta del firewall.

Todas las personas son parte de DevOps, y una vez que su organización lo entienda, las herramientas y la tecnología que lo ayudarán a administrarlo aparecerán mágicamente.