DevOps Teams – Topología o Antipatrones
La implementación de una cultura DevOps requiere de herramientas y sobretodo de organizarse en base a una orientación. Dos conceptos básicos para los DevOps teams en esto de las Topologías Devops: Antipatrones (Anti Types) y las topologías de Equipo.
Se trata de un modelo desarrollado en https://web.devopstopologies.com/ que he traducido para su lectura en castellano 🙂
Topologías de Equipo
Son los modelos organizativos que puedes optar para implementar los DevOps Teams y que mejor pueden funcionar.
Topología 1: Colaboración entre Dev y Ops
Tierra soñada para todas las organizaciones.
Ideal para organizaciones tecnológicas.
Efectividad potencial: ALTA
Efectividad potencial: ALTA
Topología 2: Responsabilidades Ops totalmente compartidas
Organizaciones como Netflix y Facebook totalmente orientadas a un producto digital consiguen esta forma de trabajar en la que no se distingue apenas entre técnicos para tocar cualquier aspecto.
Topología 3: Ops cuando se convierte en Infraestructura como servicio (IaaS)
Cuando llevas mucho tiempo con TI.
Organizaciones con muchas plataformas tecnológicas y servicios con un área Ops tradicional o que están funcionando completamente en Nube Pública.
Efectividad potencial: MEDIA
Efectividad potencial: MEDIA
Topología 4: DevOps como servicio externo
Para organizaciones pequeñas antes de saltar a la topología 3 o quizás la 1.
Topología 5: Equipo DevOps con fecha de caducidad
Para evitar caer en el riesgo de implementar mal una cultura DevOps.
Como modelo precursor para la Topología 1.
Efectividad potencial: BAJA – ALTA
Efectividad potencial: MEDIA o ALTA
Topología 6: Equipo defensor de DevOps
Para organizaciones grandes previa a la implementación de la topología 5.
Topología 7: Equipo SRE (Modelo Google)
SRE – Site Reliability Engineering.
Es un modelo para organizaciones muy maduras en el mantenimiento de la Disponibilidad/Servicio operativo.
Efectividad potencial: BAJA – ALTA
Efectividad potencial: MEDIA-ALTA
Topología 8: Colaboración orientada al contenedor
Con la implementación de Contenedores resulta efectivo para desarrollar multiplataforma manteniendo equipos especializados en Ops.
Topología 9: Colaboración Dev con DBA
Se trata de una colaboración entre el equipo Dev que tiene expertos en DBA pero que contrastan con los DBA focalizados en la optimización de recursos.
Efectividad potencial: MEDIA
Anti Patrones DevOps
Se refieren a estructuras organizativas de malas prácticas en la implementación de Devops
Antipatrón A: Silo entre Dev y Ops
Situación habitual cuando se empieza a trabajar de modo Agile en la que Dev no cuenta con la parte Ops de los productos software.
Antipatrón B: Silo generado con el equipo DevOps
Con el afán de empezar a trabajar esto de DevOps puede generar un equipo en la mitad que vuelve a establecer un nuevo grupo, con nuevos silos.
Antipatrón C: Dev no necesita de Ops
Situación generada cuando el equipo Dev cree innecesaria la participación de Ops porque con la nube, ya no les necesitan.
Antipatrón D: DevOps como equipos de herramientas
Ocurre cuando hemos empezado a trabajar en Agile y para no penalizar la velocidad de los equipos, se crea un equipo para generar herramientas pero las aplicaciones se siguen desplegando a producción vía Ops, sin contar con Ops.
Antipatrón E: Renombrar al SysAdmin
En organizaciones con escasos conocimientos técnicos. Cuando quieren mejorar su nivel para reducir costes y mejorar la fiabilidad de los sistemas. Contratan Administradores DevOps en su parte Ops.
Antipatrón F: Ops embebido en el equipo Dev
Cuando se elimina la parte Ops para participar como integrantes de los equipos Dev y se deja de lado la importancia del conocimiento de las operaciones.
Antipatrón G: Silos entre Dev y DBA
Ocurre en organizaciones con bastante legacy que se basan en bases de datos con muchos años. La labor de los DBA (Data Base Administrator) dentro de Ops es defender la correctitud del sistema siendo una limitación para el desarrollo de la integración continua.
