Etapas de evolución de DevOps

Estandarizar y reducir la variabilidad

En la Etapa 1, normalizamos tecnologías y procesos. Se separon las configuraciones de las aplicaciones y se colocaron en control de versiones, se adaptó un proceso coherente para las pruebas de infraestructura y un patrón para compartir en base al código fuente.

En la Etapa 2, las organizaciones trabajan para estandarizar aún más y reducir la variabilidad, un objetivo que debe prevalecer en cada etapa de la evolución de DevOps.

Toda organización tiene variación, que puede provenir de varias causas diferentes:

● Adopción de nuevas tecnologías para reemplazar muchas funciones antiguas; sin embargo, éstas funciones antiguas nunca se eliminan ● Soluciones en casa que no siguen ningún estándar común de la industria y carecen de interfaces comunes ● Una propagación de herramientas que se superponen y no han sido justificadas ● Fusiones y adquisiciones

En la Etapa 2, la reutilización de tecnologías y patrones se vuelve importante. Esto impulsa a Dev y Ops a colaborar y tomar decisiones arquitectónicas que afectan el despliegue y capacidad de prueba de las aplicaciones.

¡Cuidado!

Un antipatrón a tener en cuenta en esta etapa es que cada equipo se normalice según sus propios estándares. Esto conducirá a un m ayor grado de variación global y es exactamente la dirección equivocada.

Prácticas que definenla Etapa 2

Para lograr estandarizar y reducir (aún más) la variabilidad en esta etapa, nos basaremos en las siguientes prácticas:

Uso estándar de tecnologías y frameworks Despliegues en un único sistema operativo estándar

Exploremos más a detalle el alcance de estas prácticas.

Uso estándar de tecnologías y frameworks

Tomando la perspectiva de un equipo encargado de la entrega de un producto, sin importar cómo está compuesto, el equipo como necesidad primaria necesita desplegar servicios (o funcionalidades de un servicio). De esta necesidad surgen las preguntas:

● ¿Cada servicio se basa en la misma arquitectura? ● ¿Todos usan la misma cola de mensajes? ● ¿Todos usan los mismos componentes y patrones?

Cuando la respuesta a cualquiera de estas preguntas es “No”, la complejidad entra en el sistema y aumenta la carga de mantenimiento.

Cuando se estandarizan patrones y componentes, el equipo ya no tiene que volver a aprender continuamente cómo funcionan, escalan, fallan, recuperan y actualizan las diferentes tecnologías. El tiempo recuperado se puede utilizar para aumentar la velocidad o para desarrollar funcionalidades que diferencien la aplicación o el servicio, los cuales pueden ayudar a proporcionar una ventaja competitiva para toda la organización.

La necesidad de normalización y estándares no significa que los equipos no deban innovar. Para probar algo debe haber una barerra menor y poca resistencia a la experimentación. La barrera debería aumentar significativamente cuando se trata de introducir una nueva pieza de tecnología en un ciclo de vida de producción.

Los beneficios clave de estandarizar los patrones de un equipo y tecnologías son:

● Mayor velocidad de entrega ● Más flexibilidad para que el personal de desarrollo trabaje en diferentes

aplicaciones, servicios o componentes

● Superficie reducida para vulnerabilidades de seguridad ● Menos piezas móviles para mantener, actualizar y aprender