DevOps: ¿qué tal si nos incomodamos un poco para estar más cómodos a largo plazo?

Compartir en

Video más reciente

Nuevo PodCASTOR

A VPN is an essential component of IT security, whether you’re just starting a business or are already up and running. Most business interactions and transactions happen online and VPN

Entendiendo que cada contexto tiene sus necesidades es imposible la existencia de una fórmula que nos dé el paso a paso para hacer DevOps de modo tal que nos funcione bien a todos, por lo tanto, su aplicación varía y en algunos momentos nos puede llevar por otros caminos que nos alejan del objetivo inicial.

 

Aprovecho entonces que en DevOps Topologies se han tomado el trabajo de identificar las buenas y las malas topologías de DevOps para relacionar aquellas clasificadas como “malas” con la intención de que a partir de su identificación seamos muy conscientes de ellas y procuremos evitarlas para que cada vez podamos hacer mejor DevOps:

 

Anti-Tipo A: Silos de desarrollo y operaciones

Se presenta una división entre los silos de Desarrollo y Operaciones y la operatividad del software se ve afectada. Esto significa que el equipo de Operaciones no tiene tiempo o inclinación para participar y el de Desarrollo no tiene suficiente contexto de las características operativas para así solucionar los problemas antes de que el software entre en funcionamiento.

 

Anti-Tipo B: Silo del equipo de DevOps

Un gerente o ejecutivo decide usar un poco de DevOps y por lo tanto, conforma un equipo para lograrlo. A su vez los miembros del equipo de DevOps forman otro Silo, lo que trae como resultado la separación de Dev y Ops.

 

Es importante tener en cuenta que solo es válido un silo de DevOps separado cuando se trata de un equipo temporal con el propósito de poner en funcionamiento DevOps para acercar a Devs y Ops.

 

Anti-Tipo C: los desarrolladores no necesitan operaciones

Los desarrolladores y los gerentes de desarrollo suponen que Ops es cosa del pasado y subestiman la complejidad e importancia de las habilidades y actividades operativas, creyendo que pueden prescindir de ellas o que están en capacidad de cubrirlas.

 

Anti-Tipo D: DevOps como equipo de herramientas

Nace de la conformación de un equipo de DevOps para trabajar en las herramientas que se requieren para las canalizaciones de implementación, la gestión de la configuración, la gestión del entorno, etc. y los equipos de Desarrollo y de Operaciones trabajan de forma aislada. Es cierto que esta forma de trabajo puede traer beneficios, no obstante, su impacto será limitado.

 

Anti-Tipo E: SysAdmin renombrado

Es típico en organizaciones con baja madurez de ingeniería que quieren mejorar sus prácticas y reducir costos, pero no ven a la TI como un impulsor central del negocio y en vez de reflexionar sobre las brechas en la estructura y las relaciones actuales, deciden contratar «ingenieros de DevOps» para su (s) equipo (s) de operaciones.

 

DevOps les termina representando un cambio de marca del rol conocido como SysAdmin, sin que en realidad se produzca un cambio cultural / organizativo como tal. 

 

Anti-Tipo F: Operaciones integradas en el equipo de desarrollo

Los equipos de desarrollo asumen la responsabilidad de la infraestructura, la gestión de entornos, el monitoreo, entre otros, porque la organización no quiere mantener un equipo de operaciones separado.

 

Sin embargo, hacerlo por proyectos o productos significa que esos elementos están sujetos a restricciones de recursos y priorizaciones que conducen a enfoques deficientes y soluciones a medias.

 

Anti-Tipo G: Silos Dev y DBA

Se da en empresas medianas y grandes donde múltiples sistemas heredados dependen del mismo conjunto central de datos.  Como estas bases de datos son vitales para la empresa, un equipo de DBA es el responsable de su mantenimiento, ajuste de rendimiento y recuperación ante desastres, convirtiéndose en un obstáculo para implementaciones pequeñas y frecuentes (un principio básico de DevOps y Entrega continua).

 

Además, el equipo de DBA no participa al principio del desarrollo de la aplicación, por lo que los problemas de datos (migraciones, rendimiento, etc.) se encuentran al final del ciclo de entrega, pues con la sobrecarga de admitir bases de datos de múltiples aplicaciones, el resultado final es una lucha constante y una creciente presión para cumplir.

 

¿Te has preguntado por qué nos acercamos a estas malas prácticas? 

 

Tal vez sean formas de mantener el statu quo y continuar cómodos en nuestra posición. Ahora ¿qué tal si nos incomodamos un poco para estar más cómodos a largo plazo?

 

La imagen de portada fue tomada de: Background vector created by freepik – www.freepik.com

 

Mantente al tanto de nuestras publicaciones a través de nuestras redes sociales: LinkedIn, Instagram y Twitter, o déjanos tus datos y recibe mensualmente nuestro sumario:

 

Felipe Mejía

Felipe Mejía

Director de Operaciones de Castor Certificados en ITIL, agilidad y gamification. Scrum Master PSM I Certified. Orientado al cambio, entusiasta de la lectura y aprender. Consciente que se aprende más enseñando y facilitando a los demás. El pensamiento ágil nos facilita mejorar siempre.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Publicaciones Relacionadas

Contáctanos

Comunicate con nosotros

Estamos acá para acompañarte en tus estrategias de  Transformación Digital.

Cualquier inquietud no dudes en comunicarse con nosotros.

  • Solicitar propuestas
  • Preguntas sobre nuestros servicios
  • Requerir consultoría profesional