DevOps: todo

[Este material es una traducción de una serie de tweets de Michael DeKhan, uno de los creadores del popular motor de automatización Ansible - aprox. ]

Entonces, opsmop tiene el mismo problema con el calendario de aceptación y participación que vespene_io , y tampoco veo ninguna razón para continuar. Creo obstinadamente en la idea misma, pero creo que todo el mundo de las TI de código abierto se ha extinguido, y estoy cansado de tratar de interesar a las personas.

Para aquellos que dicen que este era un producto que no llegaba al mercado, o que debía esperar un poco más, con el debido respeto, se equivocan. Sé sobre esta área mucho más que nadie, excepto cinco personas en el mundo :-) Las razones de esto son interesantes ...

Esencialmente (1) un gráfico ágil significa que nadie tiene tiempo para trabajar, (2) DevOps no podría funcionar según lo previsto. Tanto eso como eso tomó tiempo para una manifestación gradual y causar daño. Honestamente, unos 12 años.

DevOps [- enfoque - aprox . ] debería haberse convertido en un híbrido de desarrollo y administración [desarrollo / operación s - traducción aprox.], pero en cambio, las personas crean herramientas cotidianas y los desarrolladores hacen mucho de lo que los administradores están acostumbrados. Y los administradores se convierten en * incluso más * administradores de sistemas de lo que eran al menos en la mitad de este período [a los 12 años de edad, aprox.

La clave del éxito del código abierto es cuando la audiencia de usuarios y desarrolladores (aquellos que pueden contribuir) se cruzan fuertemente, y también están involucrados e inspirados.

En nuestro caso, muchas discusiones indican que todos están ocupados, nadie tiene tiempo y, sin embargo ... todos están cada vez más interesados ​​en soluciones como "pequeño código / sin código". Esto no se aplica al código abierto en general, sino solo al segmento de administración de TI.

Mirando hacia atrás en las discusiones sobre licencias (Mongo, Redis, Confluent), tenían razón, defendiéndose de abusos "nublados", pero esto también dice algo más: para comenzar a hacerlo, tuvieron que enfrentar un valor decreciente al interactuar con la comunidad.

Es cierto que no todas las mejoras propuestas son siempre buenas, pero la interacción y la experiencia con las personas es muy positiva. Pero parecen disminuir la velocidad en todas partes . Probablemente piense que si alguien escribió una de esas piezas en GitHub que recibe la mayoría de las solicitudes de mejora, a la gente le gustaría probar sus nuevas piezas y compartir ideas, pero en mi foro solo hay 60 participantes, y solo 10 de ellos llegaron la semana pasada. Cada proyecto se clona solo dos veces al día y, lo más probable, automáticamente.

Veo un fuerte movimiento en otras áreas, como el ecosistema de JavaScript. Tengo mucho entusiasmo por el código abierto y el intercambio de ideas. Hablé mucho con personas que tienen problemas serios de administración de la configuración. Pero, al final, la interacción falla.

Los programas de código abierto alimentan la interacción. Y, básicamente, aquí está mi diagnóstico: agotamiento a gran escala. Llegó lentamente y no nos dimos cuenta. Agile y DevOps - Burnout. En mi opinión, en algunas áreas somos tecnológicamente más pobres que hace seis años. Por qué

Estamos cansados ​​y simplemente dejamos que todo vaya como va. Usamos lo mismo que otros. Lanzamos nubes sobre nuestras jodidas nubes sin ninguna razón, y estamos mucho más interesados ​​en la moda técnica que en lo que nos hace productivos. Soportamos software con miles de errores.

Básicamente, dejamos que nuestro software de gestión se convierta en una broma. En lugar de insistir en el dominio del nivel del cohete espacial, simplemente atornillamos aún más capas en la parte superior. Y nadie tiene la fuerza para decir que no. El software de TI ha ido demasiado lejos de cualquier aspecto de ingeniería.

Quiero ayudar a combatir esto, pero al final, el compromiso y la lluvia de ideas son mi combustible. Si no hay participación, y no puedo solucionar esta participación, no obtendré nada de ella. Así que resultó ser muy canario, en mayor o menor medida.

Todavía me encanta escribir software, pero voy a tratar de crear proyectos que me interesen personalmente y, de manera bastante notable, le doy la espalda a ayudar al liderazgo. Eso significa cosas como mi proyecto para un secuenciador de música. Porque creo que a la gente no le importa un hobby ...

Espero que aquí el compromiso se exprese en grandes cantidades. Bueno, si no, todavía puedes usarlo para archivar melodías geniales. Quizás me sumergiré en algunas cosas interesantes sobre el análisis de datos, porque también me interesan.

¿Cómo podemos arreglar el código abierto para TI en general y en general? Eche un vistazo a quién debería ser DevOps ... debería ser tanto un desarrollador, como un administrador. Lucha contra el ágil que devora tu agenda. Pruebe cosas nuevas, piense, estudie opciones y no intente ser otra persona.

Bloquear a los "defensores de los desarrolladores" de Twitter Nos encanta hablar de representación, pero pensamos en lo que la tecnología puede significar "comprar localmente". Apoye proyectos pequeños e ISV [proveedores de software independientes - aprox. ] Interactuar La mayoría de nosotros nos alimentamos de la interacción más que cualquier otra cosa.

El futuro, en el que simplemente consumimos software lanzado por una de las cuatro marcas, me parece bastante aburrido, especialmente si no hay suficiente código en este futuro. Para sobrevivir a esta unión, necesitamos diversidad. Y para llegar a él, debemos rechazar la osificación de las prácticas.

Hacemos muy pocas cosas de la mejor manera, básicamente como todos lo hacen. La mayoría del software que todos quieren usar es basura. Bueno, ¿cuál es el problema, bueno, en serio? Renunciar a la mediocridad y hacer lo que mejor le parezca.

Con respecto a eso de la depresión / agotamiento, cuide sus habilidades. Disfruta el rendimiento. Crea artículos a prueba de balas. Comparte guiones escritos. Blogging Cualquier cosa Comunícate y comparte aún más. Quizás, poco a poco, podamos cambiar eso.

Pero la próxima vez, cuando la conversación llegue a un cambio de paradigma como "ágil" o "devops", iniciada por alguien que no escribió ni construyó nada significativo, sea cortés, pero no se deje engañar por el hecho de que están tratando de hacer reír.

Deberíamos apreciar el trabajo de ingeniería : lo que creamos, cosas especiales y relevantes, no dichos de mierda o repetir mantras sobre los procesos. Los primeros son un indicador de nuestro valor y cuánto estamos mejorando.

Hicimos los movimientos que nos hicieron esto, y aún lo hacemos. Aceptación de la osificación [practicante - aprox. Transl. ] y escupe la calidad del software que todos soportamos, solo tenemos que parar. TI es ingeniería, así que trátelos en consecuencia.

Si esto es difícil para mí , imagina cómo es para alguien sin una plataforma. Para mí, OSS fue una excelente manera de conocer a mucha gente y mucha alegría, y ... si no puedo hacerlo hoy, oh ...

Todo tipo de ayuda genial sobre el movimiento OSS que disfrutamos en RedHat en 2006 es algo que simplemente no creo hoy. El movimiento no fue erróneo, solo algo se movió en la cultura y lo mató.

No puedo evitar pensar que no fue porque Red Hat se vendió no para la distribución, sino (según un anuncio de IBM) para las distribuciones Kubernetes y OpenStack. ¿Encontraron esto también? ¿Qué piensa cada empresa grande con un proyecto OSS sobre el compromiso, pero no puede decir?

Por supuesto, lo más probable es que digan algo más, pero me pregunto qué piensan. Y creo que todos piensan que Freemium es un buen modelo de descarga, pero el código real y la colaboración no significan nada más, porque las personas no están involucradas.

(a todos los que ponen un "plus" por esto, hmm ... ¿gracias?)