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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
jmfloreszazo
jacopen
arthur1
sbtechnight
keigotomomatsu
oracle4engineer
ryomaru0825
line_developers
cembasaranoglu
masashi_sutou
garrettdimon
aleyda
marktimemedia
chrislema
kastner
productmarketing
jlugia
62gerente
eileencodes
holman
moore
stephaniewalter