Por: Isabel Yepes
A continuación un par de video que explican cómo crear Web Apps en la nube de Microsoft Azure, sacando provecho del tier gratuito para la realización de pruebas. Además cómo configurar el despliegue de código hacia la web app desde un repositorio local en Git.
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.
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.
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.
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.
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:
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:
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.
Hacemos Contactos 