DevOps significa que los desarrolladores ahora se hacen responsables de la infraestructura y el lanzamiento, pero ¿cuáles son los impulsores de este cambio?

18

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?

process devops

— Ben
fuente

44

¿Está diciendo que la calidad de su código está bajando porque hace otras cosas o que la cantidad de su código está bajando?

— Caleth

1

Quita tus cartas de la mesa, por favor. Esto solo se lee como una queja tal como está.

— svidgen

77

@svidgen Si esta pregunta fuera puramente una queja, sería diferente, pero el OP tiene derecho a expresar su opinión, así como a hacer una pregunta perfectamente válida.

— Robbie Dee

1

@robbie seguro. notará que lo respondí de todos modos ... pero, la parte de "opinión" de esta pregunta consume más de la mitad del cuerpo, intercalada entre la misma pregunta básica reiterada, y distrae de la pureza potencial de la pregunta básica en este caso. Pero si. Todavía vale la pena responder ..

— svidgen

19

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.

— Telastyn
fuente

2

Me perdiste en " La razón principal es el trasero ".

— tedder42

15

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.

— Miguel van de Laar
fuente

44

+1 - Porque se trata del usuario final y no solo del código.

— JeffO

3

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.

— JeffO
fuente

2

Estoy seguro de que sabe lo difícil que es contratar buenos desarrolladores de software. Y ahora necesitamos que sean buenos analistas de negocios, interesados en la ceremonia de control de calidad y preocupados por los procesos de lanzamiento. El número de personas que se encuentran con el nuevo bar será muy pequeño.

— Ben

2

@Ben: No hay "y ahora"; Estas son cosas que los buenos desarrolladores estaban haciendo décadas antes de que alguien pensara que DevOps era algo nuevo y acuñó el término. Su trabajo como desarrollador es resolver problemas que se extienden desde la necesidad de alguien de una solución para asegurarse de que las personas que tienen que manejar su código después de que lo haya escrito no tengan dificultades. No escatime en nada y a nadie le importará lo bien que estén hechas sus clavijas cuadradas si necesitan un trineo de diez libras para meterlas en agujeros redondos.

— Blrfl

Esto parece un argumento contra la especialización. Que una persona debe ser un gato de todos los oficios maestro de ninguno. Eso no se sugiere en ninguna otra industria, no tienes electristas-albañiles-fontaneros-techadores tratando de entender cada detalle sobre la construcción de una casa

— Richard Tingle

2

@ RichardTingle: Nadie dice que tiene que entender todo, pero sí tiene que entender las cosas que su producto tocará cuando se use. Un plomero tiene que saber lo suficiente sobre lo que hacen los electricistas, o al menos trabajar con uno, para saber que no es seguro hacer pasar una tubería de agua fría a través de una caja de interruptores a pesar de que hay nocauts disponibles para hacerlo.

— Blrfl

Ni siquiera se molesta en tratar de responder la pregunta. -1

— RubberDuck

2

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.

— Robbie Dee
fuente

-1 "ya no son roles claramente definidos: todos somos desarrolladores". Eso no es cierto en absoluto. Se supone que un equipo scrum está compuesto por un conjunto diverso de personas, que incluye desarrolladores, artistas gráficos, personal de TI, etc. Los roles no desaparecen, pero la idea es que ahora todos están en un solo equipo, no departamentos separados.

— Andy

1

@Andy, te sugiero que leas la guía scrum nuevamente: Scrum no reconoce títulos para los miembros del Equipo de Desarrollo que no sean Desarrollador, independientemente del trabajo que realice la persona; No hay excepciones a esta regla . Por supuesto, las personas se especializan, pero por su propia naturaleza, se supone que es una entidad autoorganizada.

— Robbie Dee

Llamar a alguien cuya especialidad es crear gráficos en Photoshop, o alguien que tiene la función de traducir, un desarrollador es engañoso ya que se entiende universalmente que el desarrollador en proyectos de software significa desarrollador de software. La guía scrum simplemente está mal con esa declaración.

— Andy

0

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:

Interés
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.
Costo Las
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.
Tamaño del proyecto
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.

— svidgen
fuente

0

"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.

— chiflado mate
fuente

0

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 :

DevOps (un compuesto recortado de desarrollo y operaciones) es una cultura, movimiento o práctica que enfatiza la colaboración y comunicación de los desarrolladores de software y otros profesionales de tecnología de la información (TI) mientras automatiza el proceso de entrega de software y cambios de infraestructura

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 ..."

— jhyot
fuente