¿Qué es DevOps? Cual es la deficniciòn y rol de un DevOps?

DevOps es un término para un grupo de conceptos que, aunque no todos son nuevos, se han convertido en un movimiento y se están extendiendo rápidamente por toda la comunidad técnica. Como cualquier término nuevo y popular, la gente puede tener impresiones confusas y a veces contradictorias de lo que es. Este es mi punto de vista sobre cómo se pueden definir útilmente los DevOps; propongo esta definición como un marco estándar para discutir más claramente las diversas áreas que cubre DevOps. Al igual que “Calidad” o “Ágil”, DevOps es un concepto lo suficientemente grande como para que requiera algún matiz para ser comprendido plenamente.
Definición de DevOps

DevOps es un nuevo término que surge de la colisión de dos grandes tendencias relacionadas. El primero también se denominó “infraestructura ágil” u “operaciones ágiles”; surgió de la aplicación de enfoques Ágiles y Lean al trabajo de operaciones. El segundo es una comprensión mucho más amplia del valor de la colaboración entre el personal de desarrollo y de operaciones a lo largo de todas las etapas del ciclo de vida de desarrollo al crear y operar un servicio, y de la importancia que han adquirido las operaciones en nuestro mundo cada vez más orientado al servicio (cf. Operaciones: La nueva salsa secreta).

Una definición que Jez Humble me propuso es que DevOps es “una comunidad interdisciplinaria de práctica dedicada al estudio de la construcción, evolución y operación de sistemas resilientes a escala que cambian rápidamente”.

Eso es bueno y carnoso, pero puede ser un poco demasiado esotérico y específico para los tipos de inicio de Internet. Creo que puedes definir DevOps más prácticamente como

DevOps es la práctica de los ingenieros de operaciones y desarrollo que participan juntos en todo el ciclo de vida del servicio, desde el diseño, pasando por el proceso de desarrollo, hasta el soporte de producción.

Un corolario primario de esto es que parte del cambio más importante en la práctica con respecto a los métodos anteriores es

DevOps también se caracteriza por un personal de operaciones que utiliza muchas de las mismas técnicas que los desarrolladores para el trabajo de sus sistemas.

Estas técnicas pueden ir desde el uso del control de fuentes hasta la participación en un proceso de desarrollo ágil.

Para este propósito, “DevOps” no distingue entre diferentes sub-disciplinas de administración de sistemas – “Ops” es un término general para ingenieros de sistemas, administradores de sistemas, personal de operaciones, ingenieros de lanzamiento, DBAs, ingenieros de redes, profesionales de seguridad, y varias otras sub-disciplinas y títulos de trabajo. “Dev” se utiliza como abreviatura para los desarrolladores en particular, pero en la práctica es aún más amplio y significa “todas las personas involucradas en el desarrollo del producto”, que puede incluir Producto, control de calidad y otros tipos de disciplinas.

DevOps tiene fuertes afinidades con los enfoques Agile y Lean. La antigua visión de las operaciones tendía a que el lado “Dev” fuera el lado “creador” y el lado “Ops” el lado “personas que se ocupan de la creación después de su nacimiento” – la realización del daño que se ha hecho en la industria de esos dos que se han tratado como preocupaciones silenciadas es el motor principal detrás de DevOps. De esta manera, DevOps puede ser interpretado como una consecuencia de Agile – el desarrollo ágil de software prescribe una estrecha colaboración de los clientes, la gestión de productos, los desarrolladores, y (a veces) QA para llenar los vacíos y rápidamente iterar hacia un mejor producto – DevOps dice “sí, pero la prestación de servicios y la forma en que la aplicación y los sistemas interactúan son una parte fundamental de la propuesta de valor para el cliente, por lo que el equipo de productos necesita incluir esas preocupaciones como un elemento de alto nivel”. Desde esta perspectiva, DevOps simplemente está extendiendo los principios ágiles más allá de los límites del “código” a todo el servicio entregado.
Definición En Profundidad

DevOps significa muchas cosas diferentes para diferentes personas porque la discusión a su alrededor cubre mucho terreno. La gente habla de DevOps como “colaboración entre desarrolladores y operaciones”, o como “tratar su código como infraestructura”, o como “usar automatización”, o “usar kanban”, o “un enfoque de cadena de herramientas”, o “cultura”, o una variedad de elementos aparentemente poco relacionados. La mejor manera de definirlo en profundidad es utilizar un método paralelo a la definición de un término igualmente complejo, el desarrollo ágil. El desarrollo ágil, según Wikipedia y el manifiesto ágil, consta de cuatro “niveles” de preocupación diferentes. He añadido una quinta, el nivel de herramientas – hablar de ágiles y los devops puede llegar a obsesionarse demasiado con las herramientas, pero pretender que no existen también es inútil.

Valores Ágiles – Filosofía de alto nivel, generalmente aceptada para ser incorporada en el Manifiesto Ágil. Estos son los valores centrales que informan a ágil.
Principios Ágiles – Enfoques estratégicos generalmente acordados que apoyan estos valores. El Manifiesto Ágil cita una docena de estos principios más específicos. No tienes que comprar en todos ellos para ser ágil, pero si no te suscribes a muchos de ellos, es probable que estés haciendo otra cosa.
Métodos Ágiles – Implementaciones de procesos más específicos de los principios. XP, Scrum, su propio proceso casero – aquí es donde la filosofía da paso a los playbooks operativos de “cómo pretendemos hacer esto en la vida real”.

Prácticas Ágiles – técnicas tácticas altamente específicas que tienden a ser usadas en conjunto con implementaciones ágiles. No se requiere que ninguno sea ágil, pero muchas implementaciones ágiles han visto el valor de adoptarlas. Standups, póquer de planificación, backlogs, CI, todos los artefactos específicos que un desarrollador utiliza para realizar su trabajo.
Herramientas Ágiles – Implementaciones técnicas específicas de estas prácticas utilizadas por los equipos para facilitar la realización de su trabajo de acuerdo a estos métodos. JIRA Agile (alias Greenhopper), planningpoker.com, et al.

Idealmente, los niveles más altos informan a los niveles más bajos – las personas u organizaciones que recogen herramientas y prácticas específicas sin entender los fundamentos pueden o no ver beneficios, pero este enfoque de “culto a la carga” generalmente se considera que tiene resultados subóptimos. Creo que las diferentes partes de DevOps de las que la gente habla son mapas directamente a estos mismos niveles.

Valores DevOps – Creo que los valores fundamentales de DevOps están efectivamente capturados en el Manifiesto Ágil – con tal vez una pequeña corrección para enfocarse en el servicio global o el software totalmente entregado al cliente en lugar de simplemente “software de trabajo”. Algunas definiciones previas de DevOps, como “People over Process over Tools” de Alex Honor, se hacen eco de las declaraciones básicas del Agile Manifesto e instan a la colaboración de dev+ops.
Principios DevOps – No hay una sola lista acordada, pero hay varios intentos ampliamente aceptados – aquí está John Willis acuñando “CAMS” y aquí está James Turnbull dando su propia definición a este nivel. “Infraestructura como código” es un principio de DevOps comúnmente citado. He hecho un corte en “DevOps’ing” del manifiesto y los principios ágiles existentes aquí. Personalmente creo que DevOps a nivel conceptual es principalmente la ampliación de los principios de Agile para incluir sistemas y operaciones en lugar de detener sus preocupaciones en el chequeo de código.
Métodos DevOps – Algunos de los métodos aquí son los mismos; puede usar Scrum con operaciones, Kanban con operaciones, etc. (aunque normalmente con más enfoque en la integración de operaciones con dev, QA, y producto en los equipos de producto). Existen algunos métodos más distintos, como el control de cambios al estilo de las operaciones visibles y el uso del Sistema de Mando de Incidentes para la respuesta a incidentes. El conjunto de estas metodologías está creciendo; un enfoque más reflexivo del monitoreo es un área donde las metodologías comunes no han sido bien definidas, por ejemplo.
Prácticas de desarrollo -Técnicas específicas utilizadas como parte de la implementación de los conceptos y procesos anteriores. Integración continua y despliegue continuo, “Dé a sus desarrolladores un buscapersonas y póngalos a disposición”, utilizando gestión de configuración, métricas y esquemas de monitorización, un enfoque de cadena de herramientas para el herramental…. Incluso el uso de la virtualización y la computación en nube es una práctica común utilizada para acelerar el cambio en el mundo de la infraestructura moderna.
Herramientas de DevOps – Herramientas que usted usaría en la comisión de estos principios. En el mundo de DevOps ha habido una explosión de herramientas en lanzamiento (jenkins, travis, teamcity), gestión de configuración (marionetas, chef, ansible, cfengine), orquestación (zookeeper, noah, mesos), monitorización, virtualización y contenedorización (AWS, OpenStack, vagrant, docker) y muchas más. Mientras que, al igual que con Agile, es incorrecto decir que una herramienta es “una herramienta DevOps” en el sentido de que mágicamente te traerá DevOps, ciertamente hay herramientas específicas que están siendo desarrolladas con el objetivo expreso de facilitar los principios, métodos y prácticas anteriores, y una comprensión holística de DevOps debería incorporar esta capa.

Al final, DevOps es un poco difícil de definir, al igual que su hermano mayor Agile. Pero vale la pena hacerlo. Cuando se dejan en el nivel de filosofía pura, ambas pueden parecer declaraciones vacías de mamá y manzana, sujetas a la crítica “Sólo me estás diciendo “hacer mejor mi trabajo,’ duh….” Pero a la inversa, sólo las prácticas sin la guía de nivel superior se convierten en un culto a la carga. “Hago lo que dice este libro de Scrum para hacer Agile” es tan erróneo como “Estoy usando Chef y soy DevOps, ¿verdad?” Ser un practicante exitoso de Agile o DevOps es entender todas las capas que lo componen, y lo que una determinada implementación de DevOps puede contener o no contener. Al final, lo que DevOps espera traer a Agile es el entendimiento y la práctica de que el software no se hace hasta que es entregado exitosamente a un usuario y cumple con sus expectativas en cuanto a disponibilidad, rendimiento y ritmo de cambio.

Específicamente, he llegado a la conclusión de que hay tres áreas de práctica principales que normalmente se discuten en el contexto de DevOps.

Automatización de la infraestructura: cree sus sistemas, configuraciones del sistema operativo e implementaciones de aplicaciones como código.
Entrega Continua – construya, pruebe e implemente sus aplicaciones de forma rápida y automatizada.
Ingeniería de Confiabilidad del Sitio – opere sus sistemas; monitoreo y orquestación, seguro, pero también diseñando para la operabilidad en primer lugar.

Historia de DevOps

La génesis de DevOps proviene de una creciente necesidad de innovación en el lado de los sistemas del trabajo tecnológico. El movimiento DevOps hereda del movimiento Agile System Administration y del movimiento Enterprise Systems Management (ESM).

ESM, que surgió a mediados de 2000, proporcionó el impulso original de “Hey, nuestra metodología de funcionamiento de los sistemas parece estar todavía en un estado bastante primitivo a pesar de los años de esfuerzo. Empecemos a hablar de hacerlo mejor”. John Willis, Whurley, y Mark Hinkle de Zenoss estuvieron involucrados en eso, y patrocinaron un BarCamp alrededor del concepto. Creo que durante esta fase, el encanto inicial con ITIL como marco de gobierno fue derrocado en gran medida por el enfoque de Visible Ops de “ITIL Lite”, así como por el cambio de estar enfocado en los “grandes proveedores” – antes, los marcos empresariales como HP, IBM y CA eran las únicas soluciones significativas para la gestión de sistemas de extremo a extremo, pero estaban surgiendo más cosas de código abierto y de proveedores más pequeños, incluyendo Spiceworks, Hyperic, Zenoss, y otros.

También en 2008, O’Reilly celebró la primera conferencia Velocity, centrada en el rendimiento y las operaciones de la Web, que proporcionó un lugar para compartir información sobre las mejores prácticas de las operaciones. En 2009 hubo algunas presentaciones importantes sobre la colaboración entre desarrolladores/operaciones en grandes tiendas (más notablemente Flickr) y cómo esto promovió un cambio rápido y seguro en los entornos Web. Herramientas de aprovisionamiento como Puppet y Chef tuvieron fuertes presentaciones allí. Más gente empezó a pensar en estos nuevos conceptos y a preguntarse cómo podrían implementarlos.

Paralelamente, a medida que el crecimiento del desarrollo ágil en el espacio de desarrollo alcanzaba su punto más álgido y pasaba de un nicho a una práctica común, esto se convirtió en una reflexión sobre la “Administración de Sistemas Ágiles”, especialmente en Europa. Gordon Banner, del Reino Unido, habló de ello desde el principio con esta presentación. Gran parte del enfoque de este movimiento se centró en el proceso y las analogías desde los procesos de kanban y lean manufacturing hasta la administración de sistemas de TI. Luego, en 2009, Patrick Debois de Bélgica y Andrew “Clay” Shafer de los Estados Unidos se conocieron y comenzaron a hablar de DevOps (y acuñaron el término), y luego Patrick organizó el primer evento DevOpsDays en Gante que encendió la mecha. El concepto, ahora que tenía un nombre, empezó a ser más hablado en otros lugares (lo descubrí en OpsCamp Austin) incluyendo Velocity y DevOpsDays aquí en los EE.UU. y se extendió rápidamente.

Desde el punto de vista de Patrick Debois, DevOps surgió como una reacción contra los silos y la inflexibilidad que estaban resultando de las prácticas existentes, lo que probablemente suena familiar. He aquí una buena pieza de John Willis sobre la historia del movimiento DevOps que deconstruye los hilos que se unieron para crearlo.

DevOps surgió de una “tormenta perfecta” de estas cosas que se juntaron. La creciente automatización y el enfoque de la cadena de herramientas alimentado por más herramientas de monitoreo y aprovisionamiento, la necesidad de procesos ágiles y la colaboración entre los departamentos de desarrollo y operaciones, junto con el fracaso de las grandes y pesadas implementaciones de ITSM/ITIL, colisionaron y unieron inconscientemente las tres capas de lo que se necesita para el movimiento ágil (principios, procesos y prácticas) y se incendiaron. Desde entonces se ha desarrollado aún más, sobre todo mediante la inclusión de los principios Lean por parte de muchos de los líderes de pensamiento.

No es “nos están quitando el trabajo”. Algunos piensan que DevOps significa que los desarrolladores se están haciendo cargo de las operaciones y lo hacen ellos mismos. Parte de eso es cierto y parte no lo es.

Es un concepto erróneo que DevOps viene del lado del desarrollo de la casa para eliminar las operaciones – DevOps, y sus antecedentes en operaciones ágiles, están siendo iniciados fuera de los equipos de operaciones más a menudo que no. Esto se debe a que la gente de operaciones (y hablo por mí mismo aquí también) se ha dado cuenta de que nuestros principios, procesos y prácticas existentes no han seguido el ritmo de lo que se necesita para el éxito. A medida que las empresas y los equipos de desarrollo necesitan más agilidad a medida que el clima empresarial se acelera, a menudo hemos estado proporcionando menos a medida que intentamos resolver nuestros problemas con más rigidez, y necesitamos una reorientación fundamental para poder proporcionar una infraestructura de sistemas de manera eficaz.

Ahora, cuando nos damos cuenta de que algunas partes de las operaciones necesitan ser automatizadas, eso significa que o bien la gente de ops realiza algún desarrollo de automatización, o bien los desarrolladores están escribiendo código de “operaciones”, o ambos. Eso asusta a algunos, pero es parte del valor del enfoque de colaboración general. Todos los equipos exitosos que he dirigido utilizando este enfoque tienen tanto personas con un conjunto de habilidades de desarrollo como de operaciones que trabajan juntas para crear un mejor producto en general. Y todavía no he visto a nadie que se automatice a sí mismo fuera de un trabajo en alta tecnología – a medida que las preocupaciones de bajo nivel se vuelven más automatizadas, el personal técnicamente capacitado comienza a resolver los problemas de mayor valor en un nivel superior.
No son (sólo) herramientas

 

 

Secured By miniOrange