¿Cuál es la diferencia entre DevOps y Automation?

Veo que cada vez que alguien hace DevOps, se trata principalmente de automatizar cosas como la implementación, etc.

Pero, ¿dónde termina la automatización y comienza DevOps?

Una gran parte de DevOps está haciendo posible el lanzamiento con mucha frecuencia. Eso viene con compilación automatizada, pruebas automatizadas, etc. Puede decir que para lograr sus objetivos, DevOps necesita usar la automatización para ser eficiente.

Así es como se relacionan DevOps y la automatización. DevOps no es solo automatización, hay más. Por el contrario, la automatización no es utilizada exclusivamente por "personas DevOps". Se estaba produciendo mucha automatización en TI antes de que DevOps apareciera.

No considere el diagrama anterior para representar todo lo que es DevOps, o todo esto es automatización. Es para ayudar al lector a imaginar cómo se relacionan los dos conceptos.

La automatización es un atributo clave de DevOps, pero no es la historia completa. La pregunta es algo así como "¿Cuál es la diferencia entre time-boxing y Scrum?".

Escuchará a DevOps llamado una 'cultura', un 'movimiento', una 'metodología' y todo tipo de cosas que no lo encajarán lo suficientemente bien como para que usted lo entienda, aunque esas descripciones sean precisas. En pocas palabras, DevOps trata sobre la confluencia de metodologías ágiles, automatización y virtualización que permite un nuevo ciclo de retroalimentación en la gestión / control / dirección de un proyecto de software.

Con la automatización agresiva, las cosas que solían llevar mucho tiempo y estar sujetas a errores humanos ahora suceden rápidamente y sin incidentes. Como resultado, tendemos a hacerlas más a menudo. Un ejemplo principal de esto es un 'despliegue en producción'. Solíamos guardar grandes lotes de trabajo y desplegarlos fuera de horario en caso de que 'algo saliera mal'. Pero ahora podemos implementar cambios varias veces al día, de manera que las posibilidades de que "algo salga mal" se reduzca drásticamente, y de tal manera que el impacto de que algo salga mal sea mucho menor cuando ocurra.

Una vez que tenemos este proceso repetible en su lugar, comenzamos a verlo como una 'tubería'. Los requisitos entran, sale el código implementado en producción. Automatizamos todo a lo largo de esta tubería: pruebas, documentación, fusiones, implementaciones y más pruebas, y así sucesivamente ... Debido a que las personas se centran en la automatización, no ven la 'mentalidad de tubería' que la impulsó. Esta es la metodología de gestión, la atención prestada en la tubería, que hace que DevOps sea más que Automatización.

Una vez que tenemos esa automatización en su lugar, los bucles de retroalimentación entran en acción. Comenzamos a medir cosas como el tiempo del ciclo para que podamos descubrir cosas que habíamos intentado adivinar con estimaciones. Las cosas sobre la arquitectura que hacen que la automatización / entrega continua sea difícil tienden a ser reemplazadas por patrones arquitectónicos alternativos que hacen que la automatización / entrega continua sea más fácil (varios ejemplos excelentes de esto están documentados en el libro 'Bases de datos evolutivas'. 'Las implementaciones verdes / azules' son otra )

Tenga en cuenta que pude proporcionar esta descripción sin hablar de Jenkins, Check, Puppet, Ansible, Vagrant, AWS o cualquiera de las otras herramientas que lo admiten. Esto es lo que queremos decir con palabras de moda de nivel más alto como 'metodología'. Al final, cualquier conjunto de herramientas puede ser reemplazado ... Lo que nos queda son los principios básicos de administración habilitados por la automatización y el enfoque en la tubería.

DevOps es realmente un cambio cultural: está destinado a romper las barreras tradicionales entre las operaciones y el desarrollo (¡y realmente también con el control de calidad y el resto del negocio!). La idea es que, en lugar de tener 'silos' departamentales, puede trabajar directamente con otros equipos para hacer las cosas de manera más rápida y eficiente.

Se trata de eliminar restricciones y racionalizar procesos. La automatización entra en gran medida porque tener procesos repetibles ayuda a eliminar restricciones. Por ejemplo: si alguien de operaciones tiene que hacer un proceso de liberación manual para llevar el código a un entorno, hay un par de cosas que pueden interponerse en el camino, una es que tiene que haber alguien en operaciones libre para hacer la implementación, y dos, hay menos confianza en el proceso de lanzamiento porque el trabajo manual es propenso a errores.

DevOps incluye automatización, pero eso es solo una parte. DevOps es un cambio cultural para romper los silos entre las diferentes partes de la organización para proporcionar un flujo de valor completo. Proporcionando una cultura donde los negocios, el desarrollo, el aseguramiento de la calidad, la infraestructura, la seguridad, las operaciones, etc., todos trabajen juntos para proporcionar valor a quien sea el usuario final. DevOps no es una herramienta, no puedes comprarla, tienes que cambiar tu cultura.

La automatización es una parte clave de DevOps, ya que permite la velocidad de entrega con calidad. La automatización para el proceso de implementación es una de las áreas en las que muchas personas se enfocan primero, ya que es una de las mejores maneras de ganar valor rápidamente y proporciona un alto retorno de la inversión no solo al reducir el tiempo de implementación sino también al estandarizar el proceso y eliminar errores

Me gustaría agregar mis 2 centavos:
1) Automatización :
     Algo a lo que hoy tenemos que movernos. Se ha convertido en una necesidad en la que la forma preferida sería automatizar piezas, si no todo el proceso. Este enfoque brinda a los usuarios (desarrolladores) flexibilidad para usar un paso fijo y poder personalizarlo según sea necesario.
     La ventaja de este enfoque es que podemos automatizar las partes que deseamos, mientras que el proceso individual puede ser vinculado por el desarrollador. Cuanto más granulados sean los pasos de automatización, mejor control tendrán.
     Además, hay muchas herramientas para la automatización en espacios como la automatización robótica, la automatización SOP (para la industria de servicios), la automatización de informes (como Splunk), etc.
2) DevOps:
     Dado el estado de calidad de entrega y la puntualidad que se espera del mundo actual, existe la necesidad de extender la automatización del proceso de entrega de software. Para habilitar esto y proporcionar valor al cliente de la manera más rápida posible, DevOps confía ampliamente en las herramientas de automatización.
     La ventaja de este enfoque es que los pasos individuales pueden automatizarse para lograr consistencia en toda la empresa, mientras que la orquestación general puede modificarse para adaptarse al proceso que necesita ese proyecto.
     Las herramientas de automatización individuales (en cierto modo) como Chef para la implementación, Docker a través de Dockerfile, Maven para la compilación, etc. se pueden unir probablemente a través de Jenkins para proporcionar la solución requerida y al mismo tiempo reducir el tiempo necesario para la implementación o el uso .
Espero que esto ayude a agregar valor al proceso de pensamiento que ya pueda tener.

Editar: Olvidé agregar que había hablado sobre el Proceso y las Herramientas - 2 de los 3 aspectos en DevOps. Como lo mencionaron los demás, el tercer aspecto e igualmente importante es la Gente. Una de las principales diferencias que asumiría entre esto y la automatización sería que las personas son más propensas a absorber la automatización con más frecuencia de lo que se resistirían a DevOps. Creo que esto se debe a la naturaleza de DevOps en sí, ya que la automatización generalmente se asocia con hacerles las cosas más fáciles, mientras que sienten que DevOps está cambiando la forma en que se sienten cómodos.

El movimiento DevOps consta de cuatro áreas principales abreviadas como CAMS :

1. Cultura
2. Automatización
3. Medición
4. Compartir

Aquí está la publicación definitoria original de 2010.

En cada área hay algunas herramientas, procesos y prácticas que generalmente se aceptan, aunque el tema no está bien definido para las mejores prácticas, en la mayoría de los casos hay algunas buenas prácticas a seguir.

La automatización en sí misma es un tema un poco más amplio, pero en el contexto de DevOps es solo un subconjunto de lo que se está cubriendo. Tome nota de que lideramos con la cultura, aunque muchos profesionales de DevOps nuevos en el campo a menudo lo pasan por alto bajo su propio riesgo y pasan directamente a la automatización.

La automatización y DevOps no están relacionados. DevOps es más como una ingeniería combinada en la que los Desarrolladores de un sitio o servicio son todos los Operadores de ese sitio o servicio. ¿Por qué es esta novela? En mi experiencia, lo primero que hizo el equipo de Ops cuando sucedió algo más emocionante que una falla en la red fue llamar al equipo de desarrollo. ¿Por qué hicieron eso? Porque todo lo que hizo el equipo de Ops fue monitorear y mantener una lista de números de teléfono de desarrolladores para llamar.

Tenga en cuenta que no he dicho nada sobre la automatización.

La automatización se trata de repetir el éxito. Si hago los pasos a, byc y el proceso X siempre funciona, entonces los pasos a, byc son buenos candidatos para la automatización. Entonces puedo usar el tiempo para lo que solía ser un proceso manual para hacer cosas que me hacen ganar más dinero. La automatización es exitosa cuando es simple. La implementación de nuevas versiones, la ejecución de pruebas de integración, el apriete de una tuerca en un tornillo, la copia de seguridad de datos, el equilibrio de créditos frente a débitos, etc.son excelentes candidatos para la automatización porque los pasos los repite una persona o un robot.

Nota : Lo nuevo es que los desarrolladores también son los operadores. No hay otro grupo. La cooperación en mi caso fue rara. Si no había nada en la Guía de solución de problemas (también conocido como TSG), se le garantizó una llamada telefónica. En mi experiencia, Ops fue la primera llamada en caso de retroexcavadora. Los problemas entre los servicios estaban fuera de su timonera.