IBM & Turbonomic | Observando el desempeño de las aplicaciones ¡Participa del Webinar!

DevOps

¿Qué es DevOps?

Por definición, DevOps esboza un proceso de desarrollo de software y un cambio de cultura organizativa que acelera la entrega de software de mayor calidad mediante la automatización y la integración de los esfuerzos de los equipos de desarrollo y de operaciones de TI, dos grupos que tradicionalmente trabajaban por separado el uno del otro, o en silos.

En la práctica, los mejores procesos y culturas DevOps se ex tienden más allá del desarrollo y las operaciones para incorporar las aportaciones de todas las partes interesadas en la aplicación, incluyendo la ingeniería de la plataforma y la infraestructura, la seguridad, la conformidad, la gestión, la gestión de riesgos, la línea de negocio, los usuarios finales y los clientes, en el ciclo de vida del desarrollo de software.

DevOps representa el estado actual de la evolución de los ciclos de entrega de software durante los últimos 20 años, desde los gigantescos lanzamientos de códigos para toda la aplicación cada varios meses o incluso años, hasta las presentaciones iterativas más pequeñas o las actualizaciones funcionales lanzadas tan frecuentemente como a diario o varias veces al día.

En última instancia, DevOps trata de satisfacer las exigencias cada vez mayores de los usuarios de software en cuanto a nuevas funciones frecuentes e innovadoras y a un rendimiento y disponibilidad ininterrumpidos.

Cómo llegamos a DevOps

Hasta poco antes del año 2000, la mayoría de los programas informáticos se desarrollaban y actualizaban utilizando la metodología de cascada, un enfoque lineal para los proyectos de desarrollo a gran escala. Los equipos de desarrollo de software pasaban meses desarrollando grandes conjuntos de código nuevo que afectaban a la mayor parte o a la totalidad de la aplicación. Como los cambios eran tan amplios, pasaron varios meses más integrando ese nuevo código en el código base.

A continuación, los equipos de garantía de calidad (QA), seguridad y operaciones pasarían aún más meses probando el código. El resultado era que transcurrían meses o incluso años entre los lanzamientos de software, y generalmente también varios parches o correcciones de errores significativos entre los lanzamientos. Y este enfoque de «big bang» para la presentación de la entrega se caracterizaba generalmente por planes de implementación complejos y arriesgados, por la dificultad de planificar las interconexiones con los sistemas anteriores y posteriores, y por la «gran esperanza» de TI de que los requisitos del negocio no hubieran cambiado drásticamente en los meses previos a la puesta en vivo de la producción.

Para acelerar el desarrollo y mejorar la calidad, los equipos de desarrollo comenzaron a adoptar metodologías ágiles de desarrollo de software, que son iterativas en lugar de lineales y se centran en realizar actualizaciones más pequeñas y frecuentes del código base de la aplicación. Entre estas metodologías destacan integración continua y entrega continua, o CI/CD. En CI/CD se fusionan porciones más pequeñas de código nuevo en la base de código cada una o dos semanas, y luego se integran, se prueban y se preparan automáticamente para su implementación en el entorno de producción. El enfoque ágil hizo evolucionar el «big bang» hacia una serie de «pequeños snaps» que también compartimentaron los riesgos.

Cuanto más eficazmente aceleraban estas prácticas de desarrollo ágil el desarrollo y la entrega de software, más exponían las operaciones de TI aún en silos, aprovisionamiento del sistema, configuración, prueba de aceptación, gestión, supervisión, como el siguiente cuello de botella en el ciclo de vida de la entrega de software.

Así que DevOps surgió de Agile. Añadió nuevos procesos y herramientas que extienden la iteración continua y la automatización de CI/CD al resto del ciclo de vida de la entrega de software. Y puso en marcha una estrecha colaboración entre desarrollo y operaciones en cada paso del proceso.

Cómo funciona DevOps: El ciclo de vida deDevOps

Diagrama de flujo demostrando el ciclo de vida de DevOps

Figura 1: El ciclo de vida de DevOps

El ciclo de vida de DevOps (a veces llamado el conducto de entrega continua, cuando se representa de forma lineal) es una serie de procesos de desarrollo iterativos y automáticos, o flujos de trabajo, ejecutados dentro de un ciclo de vida de desarrollo más amplio, automático e iterativo, diseñado para optimizar la entrega rápida de software de alta calidad. El nombre y el número de flujos de trabajo pueden variar según a quién se pregunte, pero normalmente se reducen a estos seis:

  • Planificación (o ideación). En este flujo de trabajo, los equipos abarcan nuevas características y funcionalidades en el próximo lanzamiento, basándose en la retroalimentación priorizada de los usuarios finales y en los estudios de casos, así como en las aportaciones de todas las partes interesadas internas. La meta en la etapa de planeación es maximizar el valor de negocio del producto produciendo una lista de tareas de características que al ser entregadas producen un resultado deseado que tiene valor.

  • Desarrollo. Esta es la etapa de programación, en la que los desarrolladores prueban, codifican y construyen funciones nuevas y mejoradas, basándose en las historias de los usuarios y en los elementos de trabajo de la lista de tareas. Es habitual la combinación de prácticas como el desarrollo dirigido por pruebas (TDD), la programación por pares y las revisiones de códigos por iguales, entre otras. Los desarrolladores suelen utilizar sus estaciones de trabajo locales para ejecutar el «ciclo interno» de escritura y prueba de código antes de enviarlo por la línea de trabajo de entrega continua.

  • Integración (o construir, o integración continua y entrega continua (CI/CD). Como se ha señalado anteriormente, en este flujo de trabajo el nuevo código se integra en el código base existente, luego se prueba y se empaqueta en un ejecutable para su implementación. Las actividades comunes de automatización incluyen la fusión de los cambios del código en una copia «maestra», la comprobación de ese código desde un repositorio de código de origen, y la automatización de la compilación, la unidad de prueba y el empaquetado en un ejecutable. La mejor práctica es almacenar la salida de la fase CI en un repositorio binario, para la siguiente fase.

  • Implementación (normalmente llamada implementación continua). Aquí la salida de construcción de tiempo de ejecución (de la integración) se implementa a un entorno de tiempo de ejecución – normalmente un entorno de desarrollo donde se ejecutan pruebas de tiempo de ejecución para la calidad, la conformidad y la seguridad. Si se encuentran errores o defectos, los desarrolladores tienen la oportunidad de interceptar y resolver cualquier problema antes de que los usuarios finales lo vean. Normalmente existen entornos de desarrollo, prueba y producción, y cada uno de ellos requiere puertas de calidad cada vez más «estrictas». Una buena práctica para la implementación a un entorno de producción suele ser implementar primero a un subconjunto de usuarios finales, y luego, eventualmente, a todos los usuarios una vez establecida la estabilidad.

  • Operaciones. Si conseguir que las características se entreguen a un entorno de producción se caracteriza como «Día 1», entonces una vez que las características están funcionando en la producción se producen las operaciones del «Día 2». La supervisión del rendimiento de la presentación, del comportamiento y de la disponibilidad garantiza que las funciones sean capaces de aportar valor añadido a los usuarios finales. Operaciones se encarga de que las funciones se ejecuten sin problemas y de que no haya interrupciones en el servicio, asegurándose de que la red, el almacenamiento, la plataforma, la computación y la posición de seguridad estén en buen estado. Si algo va mal, el departamento de operaciones se asegura de que se identifiquen los incidentes, se avise al personal adecuado, se determinen los problemas y se apliquen las soluciones.
  • Aprendizaje (a veces llamado retroalimentación continua). Se trata de la recopilación de la retroalimentación de los usuarios finales y los clientes sobre las características, la funcionalidad, el rendimiento y el valor de negocios para regresar a la planificación de las mejoras y características el próximo lanzamiento. Esto también incluiría cualquier elemento de aprendizaje y lista de tareas de las actividades de las operaciones, que podría facultar a los desarrolladores para evitar proactivamente cualquier incidente pasado que pudiera volver a ocurrir en el futuro. Este es el punto en el que se produce la ‘envoltura’ a la fase de Planificación y ‘mejoramos continuamente’.

Entre estos flujos de trabajo continuos hay otros tres importantes:

Prueba continua: Los ciclos de vida clásicos de DevOps incluyen una fase discreta de «prueba» que ocurre entre la integración y la implementación. Sin embargo, DevOps ha avanzado de tal manera que ciertos elementos de prueba pueden ocurrir en la planeación (desarrollo impulsado por el comportamiento), desarrollo (prueba de unidad, prueba de contrato), integración (escaneos de código estático, escaneos CVE, linting), implementación ( prueba de humo, prueba de penetración, prueba de configuración ), operaciones (prueba de caos, prueba de conformidad ) y aprendizaje (prueba A/B). Las pruebas son un potente formulario de identificación de riesgos y vulnerabilidades y proporcionan una oportunidad para que TI acepte, mitigue o resuelva los riesgos.

Seguridad: Mientras que las metodologías en cascada y las implementaciones ágiles «añaden» flujos de trabajo de seguridad después de la entrega o la implementación, DevOps se esfuerza por incorporar la seguridad desde el inicio (planificación) -cuando los problemas de seguridad son más fáciles y menos costosos de dirigir- y de forma continua durante el resto del ciclo de desarrollo. Este enfoque de la seguridad se denomina desplazamiento a la izquierda (que es más fácil de entender si se observa la Figura 1). Algunas organizaciones han tenido menos éxito en el cambio a la izquierda que otras, lo que ha llevado al surgimiento de DevSecOps (ver a continuación).

Conformidad. La conformidad regulatoria (gestión y riesgo) también se aborda mejor desde el principio y a lo largo del ciclo de vida del desarrollo. Los sectores regulados suelen tener el mandato de proporcionar un cierto nivel de observabilidad, rastreabilidad y acceso a cómo se entregan y administran las características en su entorno operativo de tiempo de ejecución. Esto requiere la planificación, el desarrollo, la prueba y la aplicación de políticas en el proceso de entrega continua y en el entorno de tiempo de ejecución. La auditabilidad de las medidas de conformidad es extremadamente importante para demostrar la conformidad a los auditores terceros.

Cultura de DevOps

Es generalmente aceptado que los métodos DevOps no pueden funcionar sin un compromiso con la cultura DevOps, que se puede resumir como un enfoque organizativo y técnico diferente para el desarrollo de software.

A nivel organizativo, DevOps requiere comunicación continua, colaboración y responsabilidad compartida entre todas las partes interesadas en la entrega de software -los equipos de desarrollo de software y de operaciones de TI, por supuesto, pero también los equipos de seguridad, conformidad, gestión, riesgo y línea de negocios- para innovar de forma rápida y continua, y para incorporar la calidad en el software desde el principio.

En la mayoría de los casos, la mejor manera de conseguirlo es romper estos silos y reorganizarlos en equipos de DevOps autónomos e interfuncionales que puedan trabajar en proyectos de código desde el inicio hasta el final -planificación a retroalimentación- sin tener que hacer traspasos a otros equipos ni esperar sus aprobaciones. En el contexto del desarrollo ágil, la responsabilidad compartida y la colaboración son la base para tener un enfoque de producto compartido que tenga un resultado valioso.

A nivel técnico, DevOps requiere un compromiso con la automatización que mantiene los proyectos en movimiento dentro y entre los flujos de trabajo, y con la retroalimentación y la medición que habilitan a los equipos para acelerar continuamente los ciclos y mejorar la calidad y el rendimiento del software.

Herramientas de DevOps: Creación de una cadena de herramientas de DevOps

Las exigencias de DevOps y de la cultura DevOps hacen que sea necesario contar con herramientas que soporten la colaboración asíncrona, que integren a la perfección los flujos de trabajo de DevOps y que automaticen todo el ciclo de vida de DevOps en la medida de lo posible. Las categorías de herramientas DevOps incluyen:

  • • Herramientas de gestión de proyectos -herramientas que habilitan a los equipos para construir una lista de tareas de historias de usuario (requisitos) que forman los proyectos de codificación, desglosándolas en tareas más pequeñas y realizando el seguimiento de las tareas hasta su finalización. Muchos soportan prácticas ágiles de gestión de proyectos, como Scrum, Lean y Kanban, que los desarrolladores aportan a DevOps. Las opciones populares de código abierto incluyen GitHub Issues y Jira.
  • Repositorios colaborativos de código de origen -entornos de codificación con control de versiones que permiten a varios desarrolladores trabajar sobre el mismo código base. Los repositorios de código deben integrarse con herramientas de CI/CD, de prueba y de seguridad, de modo que cuando el código se consigne en el repositorio pueda pasar automáticamente al siguiente paso. Los repositorios de código abiertos de origen incluyen GiHub y GitLab.
  • Líneas de trabajo de CI/CD- herramientas que automatizan la finalización de compra, construcción, prueba e implementación de código. Jenkins es la herramienta de código abierto más popular en esta categoría; muchas alternativas previas de código abierto, como CircleCI, están ahora disponibles sólo en versiones comerciales. Cuando se trata de herramientas de implementación continua (CD), Spinnaker se sitúa entre la aplicación y la infraestructura como capas de código. ArgoCD es otro código abierto popular para CI/CD nativo de Kubernetes.
  • Marcos de automatización de pruebas- incluyen herramientas de software, bibliotecas y mejores prácticas para automatizar pruebas de unidad, contrato, funcionales, de rendimiento, de usabilidad, de penetración y de seguridad. Las mejores de estas herramientas admiten varios idiomas; algunas utilizan la inteligencia artificial para reconfigurar automáticamente las pruebas en respuesta a los cambios de código. El abanico de herramientas y marcos de prueba es muy amplio. Los marcos populares de código abierto para probar la automatización incluyen Selenium, Appium, Katalon, Robot Framework y Serenity (anteriormente conocidos como Thucydides).
  • Herramientas de gestión de configuración (infraestructura como código), estas permiten a los ingenieros de DevOps configurar y suministrar infraestructura totalmente versionada y documentada mediante la ejecución de un script. Las opciones de código abierto incluyen Ansible (Red Hat), Chef, Puppet y Terraform. Kubernetes realiza la misma función para aplicaciones contenedorizadas (ver ‘DevOps y desarrollo nativo en nube’ a continuación).
  • Herramientas de monitoreo – ayudan a los equipos de DevOps a identificar y resolver los problemas del sistema; también recopilan y analizan datos en tiempo real para revelar cómo los cambios de código afectan al rendimiento de la aplicación. Las herramientas de monitoreo de código abierto incluyen Datadog, Nagios, Prometheus y Splunk.
  • Herramientas de retroalimentación continua- herramientas que recopilan la retroalimentación de los usuarios, ya sea a través de mapas de calor (registro de las acciones de los usuarios en la pantalla), encuestas o emisión de tickets de problemas de autoservicio.

Desarrollo de DevOps y nativo en la nube

Nativo en la nube es un enfoque para la construcción de aplicaciones que aprovechan las tecnologías de computación en nube. La meta de lo nativo en la nube es habilitar un desarrollo de aplicación, implementación, gestión y rendimiento consistente y óptimo en entornos públicos, privados y multinube.

Hoy en día, las aplicaciones nativas en la nube suelen ser

  • Construidas usando microservicios – componentes libremente acoplados, independientemente implementables que tienen su propia pila autónoma, y se comunican entre sí a través de las APIs REST, streaming de eventos o message brokers.
  • Implementado en contenedores – unidades ejecutables de código que contienen todo el código, los tiempos de ejecución y las dependencias del sistema operativo necesarias para ejecutar la aplicación. (Para la mayoría de las organizaciones, «contenedores» es sinónimo de contenedores Docker pero existen otros tipos de contenedores).
  • Operado (en escalar) usando Kubernetes, una plataforma de orquestación de contenedores de código abierto para programar y automatizar la implementación, gestión y escalamiento de aplicaciones contenedorizadas.

En muchos sentidos, el desarrollo nativo en la nube y DevOps están hechos el uno para el otro.

Por ejemplo, el desarrollo y la actualización de microservicios -es decir, la entrega iterativa de pequeñas unidades de código a una pequeña base de código- se ajusta perfectamente a los ciclos de lanzamiento y gestión rápidos de DevOps. Y sería difícil abordar la complejidad de una arquitectura de microservicios sin la implementación y operación de DevOps. Una encuesta reciente de IBM entre desarrolladores y ejecutivos de TI descubrió que el 78 % de los usuarios actuales de microservicios esperan aumentar el tiempo, el dinero y el esfuerzo que han invertido en la arquitectura, y el 56 % de los no usuarios probablemente adoptarán los microservicios en los próximos dos años. Para explorar algunos de los beneficios y desafíos específicos de los microservicios que se citan, utilice la herramienta interactiva que aparece a continuación:

¿Qué opinan los profesionales de TI y desarrollo?

Los no usuarios están de acuerdo Los usuarios están de acuerdo

(Fuente: ‘Microservices in the enterprise 2021: Real benefits, worth the challenges.’)

Al empaquetar y fijar permanentemente todas las dependencias del sistema operativo, los contenedores habilitan rápidos ciclos de CI/CD e implementación, porque toda la integración, prueba e implementación ocurre en el mismo entorno. Y la orquestación de Kubernetes realiza las mismas tareas de configuración continua para aplicaciones contenedorizadas que Ansible, Puppet y Chef desempeñan para aplicaciones no contenedorizadas.

La mayoría de los principales proveedores de computación en nube -incluyendo AWS, Google, Microsoft Azure e IBM Cloud- ofrecen algún tipo de solución de línea de trabajo de DevOps administrado.

¿Qué es DevOps?

DevSecOps es DevOps que integra y automatiza continuamente la seguridad en todo el ciclo de vida de DevOps, desde el inicio hasta el final, desde la planeación a través de la retroalimentación y el respaldo a la planeación de nuevo.

Otra forma de decirlo es que DevSecOps es lo que DevOps debía ser desde el principio. Pero dos de los primeros retos significativos (y durante un tiempo insuperables) de la adopción de DevOps fueron la integración de la experiencia en seguridad en los equipos multifuncionales (un problema cultural) y la implementación de la automatización de la seguridad en el ciclo de vida de DevOps (un problema técnico). La seguridad llegó a ser percibida como el «Equipo del ‘No'» y como un costoso cuello de botella en muchas prácticas de DevOps.

DevSecOps surgió como un esfuerzo específico para integrar y automatizar la seguridad como se pretendía originalmente. En DevSecOps, la seguridad es un interesado de «primera clase» junto con el desarrollo y las Operaciones, y lleva la seguridad al proceso el desarrollo con un enfoque de producto.

Vea «¿Qué es DevSecOps? para saber más sobre los principios, beneficios y casos de uso de DevSecOps:



DevOps e ingeniería de confiabilidad de sitio (SRE)

La ingeniería de confiabilidad ( SRE) utiliza técnicas de ingeniería de software para automatizar las tareas de operaciones de TI -por ejemplo, la gestión de sistemas de producción, la gestión de cambios, la respuesta a incidentes, incluso la respuesta a emergencias- que de otro modo podrían realizar manualmente los administradores de sistemas. La SRE pretende transformar al clásico administrador de sistemas en un ingeniero.

El objetivo final de la SRE es similar al de DevOps, pero más específico: la SRE pretende equilibrar el deseo de una organización de desarrollar rápidamente la aplicación con su necesidad de cumplir los niveles de rendimiento y disponibilidad especificados en los acuerdos de nivel de servicio (SLA) con los clientes y usuarios finales.

Los ingenieros de confiabilidad del sitio logran este equilibrio determinando un nivel aceptable de riesgo operativo causado por las aplicaciones -llamado «presupuesto de errores»- y automatizando las operaciones para cumplir ese nivel.

En un equipo de DevOps multifuncional, SRE puede servir de puente entre el desarrollo y las operaciones, proporcionando las métricas y la automatización que el equipo necesita para impulsar los cambios de código y las nuevas características a través de la línea de trabajo de DevOps tan rápido como sea posible, sin «romper» los términos de los SLA de las organizaciones.

Descubra más sobre ingeniería de confiabilidad de sitio

DevOps e IBM Cloud

DevOps requiere la colaboración de las partes interesadas en el negocio, el desarrollo y la operación para entregar y ejecutar rápidamente un software confiable. Las organizaciones que utilizan herramientas y prácticas DevOps mientras transforman su cultura construyen una poderosa base para la transformación digital, y para modernizar sus aplicaciones a medida que la necesidad de automatización se amplía en todo el negocio y las operaciones de TI.

Un movimiento hacia una mayor automatización debería iniciarse con pequeños proyectos de éxito medible, que luego puede escalar y optimizar para otros procesos y en otras partes de su organización.

Trabajando con IBM, tendrá acceso a funcionalidades de automatización potenciadas por IA , recursos, incluyendo flujos de trabajo preconstruidos, para hacer que todos los servicios de TI procesen de forma más inteligente, liberando a los equipos para que se centren en los problemas de TI más importantes y aceleren la innovación.

Emprenda el próximo paso:

Empiece con una cuenta de IBM Cloud hoy.

IBM Cloud Pak for Watson AIOps utiliza machine learning y la comprensión del lenguaje natural para correlacionar los datos estructurados y no estructurados en su cadena de herramientas de operaciones en tiempo real para descubrir conocimientos ocultos y ayudar a identificar las causas raíz más rápidamente. Eliminando la necesidad de varios tableros, Watson AIOps alimenta los conocimientos y las recomendaciones directamente en los flujos de trabajo de su equipo para acelerar la resolución de incidentes.

Sobre los autores

Andrea C. Crawford es un ingeniero distinguido de IBM con experiencia en DevOps clásicas y modernas. Le apasiona ayudar a los clientes a transformar la entrega de aplicaciones a través de personas, procesos y modernización de herramientas. A Andrea le gusta explorar los «extremos» tácticos, como la jardinería y la conducción de motocicletas.

https://twitter.com/acmthinks (enlace externo a IBM)
https://medium.com/@acmThinks (enlace externo a IBM)