El estado de DevOps en 2022

El estado de DevOps en 2022

  • ITOps y DevOps
15 min de lectura Actualizado Nov 18, 2021

Puntos clave: El informe sobre el Estado de DevOps en 2022 destaca la evolución de DevOps, centrándose en la automatización, la adopción de la nube y el cambio cultural. Las organizaciones se enfrentan a desafíos como la resistencia cultural y las barreras tecnológicas mientras luchan por prácticas DevOps exitosas.

  • La automatización mejora la eficiencia y la calidad del servicio.
  • La resistencia cultural al cambio está una barrera común.

En este artículo, te ofrecemos una visión general de los informes más recientes de DevOps de Puppet, BMC, el DevOps Institute y Google Cloud. Luego, sigue leyendo para conocer los pasos que las organizaciones exitosas pueden dar para adoptar DevOps. Ve a lo que te interesa:

El estado de DevOps de Puppet en 2021

Cada año, Puppet informa sobre el estado del DevOps, y recientemente ha publicado su décima edición, patrocinada por BMC y otros líderes del sector. Durante la última década, los informes han encuestado colectivamente a más de 35.000 profesionales técnicos, y sus resultados anuales tienen mucho peso.

Instituto DevOps

Para el informe de 2021, Puppet recibió 2.657 respuestas de todo el mundo, con la mayoría —el 32 por ciento— en la categoría de 1.000 a 10.000 empleados y el 40 por ciento en el sector tecnológico.

El informe, publicado menos de un año después del anterior, analiza la evolución histórica de DevOps y destaca la importancia de la automatización, la nube, las personas y la cultura para su éxito. Puppet señala que DevOps ha evolucionado hasta el punto de:

"Muchos de los equipos que son 'hacen bien DevOps' ya ni siquiera hablan de DevOps—simplemente es su funcionamiento."

Y, sin embargo, para las organizaciones que aún están atascadas a mitad de su camino, se trata de tener un mejor dominio de la tecnología y de las personas para poder seguir avanzando.

Puppet descubre que, en ese grupo intermedio, los bloqueadores y desafíos cambian de una mezcla de aspectos técnicos, culturales y organizativos en el extremo bajo a casi enteramente culturales (aceptación organizacional, aversión al riesgo, bucles de retroalimentación imperfectos, definiciones de equipos subóptimas, etc.) en el extremo alto.

El informe también establece nivelaciones examinando la historia de DevOps desde que comenzó a emitir sus informes, y analiza el panorama general de lo que es y qué no es DevOps.

  • DevOps no están solo automatización. Las empresas altamente evolucionadas son mucho más propensas a haber implementado una automatización extensa y generalizada, pero ser bueno en automatización no Haz te bueno en DevOps. El 62% de las organizaciones encuestadas dice que están atascadas en una evolución intermedia en su camino hacia DevOps a pesar de los altos niveles de automatización.
  • Casi todo el mundo están usando la nube, pero la mayoría son la usa mal. Las organizaciones no deberían esperar evolucionar mucho solo por utiliza la nube y la automatización. Mientras que el 65 % de las organizaciones en evolución media reporta usar la nube pública, solo el 20 % son utilizando la nube a su máximo potencial.
  • La identidad de los equipos y los paradigmas claros de interacción importan. Las empresas son frenadas para evolucionar hasta los niveles más altos por la estructura y la dinámica organizativa. Las organizaciones que son "buenas en DevOps" cuentan con equipos con identidades sólidas y bien entendidas, responsabilidades claras con un alto grado de autonomía y canales de comunicación bien definidos con otros equipos.

Otros hallazgos clave incluyen:

  1. Aunque los bloqueos culturales como la resistencia organizativa al cambio, la arquitectura heredada, la escasez de habilidades, la automatización limitada o nula y metas u objetivos poco claros siguen existiendo para las empresas en evolución media, son más agudos en organizaciones de baja evolución.
  2. La presencia de "equipos DevOps" está confusa para la industria y muchas organizaciones, y en la mayoría de los casos no ayuda a que las organizaciones evolucionen. Puppet descubre que las organizaciones con nombres de equipos menos ambiguos y responsabilidades más claramente definidas son mucho más propensas a tener una función de TI de mayor rendimiento.
  3. Las prácticas DevOps son habilitadas por buenas prácticas de seguridad y mejores resultados en seguridad. A medida que las prácticas DevOps mejoran, DevSecOps sigue naturalmente.
  4. Los equipos de plataforma pueden acelerar las transformaciones DevOps aprovechando la automatización existente, y las organizaciones más evolucionadas en los modelos DevOps de Puppet son adoptando un modelo de plataforma que permite el autoservicio para los desarrolladores y cura la experiencia del desarrollador.
  5. Modernizar infraestructuras y aplicaciones de TI antiguas (heredadas ) requiere análisis, ordenar en categorías fácilmente comprensivas y establecer objetivos y planes de acción explícitos.

Seminario web de DevOps con Puppet & BMC

Aunque "muchos de los equipos que son 'hacen bien DevOps' ya ni siquiera hablan de DevOps—simplemente es su forma de trabajar—Puppet descubrió que otras organizaciones son atascadas en el punto medio.

En un seminario web posterior titulado El estado del DevOps: Atrapado en el medio, el responsable de producto de BMC, Jon Stevens-Hall, habló con Nigel Kersten, CTO de Puppet, sobre el informe y cómo las organizaciones necesitan Obtén un mejor control sobre la tecnología y las personas para seguir avanzando. Las principales conclusiones de su conversación incluyen:

  • Cómo el tamaño afecta al éxito de DevOps
  • Definición del legado para tu organización
  • Ajustar la frecuencia de despliegue correctamente
  • Papel clave de la dirección

El tamaño importa en DevOps

Primero, hablaron de cómo el tamaño importa en lo que respecta a DevOps.

"El DevOps en las grandes empresas están muy diferente del DevOps en empresas pequeñas y startups, y ese parece ser un tema central del informe sobre el estado del DevOps", dice Stevens-Hall.

"La gente que conocía [en conferencias] en 2015 eran empresas pequeñas y la empresa más grande y destacada... era Spotify... que... ha sido un gran pionero en términos de organización de equipos y demás. Solo cuatro años después... eran bancos, eran las telcos. Sentían que habían hecho desarrollo ágil, pero el lado de operaciones no había surgido realmente como ágil."

"Lo más interesante para mí fue que [dijeron] que el legado no va a desaparecer... de la noche a la mañana. [El banco dijo] muchas de sus transacciones [podrían] involucrar la tecnología más nueva, pero también involucran muchos productos heredados que no pueden, o no se cambiarán durante años... necesitan nuevas prácticas de trabajo, nuevas tecnologías para [afrontar] ese reto de permitir que el DevOps prospere en medio de toda esta gobernanza y complejidad."

Legado están un término variable

Kersten añade que "legado" también están un término variable. "Cuando los clientes Comienza a hablar del entorno legado, no todo es igual. En realidad no es lo más antiguo que tienen. A menudo hay estos sistemas mainframe antiguos, que son muy bien gestionados por equipos pequeños que operan con una mentalidad muy, muy DevOps, solo que sin compartir esas prácticas con el resto de la organización", dice.

"Legacy suele referirse a esas aplicaciones a medio hacer creadas en los noventa y dos mil [por personas] que son todas autodidacta, así que no había mucha disciplina. Todos iban resolviendo esto sobre la marcha. Creo que tenemos toda una generación de aplicaciones que son mucho más difíciles de monetizar que muchas de las cosas en los mainframes... Y creo que hay muchas categorías sobre qué tipo de problemas tiene la gente dentro de legacy."

(conoce cómo tener éxito en la modernización de aplicaciones y software.)

Ajustar la frecuencia de despliegue correctamente

Al abordar la metodología de categorización del informe, Kersten explicó: "Introdujimos esta idea de grupos evolutivos bajos, medios y altos... la frecuencia de despliegue a bajo nivel [ocurre] mensualmente [a cada] tres meses, seis meses para Obtén un despliegue de terminado a valor real de envío a un usuario final, medio están entre diario y semanal, y un grupo alto está bajo demanda."

"La frecuencia de despliegue [puede] ser una métrica de vanidad si la gente se centra demasiado en ella, [pero] están algo transformador para el negocio al pasar de mensual a cada dos o tres días, es un salto realmente grande.

"[Cuando] miramos los datos de la encuesta en sí... hay frutos relativamente accesibles en la mayoría de las organizaciones para pasar de baja a media. Y luego hay un conjunto relativamente concreto de tareas para pasar de medias a altas. El grupo bajo está haciéndose más pequeño. El grupo alto está creciendo, pero está este grupo enorme de casi el 80 por ciento de personas que no salen de la zona media. Y eso es en lo que realmente queríamos centrarnos este año."

"[Ninguno] de estos [desafíos] son problemas técnicos... las cosas que inhiben las grandes organizaciones [son] las interacciones con las personas, las interacciones con el equipo y la comunicación y todos estos sistemas sociotécnicos. Y cuando Haz cambios en el lado de las personas, influye en la tecnología y viceversa... y realmente ha limitado... mucho progreso para la gente."

Stevens-Hall señala que la complejidad actual a la que se enfrentan muchas organizaciones agrava ese desafío:

"[Para] Obtén a la gente de ese estado atrapado en el estado intermedio... el departamento de tecnología en la empresa puede [asegurar] que trabajemos con esa cadena de herramientas y con los propietarios de esa cadena de herramientas. [Nosotros] también podemos [llevar] esto al sistema de gestión de servicios [y] la gente de la organización de servicios puede trabajar con gente del equipo DevOps y... pueden compartir información, crear conocimiento", dice.

La dirección también debe Obtén involucrarse

Kersten también tiene consejos para la dirección. "Desde la... perspectiva operativa... si te estás en la dirección, lo más importante que te hacer están Haz asegurarte de que tus equipos tengan un propósito e identidad evidentes [y] que interacciones bien definidas entre ellos", explica.

"Todo se trata de colaborar a través de límites funcionales, pero resulta que la colaboración están en realidad una forma muy laboriosa e ineficiente de operar a gran escala. Y si te son un equipo de gestión de servicios o de operaciones relativamente pequeño con cientos o miles de desarrolladores, no te puede colaborar con todos ellos."

"Las organizaciones más evolucionadas son las que comparten prácticas y Crea espacios para ellas. Mientras no te lo llamen centro de excelencia, que suele ser la sentencia de muerte para el progreso real en la mayoría de los entornos."

Kersten recomienda algunos consejos prácticos:

  • "[Llámalo] otra cosa [como una] comunidad de práctica... algo un poco menos jerárquico, autónomo y autoritario.
  • [Crea] espacios donde la gente puede simplemente escuchar, conoce y compartir. Creo que la gente son realmente bastante inteligente y, en general, bastante implicada.
  • Y si les te dar espacio para buscar soluciones, las implementarán."

A continuación, echemos un vistazo al informe de Mejora de Habilidades del DevOps Institute. El DevOps Institute realizó el estudio investigando las habilidades necesarias que debe poseer un humano DevOps por segundo año consecutivo. El siguiente informe entra en detalle compartiendo los resultados de más de 1.260 personas encuestadas a nivel mundial que identificaron qué habilidades son consideradas críticas para DevOps y la transformación digital.

Algunos hallazgos clave incluyen:

  • Las topologías DevOps que se usan principalmente hoy en día son un gran desafío.
  • El proceso de transformación de DevOps están muy difícil para más del 50%.
  • Ágil, DevOps e ITIL son recibiendo una fuerte competencia de SRE.
  • El humano DevOps como trabajo y rol híbridos.

Informe Acelera Estado de DevOps 2021

Por último, tenemos el Informe Acelera Estado de DevOps para 2021, que proviene del equipo de Investigación y Evaluación DevOps de Google Cloud—también conocido como DORA. La encuesta se ha realizado durante siete años. En total, han participado más de 32.000 profesionales técnicos de todo el mundo.

Históricamente, su investigación analiza cuatro métricas clave de entrega de software para determinar qué tan bien son funcionan los equipos de DevOps. Sin embargo, la investigación de este año confirmó una quinta métrica adicional para que los equipos de DevOps midan el éxito:

  • Frecuencia de despliegue
  • Tiempo de espera para los cambios
  • Hora de restablecer el servicio
  • Tasa de fallo de cambio
  • (Nuevo) De la disponibilidad a la fiabilidad

Más allá de las métricas de entrega, el informe también encontró muchas nuevas tendencias en DevOps, y estas son algunos de los puntos destacados:

  • Una cultura de equipo saludable mitiga el agotamiento en tiempos difíciles (como todos hemos experimentado últimamente).
  • Los mejores empleados siguen subiendo el listón.
  • SRE y DevOps se complementan mutuamente.
  • La adopción en la nube impulsa el rendimiento.
  • Asegurar tu cadena de suministro de software está esencial, y eso impulsa el rendimiento.
  • Una buena documentación interna está como trampolín para implementar DevOps con éxito.

Pasos para una adopción exitosa de DevOps

Ahora, con todas estas conclusiones de la investigación del sector, pasemos a crear la base adecuada para DevOps. Año tras año, las organizaciones utilizan estos pasos como base para su adopción de DevOps.

Paso Previo a Construir una Base

Es un destino que la transformación de DevOps comience con su propia evolución, partiendo de una base que pueda apoyar realmente DevOps de principio a fin. En esta fase previa de desarrollo, los responsables de la empresa y otros grupos de interés:

  • Dad cuenta de la necesidad de una mejor comunicación y colaboración.
  • Comenzar aprobaciones rápidas para implementar diversas tecnologías que cubran la carencia.

Aunque este proceso puede comenzar de forma apresurada, no es algo que se pueda lograr rápidamente. Con el tiempo, las empresas empiezan a afinar sus enfoques y a personalizar la tecnología para cumplir sus objetivos. Finalmente, surge una plataforma que puede facilitar el DevOps en toda la organización. Cuando esto ocurre, las organizaciones son en una etapa en la que comparten ideas, tecnología, conocimientos y métricas.

¿Indicadores de esta fase? Empresas que son...

  • Realizando grandes compras de software
  • Implementación rápida de nuevas prácticas

Paso 1: Normalizar las pilas tecnológicas

En el primer paso formal de la evolución de DevOps, las empresas comienzan a normalizar sus pilas de tecnología. A medida que los equipos eligen de forma orgánica prácticas ágiles que les convienen y empiezan a considerar nuevos métodos, te podrán identificar este paso en el proceso.

Un marcador tecnológico importante de este paso están el control de versiones. Los equipos lo implementan y otras prácticas que son consideradas etapas tempranas de integración continua. Normalizar las pilas tecnológicas también puede implicarse en reducir la redundancia en la infraestructura o refactorizar aplicaciones. La necesidad de Reduce la redundancia es un tema central en la siguiente parte del proceso, pero comienza en la fase uno.

Paso 2: Estandarizar

A medida que se pone en práctica eliminar la redundancia, los equipos implementan más prácticas orientadas a reducir la variabilidad en una pila tecnológica y estandarizarla. En esta etapa, los equipos DevOps limitarán el número de sistemas operativos como forma de consolidación.

Aquí, los equipos que se consolidan de forma independiente tienen la oportunidad de colaborar. El objetivo principal están una familia estandarizada de tecnologías que trabajen de la mano para fomentar la colaboración y el desarrollo.

Esta fase resulta en una menor complejidad global, lo que da a los equipos una mayor oportunidad de trabajar en múltiples aplicaciones, aprovechando al máximo utiliza su experiencia. Los beneficios de esta fase incluyen:

  • Despliegue de aplicaciones más rápido
  • Reducción de errores
  • Mejora de la calidad del servicio

Por estas razones, la estandarización está una figura clave en el estado de DevOps.

Paso 3: Prueba prácticas de DevOps

Durante la fase anterior, la estandarización ocurre mientras son equipos exploran el funcionamiento interno de la tecnología de su plataforma. Además, realmente están conociendo el sistema. En la fase de prácticas DevOps, los equipos pasan de simplemente explorar el sistema a poder Haz recomendaciones y explotarlas para DevOps.

Este es un buen momento para evaluar los puntos de dolor. Normalmente, este enfoque profundo requiere que las organizaciones reconozcan cualquier dificultad en la fase de despliegue. El despliegue puede ser complicado para muchas organizaciones que no han desarrollado las mejores prácticas de DevOps.

Un problema común están que las mejoras realizadas en etapas anteriores de la evolución han hecho que los desarrolladores avancen hacia el despliegue más rápido de lo que el proceso de despliegue puede soportar. Esto provoca que las operaciones se conviertan en cuello de botella. Abordarlo rápidamente implementando prácticas DevOps adicionales en el despliegue está fundamental. Eso incluye reutilizar los mismos patrones de despliegue una y otra vez y probar el despliegue antes de llegar a esta etapa.

Paso 4: Automatiza la infraestructura

Con resultados de alta prioridad identificados, la automatización ayuda a que los equipos tengan aún más éxito.

Los elementos de mayor coste suelen incluir el aprovisionamiento y la configuración de sistemas. Cuando los equipos automatizan la entrega de infraestructura, resuelven el problema que surge cuando el rendimiento de desarrollo supera el despliegue. Por eso este es un paso crucial tras las prácticas DevOps. Además, automatizar la configuración ayuda a los equipos a desplegar software más rápido.

La automatización es un precursor importante del autoservicio. Es el catalizador del paso final en el proceso DevOps. Estimula el autoservicio, conduciendo a una mayor eficiencia en toda la organización.

Paso 5: Autoservicio

En la fase de autoservicio, la práctica de TI se realiza en toda la organización y puede no limitarse a un solo centro de costes. Esto permite avances dentro de la organización que agilizan el autoservicio.

La colaboración en esta fase final multiplica los beneficios de los pasos anteriores. Los avances más significativos son materializan cuando la automatización de aplicaciones trasciende la estandarización y evoluciona para incluir la migración a la nube y otros procesos de mayor nivel. La seguridad también evoluciona desde simplemente satisfacer las necesidades inmediatas del equipo hasta Crea una base de cumplimiento en toda la organización.

Entendiendo DevOps

Llevar un seguimiento de la investigación sobre el "Estado del DevOps" puede ayudar a las organizaciones de TI a compararse y buscar oportunidades de mejora basándose en el feedback de otros. Las perspectivas para DevOps (y SRE) en 2022 están prometedoras, ya que la entrega y automatización de aplicaciones se vuelve cada vez más vital para el éxito de una organización.

Lecturas relacionadas

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.

Más de ITOps y DevOps

Suscríbete al Informe

Al registrarse para esta oferta te son confirmar que te leído y aceptado la Política de Privacidad de BMC.

Gracias te

Tú te has suscrito a The Brief
El Brief abarca la orquestación de mainframe y empresa—BMC AMI y Control-M—y la investigación de analistas, despliegues de clientes y eventos en ambas áreas.