Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOps es Cultura

DevOps es Cultura

En esta presentación intento aclarar un poco que "DevOps no es un perfil, es una cultura".

En resumen: que no existe el DevOps Architect o DevOps Principal o DevOps Engineer o cosas similares.

Es una habilidad inherente, nada más.

Jose María Flores Zazo

March 19, 2021
Tweet

More Decks by Jose María Flores Zazo

Other Decks in Technology

Transcript

  1. View Slide

  2. DevOps es una cultura no un es perfil

    View Slide

  3. Bienvenidos
    Acerca de…
    ¡Hola! Gracias por entrar en esta presentación.
    Espero poder aportarte la información necesaria para que entiendas
    por qué DevOps es una cultura y no un perfil.
    Jose María Flores Zazo, autor

    View Slide

  4. Cultura
    DevOps
    Dirigir una empresa con una Cultura
    DevOps, es adoptar la cultura
    adecuada para permitir que
    desarrolladores y el equipo de
    operaciones trabajen juntos. Una
    cultura DevOps aboga por
    implementar las mejores prácticas,
    confiando en las herramientas y la
    tecnología.

    View Slide

  5. El origen de DevOps (1/4)
    Sección 1
    DevOps es un movimiento que comenzó oficialmente en Bélgica en 2009, cuando un grupo de gente se reunió en la
    primera conferencia devopsdays.org, organizada por Patrick Debois, para discutir cómo aplicar algunos conceptos
    ágiles a la infraestructura.
    Las metodologías ágiles han sido las que han transformado la forma en que se desarrolla el software actualmente.
    En un modelo de cascada (waterfall), el equipo del producto vendría con las especificaciones; el equipo de diseño
    crearía y definiría el UX/UI; el equipo de ingeniería comenzaría a implementar el producto o característica
    solicitada, y posteriormente entregaría el código al equipo de control de calidad, que probaría y aseguraría que el
    código se comportó correctamente, de acuerdo con el diseño y especificaciones. Una vez que se corrigieran todos
    los errores, un equipo de lanzamiento empaquetaría el código final, que sería entregado al equipo de operaciones
    técnicas, para implementar el código y supervisar los servicios a lo largo del tiempo.
    DevOps – HISTORIA

    View Slide

  6. El origen de DevOps (2/4)
    Sección 1
    Equipo
    Producto
    Equipo
    Diseño
    Desarrollo QA Equipo
    Lanzamiento
    Equipo
    Operaciones
    Técnicas
    Especificaciones UI/UX Implementación Testing Crear la versión
    final de despliegue
    Desplegar
    y
    monitorizar

    View Slide

  7. El origen de DevOps (3/4)
    Sección 1
    La creciente complejidad del desarrollo del software y tecnologías demostró las limitaciones con este proceso de
    tradicional de cascada. La transformación ágil se centra en algunos de estos problemas, lo que permite una mayor
    interacción entre los diseñadores, desarrolladores y verificadores. Este cambio aumentó la calidad general del
    producto, ya que estos equipos ahora tenían la oportunidad de iterar más sobre el desarrollo de productos. Sin
    embargo, aparte de esto, todavía permanecíamos en una de cascada muy clásica, de la siguiente manera:
    Complejidad – HISTORIA
    Equipo
    Producto
    Especificaciones
    QA Equipo
    Lanzamiento
    Equipo
    Operaciones
    Técnicas
    Testing Crear la versión
    final de despliegue
    Desplegar
    y
    monitorizar
    Descubrir
    Desarrollar
    Diseñar
    Testing Sprint

    View Slide

  8. El origen de DevOps (4/4)
    Sección 1
    Toda la agilidad agregada por este nuevo proceso no se extendió más allá de los ciclos de control de calidad, y
    esto demostró que era hora de modernizar este aspecto del ciclo de vida de desarrollo de software.
    Este nuevo enfoque, cambiar mediante el proceso ágil, permite una mayor colaboración entre los diseñadores,
    desarrolladores, equipos de control de calidad, es lo que DevOps buscaba inicialmente, pero muy rápidamente, el
    movimiento DevOps comenzó a repensar cómo los desarrolladores y los equipos de operaciones podrían trabajar
    juntos.
    La actualidad real de esta evolución es que muchas empresas se han quedado en el modelo anterior y no han dado
    el paso definitivo a DevOps

    View Slide

  9. El dilema de Desarrolladores vs Operaciones (1/4)
    Sección 2
    En una cultura que no es DevOps, los desarrolladores están a cargo del desarrollo de nuevos productos,
    características y mantenimiento del código existente, y en ultima instancia, se ven recompensados cuando
    entregan su código. El incentivo es entregar lo más rápido posible.
    Por otro lado, el equipo de operaciones, en general, es responsable de mantener el tiempo de actividad de la
    producción. Para este equipo, el cambio es algo negativo. Nuevas funciones y servicios aumentan el riesgo de
    sufrir una interrupción y, por lo tanto, es importante moverse con precaución. Para minimizar el riesgo de
    interrupciones, los equipos de operaciones generalmente tienen que programar cualquier implementación con
    anticipación, para que puedan organizar y probar esa implementación en producción y maximizar sus
    posibilidades de éxito.
    También es muy común en el software empresarial que las empresas programen ventanas de mantenimiento y, en
    estos casos, los cambios de producción solo se pueden realiza alguna vez durante el trimestre, semestralmente o
    una vez al año. Lamentablemente, muchas veces las implementaciones no tendrán éxito, y posiblemente existirán
    muchas razones para ello.
    DevOps – TODOS SOMOS UN EQUIPO

    View Slide

  10. El dilema de Desarrolladores vs Operaciones (2/4)
    Sección 2
    Existe una correlación que puede establecerse entre el tamaño del cambio y el riesgo de introducir errores críticos
    en el producto, tal y como podemos ver a continuación:
    Demasiado código cambiando a la vez – CORRELACIÓN

    View Slide

  11. El dilema de Desarrolladores vs Operaciones (3/4)
    Sección 2
    A menudo, el código producido por los desarrolladores funciona bien en ecosistema de desarrollo, pero no en
    producción. Muchas veces, es porque el ecosistema de producción es muy diferente de otros entornos, y se
    producen algunos errores imprevistos. Los errores más comunes que involucran al entorno de desarrollo suelen
    ser:
    • Porque los servicios son colocados en los mismos servidores, o no existe el mismo nivel de seguridad. Como
    consecuencia, los servicios pueden comunicarse entre sí en el entorno de desarrollo, pero no en producción.
    • Otro problema es que el entorno de desarrollo podría no ejecutar las mismas versiones de una biblioteca de
    software, por tanto, la interfaz para comunicarse con ellos podría diferir; el entorno de desarrollo puede estar
    ejecutando una versión más nueva de un servicio que tiene nuevas características que el de producción aún no
    tiene.
    • O podría ser simplemente una cuestión de escalado. Quizás el conjunto de datos utilizado en el desarrollo no
    sea tan grande como el de producción, y problemas de escalado surgirá una vez que el nuevo código esté en
    producción.
    Entornos – DIFERENCIAS

    View Slide

  12. El dilema de Desarrolladores vs Operaciones (4/4)
    Sección 2
    Uno de los mayores dilemas de la tecnología de la información es la falta de comunicación. De acuerdo con la Ley
    de Conway:
    “Organizations which design systems are constrained to produce designs which are copies of the communication
    structures of these organizations.” Melvin Conway.
    En otras palabras, el producto que está construyendo refleja la comunicación de su organización. Muchas veces,
    los problemas no provienen de la tecnología, sino de personas y organizaciones que rodean la tecnología. Si hay
    disfunción entre sus desarrolladores y equipo de operaciones de la organización, esto se verá reflejado.
    En una cultura DevOps, los desarrolladores y las operaciones tienen una mentalidad diferente. Ayudan a romper
    los silos que rodear a esos equipos, compartiendo responsabilidades y adoptando metodologías similares para
    mejorar la productividad. Juntos, intentan automatizar lo que sea posible (no todo, ya que no todo puede
    automatizarse de una sola vez) y usan métricas para medir su éxito.
    Comunicacion – LA BASE

    View Slide

  13. Adopta la Cultura DevOps (1/4)
    Sección 3
    En alguna ocasión habrás podido ver alguna de estas imágenes:
    Ellas hacen referencia al proceso integrador de la cultura, en ningún momento existe una desconexión entre
    cualquiera de los departamentos existentes. Es decir, lo que hace un equipo afecta al otro, por tanto, dejamos de
    estar separados y cualquier éxito o fracaso pertenece al conjunto de la organización, no aun departamento en
    concreto.
    Un solo equipo – COMUNICACIÓN

    View Slide

  14. Adopta la Cultura DevOps (1/4)
    Sección 3
    Esto no es DevOps:
    Introducir una cuña, departamento, grupo de personas, llamémosle X entre el área de Desarrollo y Operaciones, no
    es lo que se necesita. Lo que se necesita es meter agentes con habilidades y cultura para poder evangelizar a los
    demás componentes del conjunto.
    Separación – COMUNICACIÓN
    Dev
    X
    Ops

    View Slide

  15. Adopta la Cultura DevOps (1/6)
    Sección 3
    Principio #3
    Medirlo todo
    Automatizarlo todo
    Principio #2
    >
    La cultura DevOps se basa en unos principios:
    El código fuente (control de
    versiones) lo controla todo
    Principio #1

    View Slide

  16. Adopta la Cultura DevOps (2/6)
    Sección 3
    El software de control de revisiones ha existido durante muchas décadas, pero con demasiada frecuencia, solo el
    código del producto está bajo el auspicio de las herramientas de control de versiones.
    Al poner en practicar DevOps, no solo es el código de la aplicación será verificado, si no que tanto las
    configuraciones, las pruebas, la documentación y la automatización de la infraestructura necesaria para
    implementar la aplicación en todos los entornos, pasarán por esa verificación.
    Todo va a pasar el proceso de revisión regular por parte la herramienta de Source Control Manager (SCM).
    Control de versiones – LA PIEDRA ANGULAR

    View Slide

  17. Adopta la Cultura DevOps (3/6)
    Sección 3
    El software de control de revisiones ha existido durante muchas décadas, pero con demasiada frecuencia, solo el
    código del producto está bajo el auspicio de las herramientas de control de versiones.
    Al poner en practicar DevOps, no solo es el código de la aplicación será verificado, si no que tanto las
    configuraciones, las pruebas, la documentación y la automatización de la infraestructura necesaria para
    implementar la aplicación en todos los entornos, pasarán por esa verificación.
    Todo va a pasar el proceso de revisión regular por parte la herramienta de Source Control Manager (SCM).
    Automatización – LAS HERRAMIENTAS

    View Slide

  18. Adopta la Cultura DevOps (4/6)
    Sección 3
    Como ya sabrá, ahora, es más fácil escribir software en pequeños trozos y desplegar los nuevos trozos lo antes posible, para asegurarse
    de que funcionan.
    Para llegar a ello, las empresas que practican DevOps dependen de la integración continua (CI) y de las tuberías (pipelines) de
    despliegue. Cada vez que un nuevo fragmento de código está listo, la tubería de integración continua se pone en marcha: mediante de un
    sistema de pruebas automatizado, el nuevo código se ejecuta a través de todas las pruebas relevantes y disponibles; si el nuevo código
    no muestra una regresión obvia, se considera válido y ese fragmento será fusionado con la base de código principal. En ese momento,
    sin mayor participación del desarrollador, se creará una nueva versión del servicio (o de la aplicación) que incluya esos nuevos cambios y
    se entregará a un sistema denominado sistema de despliegue continuo (CD – Continuos Deployment) o entrega continuada (CD –
    Continuos Delivery).
    Despliegue automatizado (1/3) – EL MOTOR

    View Slide

  19. Adopta la Cultura DevOps (5/6)
    Sección 3
    Por ejemplo, para el sistema de despliegue continuo tomará las nuevas construcciones (builds) y las desplegará automáticamente en los
    diferentes entornos disponibles. Dependiendo de la complejidad del proceso de despliegue, éste puede incluir un entorno de AUT, un
    entorno de integración y, a veces, un entorno de preproducción. En última instancia, si todo va según lo planeado (sin ninguna
    intervención manual), esta nueva construcción será desplegada a la producción. Si optamos por la entrega continuada, todo el proceso
    es similar, con la salvedad que deberá existir una intervención humana para permitir el paso de un entorno a otro. Simplemente son
    técnicas que se adaptan a su organización.
    Despliegue automatizado (2/3) – EL MOTOR

    View Slide

  20. Adopta la Cultura DevOps (6/6)
    Sección 3
    Un aspecto de la práctica de la integración y el despliegue continuos que a menudo se malinterpreta es que las nuevas características no
    tienen por qué ser accesibles a los usuarios tan pronto como se desarrollan. En este paradigma, los desarrolladores dependen en gran
    medida de la Feature Flag y los dark lauches. Esencialmente, cada vez que se desarrolla un nuevo código y se quiere ocultar a los
    usuarios finales, se pone una Flag en la configuración del servicio para describir quién tiene acceso a la nueva característica. A nivel de
    desarrollo, al lanzar una nueva característica de esta manera, puede enviar tráfico de producción al servicio, por ejemplo, escondiéndolo
    de la interfaz de usuario, para ver el impacto que tiene en su base de datos o en el rendimiento. A nivel de producto, puedes decidir
    habilitar la nueva característica sólo para un pequeño porcentaje de sus usuarios, para ver si la nueva característica funciona
    correctamente, este grupo de usuarios que tienen acceso a la nueva característica están más comprometidos que el grupo de control. En
    resumen, podemos usar técnicas de despliegue que implican Testing estructurado y despliegue controlado: Canary Releases, A/B
    Tesging o Blue-Green Deployment.
    Despliegue automatizado (3/3) – EL MOTOR

    View Slide

  21. DevOps no es un perfil (1/3)
    Sección 4
    Tras esta explicación, habrás comprendido que cuando un reclutador de recursos humanos busca un: Ingeniero de
    DevOps, Arquitecto de DevOps o “Título” DevOps, está buscando una quimera.
    Este mal entendido suele ser por dos causas:
    • O bien, la empresa que busca este perfil desconoce que es DevOps y en realidad lo que está buscando un perfil
    de automatización, ya sea para desarrollo o infraestructura y por que a su vez el reclutador desconoce la
    realidad y se lanza a la búsqueda de estos perfiles. En conclusión: desconocimiento.
    • O bien, lo que está buscando la empresa es un engranaje que evangelice y realice proselitismo en el área que le
    corresponde: desarrollo, infraestructura u operaciones. En cuyo caso lo que se debe hacer es pedir que el perfil
    que va a formar parte del área posea unas habilidades que pueda compartir con el equipo para que poco a poco
    adopte la cultura de DevOps.
    Todo sea dicho, esta búsqueda es el primer paso hacia una cultura de DevOps.
    Habilidades – INHERENTE A LOS PERFILES

    View Slide

  22. DevOps no es un perfil (2/3)
    Sección 4
    Tal y como decía no se trata de un perfil, si no de una cualidad que debe dase en la organización. Y debe ser la
    organización quien nos provea de un ecosistema que nos permita ser DevOps.
    Por ejemplo, para poder aplicar un ciclo completo, suele usarse el ecosistema:
    • Azure DevOps, donde tenemos todas las herramientas Agiles, las herramientas de control de versiones, de
    CI/CD y QA. Junto a Azure, donde podemos realizar todas el despliegue y monitorización.
    • Otro ecosistema muy difundido es el que provee Atlassian: Confluence, Jira, Bitbucket, junto a Jenkins,
    Terraform para el IaC alojado en Bitbucket o GitLab o … junto a herramientas de QA y calidad y un entorno de
    despliegue a on-premise o AWS, por poner un ejemplo.
    Cada organización puede organizar su ecosistema de una u otra forma, pero tal y como habrás aprendido lo más
    importante que debe proveer la organización es que existe la comunicación entre los diversos entes que hacen
    funcionar el objetivo común para hacer desaparecer los silos.
    Herramientas – INHERENTES A LA ORGANIZACIÓN

    View Slide

  23. DevOps no es un perfil (3/3)
    Sección 4
    Para un Ops
    QA, monitorización, despliegues,
    etc.
    Todos DevOps
    Habilidades o herramientas
    comunicativas para poder solicitar
    a las otras áreas que colaboren con
    su problema y realizar un ALM
    completo.
    Para un Dev
    Manejo fluido del lenguaje,
    patrones, SOLID, Pipelines, control
    de versiones, QA, etc.
    Para un Infra
    Redes, seguridad, configuraciones,
    IaC, Pipelines, control de versiones,
    QA, etc.

    View Slide

  24. DevOps
    Sección 6
    Habilidades
    Cada componente debe poseer las habilidades para
    poder usar las herramientas y defender la cultura.
    Herramientas
    Son un fin para lograr el objetivo. Implementar
    herramienta sin la cultura, no sirve de nada.
    Cultura
    La organización debe proveer y velar por la cultura y
    cada componente debe defenderla de forma férrea.

    View Slide

  25. ¡Gracias!
    Puedes encontrarme buscando por jmfloreszazo en

    View Slide