Azure para no iniciados

La nube está revolucionando el mundo que conocemos, aportando enormes ventajas desconocidas e impensables hasta hace unos pocos años.

Si hace menos de cinco años estábamos pensando cómo racionalizar nuestros CPDs para convertirlos en, nada más (y nada menos), que en una pieza del entramado tecnológico que soporta el negocio, la nube ha venido a dar una nueva vuelta de tuerca.

Desde mi punto de vista, el primer paso, aquel que rompe con la inercia y que permite acometer cambios que no son solo tecnológicos sino culturales, es IaaS (Infrastructure as a Service). No es innovador, pero es útil.

Esto, que en muchos casos es un paso ya dado, si lo unimos a la creación de redes híbridas, en las que parte de nuestra infraestructura está en la nube (a partir de este punto la llamaré Azure), sigue sumando ventajas:

• Nos desliga del hierro, ya que todo lo que hay para nosotros en Azure (máquinas, aplicaciones o servicios) no depende de un montón de equipos en nuestro CPD que tienen una inevitable y desagradable tendencia a la obsolescencia con el paso del tiempo.
• Nos garantiza la disponibilidad, puesto que tal y como está hoy Azure desplegado, y me circunscribo solo a Europa, una configuración con dispersión geográfica que implique que Dublín y Ámsterdam no estén disponibles al mismo tiempo, supone un escenario en el que disponer de los sistemas posiblemente poco importe ya.
• El coste de nuestro CPD, o de una parte del mismo, pasa a ser gasto común y no una inversión (a fondo perdido).
• La puesta en marcha de un piloto de duración acotada en el tiempo o simplemente un entorno de desarrollo que durará lo que dure el proyecto, no nos obligará a hacer una compra de equipamiento que puede, o no, servir en futuros proyectos.

Este escenario, que pinta muy bien, tiene matices que hay que tener en cuenta a la hora de abordarlo. No porque lo puedan convertir en desaconsejable, sino porque de no tenerlos en cuenta producirán retrasos, quebraderos de cabeza y sinsabores que con la frustración asociada pueden llevar a despreciar la solución, especialmente si una de las variables de la ecuación es un cliente poco paciente.

Los aspectos que serán necesarios tener en cuenta, se pueden resumir de la siguiente manera:

Factores técnicos:

El primer factor es la conectividad. Dependiendo de qué es lo que vayamos a “subir” a la nube, nuestras comunicaciones tendrán que ser más o menos potentes, es decir, el famoso “canuto” que necesitaremos dependerá de qué queremos hacer y cómo queremos hacerlo.

No es lo mismo utilizar aplicaciones basadas en Web o accesibles mediante Terminal Services que aplicaciones clásicas cliente/servidor que muevan grandes volúmenes de información entre los dos extremos.

El segundo factor, relacionado con lo anterior es nuestra electrónica de red. Es necesario que permita  prolongar nuestra red uniéndola con nuestro segmento de red en Azure.

Esto se puede hacer mediante dos caminos:

• Configurando una VPN de sitio a sitio en la red virtual de Azure utilizando un dispositivo “ad-oc”.
• Configurando una VPN sitio a sitio en la Red virtual de Azure mediante el Servicio de enrutamiento y acceso remoto (RRAS) de Windows Server 2012.

La primera opción implica la utilización de un dispositivo VPN que cumpla los requisitos establecidos por Microsoft. La compañía de Redmond incluye en su página web una serie razonablemente amplia de dispositivos susceptibles de ser utilizados. En muchos casos la utilización del equipamiento existente pasa únicamente por una actualización del firmware.

Por suerte, incluso para una PYME, a día de hoy, esto es un coste menor, pero no deja de ser importante tenerlo en cuenta antes de empezar el proyecto para evitar retrasos.

En el segundo caso necesitaremos una máquina con Windows Server 2012 con dos NIC: Esta máquina sirve como servidor VPN basado en RRAS.

En ambos casos necesitaremos al menos una dirección IP pública fija.

Asimismo será necesario tener en cuenta que la conexión con el segmento Azure de nuestra red dependerá de la conexión, por lo que es conveniente plantear soluciones de contingencia en caso de pérdida de la línea.

Factores económicos:

En este sentido, un factor importante es qué compramos y cómo lo hacemos.

Microsoft publicita con éxito el asunto del “Pago por Uso” cuya gran ventaja consiste en que si una máquina virtual está apagada, solo pagamos por el espacio que ocupa (un coste ridículo), pero no por la máquina virtual. Microsoft tarifica por horas. Esto significa un ahorro de costes importante si tenemos la precaución de detener o hacer que se detengan las máquinas que no se usen durante los fines de semana o en periodos no útiles.

El inconveniente que yo me he encontrado es que cuando compras una suscripción a Azure directamente a Microsoft, puedes elegir si es de pago por uso o bien si tendrá una tarificación fija: habrá que estudiar qué es lo que conviene. Sin embargo, cuando en lugar de hacerlo a través de la web de Microsoft, lo hacemos a través de un proveedor, lo que tendremos es un contrato tipo OPEN que tiene un valor fijo, en base a nuestras necesidades y que no tiene en cuenta si las máquinas están o no apagadas.

La pregunta lógica, llegados a este punto es: ¿y entonces por qué no hacerlo directamente con Microsoft a través de su web?

En principio no hay ningún inconveniente siempre que tengamos en cuenta los siguientes aspectos:

El primer paso de una suscripción a través del portal de Microsoft pasa, obligatoriamente, por hacerlo utilizando una tarjeta de crédito, que no todas las empresas tienen (especialmente las pequeñas).

Esto que puede parecer extraño, tiene teóricamente solución, puesto que una vez adquirida la suscripción el segundo paso es solicitar un cambio en el modo de facturación.

Sin embargo, en mi experiencia, este proceso no es tan sencillo dado que en realidad estamos comprando servicios en un país diferente, que por muy comunitario que sea, puede tener una fiscalidad diferente: hace falta que la empresa tenga un tipo de CIF específico.

Si no queremos terminar con la paciencia del cliente y de la propia, este factor hay que tenerlo en cuenta en la fase de propuesta y resolverlo antes de comenzar el despliegue.

Teniendo en cuenta estos dos aspectos, manteniéndolos controlados y haciendo las previsiones y provisiones adecuadas, utilizar Microsoft Azure como una extensión de nuestra propia red es relativamente sencillo y desde mi punto de vista, tremendamente práctico.

Parte de nuestro CPD sale de nuestras instalaciones, pero no de nuestro control, podemos controlar el coste que supone, y redimensionar en función de nuestras necesidades: el sueño de un Director de Sistemas y la tranquilidad del Director Financiero.

Si quieres saber más sobre cómo SOGETI puede ayudarte con las Infraestructuras en la Nube, visita nuestra web.

Más información:

Borja Cabellos es licenciado en Ciencias Químicas,  experto en Sistemas de Seguridad y arquitecto de infraestructuras IT, con más de 20 años de experiencia en proyectos IT orientados a negocio, especializado en tecnologías Microsoft y en la prestación de servicios de gestión en proyectos informáticos de diversa índole tecnológica y en diversos sectores como energía, defensa y gobierno, tanto dentro como fuera de España.