Predicciones 2020: el año del empoderamiento de DevOps


Resultado de imagen para devops 2020

Parece que cada año desde mediados de la década, una publicación u otra ha declarado que es "el año de DevOps". Permítanme exponer que realmente sucederá en 2020.
¿La razón? Los líderes de TI finalmente están capacitando a sus ingenieros con la propiedad del servicio completo.

En un mundo en el que la velocidad, la calidad y la precisión continuarán determinando la diferencia entre el éxito continuo y el fracaso implacable, particularmente con respecto a la entrega de las mejores experiencias de extremo a extremo para todos los interesados, la propiedad del servicio completo es un cuestión de realidad y necesidad. Sin mencionar el sentido común.

El desarrollo y la entrega de productos y servicios que mantienen el ritmo y satisfacen las necesidades de las empresas dependen de lograr ciclos de lanzamiento más rápidos sin sacrificar la calidad. Pero ejecutar sistemas confiables a velocidades cada vez mayores presenta enormes desafíos que los equipos de software pueden enfrentar cambiando sus políticas de propiedad del servicio. La buena noticia es que las prácticas de DevOps han ganado una tracción considerable porque ayudan a los equipos a cumplir con mayor velocidad junto con un menor riesgo. Esta habilitación, similar a cualquier cambio introducido, requiere tiempo y práctica para hacer que el trabajo se ajuste a sus necesidades.

Codificarlo, enviarlo, poseerlo

La propiedad de servicio completo otorga a los ingenieros una mayor responsabilidad por el código que escriben y los servicios que desarrollan durante la producción. No se debe subestimar la importancia de poseer y operar su propio código y asumir la responsabilidad de todos los entregables, ya que son los ingenieros, después de todo, quienes deben ser, y se han ganado el derecho de ser responsables. Ellos son los que diseñan arquitecturas y sistemas, codifican software y escriben runbooks. Son aquellos sobre cuyos hombros se asienta la calidad general del servicio. Ellos son los que están de guardia cuando surgen problemas (invariablemente, como implica la Ley de Murphy, en medio de la noche).

Si ellos son los que lo codifican, entonces ellos son los que deben enviarlo y poseerlo. Los días en que los ingenieros "arrojan código sobre la pared" a las operaciones o dependen de los equipos de ingeniería de confiabilidad del sitio (SRE) para garantizar el desempeño de los servicios en la naturaleza ya no son relevantes, y mucho menos viables.

Eso es particularmente importante en el futuro, considerando que se prevé que el mercado de DevOps crecerá un 18% a casi $ 13 mil millones para 2025. A medida que las herramientas y soluciones de DevOps se arraigan más en las operaciones de TI, la forma más lógica y proactiva de administrar este crecimiento, y el caos inevitable traerá, es empoderar a TI con propiedad de servicio completo.

Las fuerzas detrás de la propiedad del servicio completo

Esto está sucediendo por tres razones:

Responsabilidad

Es una verdad simple; Los consumidores esperan implícitamente que los servicios que utilizan funcionen sin problemas y con una latencia mínima. Teniendo en cuenta que los consumidores simplemente se mudarán a otro sitio cuando una página tarda en cargarse o devuelve un error 404, la recompensa en términos de aumentar la ventaja competitiva de la empresa es inmensa.

La propiedad de servicio completo promueve el trabajo de mayor calidad porque brinda a los ingenieros una visibilidad clara de cómo el código y los servicios que han creado están funcionando e impactando las actividades diarias de sus clientes. 

Fiabilidad

No es ciencia de cohetes pedirle al científico que construyó el cohete que lo repare cuando se rompa. Del mismo modo, las empresas pueden reducir la cantidad de tiempo de inactividad y el impacto en el cliente cuando ocurre un incidente grave al traer de inmediato a los ingenieros que escribieron el código o crearon el servicio. 

La propiedad del servicio completo ofrece otra ventaja importante: conocimiento institucional general entre los equipos de TI. Los ingenieros individuales se benefician enormemente de las revisiones de códigos, las entregas de guardia, las paradas diarias, el intercambio informal de información y otros ejercicios que generan redundancia en el conocimiento y la experiencia.

Mejora continua

Una idea errónea común en el mundo de la ingeniería es que "de guardia" es sinónimo de "siempre activo". Eso en sí mismo es contraproducente porque puede conducir directamente a la fatiga de alerta. En un mundo ideal, los equipos acumularán tiempo en su trabajo de desarrollo para ir "fuera de servicio", una práctica que alivia la fatiga de alerta y fomenta la propiedad del servicio completo.

También encaja perfectamente con un elemento integral de la cultura de los ingenieros: un compromiso para refinar y mejorar continuamente su código, producto, servicios y alertas. El proceso más efectivo va más allá de solucionar problemas, también incluye adelantarse a ellos, automatizando el trabajo necesario para evitarlos, liberando a los ingenieros para que se concentren en el trabajo que más importa. 

Cinco beneficios de la propiedad de servicio completo

  • La calidad del código aumentará.
  • Los ingenieros sabrán cuándo están fuera de servicio, y las alertas serán cubiertas por otro desarrollador con la misma experiencia.
  • El conocimiento y las habilidades del equipo aumentarán a través de una comprensión más profunda de la base de código.
  • Los servicios serán más confiables.
  • Las operaciones serán más ágiles.

Cuando los ingenieros tienen el poder de codificarlo, enviarlo y poseerlo, las empresas se colocan en una mejor posición para mejorar la experiencia del cliente y reducir el impacto de las interrupciones, lo que les permite centrarse más en la innovación. Al definir y refinar roles y responsabilidades, la propiedad del servicio completo también reduce el caos asociado con los incidentes, elimina los silos y las capas innecesarias y, en última instancia, promueve una cultura de empoderamiento y responsabilidad.

Comentarios

Entradas populares de este blog

AWS SAM y AWS Lambda docker Container Image tutorial con PYTHON USANDO A...

Solucion: Docker Error: No such container:

Los unicas 4 herramientas que necesitas para volverte un master en Devops