Casos Reales: ForexStreet, servicio líder en mercados de divisas, explica sus 5 motivos para migrar a Windows Azure

NOTA: Hoy inicio una nueva serie de posts sobre casos reales de migración a Windows Azure pero contado por sus propios protagonistas.   El post de hoy, escrito por Jordi Torra, CTO de ForexStreet, describe como su compañía utiliza Windows Azure para mejorar su eficiencia, agilidad y escalabilidad para su sitio web FXstreet.com. Lectura amena y muy didáctica.

 

Ya hace más de un año que puse el primer pie en la plataforma Windows Azure. Al principio fui un poco escéptico y me costó. Hoy en día tengo ya decenas de servicios críticos en producción y no se me ocurriría alojar nada en ningún sitio que no fuera “cloud computing”.

FXstreet.com es el portal de referencia de forex (intercambio de divisas) desde el año 2000. Empezando como un home business administrado por 3 personas (dios bendiga el Access trabajando con SQL Server 2000), ha vivido un crecimiento exponencial teniendo hoy en día personal repartido por todo el mundo y decenas de servidores físicos e incontables instancias en el Cloud.

Empezando con una página de HTML plano en inglés, hoy en día cubrimos decenas de lenguajes pasando a no tener reloj y dar una cobertura 24x5. En el sector donde la gente espera un dato económico a la espera de ejecutar sus órdenes de mercado, existen dos tipos de site: el que saca primero el dato y el muerto.

Como CTO, mi responsabilidad es garantizar el up-time del site. Adaptarme a los cambios de demanda de nuestros clientes y al mismo tiempo mantener los costes de alojamiento bajo control.

En una situación normal las visitas diarias a nuestro sitio web siguen un patrón bastante estable:

fig 1. El mercado de divisas cierra a las 19:00 GMT de los viernes y reabre el domingo a las 23:00 GMT. Nótese los marcados valles del fin de semana (1) y el tráfico con el mercado abierto (2).

Haciendo un poco más de zoom, vemos que el comportamiento horario también sigue un patrón bastante claro:

fig 2. Observamos caídas de visitas por la noche (1) y vemos una caída aún mayor en fin de semana (2)

Siguiendo la norma “llamarle al problema solución”, aproveché la bajada de demanda nocturna para ejecutar los backups diarios y las bajadas de demanda semanales para distribuir las actualizaciones con Windows Update y ejecutar tediosos full backups en mis servers. De esta forma seguía teniendo muchos recursos sin utilizar durante demasiadas horas.

A todo esto, calendario en mano, se pueden prever picos planificados que coinciden con la salida de eventos macroeconómicos, como puede ser el índice del paro de EEUU. El protocolo en IT para estos casos es “no tocar nada” unas horas antes del evento y esperar que el trafico baje antes de tocar ningún elemento de producción.

fig 3. Los visitantes entran expectantes para conocer el dato (1) llegando a su zenit en los 2, 3 segundos en que llega el resultado (2). A partir de este momento usan la información para operar y van desapareciendo lentamente (3).

Hasta aquí, todo feliz. Los problemas empezaron en 2008, cuando el mercado se volvió loco y empezaron a salir eventos no planificados en los peores momentos.

fig 4. No es divertido chequear los cores del SQL Server o el network usage de los web servers en el momento del pico.

Para más dramatismo, fines de semana a priori tranquilos, acaban demasiado a menudo en días donde se anuncian grandes cosas.

fig 4. En naranja la media de visitas en fin de semana. En azul las visitas registradas en fin de semana en el que hay un anuncio económico de relevancia.

Este incremento puede parecer poco importante, pero si los servidores se están actualizando, reiniciando, ejecutando análisis de antivirus, ejecutando full backups, la cosa puede terminar en desastre.

Sea como sea, con este cuadro de síntomas el remedio estaba claro. ¡Era hora de moverse al Cloud!

Ahí van, sin importar el orden, mis.....

Cinco motivos para moverse a Windows Azure

● Hacer mucho sin hacer nada

● Las cosas funcionan perfectas o no funcionan

● Simplicidad del deploy

● Trabajar sin bottlenecks es posible

● Escalar y ahorrar

Hacer mucho sin hacer nada

Suena bien ¿verdad? Pues es exactamente tal como parece. Voy a explicarme un poco. La primera cosa que debes saber del Cloud es que puedes olvidarte del hardware. Eso fue muy duro para mi al principio, pues cada vez que contrataba un servidor nuevo, me costaba unos 100 emails (no dejo ningún detalle al azar). Fue un primer gran paso para mi :)

Con el cloud contratas instancias de un tamaño determinado: extra small, small, medium, large. Lo bueno es que una vez desplegado un hosted service instancias de un tamaño determinado, sabes que cada vez que actualicen el hardware de los servidores en Windows Azure, tu hosted service se verá actualizado sin necesidad de ninguna acción. Si esto fuera poco, Microsoft se encarga de mantener actualizado el sistema operativo de las instancias, te olvidas de lo que era el Windows Update, corrupción de discos, etc. El peor escenario, que una máquina fallase de repente por llenar el disco o por algún otro motivo, acabaría en una re-imagen del servicio y otra vez a la carga. Resultaría difícil llegar a detectar que ha pasado realmente.

Lo mismo de las instancias puedes presuponerlo del servicio SQL Database (anteriormente conocido como SQL Azure), la conectividad en red, etc. Los sistemas no “degeneran”, su entropía natural es tender a mejorar sin requerir ninguna acción.

fig 5. Ver a tu sysadmin relajado es la forma que tiene la naturaleza de decirte que está haciendo un buen trabajo.

Las cosas funcionan perfectas o no funcionan

Puede parecer un poco esotérico al principio pero trabajar con Windows Azure es exactamente esto. Con el Visual Studio generas un paquete. En ese paquete hay todas las instrucciones, todas las configuraciones, todas las dll’s que necesita para funcionar. Esto implica que el hosted service quedará perfecto o no quedará. Una vez instalado no hay que configurar ningún hardware, no hay que registrar ninguna DLL, no hay que instalar ningún sofware, todo está en el package.

Si lo piensas bien esto es muy potente. Creo que todos en nuestra infraestructura tenemos el servidor “hago de todo” con centenares de scheduled tasks y otros servicios muy complejos corriendo. Tenemos pesadillas con solo pensar que esa máquina algún día pudiese fallar y acabamos confiando ciegamente en el hosting para que tenga un backup decente por si pasase lo peor. En Windows Azure sabes que un paquete funciona. Está funcionado hoy, funcionará mañana. Lo único que te pide es que lo instales como hosted service.

fig 6. “hazlo o no lo hagas, pero no lo intentes”

Simplicidad deploy

Cambiar el entorno de pre-producción a producción en Windows Azure resulta sorprendentemente trivial. A tan solo 2 clics (un clic y confirmar) y esperando unos 30 segundos podemos mover nuestro candidato a nueva versión a producción. Nada más. Solo 2 clics. Si al cabo de 1 hora se detectan problemas, alguien no está satisfecho o por algún otro motivo se necesita “tirar atrás” pues es tan sencillo como 2 clics más y esperar 30 segundos más.

Esto si lo combinas con subir los packages (un package es lo que te permite instalar un servicio) en el blob storage (un servicio para almacenar ficheros binarios) te permite poder hacer la acción realmente rápido y reaccionar en cualquier situación.

Imagina que estás en la playa y suena el teléfono. Por algún motivo la subida “de los viernes” ha ido mal y se necesita retroceder a una versión anterior del servicio. Con un netbook, una conexión 3G y 5 minutos lo consigo (mi netbook tarda un poco en arrancar). No necesito VPNs, no necesito conectar a las virtual machines de la oficina, no necesito nada. Con un navegador te conectas al control panel, buscas en el blob storage el deploy que quieres restaurar y taraaaaaa. ¡Otro trabajo bien hecho!

fig 7. Calvicie, mal afeitado, obesidad, novia imaginaria. ¡Muchos son los dones de un True Dev Hero!

Trabajar sin bottlenecks es posible

Con  el diseño correcto, puedes llegar a conseguir un entorno sin ningún cuello de botella. Sé que suena imposible, yo no lo creí tampoco hasta que lo vi por mi mismo :)

Pensemos en el peor de los escenarios posibles, la venta de entradas para un concierto. Una infraestructura que el 99.99% del año esta “haciendo nada” y en menos de una hora es capaz de vender un estadio completo. Además, el usuario en estas situaciones se comporta como un auténtico troll. ¿Qué la página no carga? F5. ¿Que parece que va lento?. Abramos 10 pestañas paralelas. ¿Que un botón parece que se toma su tiempo para realizar una acción? Pulsémoslos repetidamente hasta que consigamos el resultado.

Con un entorno de estas características el cloud computing resulta extremadamente eficiente. Levantar 20, 50... instancias paralelas y agregarlas al web cluster se puede realizar en menos de 5 minutos y desactivar conforme desaparezca el pico. Uno podría pensar que el SQL Database podría ser el bottleneck al ser compartido. La solución de Federations funciona especialmente bien para el caso de venta de entradas. “particionando” o “shardeando” el estadio en zonas, conseguimos tener un servidor independiente para cada shard aunque para nosotros el estadio al completo sigue siendo una sola entidad lógica.

En el caso de mi negocio, que siempre lo más interesante es lo más reciente, la solución de Shards no funciona, ya que siempre tengo la misma partición “caliente”. Aun así, mediante Sql Data Sync puedes montar soluciones muy rápida y cómodamente. Tu escenario puede parecer terrible, pero no puede ser peor que la venta de entradas :)

fig 8. El paraíso existe. Está en la nube!

Escalar y ahorrar

Empezar un negocio en el cloud es muy barato. No hay visitas, no hay consumo, no hay gasto :) el coste en hosting sólo se alcanza cuando se alcanza el éxito.

¿Cuantos servidores necesitamos? ¿Cuantas visitas tendremos? ¿Tendrá éxito este nuevo servicio? La actual infraestructura... ¿aguantará?

Intentar predecir cuanto éxito tendrá algo y si la actual infraestructura podrá soportarlo acostumbra a ser una tarea casi imposible. La gente no iniciada tiende a hacer proyecciones lineales para enfrentarse a este problema. Es decir, si mis visitas se duplican, mis servidores deberían duplicarse. Desafortunadamente esto no es cierto, pues la mayoría de “capacidad de trabajo” de los servidores acostumbra a tener una gráfica parecida a esto:

fig 9. Desafortunadamente es muy peligroso exprimir un servidor.

Si esto no fuera suficiente problema, el éxito tendemos también a pensar que llegará de forma lineal y “desafortunadamente” acostumbra a llegar de forma exponencial.

Con un entorno “tradicional” de servidores físicos, cada vez que la carga nos provoca estragos reaccionaríamos aumentando el número de servidores. Es decir, hacer petición formal, decidir hardware, esperar que el hosting se ponga a ello, configurar la máquina, instalar servicio y agregar (si es el caso) en el cluster correspondiente. Esto, en un entorno de éxito lineal encajaría de la siguiente forma

fig 10. Escoger entre hardware en desuso o peligro de fallo.

Esto que a mucha gente le puede parecer una buena idea no es del todo ideal, pues tenemos muchos recursos en desuso una vez hemos invertido y podemos tener muchos problemas si la tendencia de las visitas pasa de lineal a exponencial.

fig 11. Morir de éxito, la peor de las muertes!

Al final, ¿cuánto tardamos a añadir una máquina en un cluster? Contactar hosting, ver opciones disponibles, instalar sistema operativo, configurar aplicación, configurar firewall, configurar antivirus, configurar backups...

El peligro de las buenas ideas Trabajar en Internet es frustrante y peligroso. Cada una de las ideas es como tirar una caña de pescar sabiendo que de cada 20, 19 no picarán. Eso sí, la que pique te compensará con creces los 20 intentos. Esto a nivel de deploy resulta un problema, ya que nos obliga continuamente a instalar nuevos servicios de los que sabemos que no funcionarán en absoluto en la mayoría de los casos o que tendrán un éxito espectacular. Entonces.... ¿donde los pongo? Tradicionalmente todos acabamos montando el servicio en el típico servidor que tiene decenas de sites y confiamos que si la idea acaba funcionando no nos pille fuera de la oficina y que seamos capaces de escalar a tiempo. De ninguna manera podemos colocar cada una de las ideas que llegan bajo un balanceador de carga y con un par de servers dedicados. En Windows Azure la solución es tan fácil como instalar 2 instancias small (o medium si es que se usa mucha CPU) y olvidarte. Si el servicio tiene éxito y hemos programado con las buenas prácticas se escalará solito y nos enteraremos por el informe trimestral de la empresa.

Reflexiones finales

Plataforma viva y sujeta a continuos cambios

Es bastante frecuente acceder al control panel de Windows Azure y encontrar opciones nuevas. Esto puede producir inseguridades, pero al final, no se pierden nunca funcionalidades y las nuevas opciones acaban siendo bastante obvias. Algunas funcionalidades que pueden estar en Beta pueden aparecer en el control panel de repente. Mantente al día de los cambios y próximas entregas y esperarás los cambios con gran expectativa.

Resulta un poco frustrante Bingear información cuando tienes algún problema. Hoy por hoy encuentras posts con 4 o 5 meses de antigüedad que ya no sirven para nada o están completamente obsoletos. Para más dramatismo, si incluyen pantallazos descubres que no concuerdan con lo que tu tienes. Con un poco de práctica acabas discriminando qué es útil y qué no lo es. Confío que esto que conforme escribo este post puede ser un problema deje de serlo en los próximos meses.

Peligro de usar la herramienta incorrecta

Queues, Table Storage, Blob Storage, Federations para SQL Database, MemCache, etc. Cada una de estas tecnologías están muy pensadas para un uso muy concreto. Usa una tecnología incorrecta y sufrirás las consecuencias. Invierte un poco de tiempo en buscar qué es una “best practice” y ahorrarás muchas frustraciones. Hacer un pequeño mock o test es el mejor de los antídotos.

Aprende a entender los costes

Horas de CPU, consumo de red, accesos al blob storage... Intentar “sobre el papel” saber cuanto te costaría la infraestructura actual de tu hosting tradicional en el cloud resulta una tarea titánica. Mi solución para estos casos es desplegar un pequeño servicio y hacer una regla de tres. O sea, exponer un servicio a carga real y poder tener una primera estimación de costes. Lanzarse a ciegas al Cloud moviendo el negocio sin ninguna precaución puede acabar en costes muy elevados.

Hay también ciertas cosas que debes aprender cuanto antes mejor, como por ejemplo, una instancia que tenga menos de una hora de vida, te cobrarán una hora por ella. Eso significa que una vez creamos un entorno de preproducción para testear y desplegar a producción no hay prisa. Tienes por lo menos una hora. Úsala.

Hay otros detalles como que una instancia parada sigue imputando a costes. En realidad tiene sentido, pues estás usando un espacio y una reserva de CPU, memoria, etc. Lo mejor es mirar con tranquilidad las primeras facturas y entender bien qué es qué. Si algo no se entiende, ¡pregunta!

Ataques de Denegación de Servición (DDoS)

Cuando configuramos el auto escalado de las instancias debemos tener en mente siempre que podemos llegar a ser presa de un ataque DDoS.  Windows Azure reacciona a un ataque DDoS poniendo más y más recursos a nuestra disposición, si así lo decidimos, a menos que le configuremos límites razonables. Aun así, hay empresas muy serias en el sector que se encargan de prefiltrar las llamadas a tu site y dejar pasar solo el tráfico legítimo. Tener en mente eso es importante, ya que en unas pocas un ataque DDoS decente puede dejarte una buena sorpresa en la factura.

Soporte técnico y comercial. ¡Úsalo!

El soporte vía email o vía teléfono es excelso. Para Microsoft no hay clientes poco importantes. Aunque estés en periodo trial, si tienes un problema, ¡úsalo!