HISTORIA DE DEVOPS
Muchos de los métodos de DevOps que se utilizan para sacar el máximo
partido a las fases de desarrollo y puesta en marcha de software se basan en
las anteriores metodologías de desarollo de software Agile y de programación
Lean. Sin embargo, DevOps surgió en un principio a partir de varios
movimientos de base que trataban de harmonizar las actividades de
desarrolladores y sus homólogos en operaciones.
En la primera década de los años 2000, observamos la necesidad de mantener
la disponibilidad de sitios web populares, como Google y Flickr, frente a otros
casos masivos de éxito. Esta necesidad generó que se comenzaran a
demandar ingenieros de fiabilidad de software (SRE, «software reliability
engineer»); es decir, responsables de operaciones que trabajaran codo con
codo con los desarrolladores para garantizar que los sitios seguirían
funcionando una vez que se lanzara el código en la fase de producción.
En 2009, los ingenieros de Flickr John Allspaw y Paul Hammond presentaron
en una conferencia su propia metodología de DevOps. La presentación se
llamó «10+ Deploys per Day: Dev and Ops Cooperation at Flickr» (Más de 10
puestas en marcha al día: la cooperación entre departamentos de desarrollo y
operaciones en Flickr) y, en ese mismo año, Patrick Debois organizó la primera
«jornada de DevOps» en Bélgica. También se incorporó el hashtag #DevOps,
el cual fue ganando adeptos a medida que se iban celebrando más «jornadas
de DevOps» en todo el mundo.
Durante todos los años siguientes, se fueron desarrollando y proponiendo
marcos y herramientas de código abierto y del sector para ir ampliando los
objetivos de DevOps.
¿QUÉ ES DEVOPS?
DevOps es un marco de trabajo y una filosofía en constante evolución que
promueve un mejor desarrollo de aplicaciones en menos tiempo y la rápida
publicación de nuevas o revisadas funciones de software o productos para los
clientes.
Con DevOps se promueve una comunicación continua más fluida, la
colaboración, la integración, la visibilidad y la transparencia entre equipos de
desarrollo de aplicaciones (Dev) y sus homólogos en operaciones tecnológicas
(Ops).
Esta relación estrecha entre «Dev» y «Ops» se extiende a cada una de las
fases del ciclo de vida de DevOps: desde la planificación inicial del software a
las fases de codificación, compilación, pruebas y publicación, y en la puesta en
marcha, las operaciones y la supervisión continua. Esta relación impulsa un
bucle de retroalimentación continua con los clientes sobre las mejoras, el
desarrollo, las pruebas y la puesta en marcha. Uno de los resultados de todos
estos esfuerzos puede ser la publicación continua y más rápida de las
adiciones y los cambios que se necesitan en las funciones.
Algunas personas agrupan los objetivos de DevOps en cuatro categorías:
cultura, automatización, medición y uso compartido (CAMS, por sus siglas en
inglés), y las herramientas de DevOps pueden ayudar en estas tareas. Con
estas herramientas, los flujos de trabajo de desarrollo y operaciones se
convierten en tareas más optimizadas y colaborativas al automatizar tareas que
antes eran manuales, estáticas o que llevaban mucho tiempo, y que son
necesarias para la integración, el desarrollo, las pruebas, la puesta en marcha
o la supervisión.
POR QUÉ ES TAN IMPORTANTE DEVOPS
Además de los esfuerzos por romper las barreras de comunicación y fomentar
la colaboración entre los equipos de desarrollo y operaciones tecnológicas, uno
de los principales valores de DevOps es lograr la satisfacción del cliente y
prestar sus servicios en menos tiempo. DevOps también se ha creado para
impulsar la innovación empresarial y ser el motor de continuas mejoras en los
procesos.
La práctica de DevOps propicia que cada empresa se ponga como objetivo
ofrecer un mejor servicio cada vez, en menos tiempo, de mejor calidad y con
mayor seguridad a sus clientes finales; por ejemplo, con actualizaciones,
funciones o versiones de producto más frecuentes. Puede reflejarse en la
rapidez con la que llega al cliente una nueva versión del producto o una nueva
función manteniendo los mismos niveles de calidad y seguridad, o en el poco
tiempo que se necesita para identificar un problema o un error y, a
continuación, solucionarlo y volver a publicar una versión corregida.
Sin duda, todo este trabajo de DevOps se sustenta en una infraestructura
subyacente con un rendimiento, una disponibilidad y una fiabilidad fluida y sin
interrupciones del software, el cual se desarrolla y se prueba en primer lugar y,
luego, se lanza a la fase de producción.
MÉTODOS DE DEVOPS
Existen varios métodos de DevOps comunes que las organizaciones usan para
acelerar y mejorar el desarrollo y las publicaciones de productos. Normalmente
se presentan como prácticas y metodologías de desarrollo de software. Entre
los más populares están Scrum, Kanban y Agile:
Scrum. Scrum define la forma en la que los miembros de un equipo
deben colaborar para conseguir entre todos acelerar los proyectos
de desarrollo y control de calidad. Las prácticas de Scrum incluyen
flujos de trabajo principales y terminología específica (sprints,
bloques de tiempo, scrum diario [reunión]), y roles designados
(Scrum Master, propietario del producto [product owner]).
Kanban. Kanban se originó a partir de las eficiencias que se
alcanzaron en la fábrica de Toyota. Kanban prescribe que el estado
«en curso» (WIP, del inglés «work in progress») de un proyecto de
software debe controlarse en un tablero Kanban.
Agile. Los anteriores métodos de desarrollo de software Agile
siguen teniendo una gran influencia en las herramientas y las
prácticas de DevOps. Muchos de estos métodos, incluidos Scrum y
Kanban, han incorporado elementos de la programación Agile.
Algunas de estas prácticas están asociadas a una mayor capacidad
de respuesta a los continuos cambios en requisitos y necesidades,
los requisitos de documentación en forma de casos prácticos, la
realización de reuniones diarias para ponerse al día y la
incorporación de comunicación continua con los clientes para
conocer sus opiniones. En Agile también se estipulan ciclos de
desarrollo de software más cortos en lugar de los tradicionales
métodos de desarrollo «en cascada» que se prolongaban en el
tiempo.
CADENA DE HERRAMIENTAS DE DEVOPS
Los seguidores de las prácticas de DevOps a menudo incorporan a su «cadena
de herramientas» de DevOps particular algunas herramientas que se adaptan
perfectamente a estos métodos. El objetivo de estas herramientas es tratar de
optimizar, acortar y automatizar las diversas etapas del flujo de trabajo de
creación de software (o «canalización»). Muchas de estas herramientas
también promueven los postulados principales de DevOps, como son la
automatización, la colaboración y la integración entre los equipos de desarrollo
y operaciones. A continuación se ofrece un ejemplo de herramientas que se
emplean en las diversas etapas del ciclo de DevOps.
Planificación. En esta fase se definen los requisitos y valores
empresariales. Algunas herramientas de muestra son Jira o Git, con
las cuales se puede hacer un seguimiento de los problemas
conocidos y llevar a cabo la gestión de los proyectos.
Codificación. Esta fase implica el diseño del software y la creación
del código. Algunas herramientas de muestra son GitHub, GitLab,
Bitbucket o Stash.
Compilación. En esta fase se gestionan las versiones y las
compilaciones del software, y se utilizan herramientas
automatizadas que ayudan a compilar y crear paquetes de código
para publicarlos después para la producción. Se
utilizan repositorios de código fuente o repositorios de paquetes
que también «empaquetan» la infraestructura que se necesita para
el lanzamiento del producto. Algunas herramientas de muestra son
Docker, Ansible, Puppet, Chef, Gradle, Maven o JFrog Artifactory.
Prueba. Esta fase incluye la realización de pruebas continuas
(manuales o automatizadas) para garantizar la calidad de la
programación. Algunas herramientas de muestra son JUnit,
Codeception, Selenium, Vagrant, TestNG o BlazeMeter.
Puesta en marcha. En esta fase se emplean herramientas que
ayudan a gestionar, coordinar, programar y automatizar las tareas
de producción de las versiones de productos. Algunas herramientas
de muestra son Puppet, Chef, Ansible, Jenkins, Kubernetes,
OpenShift, OpenStack, Docker o Jira.
Funcionamiento. En esta fase se gestiona el software durante su
producción. Algunas herramientas de muestra son Ansible, Puppet,
PowerShell, Chef, Salt o Otter.
Supervisión. En esta fase se identifica y recopila información sobre
problemas que surgen en una versión de software específica que se
encuentra en producción. Algunas herramientas de muestra son
New Relic, Datadog, Grafana, Wireshark, Splunk, Nagios o Slack.
PRÁCTICAS DE DEVOPS
Las prácticas de DevOps son un reflejo de la idea de automatización y mejora
continuas, y muchas de ellas se centran en una o en varias fases del ciclo de
desarrollo. Estas prácticas incluyen lo siguiente:
Desarrollo continuo. Esta práctica abarca las fases de
planificación y codificación del ciclo de DevOps. Puede incluir
también mecanismos de control de versiones.
Realización de pruebas continuas. Esta práctica incorpora
continuas pruebas de código automatizadas y programadas con
antelación que se realizan a medida que el código de aplicación se
está creando o actualizando. Gracias a estas pruebas, el código
pasa antes a la fase de producción.
Integración continua (CI). En esta práctica se combinan
herramientas de gestión de configuración (CM) con otras
herramientas de pruebas y desarrollo para saber qué cantidad del
código que se está creando está listo para pasar a producción. Para
ello, debe existir un intercambio fluido de información entre las fases
de prueba y de desarrollo que permita identificar y resolver con
rapidez problemas en el código.
Entrega continua. Esta práctica automatiza la introducción de
cambios en el código para pasar a un entorno de preproducción o
de almacenamiento provisional tras la fase de pruebas. Un miembro
de la plantilla podría entonces decidir si es conveniente promover
estos cambios de código a la fase de producción.
Puesta en marcha continua (CD). Al igual que sucede con la
entrega continua, esta práctica automatiza el lanzamiento de código
nuevo o modificado a la fase de producción. Una empresa que pone
en práctica la puesta en marcha continua podría publicar cambios
en código o funciones varias veces al día. Las tecnologías de
contenedor, como Docker y Kubernetes, hacen posible esta fase de
puesta en marcha continua al ayudar a mantener la coherencia del
código entre los diferentes entornos y plataformas de puesta en
marcha.
Supervisión continua. Esta práctica implica la supervisión continua
del código en la fase de producción y la infraestructura subyacente
que la sustenta. A través de un bucle de retroalimentación en el que
se notifican errores o problemas, este podría volver a la fase de
desarrollo.
Infraestructura como código. Esta práctica se puede utilizar
durante varias fases de DevOps para automatizar el
aprovisionamiento de la infraestructura que se necesita para
publicar el software. Los desarrolladores añaden «código» de
infraestructura procedente de las herramientas de desarrollo
actuales. Por ejemplo, los desarrolladores podrían crear un volumen
de almacenamiento bajo demanda desde Docker, Kubernetes u
OpenShift. Gracias a esta práctica, los equipos de operaciones
también pueden supervisar las configuraciones de entorno, registrar
los cambios y simplificar la reversión de las configuraciones.
VENTAJAS DE DEVOPS
Los partidarios de DevOps describen varias ventajas técnicas y empresariales
con las que, en última instancia, se consiguen clientes más satisfechos. Entre
algunas de las ventajas de DevOps se incluyen las siguientes:
Una mejor y más rápida entrega de productos
Resolución de problemas en menos tiempo y con menor
complejidad
Mejor escalabilidad y disponibilidad
Entornos de funcionamiento más estables
Mejor utilización de los recursos
Mayor automatización
Mayor visibilidad de resultados del sistema
Mayor innovación
Definición de DevSecOps
DevSecOps, que significa desarrollo, seguridad y operaciones, es un marco
que integra la seguridad en todas las fases del ciclo de vida de desarrollo de
software. Las organizaciones adoptan este enfoque para reducir el riesgo de
publicar código con vulnerabilidades de seguridad. A través de la colaboración,
la automatización y los procesos claros, los equipos comparten la
responsabilidad de la seguridad, en lugar de dejarla al final cuando los
problemas pueden ser mucho más difíciles y costosos de abordar. DevSecOps
es un componente fundamental de una estrategia de seguridad multinube.
¿Por qué es importante DevSecOps?
Hay muchos métodos que los atacantes usan para obtener acceso a los datos
y recursos de una organización, pero una táctica común es aprovechar las
vulnerabilidades de software. Estos tipos de vulneraciones son costosas,
consumen mucho tiempo y dependen de la gravedad, lo que afecta a la
reputación de una empresa. El marco DevSecOps reduce el riesgo de
implementar software con configuraciones incorrectas y
otras vulnerabilidades que los actores malintencionados pueden aprovechar.
DevSecOps frente a DevOps
En el desarrollo de software tradicional, los proyectos se dividen en distintas
fases para el planeamiento, el diseño, el desarrollo, la integración y las
pruebas, que se producen de manera secuencial durante varios meses o
incluso años. Aunque este enfoque es muy metódico, muchas organizaciones
han detectado que es demasiado lento, lo que dificulta el cumplimiento de las
expectativas de los clientes en cuanto a mejoras continuas del producto.
Además, la seguridad normalmente se deja para el final, lo que pone a las
empresas en riesgo de sufrir una vulneración.
Para seguir siendo competitivas, muchas empresas han adoptado un modelo
de DevOps que prioriza la entrega de paquetes más pequeños de código de
alta calidad en lugar de proyectos con muchas características que tardan más
tiempo. En este marco, los equipos de operaciones y desarrollo de software
colaboran para incorporar pruebas e integración a lo largo del proceso. La
automatización, los procesos estandarizados y la colaboración ayudan a los
equipos a moverse rápidamente sin sacrificar la calidad.
DevSecOps es una mejora de DevOps que integra la seguridad en todos los
aspectos del proceso. El objetivo es solucionar los problemas de seguridad
desde el principio del proyecto. En este marco, no solo todo el equipo asume la
responsabilidad del control de calidad y la integración del código, sino también
de la seguridad. En la práctica, esto significa que los equipos analizan las
implicaciones de seguridad durante la planeación y comienzan a probar para
detectar problemas de seguridad en entornos de desarrollo, en lugar de
esperar hasta el final. Otro nombre para este enfoque es seguridad “shift left”.