El día de hoy 11 de Febrero hablare en un Meetup de SysArmy México, un tema bastante interesante que parece estar en boca de muchos, en la mente de pocos y el actuar de casi nadie.
Así es hoy día parece ser que los reclutadores y empresas hablan sobre una «nueva» vacante, DevOps y como todo diferentes precios, algunos totalmente irrisorios y otros realmente extravagantes.
Pareciera que este «nuevo» puesto, persona, habilidad, conocimiento… viniera un poco de la mano de las «fabulosas» nubes (Cloud ya se privada o pública), en realidad no. Pero se cruzaron en el camino y pues se sumo a la causa para obviamente vender certificaciones y productos (AWS, GCP, IBM, RedHat, etc..).
Pero, ¿entonces qué es o quién es un DevOps?, realmente conozco a muy pocos que les podría decir son un DevOps, y no digo que sea imposible sino que no es algo que aprendas en un curso virtual de esas plataformas que te venden ser experto en menos de 128 hrs. (aquí un enlace interesante de aprende a programar en diez años), así que dejaré que ustedes mismos lleguen a esa conclusión.
DevOps es un cambio de pensamiento, una vuelta de tuerca, algo que implica un cambio en la organizacional que impacta a la cultura, al proceso, ejecución y lo más importante a sus personas.
Si nos vamos a lo que dice Wikipedia:
DevOps (acrónimo inglés de development -desarrollo- y operations -operaciones-) es una práctica de ingeniería de software que tiene como objetivo unificar el desarrollo de software (Dev) y la operación del software (Ops). La principal característica del movimiento DevOps es defender enérgicamente la automatización y el monitoreo en todos los pasos de la construcción del software, desde la integración, las pruebas, la liberación hasta la implementación y la administración de la infraestructura. DevOps apunta a ciclos de desarrollo más cortos, mayor frecuencia de implementación, lanzamientos más confiables, en estrecha alineación con los objetivos comerciales.
En lo anterior solo leemos la punta del Iceberg, y gráficamente sería esta punta la que hace que muchas empresas fracasen al igual que el Titanic esa noche del 14 de abril de 1912 y que sus despliegues se hundan como el 15 de abril de 1912.
Y este es el Titanic del DevOps (es una metáfora).
Que lo que pretende es hacer una combinación de filosofías culturales, prácticas y herramientas que incrementen la capacidad de una «organización» de proporcionar aplicaciones y servicios a gran velocidad. Así cómo desarrollar y mejorar productos con mayor rapidez a diferencia de organizaciones (la competencia) que sigue usando procesos «tradicionales» de desarrollo de software y administración de la infraestructura.
En palabras mortales, hacer más dinero reduciendo el tiempo en que terminado el desarrollo llega a su salida productiva y esta empieza a generar ganancia. Y para llegar a esto debemos lidiar con algunos problemas convencionales:
Miedo al cambio:
Una vez que estamos a gusto con una versión, cuando sale una es normal la resistencia a este por posible frágilidad y vulnerabilidad. Y la burocrática pero necesaria manera de gestión de cambios para poder introducir nuevas funcionalidades o soluciones a problemas de la aplicación.
Despliegues arriesgados:
Este es el suplicio de cada salida a producción, dónde se hace un llamado a todas las áreas involucradas para «asegurar» que el producto tenga vida en producción. Y pero la realidad es que nadie sabe si realmente va a funcionar y cada área se coloca en su trinchera y es un fuego cruzado.
Él ¡Funciona en mi máquina!
Esto es tan típico que los PM’s o Gerentes no te creen y te amenazan con tu despido, sino averiguas la solución del problema que se presenta en producción. Esta situación es muy simple de explicar, en mi experiencia he visto lo siguiente:
- Desarrollo
Máquinas con Windows con una versión X del compilador o interprete del lenguaje diferente a la de otros ambientes, así como la configuración de propiedades y servidores de aplicaciones.
- Test (que realmente no existe y debería tener lo mismo que el ambiente productivo)
Un ambiente previo a producción tiene otra versión de sistema operativo, de interprete o máquina virtual, de servidor de aplicaciones. Y cuando hacen pruebas son solo de happy path, y jamás probaron lo que debían y cómo debían.
- Producción
Este ambiente no solo tiene otra versión otra versión de sistema operativo, de interprete o máquina virtual, de servidor de aplicaciones. Y la configuración es diferentes en los archivos de propiedades, y aunado a esto arriba de el hay dos servidores sirviendo de CDN, un balanceador de carga, una alta disponibilidad en los servidores.
Muchos de los problemas de diferentes versiones es por temas de licenciamiento, de recursos, de responsables de área. Así que es muy valido decir que funciona en mi máquina si funciona, debido a que no es lo mismo la máquina y ambiente del desarrollo que la puesta en producción.
Mi departamento/Mi Área/Mi aislamiento
Este es el gran muro, la separación, las castas, las culturas.. etc… En un desarrollo de una nueva o legada aplicación nos encontramos con el equipo de desarrollo, evaluadores (testers), administradores de versiones y administradores de sistemas. Estos son por citar algunos, y este no solo es un factor atenuante, a veces muchos de estos ni siquiera están en la misma oficina, ciudad o inclusive ni en el mismo país (y la diferencia de horario como rompe, las buenas costumbres de uno).
La suma de todos estos factores lo único que logra es una mentalidad de «nosotros y ellos», un grupo de personas (que están en el mismo proyecto) que al mismo tiempo desconfían y temen entre sí.
Este es el problema que intenta erradicar el pensamiento/movimiento DevOps, fusionando no solo equipos, sino pensamientos. Lo que debe hacer es que ingenieros trabajen en todo el ciclo de vida de la aplicación (desde el desarrollo, pruebas, implementación y las operaciones) en conjunto, no en aislamiento, para así desarrollar habilidades no limitadas a su única función.
En algunos modelos de operaciones de desarrollo, los equipos de control de calidad y de seguridad también se integran más con el desarrollo y las operaciones e intervienen durante todo el ciclo de vida de la aplicación. Cuando la seguridad es la prioridad de todos los miembros del equipo de operaciones de desarrollo, a veces se conoce como operaciones de seguridad de desarrollo.
Así que el movimiento Devops se basa en un grupo de personas que creen que la aplicación de una combinación de tecnología y actitud adecuadas puede revolucionar el mundo del desarrollo y la entrega de software.
Los beneficios de esto es:
- Velocidad
- Entrega rápida
- Fiabilidad
- Escalado
- Colaboración mejorada
- Seguridad
Y esto empieza a integrarse o interconectarse con las siguientes ideas:
- Integración continua
- Entrega continua
- Microservicios
- Infraestructura como código
- Monitorización y registro
- Comunicación y colaboración
Todo lo anterior ayuda a las empresas de desarrollo a poder crear productos finales en «menor» tiempo haciendo frente a la competencia, siempre y cuando se aplique correctamente.
Así que pueden preguntarse nuevamente, son un DevOps o son partidarios de esta nueva corriente. No es un quién, es un qué.
Pero no siempre las ideas son bien abordadas e implementadas por las empresas, a veces por desconocimiento o por simple pereza de leer qué es.
Veremos ejemplos de lo que ofertan las empresas respecto a DevOps:
Primero veremos lugares que piensan que una sola persona es un DevOps
Y en ellas podremos ver que piden cosas diferentes en cada una de ellas, jugando el amplio espectro del concepto de Devops.
Ahora veremos dónde buscan es la cultura de DevOps:
Con esto parece más complejo responder si es qué o quién, la realidad no lo es. El problema es el error de las empresas y su área de reclutamiento (que ciertamente no saben, solo apuntan, publican, agendan y marcan por teléfono), y este error hará que lleguen al mismo destino que el Titanic.
