In­fra­s­tru­c­tu­re as code (IaC)

Ac­tua­l­me­n­te, en el ámbito de las in­frae­s­tru­c­tu­ras de TI, casi todos los caminos llevan al hardware vi­r­tua­li­za­do y co­n­tro­la­ble por software. Tanto los recursos de red, servidor y al­ma­ce­na­mie­n­to, como los centros de datos al completo se pueden combinar y escalar de forma muy precisa en todo momento sin la necesidad de manipular los co­rre­s­po­n­die­n­tes di­s­po­si­ti­vos en persona. Gracias a los pro­vee­do­res de in­frae­s­tru­c­tu­ra como servicio, podemos incluso alquilar el hardware su­b­ya­ce­n­te definido por software a un precio económico, li­brá­n­do­nos de la necesidad de contar con una in­frae­s­tru­c­tu­ra interna.

No obstante, sigue siendo un reto ad­mi­ni­s­trar los distintos recursos, en pa­r­ti­cu­lar, debido a las exi­ge­n­cias cada vez mayores de las in­frae­s­tru­c­tu­ras de TI y al hecho de que, a menudo, se recurre a los servicios de varios pro­vee­do­res de IaaS di­fe­re­n­tes al mismo tiempo. De ahí que el principio de in­fra­s­tru­c­tu­re as code, en ca­s­te­llano in­frae­s­tru­c­tu­ra como código o in­frae­s­tru­c­tu­ra pro­gra­ma­ble, cobre cada vez más im­po­r­ta­n­cia.

In­fra­s­tru­c­tu­re as code (abreviado como IaC) es un paradigma de TI que describe en lenguaje in­fo­r­má­ti­co no solo el software, sino también la in­frae­s­tru­c­tu­ra necesaria para eje­cu­tar­lo, como el espacio de al­ma­ce­na­mie­n­to, la potencia co­mpu­tacio­nal o los recursos de red. Bá­si­ca­me­n­te, se trata de programar es­tru­c­tu­ras de hardware como un código eje­cu­ta­ble que puede adaptarse, du­pli­car­se, eli­mi­nar­se y ve­r­sio­nar­se fá­ci­l­me­n­te en cualquier momento. El concepto de la in­frae­s­tru­c­tu­ra como código se basa en te­c­no­lo­gías de nube modernas como la vi­r­tua­li­za­ción y el manejo de recursos definidos por software, lo que hace posible gestionar el hardware sin acceder ma­nua­l­me­n­te a los di­s­po­si­ti­vos su­b­ya­ce­n­tes.

El nivel de exigencia respecto a los productos de software ha aumentado a ritmo ve­r­ti­gi­no­so en los últimos años. Como co­n­se­cue­n­cia, los ciclos de de­sa­rro­llo se acortan cada vez más y se busca co­n­s­ta­n­te­me­n­te la máxima di­s­po­ni­bi­li­dad y fle­xi­bi­li­dad. Por lo tanto, además de la op­ti­mi­za­ción del de­sa­rro­llo del código, uno de los pilares de una ar­qui­te­c­tu­ra global funcional, estable y, sobre todo, co­m­pe­ti­ti­va, es el ma­n­te­ni­mie­n­to y la mejora constante de la in­frae­s­tru­c­tu­ra de hardware su­b­ya­ce­n­te. Aquí es donde entra en juego el concepto de in­fra­s­tru­c­tu­re as code, diseñado es­pe­cia­l­me­n­te para aumentar la calidad y la efi­cie­n­cia de las in­frae­s­tru­c­tu­ras. Entre los objetivos y funciones básicas de IaC se incluyen, entre otros:

• Au­to­ma­ti­zar los procesos manuales lo máximo posible.
• Borrar los límites entre las apli­ca­cio­nes y los entornos en los que se ejecutan.
• Es­ta­ble­cer un flujo de trabajo flexible que facilite la co­la­bo­ra­ción de todos los im­pli­ca­dos en el proceso de de­sa­rro­llo en toda la empresa.
• Presentar los cambios y mo­vi­mie­n­tos de contenido de forma tra­n­s­pa­re­n­te y detallada en todo momento.
• Lograr que la co­n­fi­gu­ra­ción del hardware sea tan ve­ri­fi­ca­ble como la del software.

En el entorno clásico no vi­r­tua­li­za­do, todos los recursos están siempre co­ne­c­ta­dos con el hardware físico, lo que no solo resulta en una in­frae­s­tru­c­tu­ra poco flexible, sino que también conlleva muchas horas de trabajo manual a la hora de realizar co­n­fi­gu­ra­cio­nes.

Con la vi­r­tua­li­za­ción del hardware del servidor, del al­ma­ce­na­mie­n­to y de las es­tru­c­tu­ras de red, esta situación cambia ra­di­ca­l­me­n­te: gracias a esta te­c­no­lo­gía, los pro­vee­do­res pueden ofrecer a los clientes recursos re­gu­la­bles de forma ce­n­tra­li­za­da, evi­tá­n­do­les tener que disponer de un hardware especial para ello. Por un lado, esto garantiza una fia­bi­li­dad si­g­ni­fi­ca­ti­va­me­n­te mayor, ya que el hardware de­fe­c­tuo­so puede su­s­ti­tui­r­se de inmediato. Por el otro, también es mucho más fácil para ambas partes añadir nuevos servicios o cancelar recursos al­qui­la­dos que ya no se necesitan.

Los entornos definidos por software (en inglés, “software defined”) van un paso más allá de las in­frae­s­tru­c­tu­ras vi­r­tua­li­za­das ha­bi­tua­les y se ca­ra­c­te­ri­zan por el hecho de que el sistema lógico de control se abstrae co­m­ple­ta­me­n­te de los co­m­po­ne­n­tes de hardware y se im­ple­me­n­ta en un software de control central. Con las in­te­r­fa­ces y he­rra­mie­n­tas adecuadas, los pro­vee­do­res y clientes pueden acceder fá­ci­l­me­n­te a esta unidad de control, compilar in­di­vi­dua­l­me­n­te las es­tru­c­tu­ras de TI y es­ca­lar­las de forma muy precisa. Además, ambas partes se be­ne­fi­cian de un mayor re­n­di­mie­n­to del hardware, ya que este ya no se encarga de procesar datos.

In­fra­s­tru­c­tu­re as code utiliza las técnicas me­n­cio­na­das más arriba, au­to­ma­ti­za­n­do la ad­mi­ni­s­tra­ción por software de los recursos vi­r­tua­li­za­dos para maximizar el potencial de la nube. Por lo tanto, no debe en­te­n­de­r­se como una al­te­r­na­ti­va, sino como un co­m­ple­me­n­to u op­ti­mi­za­ción de la in­frae­s­tru­c­tu­ra definida por software.

La in­frae­s­tru­c­tu­ra como código desempeña un papel fu­n­da­me­n­tal a la hora de superar los retos que plantea agilizar el de­sa­rro­llo del software. Gracias a los scripts pre­co­n­fi­gu­ra­dos, los cambios ne­ce­sa­rios en la in­frae­s­tru­c­tu­ra se realizan a un ritmo que sería imposible de alcanzar si se hicieran ma­nua­l­me­n­te. Tampoco importa si los ajustes deben hacerse en plena noche, fin de semana o día festivo. Asimismo, disminuye la po­si­bi­li­dad de error, es­pe­cia­l­me­n­te en el caso de los pro­ce­di­mie­n­tos ad­mi­ni­s­tra­ti­vos que se repiten a menudo, porque no se pueden cometer errores ti­po­grá­fi­cos o de in­tro­du­c­ción de datos. Además de la alta velocidad y la baja tasa de error, in­fra­s­tru­c­tu­re as code ofrece las si­guie­n­tes ventajas frente a la co­n­fi­gu­ra­ción manual:

• Alta efi­cie­n­cia: la in­frae­s­tru­c­tu­ra como código au­to­ma­ti­za la mayor parte de la ad­mi­ni­s­tra­ción de recursos, lo que ayuda a optimizar el ciclo de vida del de­sa­rro­llo del software (SDLC, por sus siglas en inglés), es decir, de todo su proceso de de­sa­rro­llo.
   
• Re­uti­li­za­ción: una vez se ha escrito el código para una in­frae­s­tru­c­tu­ra, este se puede ejecutar en cualquier momento y todas las veces que se desee. Lo mismo se aplica, por ejemplo, a los entornos de pruebas durante la(s) fase(s) de de­sa­rro­llo.
   
• Control de versiones: donde haya código, también es posible controlar las versiones, por lo que el principio de in­fra­s­tru­c­tu­re as code permite do­cu­me­n­tar y rastrear cualquier cambio realizado en una in­frae­s­tru­c­tu­ra. Esto tiene la ventaja, entre otras, de que cualquier co­n­fi­gu­ra­ción anterior se puede restaurar sin ningún problema.
   
• Minimizar costes/esfuerzo: au­to­ma­ti­zar la ad­mi­ni­s­tra­ción de la in­frae­s­tru­c­tu­ra ahorra muchos costes y horas de trabajo que, a su vez, pueden in­ve­r­ti­r­se en otros ámbitos.

La última ventaja, sin embargo, no está exenta de li­mi­ta­cio­nes. Seguro que un entorno bien pro­gra­ma­do de in­frae­s­tru­c­tu­ra como código nos ahorra costes y tiempo, pero no podemos ignorar el trabajo que conlleva diseñar e im­ple­me­n­tar este sistema. Para muchos ad­mi­ni­s­tra­do­res, el modelo de IaC implica cambios im­po­r­ta­n­tes porque resulta prá­c­ti­ca­me­n­te imposible realizar la tra­n­si­ción a una in­frae­s­tru­c­tu­ra au­to­ma­ti­za­da o im­ple­me­n­tar­la sin tener una co­m­pre­n­sión profunda de los conceptos de ar­qui­te­c­tu­ra en la nube y co­no­ci­mie­n­tos de lenguajes de pro­gra­ma­ción como Java, Node.js, Python, etc. y del manejo de las API. Es­pe­cia­l­me­n­te al principio, por lo tanto, hay que contar con unos costes re­la­ti­va­me­n­te altos y muchas horas de formación.

Me­n­cio­na­mos, al principio, que las empresas suelen recurrir a varios pro­vee­do­res de servicios de IaaS distintos. Como co­n­se­cue­n­cia, los ad­mi­ni­s­tra­do­res tienen que lidiar con las pa­r­ti­cu­la­ri­da­des y, sobre todo, con las di­fe­re­n­tes in­te­r­fa­ces de cada pla­ta­fo­r­ma. En cambio, las he­rra­mie­n­tas y marcos de trabajo es­pe­cia­les de IaC ofrecen sus propios lenguajes de co­n­fi­gu­ra­ción, que permiten ad­mi­ni­s­trar recursos de múltiples pro­vee­do­res y eliminan la necesidad de conocer las API co­rre­s­po­n­die­n­tes en pro­fu­n­di­dad. Algunas de las so­lu­cio­nes más uti­li­za­das son las si­guie­n­tes:

• Terraform: la versión básica de Terraform, un software de código libre de­sa­rro­lla­do por HashiCrop, está di­s­po­ni­ble de forma gratuita. Sus dos versiones de pago pro­po­r­cio­nan funciones de co­n­fi­gu­ra­ción y or­ga­ni­za­ción, además de ca­ra­c­te­rí­s­ti­cas para el trabajo grupal.
   
• AWS Clou­d­Fo­r­ma­tion: Clou­d­Fo­r­ma­tion es la he­rra­mie­n­ta interna de IaC de Amazon Web Services (AWS) y, como tal, es prá­c­ti­ca­me­n­te im­pre­s­ci­n­di­ble para cua­l­quie­ra que trabaje con productos de AWS como ELB, S3 o EFS. Uti­li­zar­la no conlleva ningún coste adicional, tan solo hay que pagar por los recursos re­se­r­va­dos.
   
• Google Cloud De­plo­y­me­nt Manager: De­plo­y­me­nt Manager es para la pla­ta­fo­r­ma Google Cloud lo que Clou­d­Fo­r­ma­tion es para AWS. Con esta he­rra­mie­n­ta gratuita, los usuarios de recursos de IaaS de Google pueden ad­mi­ni­s­trar­los fá­ci­l­me­n­te mediante archivos de co­n­fi­gu­ra­ción central en el lenguaje de marcado YAML.
   
• Chef Infra: Chef Infra, la solución de IaC de la empresa es­ta­dou­ni­de­n­se Chef, está di­s­po­ni­ble desde abril de 2019 bajo la licencia gratuita Apache 2.0 y es utilizado por Facebook, entre otras empresas. Entre las pla­ta­fo­r­mas co­m­pa­ti­bles se incluyen Google Cloud, Microsoft Azure, Amazon EC2 y OpenStack.
   
• Red Hat Ansible Tower: la he­rra­mie­n­ta de in­fra­s­tru­c­tu­re as code Ansible forma parte del catálogo del de­sa­rro­lla­dor de software Red Hat desde 2015. Ofrece un panel de control, su propia línea de comandos y una poderosa API REST. En este caso, ambos paquetes di­s­po­ni­bles, tanto el estándar como el extendido, son de pago.

El principio de la in­frae­s­tru­c­tu­ra como código es útil para todas las empresas que de­sa­rro­llan y gestionan apli­ca­cio­nes complejas y, por lo tanto, dependen de una in­frae­s­tru­c­tu­ra igua­l­me­n­te extensa y potente. Entre los motivos más im­po­r­ta­n­tes para recurrir a una in­frae­s­tru­c­tu­ra pro­gra­ma­ble se incluyen los si­guie­n­tes:

• Se utiliza una gran cantidad de recursos de IaaS
• La in­frae­s­tru­c­tu­ra se alquila a muchos pro­vee­do­res o pla­ta­fo­r­mas di­fe­re­n­tes
• La in­frae­s­tru­c­tu­ra se tiene que modificar re­gu­la­r­me­n­te
• Se requiere una buena do­cu­me­n­ta­ción de los cambios de in­frae­s­tru­c­tu­ra
• Se desea optimizar la co­la­bo­ra­ción entre ad­mi­ni­s­tra­do­res y de­sa­rro­lla­do­res

Las empresas tienen la opción de programar sus propios archivos de co­n­fi­gu­ra­ción de IaC y, se­gu­ra­me­n­te, muchas ya lo hagan en parte. No obstante, casi todos los ad­mi­ni­s­tra­do­res que trabajan con IaC utilizan las he­rra­mie­n­tas y marcos me­n­cio­na­dos más arriba en su rutina diaria. Por ello, para concluir este artículo, en lugar de darte un ejemplo de in­frae­s­tru­c­tu­ra como código, te pro­po­ne­mos los si­guie­n­tes vídeos, que presentan cómo programar el código de in­frae­s­tru­c­tu­ra uti­li­za­n­do las prácticas he­rra­mie­n­tas de IaC (en este caso, AWS Clou­d­Fo­r­ma­tion y Terraform).