La Cumbre de DevOps Enterprise periódica se celebró en Londres del 23 al 25 de junio de 2020. "En Londres" se puede escribir entre comillas, ya que la pandemia hizo su trabajo y la conferencia se celebró en línea. Tiene tanto cosas malas aquí (las redes aún sufren mucho) como cosas buenas: puede tomar un descanso entre los informes de todas las personas, puede reservar unos días enteros para estudiar los informes que le interesan y centrarse, esto es muy útil ... Hace poco estuve en una reunión "en Chelyabinsk", al día siguiente - "en Novosibirsk", y unos días después - en California: físicamente sería extremadamente difícil hacer esto. Por supuesto, hay grabaciones, pero la sensación de hacer tiempo para aprender parece ayudarlo a aprender.
Los formatos de los informes de la conferencia ya se han arraigado en Habré, y el deseo de desarrollarse en condiciones cuando te sientas en casa se ha vuelto especialmente fuerte (tienes que hacer algo), y aquí surge la pregunta: hay muchas conferencias ... ¿cómo ver todo lo que quieres ver?
Y aquí pensé que podría intentar hacer un informe sobre la conferencia en un formato diferente, no para contar cuáles eran los informes (para esto publiqué una "transmisión de texto en vivo" separada de los informes que escuché), sino para escribir un artículo que resuma conclusiones y tendencias actuales, indicarán a dónde acudir para obtener los últimos conocimientos.
¿Qué es la Cumbre de DevOps Enterprise? ¿Cómo es diferente de otras conferencias?
Cualquier artículo sobre la conferencia DevOps, por supuesto, debe comenzar con una discusión sobre qué es DevOps, y, por supuesto, todos están cansados de ello. ¡Por lo tanto, trataré de ser conciso!
De hecho, es probable que todos los que argumentan estén de acuerdo en al menos una cosa: que "devops es un conjunto de prácticas que facilitan la entrega de software y la administración de la infraestructura". Las únicas diferencias son que un grupo (y la mayoría de las veces son "administradores") dice "la discusión de las prácticas debe ser práctica", y el segundo grupo (y esto es desarrollo y, con mayor frecuencia, gestión en desarrollo) cree que "esto es filosofía y metodología ".
Me arriesgaría a enojarme por la "simplificación", pero en esencia: para el desarrollo, la introducción de métodos y capacidades de "administrador" cambió el proceso de desarrollo en sí mismo ideológicamente y convirtió a DevOps en un nuevo Agile: cuando escuchamos sobre conferencias gerenciales sobre DevOps, escuchamos sobre cambios en la metodología desarrollo. Y DevOps Enterprise Summit es una de esas conferencias que son útiles para los "administradores": también hubo informes más cercanos a los técnicos.
Entonces, la Cumbre Empresarial DevOps se lleva a cabo desde 2014, y está organizada por IT Revolution con el fundador de Gene Kim, conocido por muchos del libro "Proyecto Phoenix". IT Revolution es el editor que ha lanzado una serie de libros sobre DevOps y sus enlaces a Agile. ¿Por qué Enterprise? Este es un punto particularmente importante.
Introducir metodologías ágiles en una empresa pequeña es fácil: en empresas con varias personas, lo más probable es que hayan existido desde el principio, solo necesita nombrarlas de esa manera. Con compañías de miles, decenas de miles de personas, todo es mucho más complicado. Hay una gran cantidad de procesos en ellos, construidos para que este coloso continúe moviéndose, y esto se puede comparar con un gran barco. Cuando un barco viaja a través del océano de un continente a otro, cumple su función, pero el barco no puede cambiar su ruta y su curso en el menor tiempo posible, esto lleva tiempo, especialmente en negocios de tecnología. Una empresa joven de unos pocos puede construir un prototipo en cuestión de días que una empresa de miles construirá durante años, si no cambia.Por lo tanto, las grandes empresas quieren cambiar y usar los métodos de los "jóvenes", pero necesitan entender cómo no interrumpir sus procesos. Ya he dado un ejemplo en otro artículo: en Excel 1900 se considera un año bisiesto, y esto se hace por compatibilidad con versiones anteriores de Lotus 1-2-3, que tenían ese error. Estas versiones se lanzaron en los años 80, y la pregunta es: ¿debería mantenerse esta compatibilidad? ¿En qué medida se pueden permitir errores en el enfoque "lo arreglaremos más tarde" cuando instala software en bancos en servidores que generalmente están desconectados de Internet? ¿Cómo puedes mantener esa misma flexibilidad? De esto se trató la conferencia.Estas versiones se lanzaron en los años 80, y la pregunta es: ¿debería mantenerse esta compatibilidad? ¿En qué medida se pueden permitir errores en el enfoque "lo arreglaremos más tarde" cuando instala software en bancos en servidores que generalmente están desconectados de Internet? ¿Cómo puedes mantener esa misma flexibilidad? De esto se trató la conferencia.Estas versiones se lanzaron en los años 80, y la pregunta es: ¿debería mantenerse esta compatibilidad? ¿En qué medida se pueden permitir errores en el enfoque "lo arreglaremos más tarde" cuando instala software en bancos en servidores que generalmente están desconectados de Internet? ¿Cómo puedes mantener esa misma flexibilidad? De esto se trató la conferencia.
Formato
Cada conferencia intenta descubrir cómo conectarse en línea, y es interesante. En DOES, se puede observar lo siguiente:
- Los informes todavía se dividen por pista, el espectador puede cambiar entre pistas en el proceso.
- Los informes se grabaron antes del día de la conferencia, para evitar problemas técnicos con la transmisión, el orador durante el informe está en el canal flojo y se comunica con la audiencia. Esto es probablemente lo más interesante que aprendí de la organización. La solución es contradictoria: por un lado, lo interactivo desaparece, por otro lado, mucho más tiempo para preguntas (y muchas más oportunidades para que el hablante responda más preguntas). Sin embargo, por ejemplo, escuché principalmente el informe y no quería cambiar a discusión, así que llegué al final, cuando quedaba poco tiempo y un nuevo orador llegó al siguiente informe.
- , -, .
- , , , , « », - , , , .
- -Horses, -Unicorns — -, « », , — , , .. , - «-» , , ( ) ( Gene Kim).
- DevOps « » — scenius. Scenius «» — genius, , , , scenius, ( Gene Kim). (. medium.com/@stevesargon/steal-like-devops-artist-1-you-dont-have-to-be-a-genius-or-googler-6e9f17c14fb5 Scenius.)
- Platform Engineering, «» «», (DevOps Journey at Adidas III, Exploring Data in the Cloud Fernando Cornago VP, Platform Engineering, Daniel Eichten VP, Enterprise Architecture, Adidas ). (. softwareengineeringdaily.com/2020/02/13/setting-the-stage-for-platform-engineering platform engineering platform team). , , , , . — , , . , , (platform advisory/community management/platform operation/platform evolution).
DevOps Dojo. . , . SRE- Uptime community, , ? Dojo — , , . DevOps- Target, , , , , , , . . youtu.be/1FMktLCYukQ
- Swiss Re — , 156 , DevOps- . , « ». «» — «» CEO, , .. , , , Gartner-, 76% DevOps- «, ». . — , . , «» DevOps- — . . , , : Hermes Germany GmbH , CIO, « », «» .
- , — . State of Devops, Gene Kim Accelerate.
- , , DevOps And Modernization 2.0 (CSG) Scott Prugh — DevOps . , — , : Cobol-, 3,7 IBM High Level Assembler Java ! : .
Libros mencionados que vale la pena leer:
Topologías de equipo en acción , Acelerar: Construir y escalar organizaciones tecnológicas de alto rendimiento .
Y soy un poco más regular que el blog aquí, tengo mi propio canal de telegramas , suscríbete.