Devops - Apuntes 1 PDF

Preview

Summary

porque se necesita Devops - intro...

Description

Origen – DevOps A pesar de que DevOps es una de las palabras de moda que a día de hoy no puede faltar en cualquier evento de IT que se precie, pocos conocen el origen de su historia Cuenta la leyenda que fue en 2008 en una convención informal de agilismo cuando un belga presentó y argumentó el concepto por primera vez, aún sin bautizarlo. El término "DevOps” como tal se popularizó en 2009, a partir de los “ DevOps Days” celebrados primero en Gante (Bélgica) y luego replicados en varias ciudades del mundo. Así, resulta muy revelador comprobar cómo el movimiento DevOps está fuertemente ligado desde su origen a las metodologías ágiles de desarrollo software. Todo comenzó de hecho en la conferencia Agile'08 celebrada en agosto de ese año en Toronto (Canadá). Andrew Clay Shafer (creador de Puppet Labs y ahora en Pivotal, la spinoff de MVware y EMC2 que liberó la base de datos NoSQL Redis), tenía un slot asignado, pero a su charla sólo había acudido una persona, un belga llamado Patrick Debois, así que decidió ahorrársela. Asaltado en los pasillos por ese mismo joven, que había ido a contar su caso de no-éxito ("Infraestructura Agile y operaciones: ¿cómo de infra-ágil eres?"), y ante su insistencia, comenzaron a discutir cómo se podría llevar el agilismo al mundo de la infraestructura y la administración de sistemas. Patrick había vivido una experiencia muy frustrante en un proyecto para el ministerio belga de finanzas que ni desarrolladores de software ni administradores de sistemas habían logrado sacar adelante. Animados por este intercambio de ideas, acordaron crear un grupo en Google para abrir la discusión a la comunidad, el Agile System Administrators Group. Un año después, O'Reilly organizaba en junio en San José (California) el evento Velocity'09, transmitido en streaming. Tras la exposición de la ahora muy citada “10+ Deploys a Day: Dev and Ops Cooperation at Flickr" por John Allspaw y Paul Hammond, Patrick se lamentaba en Twitter de no haber podido asistir en persona. Entonces Paul Nasrat, responsable del CMS del periódico británico The Guardian y desde 2010 en Google, respondió a su tuit proponiéndole que organizara un evento similar en Europa. Patrick recogió el guante y sólo cuatro meses después estaba convocado su primer DevOps Day. La repercusión fue enorme, y el hashtag creado para la ocasión, #DevOps, triunfó en las redes sociales de forma viral, dando nombre a todo un movimiento. En lo único que parece disentir Patrick Debois, que actualmente alterna sus trabajo en la radiotelevisión flamenca con su labor de consultor de su propia empresa Jedi BVBA, es en la forma de escribirlo: frente a la común acepción de hacerlo con la doble mayúscula, DevOps, Patrick piensa que sería más pertinente una sola palabra, Devops; la discusión sigue viva, y una tercera facción aboga por eliminar las mayúsculas y escribirlo simple y llanamente como devops. Ya conoces cómo se fraguó el término y su intrínseca relación con el agilismo

Qué es DevOps (y sobre todo qué no es DevOps) DevOps es uno de los términos más mencionados en el actual entorno de IT. Normalmente se asocia a estrategias de transformación digital, y a metodologías como Continuous Delivery o desarrollo ágil. Como ocurre con la mayoría de las buzzwords tecnológicas, es complicado encontrar una definición canónica, y es frecuente de hecho encontrar usos del término contradictorios, o flagrantemente incorrectos. Gran parte de la confusión viene de mezclar lo que es DevOps con los requisitos necesarios o los beneficios obtenidos al implementar DevOps. Sin querer ser excesivamente dogmáticos acerca de un término cuyas líneas de contorno aún no han acabado de asentarse del todo, vamos a intentar al menos arrojar algo de luz sobre el concepto. DevOps según WikiPedia Comenzamos con lo más próximo que hoy en día podemos tener a una definición canónica. ¿Qué dice Wikipedia de DevOps?: *"DevOps es un acrónimo inglés de development (desarrollo) y operations (operaciones), que se refiere a una metodología de desarrollo de software que se centra en la comunicación, colaboración e integración entre desarrolladores de software y los profesionales de sistemas en las tecnologías de la información (IT)".*DevOps es una respuesta a la interdependencia del desarrollo de software y las operaciones IT. Su objetivo es ayudar a una organización a producir productos y servicios software más rápidamente, de mejor calidad y a un coste menor. Las empresas con entregas (releases) muy frecuentes podrían requerir conocimientos de DevOps. Flickr desarrolló un sistema DevOps para cumplir un requisito de negocio de diez despliegues diarios. A este tipo de sistemas se les conoce como despliegue continuo (continuous deployment) o entrega continua (continuous delivery), y suelen estar asociados a metodologías lean startup. Grupos de trabajo, asociaciones profesionales y blogs usan el término desde 2009". Todo claro, ¿verdad? ¿O pensáis como yo que hay overflow de conceptos? Rescatemos de momento tres ideas clave: 

DevOps es una metodología para creación de software.



DevOps se basa en la integración entre desarrolladores software y administradores de sistemas.



DevOps permite fabricar software más rápidamente, con mayor calidad, menor coste y una altísima frecuencia de releases.

Con estos conceptos en mente, repasemos algunas corrientes de opinión en torno a DevOps. ¿Es DevOps una cultura? No, DevOps no es en sí una cultura, pero sí requiere de un fuerte cambio cultural y organizativo para su implementación. Un cambio cultural hacia la colaboración, la comunicación, y en último término la completa integración entre las antiguas áreas (en lo habitual rabiosamente estancas) de desarrollo y sistemas.

Este cambio cultural es tan complicado de conseguir en algunas organizaciones, que son muchos los que lo identifican directamente con DevOps, pero recordemos: DevOps es una metodología de desarrollo software, y un cambio de cultura no es en sí mismo una forma de desarrollar software.

¿Es DevOps una nueva raza de hombres orquesta? Otro error común es confundir DevOps con modelos que algunas startups se ven abocadas a adoptar en sus inicios, en los que todos los miembros del equipo técnico saben de desarrollo, de sistemas, de tuning de rendimiento, de bases de datos... y hasta de cablear la oficina, comprar portátiles y hasta configurar el móvil de la gente de negocio. Ese modelo puede funcionar durante un tiempo, pero no escala. DevOps no consiste en aumentar la responsabilidad de los desarrolladores haciendo que lleven varias gorras (en particular dos, la de desarrollo y la de sistemas), sino en sustituir esas dos gorras por una sola: una nueva gorra DevOps. ¿Es DevOps una profesión? Según Rob Steward, vicepresidente de desarrollo de producto de Progress Software, “una buena práctica de DevOps liberará a los desarrolladores para que se centren en hacer lo que mejor saben hacer: escribir software. DevOps elimina el trabajo y las preocupaciones de la puesta en producción del software una vez que está escrito”. Si esto es así, ¿qué es un ingeniero DevOps? ¿No hemos quedado en que DevOps permite que un desarrollador sólo desarrolle? ¿Entonces por qué se buscan en el mercado –y cada vez con mayor demanda- perfiles con habilidades específicas para montar equipos DevOps? La respuesta es sencilla: para un desarrollador pasar a un modelo DevOps resulta inmediato, mientras que un ingeniero de sistemas necesita nuevas habilidades. Estas habilidades, según una investigación de Puppet Labs, son, por este orden: scripting, don de gentes, reingeniería de procesos, y en último lugar experiencia con herramientas específicas. Un perfil que no es fácil de encontrar. Así que no, DevOps no es una profesión, y estrictamente no existen ni perfiles DevOps ni ingenieros DevOps, sino “ingenieros de sistemas con capacidades específicas para integrarse en equipos DevOps”. DevOps: un modelo de desarrollo de productos digitales Como conclusión, quedémonos con una definición simple de DevOps con la que todos podamos estar de acuerdo: DevOps es una metodología de desarrollo software basada en la integración entre desarrolladores y administradores de sistemas, que permite que los desarrolladores puedan enfocarse sólo en desarrollar y puedan desplegar su código en segundos. DevOps es especialmente útil en el nuevo entorno de la transformación digital y el desarrollo de productos digitales, para los que el usuario final y/o el cliente interno de negocio demanda TTM (time-to-market), más flexibilidad, más calidad, menos coste y una altísima frecuencia de releases.

¿Por qué se necesita DevOps? Antes de DevOps, el equipo de desarrollo y operación trabajaba en completo aislamiento. Las pruebas y la implementación fueron actividades aisladas realizadas después de la creación del diseño. Por lo tanto, consumieron más tiempo que los ciclos reales de construcción. Sin usar DevOps, los miembros del equipo dedican una gran parte de su tiempo a probar, desplegar y diseñar en lugar de construir el proyecto. La implementación manual del código provoca errores humanos en la producción. Los equipos de codificación y operación tienen sus cronogramas separados y no están sincronizados, causando más retrasos. ¿Por qué se usa DevOps? DevOps permite a los equipos de desarrollo ágiles implementar la integración continua y la entrega continua. Esto les ayuda a lanzar productos más rápidamente en el mercado. Otras razones importantes son: Es Predecible: DevOps ofrece una tasa de fallas significativamente menor de las nuevas versiones. 1. Reproducibilidad: Permite que la versión anterior pueda restaurarse en cualquier momento. 2. Mantenimiento: Proceso de recuperación sin esfuerzo en caso de que una nueva versión falle o deshabilite el sistema actual. 3. Tiempo de comercialización: DevOps reduce el tiempo de comercialización hasta un 50% mediante la entrega de software simplificada. Este es particularmente el caso de las aplicaciones digitales y móviles. 4. Mayor calidad: DevOps ayuda al equipo a mejorar la calidad del desarrollo de aplicaciones ya que incorpora problemas de infraestructura. 5. Riesgo reducido: DevOps incorpora aspectos de seguridad en el ciclo de vida de la entrega del software. Ayuda en la reducción de defectos en todo el ciclo de vida. 6. Resistente: el estado operativo del sistema de software es más estable, seguro y los cambios son consultables. 7. Eficiencia de costes: DevOps ofrece rentabilidad en el proceso de desarrollo de software, que siempre es una aspiración de la gestión de las empresas de TI. 8. Rompe una base de código más grande en pequeños trozos: DevOps se basa en el método de programación ágil. Por lo tanto, permite dividir las bases de códigos más grandes en trozos más pequeños y manejables. ¿Cuándo no adoptar DevOps?

No debe usarse en una aplicación de misión crítica como bancos, energía y otros sitios de datos confidenciales. Dichas aplicaciones necesitan estrictos controles de acceso en el entorno de producción, una política detallada de gestión de cambios, política de control de acceso a los centros de datos. Principios de DevOps Aquí, hay seis principios que son esenciales al adoptar DevOps: 1. Acción centrada en el cliente: el equipo de DevOps debe tomar medidas centradas en el cliente para que constantemente inviertan en productos y servicios. 2. Responsabilidad de extremo a extremo: el equipo de DevOps debe proporcionar soporte de rendimiento hasta que se ocurra el fin de vida. Esto mejora el nivel de responsabilidad y la calidad de los productos diseñados. 3. Mejora Continua: la cultura DevOps se centra en la mejora continua para minimizar el desperdicio. Continuamente acelera la mejora del producto o los servicios ofrecidos. 4. Automatiza todo: la automatización es un principio vital del proceso DevOps. Esto no es solo para el desarrollo de software, sino también para todo el panorama de la infraestructura. 5. Trabajar como un solo equipo: en el rol de DevOps, el del diseñador, desarrollador y evaluador ya están definidos. Todo lo que tenían que hacer es trabajar como un equipo con total colaboración. 6. Monitorea y pruebe todo: es muy importante que el equipo de DevOps tenga un sólido monitoreo y procedimientos de prueba. El enfoque de DevOps necesita cambios frecuentes e incrementales en las versiones de código, lo que significa frecuentes despliegues y pruebas. Aunque los ingenieros de DevOps necesitan codificar de vez en cuando desde cero, es importante que tengan las bases de los lenguajes de desarrollo de software. Un ingeniero de DevOps trabajará con el personal del equipo de desarrollo para abordar la codificación y secuencias de comandos necesarias para conectar elementos de código, como bibliotecas o kits de desarrollo de software. 7 principios clave para una cultura DevOps exitosa // puede usarse este también Para satisfacer las demandas del mercado, las compañías están adoptando una cultura de DevOps para optimizar el desarrollo, la implementación, la administración y el mantenimiento del software a escala. La forma más rápida de crear un entorno DevOps es combinar el equipo de desarrollo con el equipo de operaciones, lo que obliga a colaborar y comunicarse más. Pero, para lograr realmente una cultura DevOps, deberá seguir algunos principios clave para una transición sin problemas. 1. Fomentar un entorno de colaboración

La teoría principal detrás de DevOps es combinar el desarrollo y las operaciones para crear un equipo unilateral que se enfoque en la entrega de objetivos comunes. Para que las marcas logren esto, deben alentar el desarrollo y las operaciones para comunicarse regularmente, compartir ideas y resolver problemas juntos. 2. Imponer responsabilidad de extremo a extremo En el modelo de desarrollo de software tradicional, los desarrolladores y las operaciones tenían roles separados. Pero en DevOps, ambos grupos trabajan como un equipo que es totalmente responsable de la aplicación de principio a fin. 3. Fomentar la mejora continua La responsabilidad de extremo a extremo también significa que las marcas deben adaptarse continuamente a las circunstancias cambiantes, ya sea el surgimiento de nuevas tecnologías, las necesidades de los clientes o los cambios en la legislación. DevOps se centra principalmente en la mejora continua para optimizar el rendimiento, el coste y la velocidad de entrega. 4. Automatizar (casi) todo Para luchar por la mejora continua con altas tasas de ciclos y la capacidad de responder de forma inmediata a los comentarios de los clientes, las marcas deben utilizar procesos automatizados. 5. Centrarse en las necesidades del cliente DevOps requiere que las marcas actúen como una startup que pueda innovar continuamente, girar cuando una estrategia ya no funciona, e invertir en características para brindar satisfacción al cliente. Los equipos de DevOps deben tener un dedo en el pulso para satisfacer de manera constante las necesidades de las demandas cambiantes de los consumidores. Los datos recogidos de los procesos automatizados. 6. Abrazar el fracaso y aprender de él Para adoptar plenamente la computación en la nube a través de DevOps, una marca debe cambiar su actitud hacia el fracaso. Al aceptar el fracaso, las marcas fomentan un "clima para el aprendizaje" que tendrá un impacto positivo en la cultura organizacional. 7. Unir Equipos y Experiencia Los equipos de DevOps deben participar en cada etapa del ciclo de vida del desarrollo del software, desde la planificación, la construcción, la implementación, la retroalimentación y la mejora. Esto requiere un equipo multifuncional en el que cada miembro esté bien formado y tenga un conjunto equilibrado de habilidades.

Roles, responsabilidades y habilidades de un ingeniero DevOps Los ingenieros de DevOps trabajan a tiempo completo. Ellos son responsables de la producción y el mantenimiento continuo de la plataforma de una aplicación de software.

Los siguientes son algunos de los roles, responsabilidades y habilidades que se esperan del ingeniero DevOps: 

Capaz de realizar la solución de problemas del sistema y la solución de problemas en los dominios de plataforma y aplicaciones.



Gestione el proyecto de manera efectiva a través de plataformas abiertas y basadas en estándares.



Aumentar la visibilidad del proyecto, la trazabilidad.



Mejore la calidad y reduzca los costos de desarrollo con la colaboración.



Analizar, diseñar y evaluar scripts y sistemas de automatización.



Garantizar la resolución crítica de los problemas del sistema mediante el uso de los mejores servicios de soluciones de seguridad en la nube.

El ingeniero de DevOps debe tener la habilidad suave de resolver problemas y aprender rápidamente. Descripción del ciclo de DevOps DevOps tiene sus raíces en metodologías Iterativas, y más específicamente en la evolución de las herramientas para desarrollo Agile. Reúne en un solo bucle dos mundos de la industria que hasta ahora estaban meridianamente separados, y que ha sido fuente de rivalidades y discusiones durante las últimas décadas: Desarrollo y Operaciones. Sin embargo, el objetivo de DevOps es que ambos grupos de trabajo se coordinen, se comuniquen y establezcan lazos de cooperación que dejen atrás esas diferencias artificiales, frente a las necesidades de integración que los sistemas informáticos requieren. Planificación. Esto, que en metodologías en Cascada es el principal escollo para un desarrollo iterativo, en Agile se convierte en una conversación continuada con el cliente. En donde se define el trabajo a realizar, se prioriza de acuerdo a su complejidad y valor, o se cambia el alcance de forma dinámica, quitando o añadiendo requisitos dentro del tiempo acordado. Es esta planificación, la inicial para sentar las bases del proyecto y las que se suceden de forma continuada durante todos los sprint, sobre la que trabaja el equipo. Decidiendo cual es la forma óptima de construir y tomando las decisiones tecnológicas que correspondan. Con la actualización diaria de la herramienta de visualización del flujo de trabajo, y las liturgias de descritas por la metodología, se realiza un seguimiento del estado del proyecto y de los impedimentos que estuvieran afectando al desarrollo. Desde el punto de vista de las herramientas de DevOps, partiendo de una visión Agile, estas soportan todos los trabajos de documentación, modelado de la planificación y las priorizaciones. También, la gestión del flujo de trabajo por medio de tableros electrónicos, la obtención de métricas y la visibilidad del estado de avance de forma sencilla e inmediata.

Desarrollo y pruebas En este capítulo lo que más impacto tiene, desde el punto de vista de DevOps, es la automatización del almacenamiento del código. Para ello existen plataformas de control de versiones que permiten realizar conceptos básicos como versionado, histórico y trabajo colaborativo por medio de estructuras de desarrollo en ramas. Estos repositorios de código han dado un paso adelante al asociar el código al flujo de tareas, permitiendo una trazabilidad absoluta, e integrando las herramientas de pruebas, rendimiento y calidad, en el flujo de trabajo diario del desarrollador. Pero nada de ello tendría sentido si no hubiera una (re) evolución cultural (nacida en los años 90) en la industria de la codificación de software, que ha traído nuevos baremos de calidad y buenas prácticas; donde ya no solamente importa que las aplicaciones funcionen bien, si no también el cómo lo hacen. Y que aún dista de estar implantada en la generalidad de nuestro sector. Publicación continúa Si tengo código versionado, y tengo baterías de pruebas que aseguran tanto la calidad como el funcionamiento de toda la aplicación, automatizando dichos procesos he llegado al concepto de Integración Continua. Cada vez que yo actualice mi código en el repositorio, se va a lanzar la ejecución de todas las pruebas necesarias que revisen su integración con el resto del software, y que no “rompe” nada. Fácil es de ver que el siguiente paso dentro del flujo de automatizaciones es que, ese código compilado y comprobado, pueda ser d...