Microsoft Azure, ¿Qué es y hacia dónde apuesta Microsoft con su nube?

Microsoft Azure, ¿Qué es y hacia dónde apuesta Microsoft con su nube?

La compañía de Redmond invierte para ir un paso adelante en lo que ellos denominan su “infraestructura y plataforma como servicio”.

En el mundo de los servicios de datos y la infraestructura computacional, cada vez hay más empresas apostando por llevar sus servicios a la nube o complementar sus servidores remotos con los locales. Sobre aquello, conversamos con Mauricio Arriagada, gerente de Cloud & Enterprise de Microsoft Chile, quien nos comentó sobre lo que es la nube de Microsot Azure, sus diferencias con servicios similares y la apuesta que está haciendo la compañía de Redmond sobre el Cloud.

¿Qué es Azure, exactamente? ¿Cómo se podría definir?

Azure es la oferta de Infraestructura y Plataforma como Servicio. En términos simples, son cientos de Datacenters, con una gran cantidad de recursos, que pueden ser consumidos por personas o empresas desde cualquier parte del mundo, pagando sólo por lo que usan. Azure no es solo almacenar y montar una base de datos en la nube, sino que además, es ofrecer servicios avanzados de Plataforma y esa es una diferencia importante con otros productos de Cloud que hay en el mercado.

Lo que nosotros proponemos, es una solución integral a problemas que muchas veces son costosos y complejos para una empresa, pero que en Microsoft ya resolvimos y que podemos ofrecer como servicio.

Cuando uno habla de Infraestructura como Servicio (IaaS), se dirige a un usuario más técnico, al que pide un servidor configurable donde él mismo instale el motor de base de datos, donde pueda modificar el registro, hacer clustering, etcétera, para que la infraestructura base del servicio que está levantando, no se caiga nunca. Otro punto fundamental, es que sea escalable, es decir, que pueda requerir un aumento de tamaño o una disminución del mismo, dependiendo del incremento o descenso de la demanda.

En el mundo de la Plataforma como Servicio (PaaS), si bien técnicamente se puede hacer lo mismo, hay un nivel de automatización mucho mayor, en el cual el usuario final o la empresa, se preocupa solamente de mantener su aplicación o el servicio que quiera publicar y sus datos. Si yo soy un gerente de e-commerce, me voy a preocupar de que el sitio funcione, que el catálogo de productos esté al día en los precios o en inventario, por ejemplo. Pero también necesito a alguien que se preocupe de cuantos servidores tener corriendo o para que este servicio nunca se caiga, si es Navidad o Cybermonday o si tengo una demanda inesperada, que levante nuevos nodos para satisfacer esa demanda. O al revés, si la demanda es pequeña, que rebaje los nodos de manera automática.

Y esa administración se lleva a cabo desde Microsoft…

Exacto. Cuando toda esa administración técnica se le delega a un tercero -en este caso Microsoft con Azure-, se habla de PaaS. El usuario sólo se hace cargo de la aplicación, de que su negocio esté bien implementado. De ahí hacia abajo, al usuario le da lo mismo la infraestructura técnica o si necesita equipos con Windows, con Linux, con más o menos RAM, etcétera.

Ahí está la diferencia importante con el resto de ofertas, porque nosotros somos líderes en lo que es Plataforma como Servicio. Todo lo que va desde la aplicación hacia abajo, lo tenemos automatizado y podemos entender con ciertas lógicas qué es lo que el usuario quiere hacer o qué es lo que la aplicación necesita. En base a eso, nosotros entregamos más o menos recursos, para que eso funcione siempre y no se caiga.

¿Qué nivel de fiabilidad hay en esa automatización?

Es que al hablar de fiabilidad hay dos puntos importantes. Por un lado está la disponibilidad del servicio y ahí nosotros implementamos un SLA (Service Level Agreement o Acuerdo de Nivel de Servicio) de 99.95%, que es una disponibilidad mucho más alta que varios de los Datacenters empresariales existentes. O sea, nosotros aseguramos que vamos a estar arriba y funcionando el 99.95% del tiempo y ese porcentaje satisface el 99% de los requerimientos de cualquier empresa. Existen algunos casos específicos de operaciones críticas, como la bolsa de New York, que son más exigentes. Hay clientes que nos piden un SLA de 99.999% y ahí les decimos “perfecto, podemos ofrecerles la mejor solución, pero instalada en su datacenter local”. En ese caso, no podemos recomendar la nube, porque no es posible asegurar ese nivel de disponibilidad. La infraestructura y la automatización que hay, aún no es suficiente.

Ahora, por ejemplo, el SLA de un datacenter local generalmente ronda el orden del 98%, así que nuestro número no está nada mal. El segundo punto, tiene que ver con la forma en que están construidas las aplicaciones.

O sea, como las construye el que está usando la plataforma…

Eso mismo. Porque para que estas “corran” y sean automatizables en una infraestructura de Plataforma como Servicio, tienen que cumplir con ciertos requisitos y ciertos estándares de programación que me permitan automatización. Si se entrega un e-commerce hecho a mano o que no cumpla ningún estándar de programación o de arquitectura de programación, no se puede interpretar y, por ende, no se va a poder escalar.

Ahora, todos los proveedores de servicios en la nube hemos tenido caídas que han sido mediáticamente famosas. Creo que lo importante frente a eso, es entender el SLA que ofrece el proveedor y también que el cliente entienda que esto se puede caer. Existen aplicaciones, por ejemplo, que son “multi-nube” y que se montan tanto en un datacenter local, como en Azure y así, ante cualquier eventualidad, tienen un respaldo que pueden levantar. Es por esto que cuando hablamos de Nube, lo proponemos en esquemas híbridos, es decir, un lado para el ambiente productivo y el otro, como sitio de contingencia.

Siempre depende de cuan crítico sea el servicio. Si al cliente le duele estar una hora abajo sin servicio, entonces debería replicarlo.

¿Qué pasa, por ejemplo, con esos pequeños empresarios que quisieran tener sus servicios en la nube pero que a veces sienten que Azure es demasiado?

Esto se puede escalar “hacia arriba o hacia abajo”, tanto, como la aplicación lo necesite. Como lo comenté inicialmente, es una de las gracias de la nube, con todos los proveedores en general, es que se va pagando a medida que se va usando, similar a un servicio cualquiera de agua o de luz. El cliente siempre va a pagar el recurso que levante, por el tiempo que se levante. Eso sí, nosotros, en Microsoft, a diferencia de otros proveedores, cobramos por el minuto en que está arriba ese elemento, sin ningún mínimo o aproximación. Algunos proveedores cobran por minuto, pero con un mínimo de X minutos.

Azure, además, viene con un período de prueba de 30 días -o 200 dólares-, que permite saber efectivamente, cuando va a costar esa aplicación, corriendo en un período de demanda normal. Lo que pase después, en caso que la demanda aumente, servirá para proyectar el consumo en un esquema de comportamiento histórico normal. Pero los primeros días, pese a que son gratis, entregarán igual un reporte específico de cuanto se utilizó en máquinas virtuales, cuanto se utilizó, en cómputo, etcétera.

Ahora, algunas empresas quieren usar Azure solo para testing o para desarrollo de proyectos, que funcionan sólo de lunes a viernes. Eso también se puede automatizar, para que las máquinas se levanten únicamente los días en que se necesita. Ese tipo de flexibilidad también la entregamos, aunque siempre lo primero es pasar por ese período de prueba, porque en la nube hay algunas cosas que no se cobran en un datacenter tradicional, como ser el ancho de banda o el tráfico.

Subir información hacia Azure, es gratis. Pero descargar desde Azure hacia afuera, sí tiene un precio y ese ancho de banda en un datacenter local nunca se cobra “ondemand”, no se mide porque uno compra un enlace de red con costo fijo y no siempre el cliente se preocupa de ver si lo ocupó todo o solo la mitad. Pero en la nube sí vale, porque todo se mide en cuanto a consumo y en la cuenta final, se puede ver cuánto se transfirió y cuanto no. En cualquier caso, se trata de un costo marginal y bastante pequeño, pero si no se mide inicialmente, puede convertirse en una sorpresa más adelante.

¿Qué hay de la distribución física de Azure, a nivel global y/o latinoamericano?

Azure está distribuida mundialmente en 19 regiones, con una región de datacenters para Latinoamérica en Sao Paulo. Un datacenter puede tener hasta 2 millones y medio de máquinas virtuales y, en total, son un poco más de 100 datacenters nuestros en el mundo.

Somos el proveedor de servicios en la nube que más regiones de datacenters tiene. Amazon, por ejemplo, tiene 10, Google, por su parte, tiene 5. Eso no significa que sea mejor ni peor, sino que habla del nivel de inversión que hemos hecho y vamos a seguir creciendo, porque nuestro compromiso público es duplicar la capacidad de cómputo y almacenamiento, en períodos de 6 a 9 meses.

¿Y se ha cumplido esa regla?

Sí. Llevamos 6 años, desde que partió como Windows Azure y sí lo hemos cumplido. Ahora, nuestra demanda también crece al nivel de un 200% cada año. En algunos países, incluso, llega a ser más, pero ese es el promedio mundial. En Chile estamos muy cerca de ese número.

Hoy en día parece “estar de moda” llevar todo hacia la nube. Desde almacenamiento hacia otros procesos más críticos, ¿el futuro parece estar arriba?

La industria informática tiene como tendencia a irse a la nube. Ahora, si ese cambio es 100% hacia la nube o sí se hace de forma híbrida, es todavía una discusión filosófica. Google y Amazon están completamente en la nube y no tienen nada de desarrollo para infraestructura local, mientras que Oracle, por ejemplo, tiene algunas cosas arriba, pero lo principal, lo tienen instalado de forma local.

Nuestra apuesta particular en Microsoft es lo híbrido, pero con mucha inversión en la nube. No le vamos a decir a nuestros clientes que “lo que ayer te dimos de forma local, tienes que moverlo a la nube”. Pero sí le decimos y recomendamos, es que si quieren modernizar lo que ya tienen, que lo muevan a la nube y que lo que les convenga mantener en local, que se quede ahí y que, simplemente, conecten ambos mundos.

El tema es que la nube ofrece algo de agilidad, sobre todo, si se trata de cuestiones de innovación.Por ejemplo, que una empresa quiera crear una aplicación de redes sociales para sus clientes. La estadística dice que entre comprar un servidor y tenerlo disponible, pasan en promedio tres meses. Un mes en “vitrinear” y licitar, otro mes más esperando que la máquina llegue, otro mes más en configurar y dejar todo operativo. Tres meses en total, en promedio, pues hay casos en que todo se hace más lento. Eso puede reducirse a ocho minutos en Azure.

Otros clientes a veces dicen que tienen problemas de capacidad en su datacenter local. Ahí, yo les recomiendo que se queden con la máquina local y que todo lo que venga adicional y que no puedan satisfacer, lo lleven a la nube y la conecten con el datacenter propio.

Microsoft apuesta entonces por una mezcla entre lo local y la nube…

El tema es que, como nosotros tenemos una variedad muy amplia de productos a nivel empresarial, no podemos decirle a un cliente que tome todo lo que compró durante los últimos 30 años y lo lleve a la nube. Y si uno ve una empresa de cierto tamaño hacia arriba, se dará cuenta que esa empresa tiene de todo, que compró sus nuevos servidores hace seis meses y todavía no amortiza la inversión. Entonces, por mucho que le interese la nube, no puede llevarse todo al Cloud, porque, claramente, no le saldría rentable. No se trata de tomar una escoba, barrer con todo lo que se tiene y llevarlo hacia arriba. Hay que definir qué es lo que se necesita modernizar y qué es lo que todavía puede rendir de forma local.

He escuchado de empresas que han querido llevarse todo a la nube y que en el camino, se han dado cuenta que no es posible, ya sea porque ellos no están preparados o porque la nube no está preparada. De todas maneras, ya sea en la nube Azure, en un datacenter local que esté funcionando con nuestros productos o en un sistema híbrido, Microsoft siempre velará porque el cliente tenga una respuesta adecuada a sus requerimientos.