Automatización del aprovisionamiento de la infraestructura Cloud

Por: Isabel Yepes

El uso de infraestructura en la nube ha permitido que tareas de administración de TI que antes consumían gran cantidad de tiempo y recursos puedan ser centralizadas y ejecutadas de forma automatizada y sistemática. En este artículo planteamos un recorrido por los últimos 20 años de avances en metodologías y tecnologías de centros de cómputo y como la computación en la nube ha permitido la mejora contante de ellas.

La historia

En mi primer trabajo en un área de sistemas recibí en la primera semana lo que para la época podría ser la “iniciación” al trabajo, el encargado de centro de cómputo me dice: Ahí está el servidor, el CD y el instructivo, cuando regrese debe estar instalado el sistema operativo. Si bien ya había aprendido mi trabajo anterior a ese que muchas cosas pueden sacarse de los manuales, los procesos de entrenamiento y documentación de la infraestructura no eran para entonces muy sistemáticos; al menos en mi caso me dejaron un instructivo claro, pero hubo escenarios donde tenías una caja de CDs, un montón de manuales y Google no existía entonces, debías resolverlo tu mismo con tus manos.

Ese tipo de escenarios también implicaban que cuando el de Sistemas se iba podía dejar el mundo ardiendo, la empresa sin claves de acceso a los datos y la configuración de las aplicaciones en una inmensa caja negra que solo gurús específicos podían abrir. Los inicios del hacking sirvieron para que los encargados de sistemas tuvieran herramientas para recuperar accesos cuando alguien olvidaba, cambiaba por accidente o simplemente se negaba a entregar las contraseñas por algún conflicto de intereses.

Con el advenimiento de los sistemas de aseguramiento de la calidad, este tipo de metodologías comenzaron a permear el mundo de la computación, así modelos como ITIL comenzaron a ser empleados por grandes empresas que descubrieron la importancia de documentar de manera sistemática las operaciones y cambios que tenían lugar en la infraestructura de TI. Sin embargo fue una solución metodológica que en sus inicios se convirtió en un gran dolor de cabeza, porque si bien los activos eran intangibles, la documentación si que era física, entonces se requería llevar hojas de vida de servidores, repositorios de manuales, bibliotecas de CDs con instaladores y en los escenarios más oscuros cuadernos llenos de contraseñas compartidas entre grupos de administradores. La intención era correcta, las herramientas disponibles aún insuficientes.

Las acciones repetitivas

Tuve un compañero que bien decía que la pereza era la madre de todas las automatizaciones, cualquier cosa que requiriera realizarse más de una vez, él tenía toda la disposición y método para hacer un script que lo solucionara. Claro que también había gente dispuesta a dar click cien veces sobre el mismo botón para cambiarle un parámetro a un grupo de usuarios de un Directorio Activo, pero yo bien estaba de acuerdo con mi amigo que prefería liármelas con un script de ldif en una hora y no cuatro dándole click a la pantalla.

Esos días no eran muy amigables sobre todo para quienes éramos Sysadmin de Wintel (término para aquellos quienes administrábamos plataformas windows sobre procesadores intel) la cantidad de operaciones de la interfaz gráfica que no tenían equivalente en línea de comandos era desalentadora, y las que si tenían equivalente contaban con un nivel de complejidad alto y no tanta documentación disponible. El buscador de Google ya existía pero entonces lo más confiable era irse directamente a la web del fabricante para encontrar documentación precisa y cierta. Los repositorios públicos de scripts y comunidades técnicas con foros en línea era algo que apenas se venía gestando, pero que tomaba rápidamente fuerza gracias a las comunidades de desarrollo Open Source. 

Eso en mi máquina funciona

En las compañías más grandes y mejor organizadas las metodologías de desarrollo que propenden por la separación de ambientes comenzaron a hacerse populares, pero con limitaciones importantes por el costo de la infraestructura, teniéndose entonces equipos de las más variopintas arquitecturas en cada uno de los ambientes y haciendo indispensable que varias aplicaciones corrieran en el mismo servidor por optimización de recursos, pero en ocasiones con efectos colaterales indeseados. Esta heterogeneidad de ambientes y configuraciones hacía que en ocasiones al pasar cambios o actualizaciones de aplicaciones de un ambiente a otro, de forma totalmente manual por instalación en cada uno, generaran errores que no se habían presentado en escenarios previos y la consabida frase del desarrollador que tanto detestamos en infraestructura “Eso en mi máquina funciona”, expresión de franco desacuerdo entre dos equipos de trabajo entonces claramente diferenciados y no necesariamente coordinados en sus acciones.

Uno de los asuntos más complejos, sobre todo en las plataformas Windows era la liberación constante de parches de seguridad (al menos el primer martes de cada mes) y que era necesario aplicar uniformemente en todas las plataformas. Los parches de sistema operativo tienen la mala costumbre de romper el software que tienen instalado encima, en los mejores casos porque deshabilitan opciones que el fabricante considera inseguras, en el peor de los casos porque el desarrollador aprovecha configuraciones inseguras para realizar ciertas acciones con el código o por franca ignorancia de los efectos de una cosa sobre la otra. Esto hacía que para las empresas el parcheo de sistemas operativos se convirtiera en una tarea de ensayo y error, pero en ocasiones tratándose de ensayo destructivo.

Automatización en Cloud

Esta gran cantidad de situaciones adversas y la ausencia de herramientas apropiadas son situaciones que comenzaron a ser resueltas por una tecnología que inicialmente no estaba pensada para ello, la virtualización de equipos de cómputo. Estas aplicaciones comenzaron a ofrecer la posibilidad de instalar sistemas operativos completos separados entre sí ubicados dentro de infraestructuras físicas compartidas, con capacidades de procesamiento robustas. De este modo se minimizó la cantidad de hardware físico que era necesario adquirir.

La computación en la nube nació entre otras por la posibilidad de concentrar en un mismo espacio físico gran cantidad de servidores y poder “alquilar” parte de ellos en forma separada para clientes diferentes, la virtualización creó las condiciones para que fuese posible establecer nichos aislados entre sí dentro de la misma máquina física, haciendo económicamente viable el modelo de negocio de alquiler de espacios de cómputo y almacenamiento.

Esta “replicación” de máquinas creó una capacidad que antes no se vislumbraba, la posibilidad de hacer clones de la misma infraestructura, sin tener que luchar con la diversidad de hardware y controladores del mismo que hacían casi imposible en muchos casos estas copias completas en ambientes físicos.

Esta nueva forma de ver la infraestructura, como un aspecto replicable crea el paradigma de la Infraestructura como Código (IaaC por sus siglas en inglés) que propende por tratar la configuración de plataformas y sistemas operativos por medio de scripts repetibles que pueden ser almacenados en repositorios de código y controladas sus versiones, estas capacidades están siendo cada día aprovechadas con mayor énfasis en las infraestructuras de nube, pues facilitan el despliegue, administración y recuperación de desastres, en escenarios donde con solo almacenar el respaldo de los datos y los scripts de configuración de la infraestructura es posible restituir a operación un centro de cómputo completo en cuestión de minutos en una ubicación designada en un país diferente y con la garantía de que se comportará de forma homogénea con el sistema que reemplaza

Qué cosas podemos automatizar:

  • Capa de Servidor: Utilización de plantillas y perfiles que permiten hacer repetible la configuración de hardware tipo Blade, sistemas operativos y dispositivos activos que los conectan.
  • Capa de Software: Configuración de aplicaciones en plantillas que pueden ser desplegadas a partir de umbrales de carga y habilitadas por medio de balanceadores de tráfico.
  • Capa de virtualización: Creación y destrucción de máquinas virtuales a demanda.
  • Capa de Cloud: Gestión de nubes completas privadas o públicas para procesamiento de cargassegún necesidades variables.
  • Capa de Datacenter: Tecnología en desarrollo. Uso de automatismos robóticos para ejecutar las tareas físicas de monitoreo y reemplazo de equipos que actualmente realizan seres humanos.

Esta nueva forma de ver la infraestructura automatizada creó una nueva disciplina: DevOps, donde se unen las responsabilidades del desarrollo de software con las de despliegue de las plataformas base, en pocas palabras propende por:

  • Unificar las tareas realizadas por los equipos de Desarrollo y Administración de Sistemas.
  • Mejorar la comunicación entre Desarrollo y Operación dado que cada vez más elementos de la infraestructura se vuelven programables.
  • Integrar la cadena de entrega de software como un todo, supervisando los servicios compartidos y aplicando mejores prácticas de desarrollo. Eg: Agilismo.
  • Liberar nuevas funcionalidades en las aplicaciones con mayor frecuencia.
  • Usar de herramientas de control de código fuente, que también pueden almacenar la configuración como código.  

Los datacenters continuarán avanzando y las operaciones que se realizan en ellos serán cada día más automatizadas, los paradigmas de gestión de los recursos de TI han encontrado en la infraestructura en la nube el aliado adecuado para hacer cada día más sencillo y amplio el acceso a recursos de cómputo, para beneficio de las empresas de todo tamaño y quienes administran tales sistemas.

Fuentes: 

https://www.datacenterknowledge.com/archives/2013/06/06/cloud-computing-drives-data-center-automationx 
https://searchitoperations.techtarget.com/definition/DevOps
— Icons made by Freepik– Eucalyp– SmashiconsGood WareFrom Flaticonis licensed by CC 3.0 BY

 

Advertisements

Comentarios

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.