#DevOps ¿Cuáles son las problemáticas que resuelve?

edux

Hablando de DevOps, y saliendo de las cosas marketineras de vendor como tooling en particular o frameworks, cuales consideran que son las problemáticas que DevOps resuelve o intenta resolver, ademas del objetivo claro que es acelerar el desarrollo del producto y mejorar la calidad? Me refiero a cosas como:

• Reducir la curva de aprendizaje de los nuevos team members ya sea de Dev, QA u Ops.

Tiren todo lo que se les ocurra. La mejor respuesta tiene free beer.

msx

Desde un punto de vista puramente operativo una buena imágen es la de módulos apilados que proveen la flexibilidad de ser intercambiables por otros módulos del mismo nivel - o capa.

Como dice @SalvorKun una infraestructura modularizada te permite adaptarla ágilmente a necesidades específicas, de cualquier índole: escalamiento, actualizaciones atomizadas, testing seguro, optimización de recursos, agilidad de desarrollo y operaciones. De esta forma el único factor inamovible realmente es el fierro en sí porque todo lo demás puede adaptarse y moldearse de acuerdo la necesidad específica.

La idea de un DevOps es - por favor corríjanme si me equivoco - proveer el entorno necesario a los desarrolladores y testers para que éstos puedan ocuparse de realizar su trabajo de forma transparente - optimizando así los tiempos y recursos - a la vez que provee una mecánica segura de puesta en producción y rollback.

Para mi lo más interesante de una so-called 'cultura DevOps' es que elimina la fricción entre ninjas de la infra y devolodontes obligando a que ambas áreas encuentren un espacio de trabajo común que redunda - o debería - en una mejor calidad del producto en base a las optimizaciones realizadas en el proceso de desarrollo y despliegue.

Un tema aparte quizás más complejo es el de 'SecOps', o cómo mantener segura una estructura que está en continuo cambio adaptándose a las necesidades que van surgiendo a cada momento. Lo que se plantea hoy es fusionar todas estas nuevas metodologías en algo llamado 'DevSecOps' (yeah, suena horrible) de forma que ahora se incorpore a los especialistas en seguridad a los equipos DevOps para que sean parte activa de los mismos en vez de seguir corriendo a la zaga en un eterno catch-up.

Saludos.

SalvorKun

Para empezar, releyendo tu pregunta, entiendo que todo esto va dirigido al punto de vista de cultura o políticas internas, y no a "como hacer las cosas, o con qué hacer las cosas". Por lo cual voy por ese lado.

Hay dos cosas importantes que en mi opinión se centra y no se le da bola en demasía, espero tener el tino para explicar por qué es que eso pasa.

La mejora de la comunicación

La primera vez que plantee este "pilar" en una charla, una persona bastante cerrada a la comunicación del grupo que tiene encima de 30 años en el rubro me planteó que "Hace 30 años que trabajo de esto y todo el mundo dice que hay que comunicarse mejor, pero nadie se manda un mail entre ellos".
El planteo de #DevOps va por otro lado que un simple correo. Lo primero que se busca es la descentralización de las responsabilidades, y un parate completo en algo que yo creo que todos hacemos: buscar culpables.
Es muy normal en un ambiente de trabajo que el día que algo falla lo primero que escuchemos es "Quien hizo tal cosa". Encontrar quien es el culpable no nos va a servir de nada en la solución del problema.
Por otro lado, la mejora de la comunicación lleva a la mejora en cuanto a la información que se maneja, inclusive el cliente. Blanquear las cosas que salen mal mejoran la confianza en el producto, y que las cosas que salen bien estén claras, y nos juegue a favor. Un cliente informado es un cliente feliz.

Dejar de tomar a la infraestructura como el núcleo central

Y para eso entra en juego algo que me gusta de DevOps, la Infraestructura como Código (Infrastructure as code). El hecho de tratar a nuestra infraestructura como un sistema en movimiento y cambiante, que se pueda versionar y que se adapta fácilmente a cualquier inserción externa.
Manejarnos de esa manera nos lleva a conocer un poco de Continuous Delivery. Y aun así, a mi gusto, la parte más importante no es eso, sino la capacidad de poder monitorear todo eso en un "Continuous Monitoring". Conocer nuestra infraestructura y sus cambios nos llevan a un mejor código de la misma.

 

Mejor que cualquier pavada inentendible o vueltera que yo pueda escribir con pocos fundamentos, es un poco de lo que se puede encontrar ahí afuera, algunas cosas interesante para leer:

What DevOps means to me (en el blog de Chef): https://www.chef.io/blog/2010/07/16/what-devops-means-to-me/
Understanding DevOps - Part 5: Infrastructure as Code: https://sdarchitect.wordpress.com/2012/12/13/infrastructure-as-code/

Y unos papers gratis en Kindle:

What is DevOps: http://www.amazon.com/gp/product/B0084HJB56?redirect=true&ref_=kinw_myk_ro_title
Building a DevOps Culture: http://www.amazon.com/gp/product/B00CBM1WFC?redirect=true&ref_=kinw_myk_ro_title
5 Unsung Tools of DevOps: http://www.amazon.com/gp/product/B00GM4E7DE?redirect=true&ref_=kinw_myk_ro_title
The ToolStack for DevOps (by Diego Woitassen): https://www.airpair.com/devops/posts/the-toolstack-for-devops-engineer

curif

Excelentes las respuestas de @msx y @SalvorKun, agregaría la particularidad de que DevOps es la célula de trabajo buscando cumplir el ciclo de vida de un producto (el famoso dibujo del infinito con los procesos de planning->code->build->test->release->deploy->operate->monitor->plann...). Como DevOps Engineers buscamos ayudar a que eso ocurra brindando automatizaciones, rompiendo silos, y participando activamente del ciclo en lo que nos competa.

https://help.sysarmy.com/discussion/comment/1091#Comment_1091

También me parece importante citar lo que NO es DevOps. Hay mucho ruido en el mercado, y dentro de ese ruido lo que mas me molesta es que nombren a los profesionales que realizamos esta práctica como "los DevOps" o "el DevOps" ya que DevOps es la celula y su proceso, no la persona que cumple el rol. En todo caso hablaría de un DevOps Engineer.

Slds!