DevOps significa que los desarrolladores ahora se hacen responsables de la infraestructura y el lanzamiento, pero ¿cuáles son los impulsores de este cambio?
Pondré mis cartas sobre la mesa: soy desarrollador y he trabajado tanto en "DevOps" como en otros. Tener que preocuparse por la infraestructura y los lanzamientos y el control de calidad y la ceremonia asociada es una gran distracción de escribir un buen código.
Pero la industria se está moviendo en esta dirección, entonces, ¿cuáles son las razones para esto? ¿Qué problemas engendró el "viejo" modelo de especialización de roles?
Respuestas:
La razón principal es la nube.
Solía ser que su código se envió en un disquete, y luego en CD, y luego se implementó en un servidor, y luego se implementó en dos servidores (por resistencia) ... Y toda esa implementación se podría hacer manualmente por un humano, entonces los humanos fueron entrenados para hacerlo.
Hoy, su código a menudo va a docenas o cientos de servidores. El aprovisionamiento, la configuración y la implementación en esos servidores no puede ser realizado de forma realista por un humano. Necesita que los administradores de su sistema conozcan las secuencias de comandos suficientes para automatizar ese proceso, ya que ahora está utilizando Chef o sus familiares. Pero, francamente, no había suficientes administradores de sistemas que pudieran hacer eso. Así que los desarrolladores fueron detenidos para recuperar la holgura.
Y sí, agregar más habilidades a los requisitos cada vez mayores de los desarrolladores naturalmente reducirá su competencia en otros lugares. La idea es que al permitir a los desarrolladores una visión del proceso de compilación / lanzamiento, pueden anticipar mejor los problemas o tener la autonomía para mejorarlo. La idea es que la calidad de todo aumente, ya que el lanzamiento gana supera las pérdidas de escritura de código.
Soy escéptico de que la compensación valga la pena tan a menudo como la gente cree que es.
fuente
Hay muchas razones diferentes para que varias organizaciones se trasladen a DevOps.
Trataré de enumerar los que aparecen a menudo.
Reduzca el tiempo para cambiar el ciclo
A menudo, transcurre un tiempo prolongado entre la solicitud de cambio y su implementación y uso en la organización. Primero, los desarrolladores lo planean en uno de los ciclos de desarrollo y, después de entregarlo, se planifican en uno de los ciclos de lanzamiento de las operaciones. Ambos ciclos incluyen pruebas y, en caso de problemas encontrados, ambos ciclos se reinician. Al integrar los departamentos de desarrollo y operaciones, podemos racionalizar ambos procesos.
Problemas de software vs hardware ¿
Recuerdas la caricatura de Bugs Bunny donde Bugs y Daffy están discutiendo si es temporada de patos o de conejos? Ahora imagine que lo hicimos con desarrolladores y operaciones donde los desarrolladores argumentan que es un problema de hardware y las operaciones argumentan que es un problema de software. Para el usuario final, esta es una distinción sin diferencia. Solo quieren que lo arreglen.
Al reunir a los desarrolladores y las operaciones, tendrán que solucionar los problemas. Y puede resultar que fue un problema de software y hardware.
Nosotros contra ellos
En muchas empresas, la distancia entre los probadores y los desarrolladores estaba creciendo porque eran departamentos separados y el ciclo de desarrollo se estaba volviendo cada vez más formalizado y estandarizado.
Con la llegada de Agile, los desarrolladores y evaluadores han estado trabajando más juntos y hemos comenzado a ver el punto de vista de cada uno sobre el ciclo de desarrollo y tal vez incluso llegamos a respetarlo.
Algo similar debe suceder entre los desarrolladores y las operaciones, ya que a medida que ambos campos maduran y los procesos se formalizan y estandarizan, la distancia entre estos departamentos está creciendo. Entonces, uno de los problemas con el modelo tradicional es que parece "nosotros" frente a "ellos" para desarrolladores y operaciones por igual. Ambos no comprenden completamente la dificultad de las responsabilidades del otro.
Expectativas / ventajas
Con DevOps, ambas especialidades aprenderán algunas de las habilidades tradicionalmente realizadas por la otra. Nadie esperará que un administrador del sistema se convierta en ingeniero de software o que un desarrollador se convierta en ingeniero de red, pero se espera que ambos asuman algunas de las responsabilidades del otro. Esto significa que cuando realmente necesitas algunas manos extra, están ahí.
Y hay algunos aspectos positivos para los desarrolladores: ahora tiene más control sobre sus entornos de prueba, le resultará más fácil implementar el software para los usuarios y contar con más personas en su organización para compartir su amor por el oficio.
fuente
Escribir código de calidad simplemente no es suficiente. Eres parte del problema o parte de la solución.
Para muchos programadores, estás escribiendo software que está siendo pagado por algún usuario final. Escribir código de calidad es algo bueno, pero también es algo que los clientes / gerentes suponen que siempre debe hacer y hacer rápido. Es como decir que un carpintero corta tablas con precisión, pero ¿está realmente construyendo algo por lo que alguien quiere pagar?
DevOps brinda a los desarrolladores más control y, con suerte, obliga a su código a estar en línea con el resultado final. ¿Quién es el más adecuado para automatizar el proceso de operaciones? La satisfacción del usuario final es el principal palo de medición. No solo debe escribir un código de calidad, sino que debe satisfacer al cliente. Lo sentimos, pero nadie volverá a usar líneas de código. No les importa si usted construyó su propio marco ORM desde cero, al igual que al comprador promedio de una casa no le importa si cortó el árbol e hizo sus propios tableros. ¿Alguien quiere rehacer todos sus archivos de configuración porque su "actualización" los restablece a los valores predeterminados?
¿Quieres presumir de tus habilidades de desarrollador? Cree algo que la gente quiera comprar y que incluya toda la experiencia del usuario. Es genial que esté escribiendo un código de calidad, pero desafortunadamente, es posible que no obtenga una bonificación si no se libera para la satisfacción del cliente que paga. Siéntase libre de culpar al control de calidad, pero su empresa aún no tiene suficiente dinero para pagarle más.
fuente
Es algo que ha ido de la mano con Agile & Scrum. Ya no hay roles de trabajo claramente definidos: todo el mundo es un "desarrollador".
Y no se trata solo de operaciones. Los desarrolladores a menudo tienen que asumir roles de análisis de negocios, pruebas, administración de bases de datos y gerente de construcción: la lista continúa.
En el centro del problema estaba lo que podríamos llamar abandono . A medida que aumentaba el número de roles diferentes involucrados en un proyecto, había más reuniones, malentendidos y enfrentamientos de recursos. Poner el software al frente de los usuarios rápidamente es el final del juego y cualquier cosa que pueda interponerse en el camino se ha dejado de lado.
Esto no es del todo malo. Su desarrollador promedio amplía sus habilidades, aunque el atasco se está volviendo muy delgado ahora. También evita los argumentos entre los codificadores y los administradores del servidor en cuanto a dónde se encuentran los problemas cuando las implementaciones siguen el camino de la pera. Los desarrolladores a menudo quieren implementar soluciones con tecnología de punta y los administradores del servidor a menudo no tienen idea de lo que esto significa desde un punto de vista de administrador hasta que se les presenta el conjunto de instalación.
Las empresas más brillantes y progresistas finalmente comienzan a darse cuenta de que las personas en forma de T son algo bueno. Sin embargo, hay una diferencia entre pensar que son algo bueno y esperar que esto suceda mágicamente donde previamente se había adoptado una cultura tradicional.
fuente
Estoy seguro de que hay más de algunas buenas razones para que los desarrolladores también administren las operaciones y el control de calidad (a veces). Aquí están tres de ellos:
Algunos desarrolladores realmente quieren trabajar todos los aspectos del producto. Si son buenos en eso, y si están llenando un vacío en el equipo o proporcionando un buen apoyo a los miembros existentes del equipo en otros roles, puede que no haya ninguna razón para detenerlos.
grandes empresas pueden pagar empleados especializados. Las pequeñas empresas a veces no pueden. Algunos de estos lugares pueden contratar a 1 o tal vez 2 o 3 desarrolladores que necesitan poder simplemente trabajar en la puerta.
No todos los proyectos son proyectos de muchas personas. Si está creando una aplicación "pequeña", puede ser excesivo tener más de 1 persona trabajando para completarla. Además, los pequeños proyectos con muchas personas que desempeñan funciones específicas dan miedo . Nadie tiene suficiente trabajo que hacer, incluso si puede permitirse mantenerlos a todos alrededor para girar sus pulgares durante 6 meses, los buenos no se quedarán. Si no se aburren, se asustarán, o te darás cuenta de que estás pagando bastante por nada. De cualquier manera, sus buenos empleados se irán y le dirán a todos que se mantengan alejados de usted.
... Y otras razones, estoy seguro.
fuente
"Tener que preocuparse por la infraestructura y los lanzamientos y el control de calidad y la ceremonia asociada es una gran distracción de escribir un buen código"
En esencia, creo que DevOps dice que preocuparse por la infraestructura y las versiones y el control de calidad ES escribir un buen código.
En roles anteriores que operan en culturas que no son DevOps, he tenido numerosos problemas que, posiblemente, una cultura DevOps podría haber evitado; problemas de rendimiento relacionados con el código que se desarrolló en plataformas no representativas, problemas de codificación de caracteres en los que los desarrolladores ignoraban las codificaciones de caracteres utilizadas por un cliente, instrucciones de implementación codificadas a mano e insuficientes para el equipo de operaciones sin algún tipo de conjetura -trabajo.
Ahora podría argumentar que una mayor especialización tanto en el lado de Dev como en el de Operaciones nos permite superar algunos de estos, pero aún así, muchas cosas solo se pueden resolver mediante el intercambio de conocimientos y trabajo entre nuestros equipos.
fuente
DevOps no tiene que significar "Dev ahora también hace operaciones". El término originalmente significaba "las personas Dev y Ops trabajan juntas estrechamente en un equipo". Eso hace media que el pueblo de Operaciones necesitan para ser más como Devs, debido a la automatización de las cosas requiere algún tipo de programación, y la forma manual de edad no lo corta (ver el resto de respuestas para una elaboración más detallada sobre este punto).
De Wikipedia :
En mi opinión, en realidad, si usted como Dev tiene las mismas responsabilidades de siempre y, además, ahora las responsabilidades de Operaciones, eso parece un error de cálculo por parte de la administración. Al automatizar las cosas, es muy posible que necesite menos personal de operaciones, por lo que en realidad hay un ahorro de costos. Pero DevOps ciertamente no significa "Eliminemos a todas las personas de Ops y dejemos que los Devs trabajen más".
Como ocurre a menudo con las palabras de moda, ocurre una difusión semántica , y de repente la gente piensa: "Hagamos que los desarrolladores también hagan operaciones, y creo que podemos ahorrar dinero ..."
fuente