Un momento “Eureka” con las arquitecturas de nube híbrida

Stephen Orban, Director de estrategia para empresas de Amazon Web Services

Publicado el 21 Sep 2016

Stephen Orban

Cada semana conozco a ejecutivos que están revolucionando su uso de la tecnología a la hora de aportar valor a sus empresas gracias de la nube. El motivo que les lleva a la nube varía según el caso, pero hay una serie de argumentos que se repiten en mis conversaciones con ellos: la nube permite a las organizaciones consagrar más recursos a sus actividades clave, operar con mayor agilidad y ser más seguras.

Esta transformación no se da de la noche a la mañana. Es precisamente por ello que me refiero a este proceso como un “viaje”. En este tránsito, la empresa aún tiene que operar con los activos informáticos con los que cuenta, para que su negocio siga funcionando con normalidad. La mayoría de las empresas con las que hablo están en proceso de migrar parte o la totalidad de su infraestructura informática a la nube, al haber comprendido que la nube no es una propuesta de todo o nada. Conforme las empresas van comprendiendo este planteamiento, se les abre la posibilidad de interconectar sus activos informáticos físicos con los de la nube y emplear esta interconexión para migrar el núcleo de sus procesos informáticos a la nube en un proceso gradual.

El “Eureka” de la nube híbrida

En 2012, mi jefe (en aquel entonces consejero delegado de Dow Jones), sostenía una hipótesis que todos preveíamos que representaría una gran oportunidad de negocio: Si el conjunto de los suscriptores de Wall Street Journal, uno de los productos B2C estrella de Dow Jones, poseía buena parte de la riqueza a nivel mundial, y el conjunto de los suscriptores de Factiva y Dow Jones Newswires, a su vez productos B2B de Dow Jones, gestionaba buena parte de la riqueza a nivel mundial, teníamos la oportunidad de crear una valiosa plataforma al ofrecerles un mecanismo con el que interconectar y comunicarse entre sí.

Íbamos a empezar de cero, pero queríamos progresar rápidamente. Reunimos a un equipo compuesto por un puñado de ingenieros y diseñadores para realizar una prueba experimental, y les dimos libertad para elegir las herramientas que ellos consideraban idóneas para hacer realidad el proyecto. Seis semanas después, combinando un poco de software libre, automatización, servicios de AWS y un montón de duro trabajo, habíamos creado y estábamos operando una aplicación de gran disponibilidad e invulnerable ante posibles desastres. Acabábamos de desarrollar la capacidad de ofrecer soluciones tecnológicas para la empresa con gran rapidez. Esto se convirtió rápidamente en nuestro proyecto estrella, y nos dio alas para animar a mi equipo y a nuestros ejecutivos a embarcarse en el tránsito con nosotros.

A medida que íbamos integrando esta aplicación en cada vez más productos, caímos en la cuenta de que también teníamos que integrarla en algunos de nuestros sistemas de gestión de identificación, estrictamente internos. Algunos de estos sistemas no estaban pensados para estar expuestos a la red, ni debían estarlo. Por ello, no podíamos acceder a ellos desde nuestra aplicación, que se ejecutaba sobre AWS, en la red pública.

Ingenieros de nuestros equipos de redes, infraestructuras y desarrollo empezaron a buscar soluciones al problema. Después de no poco investigar, descubrimos que podíamos valernos de Amazon VPC (Virtual Private Cloud) para crear redes virtuales dentro de nuestro espacio de IP internas, y así ejecutar nuestra aplicación dentro de la VPC.

Tras leernos la documentación de AWS y decidir cómo íbamos a integrar los grupos de seguridad de AWS con nuestros cortafuegos internos, el equipo se puso manos a la obra. En apenas 45 minutos, el equipo ya había creado la VPC; realizado una imagen de las instancias que estábamos ejecutando en la red pública; implementado las instancias en la VPC asignándolesdirecciones IP correspondientes a nuestra subred interna; redirigido el tráfico entrante a las nuevas instancias; habilitado la conectividad entre las instancias y nuestros sistemas internos de identificación y completado la migración.

Estábamos fascinados ante lo sencillo que resultaba configurar todo aquello, e incluso más sorprendidos de las oportunidades que se abrían ante nosotros para mejorar y extender nuestros sistemas heredados, valiéndonos de sistemas que podíamos crear en la nube.

A lo largo de los años siguientes, nuestro equipo de DevOps fue documentando todo cuanto habíamos descubierto en este ejercicio y automatizando la creación y administración de las VPC, en torno a una serie de arquitecturas de referencia para las diferentes áreas de nuestro negocio. Valiéndonos de esta estrategia, sencilla pero llena de potencial, empleamos este modelo de arquitecturas híbridas para crear y mejorar todos nuestros sistemas en la nube, sin tener que migrar todos nuestros sistemas a la vez.

Desde entonces, he conversado con muchos ejecutivos, y muchos de ellos han vivido momentos “Eureka” similares. En cuanto descubrían que no tenían por qué desechar todas sus inversiones en infraestructuras de plano para sacarle partido a la nube, múltiples posibilidades se abrían ante ellos. Esto brinda a los equipos la capacidad de aprender, sacar todo el partido a las inversiones existentes y agotar los ciclos de depreciación de sus infraestructuras, sin tener que renunciar a las ventajas que ofrece la nube en materia de elasticidad, agilidad, seguridad y costes.

¿Qué te ha parecido este artículo?

Tu opinión es importante para nosotros.

C
Redacción Channel Partner

Artículos relacionados

Artículo 1 de 2