Sobre DevOps y los copos de nieve

Hoy en día es casi imposible moverse en TI sin escuchar a la gente hablar de DevOps. DevOps es el nuevo tema candente del sector, que toma el relevo donde lo dejó la conversación sobre la nube, y al oír a la gente hablar de ello uno podría creer que la administración de sistemas tradicional ya está muerta y enterrada.

Primero debemos hablar de qué entendemos por DevOps. Esto puede resultar confuso porque, al igual que con la nube, a menudo se toma prestado un término más antiguo para significar algo distinto o, en el mejor de los casos, relacionado con algo que ya existía. El DevOps tradicional era la fusión de los roles de desarrollo y de operaciones. Desde la década de 1960 hasta la de 1990, esta era la forma estándar de gestionar los sistemas. En este mundo, las personas que escribían el software eran por lo general las mismas que lo desplegaban y lo mantenían. De ahí la fusión de «desarrollo» (developer) y «operaciones» (operations), siendo «operaciones» un término semiestándar para el rol de administrador de sistemas. Estos roles no se separaron de forma habitual hasta el auge del «departamento de TI» en las décadas de 1990 y 2000. Desde entonces, el regreso a la fusión de los dos roles ha empezado a ganar popularidad de nuevo, principalmente por la forma en que ambos pueden operar conjuntamente con gran valor en muchas situaciones modernas de aplicaciones web alojadas.

Aquello de lo que a menudo se habla hoy como DevOps no es una fusión estricta de los desarrolladores y el personal de operaciones, sino una modificación del personal de operaciones con un enfoque mucho mayor en programar, no la aplicación en sí, sino en definir las infraestructuras de las aplicaciones como código, como una extensión natural de las arquitecturas de nube. Esto puede resultar bastante confuso al principio. Lo importante a destacar es que el DevOps tradicional no es lo que comúnmente ocurre hoy en día, sino un nuevo DevOps «falso» en el que los desarrolladores siguen siendo desarrolladores y operaciones sigue siendo operaciones, pero operaciones ha evolucionado hacia un nuevo rol «cargado de código» que continúa centrándose en gestionar servidores que ejecutan el código proporcionado por los desarrolladores.

Lo significativo hoy en día es que el rol del administrador de sistemas ha comenzado a divergir en dos roles relacionados, pero significativamente distintos, uno de los cuales la mayor parte del sector denomina hoy incorrectamente DevOps (pues la mayor parte del sector es demasiado joven para recordar cuando DevOps era la norma, no la excepción, y desde luego no algo nuevo y novedoso). Aquí me refiero a estos dos aspectos del rol del administrador de sistemas como los enfoques DevOps y «copo de nieve».

Utilizo el término «copo de nieve» para referirme a las arquitecturas tradicionales de sistemas porque cada servidor individual puede verse como un «copo de nieve único». Todos son diferentes, al menos en la medida en que no se gestionen de alguna manera para mantenerlos idénticos. Esto no significa que tengan que ser todos únicos, solo que conservan el potencial de serlo. En los entornos tradicionales, un administrador de sistemas inicia sesión en cada servidor de forma individual para trabajar en él. Es común cierto grado de scripting para facilitar las tareas de administración, pero en esencia el rol implica mucho tiempo trabajando en sistemas individuales.

Facilitar la administración de las arquitecturas de copo de nieve a menudo implicaba intentos de minimizar las diferencias entre sistemas de maneras razonables. Esto generalmente comienza con cosas como elegir un único sistema operativo y versión estándar (Windows 2012 R2 o Red Hat Enterprise Linux 7) en lugar de permitir que cada instalación de servidor sea un sistema operativo o una versión distinta. Esta estandarización puede parecer básica, pero muchos talleres carecen de ella incluso hoy en día.

Un siguiente paso suele ser crear una metodología de despliegue estándar o una imagen maestra (gold master) que se utiliza para crear todos los sistemas, de modo que el sistema operativo base y todos los paquetes base, a menudo incluyendo la personalización del sistema, los paquetes de monitorización, los paquetes de seguridad, la configuración de autenticación y modificaciones similares, sean estándar y se desplieguen de manera uniforme. Esto proporciona un punto de partida común para todos los sistemas, a fin de minimizar la divergencia. Pero técnicamente solo garantizan un punto de partida estándar y, con el tiempo, debe preverse que habrá divergencia en la configuración.

Más allá de estos pasos, los entornos de copo de nieve suelen utilizar scripts de administración personalizados y a medida o herramientas de gestión para mantener cierta estandarización entre sistemas a lo largo del tiempo. Cuantas más cosas en común existan entre los sistemas, más fáciles son de mantener y de diagnosticar y menos conocimiento necesita el personal de administración. Más estandarización significa menos sorpresas, menos incógnitas y capacidades de prueba mucho mejores.

En un entorno con un solo administrador de sistemas y con buenas prácticas y herramientas, los entornos de copo de nieve pueden alcanzar un alto grado de estandarización. Pero en entornos con muchos administradores de sistemas, especialmente los que reciben soporte las veinticuatro horas desde muchas regiones, y con un gran número de sistemas, la estandarización, incluso con prácticas muy diligentes, puede volverse muy difícil. Y eso es incluso antes de abordar los problemas evidentes que rodean el hecho de que se necesitan paquetes distintos y, posiblemente, versiones de paquetes distintas en sistemas que desempeñan roles diferentes.

El enfoque DevOps surge de forma orgánica del modelo de arquitectura de nube. La arquitectura de nube está diseñada en torno a sistemas, a grandes rasgos idénticos (al menos en grupos), que se crean y se destruyen automáticamente y que se controlan mediante una interfaz programática o API. Este modelo se presta, de forma bastante obvia, a ser controlado de manera centralizada a través de un sistema de gestión, en lugar de mediante los esfuerzos manuales de un administrador de sistemas. La administración manual es, en la práctica, imposible y completamente impracticable bajo este modelo. Los sistemas individuales no son únicos como en el modelo de copo de nieve y cualquier divergencia generará problemas graves.

La idea que ha surgido del mundo de la arquitectura de nube es que la arquitectura de sistemas debería definirse de manera centralizada «en código» en lugar de en los propios servidores. Esto suena confuso al principio, pero tiene mucho sentido cuando lo examinamos con mayor profundidad. Para dar soporte a este modelo, ha comenzado a surgir un nuevo tipo de herramienta de gestión de sistemas que todavía no ha adoptado un nombre realmente estándar, pero que a menudo se denomina herramienta de automatización de sistemas, framework de DevOps, herramienta de automatización de TI o, simplemente, herramienta de «infraestructura como código». Los conjuntos de herramientas comunes en este ámbito incluyen Puppet, Chef, CFEngine y SaltStack.

La idea que subyace a estos conjuntos de herramientas de automatización es que se utiliza un servicio central para gestionar y controlar todos los sistemas. Esta autoridad central gestiona los servidores individuales mediante descripciones basadas en código de cómo debe verse y comportarse el sistema. En el mundo de Chef, estas se denominan «recetas» por ser ingeniosos, pero la analogía funciona bien. El código de cada sistema podría incluir información como una lista de qué paquetes y versiones de paquetes deben instalarse, qué configuraciones del sistema deben modificarse y qué archivos deben copiarse a la máquina. En muchos casos, las decisiones sobre estos despliegues o modificaciones se gestionan mediante una lógica potencialmente compleja, de ahí la necesidad de código real en lugar de algo más simplista como marcado o plantillas. Los sistemas se agrupan luego por rol y se gestionan como grupos. El rol de «servidor web» podría indicar a un conjunto de sistemas que instalen Apache y PHP y que configuren la memoria para que use muy poco el intercambio (swap). El rol de «SQL Server» podría instalar MS SQL Server y herramientas de copia de seguridad especiales utilizadas únicamente para esa aplicación y configurar la memoria para que se ajuste como se desee para un grupo de máquinas SQL Server. Estos son solo ejemplos. Normalmente, una organización tendría una gran cantidad de roles; algunos pueden ser genéricos, como «servidor web», y otros mucho más específicos para dar soporte a aplicaciones muy concretas. Por lo general, los roles pueden superponerse, de modo que un sistema podría ser a la vez un «servidor web» y un «servidor Java», satisfaciendo las necesidades combinadas de ambos.

Estas definiciones estándar significan que los sistemas, una vez designados como pertenecientes a uno u otro rol, pueden «construirse a sí mismos» automáticamente. Un nuevo sistema podría crearse cuando un administrador solicita un sistema, o un sistema de monitorización de capacidad podría decidir que se necesita capacidad adicional para un rol y generar nuevas instancias de servidor automáticamente, sin ninguna intervención humana en absoluto. En el momento en que se solicita el sistema, por un humano o de forma automática, se designa el rol y el sistema, mediante el framework de automatización, se transformará en un «nodo» totalmente configurado y actualizado. Sin necesidad de intervención humana de administración de sistemas. El proceso es rápido, sencillo y, lo más importante, completamente repetible.

Definir los sistemas en código tiene algunas consecuencias no evidentes. Una es que ya no se necesitan copias de seguridad de los sistemas completos. ¿Para qué hacer una copia de seguridad de un sistema que puedes recrear, con un esfuerzo mínimo, casi al instante? Los datos locales de los sistemas de bases de datos necesitarían respaldarse, pero solo los datos de la base de datos, no el sistema entero. Esto puede reducir enormemente la carga sobre las infraestructuras de copia de seguridad y hacer que los procesos de restauración sean más rápidos y fiables.

La cantidad de documentación necesaria para los sistemas ya definidos en código es muy mínima. En los entornos de copo de nieve, el administrador de sistemas necesita mantener documentación específica de cada host y mantener esa documentación manualmente. Esto consume mucho tiempo y es propenso a errores. Los sistemas definidos mediante código central necesitan poca o ninguna documentación y la documentación puede gestionarse a nivel de grupo, no a nivel de nodo individual.

Probar sistemas que están definidos en código también es fácil de hacer. Puedes crear un sistema mediante código, probarlo y saber que, cuando lleves esa definición a producción, el sistema de producción se creará de forma repetible exactamente como se creó en las pruebas. En los entornos de copo de nieve es muy común tener prácticas de prueba que intentan hacer esto, pero lo hacen mediante esfuerzos manuales y son propensas a ser descuidadas y no exactamente repetibles, y muy a menudo la política dictará que es más rápido simular la repetibilidad que esforzarse realmente por lograrla. Los sistemas definidos por código eluden estos problemas, haciendo que las pruebas sean mucho más valiosas.

Más allá de la necesidad de definir cuántos nodos deben existir dentro de cada rol, el sistema puede reaprovisionar una arquitectura entera, desde cero, de forma automática. La reconstrucción tras un desastre o la puesta en marcha de un sitio secundario pueden realizarse de manera muy rápida y sencilla. Además, moverse entre sistemas alojados localmente y sistemas alojados de forma remota, incluidos los de empresas como Amazon, Microsoft, IBM, Rackspace y otras, es extremadamente fácil.

Por supuesto, en el mundo de DevOps hay un gran valor en utilizar arquitecturas de nube para habilitar el nivel más extremo de automatización, pero usar arquitecturas de nube no es necesario para aprovechar este tipo de herramientas. Y, por supuesto, tener una arquitectura definida por código podría utilizarse de forma parcial, mientras que también podría implementarse la administración manual para un enfoque híbrido, pero esto rara vez se recomienda en sistemas individuales. Por lo general es mucho mejor tener dos entornos, uno que se gestione como copos de nieve y otro que se gestione como DevOps cuando se imponen ambos enfoques. Esto constituye una hibridación mucho mejor. He visto esto funcionar extremadamente bien en un entorno empresarial con varias decenas de miles de servidores «copo de nieve», cada uno muy único, pero con un entorno dedicado de decenas de miles de nodos que se gestionaba al estilo DevOps porque todos los nodos debían ser idénticos e intercambiables usando una de dos configuraciones posibles. La hibridación fue muy eficaz.

El enfoque DevOps, sin embargo, conlleva también importantes salvedades. Los conjuntos de habilidades necesarios para gestionar un sistema de esta manera son mucho mayores que los que se necesitan para la administración de sistemas tradicional ya que, como mínimo, sigue siendo necesario todo el conocimiento de administración de sistemas tradicional, más un sólido conocimiento de programación, normalmente de lenguajes modernos como Python y Ruby, y también conocimiento de los frameworks específicos en cuestión. Este requisito de una base de conocimientos ampliada significa que los profesionales de DevOps no solo son escasos, sino también caros. También significa que la formación universitaria, que ya está muy lejos de preparar a los administradores de sistemas o a los desarrolladores para el mundo profesional, está ahora aún más lejos de preparar a los graduados para trabajar bajo un modelo DevOps.

Los administradores de sistemas que trabajan en cada uno de estos dos bandos tienen tendencia a ver todos los sistemas como si tuvieran que encajar en su propio molde. Los nuevos profesionales de DevOps a menudo creen que los sistemas de copo de nieve son heredados (legacy) y necesitan actualizarse. Los administradores de copo de nieve (tradicionales) tienden a ver el movimiento de la «infraestructura como código» como una tontería, lleno de sobrecarga innecesaria, demasiado complicado y muy de nicho.

La realidad es que ambos enfoques tienen un enorme mérito y ambos van a seguir siendo extremadamente viables. Ambos tienen sentido para cargas de trabajo muy distintas y las grandes organizaciones, sospecho, verán comúnmente ambos implementados mediante alguna forma de hibridación. En el mercado de las pymes, donde típicamente solo hay un número diminuto de servidores, ninguna ventaja de escalado que justifique las arquitecturas de nube y una gran disparidad entre sistemas, sospecho que DevOps permanecerá casi indefinidamente fuera de la norma, ya que la sobrecarga y las habilidades adicionales necesarias para hacerlo funcionar son impracticables o incluso imposibles de adquirir. Las organizaciones más grandes tienen que examinar sus cargas de trabajo. Muchas cargas de trabajo tradicionales y gran parte del software tradicional no se adaptan bien al enfoque DevOps, especialmente a la automatización de la nube, y o bien requerirán hibridación o bien un nivel de programación poco práctico por cada sistema, lo que hace imposible justificar el modelo DevOps. Pero las cargas de trabajo construidas sobre arquitecturas web o que pueden escalar horizontalmente extremadamente bien se beneficiarán enormemente del modelo DevOps a gran escala. Esto podría aplicarse a grandes empresas o a compañías más pequeñas que probablemente produzcan aplicaciones alojadas para consumo externo.

Esta diferencia de enfoque significa que, en los Estados Unidos por ejemplo, la mayor parte del país está compuesta por empresas que seguirán centradas en el modelo de gestión de copo de nieve, mientras que algunas empresas de la costa este podrían evaluar el modelo DevOps de forma eficaz y comenzar a moverse en esa dirección. Pero en la costa oeste, donde las arquitecturas más modernas y un enfoque mucho mayor en las aplicaciones alojadas y las aplicaciones para consumo externo son los factores económicos impulsores, DevOps ya está pasando de ser un recién llegado a una normalidad madura y consolidada. Es probable que los enfoques DevOps y de copo de nieve sigan estando muy segregados por regiones de esta manera, al igual que en TI, en general, se observa que diferentes conjuntos de habilidades migran a diferentes regiones. No sería sorprendente ver que DevOps comienza a afianzarse en mercados como Austin, donde la TI tradicional ha rendido más bien mal.

Ningún enfoque es mejor o peor; son dos enfoques distintos que dan servicio a dos formas muy diferentes de aprovisionar sistemas y a dos necesidades fundamentales distintas de esos sistemas. Con el auge de las arquitecturas de nube y del modelo DevOps, sin embargo, es de importancia crítica que los administradores de sistemas existentes comprendan qué significa el modelo DevOps y cuándo se aplica, de modo que puedan evaluar correctamente sus propias cargas de trabajo y necesidades particulares. Una gran parte del mundo tradicional de la administración de sistemas de copo de nieve migrará, con el tiempo, al modelo DevOps. Estamos muy lejos de alcanzar un estado estable en el sector en cuanto al equilibrio entre estos dos modelos.

Publicado originalmente en el Blog de StorageCraft.