Inteligente, elástica, reactiva y eficiente. Así es la infraestructura ideal para cualquier CIO. No son características exclusivas de Amazon, Google, Microsoft ni de cualquier otro proveedor de cloud que nos venga a la mente.

Sí, desde luego, es todo un reto. Nunca antes habían existido tantas y diferentes posibilidades de diseñar la infraestructura que soporta los servicios de TI. La incorporación continua de avances en en este terreno coloca al CIO en el tablero de una guerra de tecnologías, regulaciones, estándares y metodologías que, además, deben recibir rápida respuesta.

La clásica estrategia a largo plazo ha dado paso a otra que combina ciclos cortos y otros más largos, dependiendo de los diferentes recursos implicados. Entender los diferentes modelos de prestación de los recursos ayuda a resolver estos retos y dota del criterio necesario para situar las necesidades en infraestructura en la mejor de las opciones.

En la actualidad, opciones hay muchas y muy variadas, y no son excluyentes: tan válidos son los diseños con infraestructuras clásicas como los de última generación, desde serverless, pasando por contenedores o hiperconvergencia. De hecho, nuestra infraestructura es, en realidad, una colección de infraestructuras, cada una enfocada a una solución concreta y todas conviviendo en armonía, independientemente de su localización, sea on-premise, en una nube o, dado el caso, en ambas a la vez.

Así que acompáñame en una breve retrospectiva sobre la evolución de las infraestructuras TI en los últimos 10 años, suficiente para entender cómo la transformación está siendo exponencial en esta área; y no solo en su capacidad, sino también en nuevos modelos de prestación.

La nube no es sino la capa de abstracción que aporta otro modelo de prestación de recursos

Back to the future

Consolidación y convergencia, que fueron los primeros, han ido dando paso a otros modelos más eficientes y flexibles, en los que los recursos han dejado de estar atados a una tecnología o marca concreta, y cuyo uso se puede supeditar a la demanda en tiempo real.

La noción de cloud ha ido encontrando su sentido real. Se ha ido alejando de aquel concepto solo asociado con los proveedores de cloud pública, o de sus servicios, para ser aplicado también a esas infraestructuras clásicas que coloquialmente llamamos datacenters.

Desde un punto de vista puramente de infraestructura, hemos ido aprendiendo que la nube no es sino la capa de abstracción que aporta otro modelo de prestación de recursos, donde carece de importancia si estos son prestados desde el propio datacenter o desplegados en una nube pública, que, por cierto, no olvidemos que no deja de ser “el datacenter de otro”.

Gracias a este modelo, los servicios de TI siguen evolucionado hacia un uso más cercano al de una utility. Cierto es que la virtualización de los recursos ha ido extendiendo su alcance, incorporando progresivamente todos los elementos de un datacenter: no solo la computación, el almacenamiento y las redes, sino también otros que habíamos considerado hasta el momento exclusivos del mundo físico, como la seguridad.

Infraestructura como código

Pero el detonante real del salto evolutivo sucedió con la introducción del concepto de infraestructura como código (IaC), que también conocemos como software defined. IaC no solo ayuda en la deseada automatización de las operaciones de TI que añaden agilidad en la plataforma, y que llegan incluso en ocasiones a que los entornos operen de forma autónoma. En realidad, IaC vino a revolucionar la manera en que diseñamos y entendemos los servicios de TI.

Hemos dejado de estar atados a un diseño en el que las aplicaciones se adaptaban a las capacidades de nuestra infraestructura, y hemos pasado a uno en el que las infraestructuras son las que se adaptan a las aplicaciones y al modo en el que las prestamos. IaC no solo nos proveía de mecanismos de automatización, creando o destruyendo programáticamente las infraestructuras, sino también del gobierno de las mismas mediante la monitorización continua y automática. De esta forma, IaC remodela elásticamente la infraestructura de una aplicación en función de su demanda o de las condiciones de los recursos subyacentes.

IaC se ha convertido en el principal inductor de la innovación en las infraestructuras, hasta el punto de que sigue también su propia evolución paralela. Está escapando de las implementaciones propias de cada proveedor de cloud para buscar un estándar que permita un único IaC para su interacción con todas las nubes, las de proveedores públicos o la de nuestro datacenter. Este estándar lleva un tiempo gestándose y, sin mencionar a nadie, ya hay disponibles ejemplos en el mercado.

Procesos desacoplados

Cambiemos ahora el punto de vista y miremos desde el lado de las aplicaciones. La confluencia entre los nuevos diseños de aplicaciones y la evolución en las infraestructuras es lo que ofrece nuevas tácticas en el modo en el que se prestan los servicios desde el área de TI.

Las aplicaciones monolíticas, ya obsoletas, han ido dejando paso a diseños de arquitecturas de procesos desacoplados que, no por casualidad, pueden hacer un uso más eficiente de los recursos y, a la vez, implementar un procesamiento paralelizado. Diseños, como por ejemplo el modelo de tres capas (Web+AppSrv+DB), que llevan siendo usados desde hace muchos años ahora se diseñan de manera desacoplada, rompiendo las dependencias entre las tres capas y posibilitando el uso de infraestructuras elásticas.

Otro ejemplo de estos diseños es la contenerización, donde el desacoplamiento se produce entre los propios componentes de una aplicación, a veces hasta llegar a nivel atómico. Esta atomicidad busca la eficiencia y la reusabilidad de los componentes hasta el punto de que realicen una sóla operación o cometido y, por tanto, no sean en sí mismos más desacoplables. Aunque es dificil llegar a este nivel de desacoplamiento, la tendencia en contenedores es la de crear componentes lo más independientes posible, generando un ecosistema de microservicios que, además, permita la reusabilidad, es decir, la compartición de estos microservicios entre varias aplicaciones.

Hemos pasado de hablar de aplicaciones a hacerlo de cargas de trabajo, en las que diferentes componentes colaboran para formar un servicio o aplicación y que reaccionan de manera inteligente al entorno: son diseños capaces de escalar según la demanda; de moverse entre infraestructuras; son reactivos a los fallos o, incluso, inmunes a ellos si se diseñan así. Estos resultados antes solo eran posibles con un gasto extraordinario.

El detonante del salto evolutivo fue la infraestructura como código (IaC) o software defined

Contenerización

Las aplicaciones basadas en contenedores son las grandes beneficiadas de los nuevos diseños de infraestructuras. Un claro ejemplo a la hora de ver por dónde van las cosas.

La contenerización proporciona otra capa de abstracción a los procesos y componentes de una aplicación que, de por sí, ya está generalmente abstraída sobre una infraestructura virtualizada, multiplicando los beneficios obtenidos. Esta capa adicional de abstracción permite, por sí misma, escalar los contenedores e incluso poder deslocalizar la infraestructura en la que se ejecutan, proporcionando movilidad de los contenedores entre diferentes infraestructuras.

De este modo, una arquitectura de contenedores podría ser diseñada para que estos puedan trasladarse entre diferentes infraestructuras físicas, aportando independencia del proveedor o, incluso, repartiendo la carga según criterios establecidos. Exactamente lo mismo ocurre con otras cargas de trabajo. De hecho, la tendencia, cada vez más en práctica, es que el diseño de las cargas de trabajo aloje sus componentes entre diferentes entornos, sean en nubes públicas o privadas, o en datacenters clásicos, o en todos a la vez.

Hibridación y multicloud

Como consecuencia de este escenario, revisitamos también otros dos conceptos: la hibridación y el multicloud. Este último no deja lugar a dudas: es y será cada vez más habitual que convivamos con varias nubes a la vez, lo que incluye nuestro datacenter como una nube más.

Pero la hibridación, sin embargo, no es una entelequia para extender nuestro datacenter on-premise a la nube, ni tampoco para que un servicio cloud pueda acceder a algún sistema que alojamos in-house. Es mucho más que eso. La hibridación es la capacidad de cualquier carga de trabajo para distribuir sus componentes entre las diferentes infraestructuras buscando la mayor eficiencia en todos los sentidos, no importa si son cloud u on-premise.

Es esta capacidad la que, en un futuro cercano, permitirá a cualquier departamento de TI diseñar cargas de trabajo inteligentes y autónomas que, de manera online, podrán reconfigurarse para aprovechar la mejor de las opciones disponibles de infraestructura en un momento dado, sea cual sea el proveedor de dichas infraestructuras. Será lo más habitual encontrar cargas de trabajo donde, por ejemplo, los datos sean custodiados en los datacenters on-premise pero su tratamiento —o su interacción con los usuarios— esté en una o más nubes, públicas o privadas.

Buscar la eficiencia

Dejando aparte todas las demás ventajas —que son muchas— que nos brindan la nube y los nuevos modelos de desarrollo, el futuro de las infraestructuras TI resulta apasionante si tenemos en cuenta que las posibilidades se multiplican cada día, y esto incluye a nuestro clásico datacenter.

Ya pasó la moda en que la única evolución era transformar por completo un entorno on-premise en otro alojado en una nube pública. Ahora, la tendencia es diseñar las cargas de trabajo buscando la mayor eficiencia, y esto, claramente, pasa por aprovechar lo mejor de cada mundo.