Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo DevOps cambia tanto el desarrollo como las operaciones

[15/11/2017] DevOps implica la fusión literal y figurativa de Desarrollo y de Operaciones. Por años, estos dos grupos han estado separados por límites culturales y de conocimientos, particularmente dentro de organizaciones de TI más grandes.

Esta separación era clara: Los desarrolladores se centraban solamente en el código y en las operaciones enfocadas en llevar ese código, y se aseguraban de que se mantuviera operativo. La separación completa entre estos dos grupos llevó a ciclos largos de QA y despliegues infrecuentes de producción por miedo a tiempos de inactividad o a romper algo.

La combinación de divisiones organizacionales, aversión al riesgo y métodos "cascada secuenciales de producción de software significó, que podía pasar un año o más entre las grandes actualizaciones de software. Actualmente, en muchas organizaciones grandes estas prácticas permanecen vigentes.

Aun así, un cambio significativo ha estado redefiniendo el campo de las TI durante la última década. Los desarrolladores, cansados de esperar que Producción actualizara sus códigos, han empezado a escribir software que automatiza tareas operativas. Al mismo tiempo, el personal de Operaciones ha estado contribuyendo mediante la retroalimentación de su experiencia y conocimientos profundos para el software que está siendo escrito por los desarrolladores.

Los límites entre Desarrollo y las Operaciones, que alguna vez fueron claros, se están difuminando. Esto está llevando a la aplicación de ciclos de vida cada vez más rápidos, sesiones QA más cortas, y muchos más despliegues. Nosotros incluso tenemos nuevos procesos para administrar, como la integración y despliegue continuos. Muchas aplicaciones a gran escala construidas con metodologías DevOps están siendo desplegadas hacia Producción muchas veces al día, en lugar de unas cuantas veces al año.

Esto no es solo una moda nueva y fugaz. Esta tendencia hacia la automatización ha progresado gradualmente durante los últimos 10 años, y el software y los procesos han madurado mucho. La consecuencia de la presencia de DevOps dentro de la industria de TI va a tener que ser algo que todos los involucrados tendrán que considerar.

Si no entiende por qué DevOps es tan importante y no se prepara para todos los cambios que DevOps está trayendo, su organización se atrasará.

El impacto de DevOps sobre los desarrolladores

Los orígenes de DevOps datan desde la llegada de herramientas como Puppet, que ocurrió en el 2005, antes que surgiera el termino DevOps. Luke Kanies, desarrollador de Ruby en ese entonces, estaba cansado de configurar Linux manualmente y de modificar la configuración de los archivos a mano. El soñó con una forma de provisionar y configurar sistemas de estilo Unix de una manera más programática y reproducible. Así que escribió un script Ruby que lo hizo por él, y lo llamó Puppet.

Más adelante, se desarrollaron otras herramientas similares como Chef, Ansible, SaltStack y más. Asimismo, las comunidades se unieron en torno a cada una de estas herramientas. Los desarrolladores y expertos en operaciones contribuirían con sus conocimientos mediante paquetes de "libros de cocina o "recetas.

Con estas herramientas, un desarrollador podía crear una descripción programática y autocontenida de cómo operar una aplicación. Ésta incluiría todas las dependencias y podría configurarlas e iniciarlas en varias distribuciones Unix simplemente operando un script. Lo que solía tomar semanas de instalación y afinamiento manual por parte de profesionales altamente calificados, ahora podía realizarse en unas pocas horas con la ayuda de un script.

Aunque los desarrolladores ahora podían desplegar sus códigos de forma más fácil y rápida que antes, un nuevo problema se introdujo. Debido a que los desarrolladores ya no eran tan dependientes de sus contrapartes en Operaciones, los desarrolladores se convirtieron en responsables de mantener operativas sus propias aplicaciones.

Ese problema derivó en el desarrollo de otra herramienta más: La plataforma como servicio (PaaS). Aunque fue concebida originalmente por Google y Salesforce, las primeras iteraciones de la PaaS requirieron que los desarrolladores escribieran un código especial que encerrara a las aplicaciones en sus plataformas. La PaaS no se popularizó hasta que Heruko mostró a los desarrolladores una forma de operar sus códigos con muy pocas modificaciones o sin la necesidad de éstas.

Los sistemas para PaaS fueron creados sobre de los principios de automatización de DevOps. De hecho, la mayoría de sistemas PaaS hasta la fecha usan herramientas DevOps para configurarlos y operarlos. La diferencia es que, con una PaaS, las aplicaciones que operan dentro de ellos están completamente administradas. Uno puede iniciar, detener, aumentar y monitorear una aplicación dentro de una PaaS a través de APIs. En DevOps, uno puede armar un conjunto de herramientas para administrar sus aplicaciones, pero con la PaaS las herramientas están precreadas para usted.

Finalmente, ninguna discusión sobre DevOps está completa sin mencionar a Docker y los contenedores. La mayor dificultad de la PaaS es que predefine la arquitectura muy estrictamente. Si un desarrollador desea mayor control de su ambiente, los contenedores lo proporcionan mientras que al mismo tiempo mantienen la velocidad y agilidad. Usar Chef y Puppet para configurar un ambiente de la nada puede tomar pocas horas, pero uno podría no terminar con una copia exacta. Usando un contenedor, un desarrollador puede reproducir un ambiente de Linux o Windows en una fracción de segundo y estar seguro de que es una copia exacta.

Con el trascurso de los años, los desarrolladores han podido realizar grandes mejoras en productividad mediante la adopción y refinamiento de estas herramientas DevOps. Los días en que los desarrolladores no eran conscientes del área de Operaciones y de los problemas crecientes están llegando a su fin, a medida que el arte de operar aplicaciones se destila hacia un código de computadora completamente automatizado.

El impacto de DevOps sobre las operaciones

Aunque los desarrolladores iniciaron la revolución DevOps, los expertos en Operaciones y Sistemas Administrativos han sido clave para su adopción definitiva. Después de todo, las herramientas también les ayudan a crear eficiencias en sus trabajos. De hecho, las herramientas de DevOps han cambiado de forma impresionante el panorama del tipo de trabajo del cual un equipo de operaciones moderno es responsable.

Antes de DevOps, los Administradores de Sistemas y los equipos de Operaciones eran los responsables de mantener las aplicaciones individuales operando a gran escala. Esto incluía actividades tan diversas como afinar bases de datos y servidores web, configurar balanceadores de carga, administrar la seguridad, administrar sistemas de caching, y mucho más.

En lugar de apoyarse en la intervención humana, DevOps ha permitido un alto nivel de estandarización, creando maneras eficientes de desplegar, configurar y operar muchos servidores con solo algunas herramientas.

Cada vez más, es la responsabilidad del equipo de Operaciones desplegar y mantener un servicio de aplicación automatizado y a demanda como una agrupación de contenedores de PaaS, Linux o Windows. Los desarrolladores después despliegan y agrandan las aplicaciones individuales dentro de la malla de aplicación, dejando a los equipos de Operaciones operando y agrandando la malla.

Las plataformas y herramientas de DevOps han creado una memoria de almacenamiento temporal que ha permitido a los desarrolladores y a los equipos de Operaciones trabajar de manera independiente, en lugar de dependiente. Antes de estas herramientas, existía un conducto secuencial de aplicaciones. Las aplicaciones individuales tenían que hacer solicitudes distintas a Operaciones, procesado adquisiciones y haber configurado los servidores antes de desplegarse.

Con la llegada de las herramientas de DevOps, los desarrolladores pueden tener cuotas, donde, dentro de ciertos parámetros, ellos podrían desplegar a demanda y en tiempo real. El equipo de Operaciones ya no necesita preocuparse por desplegar aplicaciones individuales. Ellos aún tienen hardware, configuran y administran servidores, pero lo hacen en una escala más grande que la unidad de la aplicación. Su responsabilidad yace en administrar la malla de DevOps automatizada, a la cual los desarrolladores tienen un acceso más inmediato.

Este buffer de tecnología ha separado el ciclo de vida secuencial de aplicación, permitiendo que los desarrolladores y equipos de Operaciones trabajen más conjuntamente. Podría parecer ilógico que separar equipos los acerque, pero la manera más rápida de empezar una pelea es poner a dos cocineros en la misma cocina. Permitiéndoles a los desarrolladores trabajar dentro de un sistema bien definido (construir el código dentro de la malla), mientras que el equipo de operaciones trabaja fuera del contenedor, asegura que los cocineros tengan responsabilidades separadas.

Pero el territorio común entre los desarrolladores y equipos de Operaciones -las propias herramientas de DevOps- se ha convertido en un ecosistema colaborativo donde las responsabilidades se difuminan. Los equipos de Operaciones tienen el conocimiento profundo de los mejores procedimientos para operar y mantener operativos a los sistemas complejos de software. Los desarrolladores tienen la habilidad de enseñar a las computadoras cómo implementar ese conocimiento profundo de las operaciones sin intervención humana.

Cada vez más, los empleadores buscan programadores con experiencia en operaciones y administradores de sistemas con experiencia en programación. Sin embargo, en general, el impacto más grande que DevOps está teniendo en los equipos de operaciones, es que a ellos cada vez más se les está asignando la operación de la malla de aplicaciones, que les proporciona opciones de despliegues a demanda y automatizados a los desarrolladores

Un círculo virtuoso

Las palabras célebres de Marc Andreessen, "el software se está comiendo el mundo, son ciertas tanto para construir y operar aplicaciones, como para llamar un taxi y alquilar una habitación de hotel. Durante décadas, la tarea de operar aplicaciones ha sido el área de aprendizaje de un grupo selecto de genios altamente entrenados en administración de sistemas. Ahora se está volviendo algo masivo.

La mayoría del conocimiento no era documentado y se trasmitía verbalmente, como el folklore, de generación en generación. Todos los archivos tenían sus propios y excéntricos formatos. A veces estos formatos eran tan extraños que había archivos de configuración que se compilaban en más archivos de configuración. El conocimiento exacto de cómo y por qué ajustar estos archivos permanecía como un misterio para la mayoría.

DevOps se ha convertido en una manera de documentar todo el conocimiento esotérico de las operaciones, en estándares abiertos capaces de ser documentados y rastreados con el tiempo. El conocimiento puede ser programado dentro de la lógica utilizada para construir mallas de plataforma de aplicación como la PaaS y las agrupaciones de contenedor Linux -y puede ser iterado y compartido con otros.

A medida que los desarrolladores mejoran sus habilidades en operaciones y los administradores de sistemas mejoran en programación, sus responsabilidades se fusionarán eventualmente. Las líneas ya se están desvaneciendo, y eso está dando paso a nuevas herramientas para la colaboración entre grupos que solían mantener una mínima colaboración.

Docker, la plataforma líder para la administración de contenedores es otro ejemplo más de esta evolución. GitHub dio a los desarrolladores un ambiente abierto para compartir código entre ellos y colaborar de manera más sencilla que nunca. El Docker Hub está abriendo el mismo tipo de colaboración para los administradores de sistemas, dando paso a un nuevo renacimiento en la administración y despliegue de infraestructura.

DevOps continuará evolucionando. Siempre habrá una nueva herramienta, una estructura distinta de trabajo y una tendencia de moda, pero el hilo conector subyacente que ata todo es la verdadera automatización del software. Al igual que la automatización trajo integración y producción continua al desarrollo de software, está trayendo infraestructura programable a las operaciones.