Divide y Vencerás (Windows Azure)
Suponga que Ud. ha creado el siguiente Facebook… o twitter
Millones de usuarios acudirán a sus servicios.
Sé que a estas alturas la respuesta a la siguiente pregunta es sencilla para muchos, pero para los que están empezando hasta ahora, es mejor clarificarla y ese es el motivo de este post:
Es mejor tener un servidor gigante, poderoso y costoso? O un montón de unidades de cómputo baratas?
La respuesta la copio de un twitt que puse (ligeramente extendido)
La instancia cara pero poderosa, llegará a un límite en el que no puede aceptar más ram o cpus; en este momento, el mega servicio que nos inventamos, ya no podrá soportar más usuarios; además qué pasa si se cae? No tendríamos cómo respaldarla y el servicio dejaría de funcionar.
Aunque esto hoy día parece muy evidente, back in 1995, ni siquiera grandes empresas tecnológicas como Amazon lo tenían muy en cuenta. Ellos comenzaron con su sistema como un gran silo de software/hardware para su gigantesco sitio de ventas online. Pero ya en 2002, viendo todas las posibilidades que se venían en el futuro y sabiendo que un acercamiento monolítico haría muy difícil a sus sistemas crecer, implementar más funcionalidades y sobretodo soportar más usuarios, el CEO de Amazon, el señor Bezos, toma la decisión de reorientar todo el sistema a un modelo en el que se pudieran tener muchos componentes de software independientes que también pudieran funcionar en unidades o instancias de hardware independiente. Básicamente, a todos los desarrolladores se les dieron estas estrictas normas para trabajar:
1. Todos los equipos deberán exponer los datos y las funcionalidades a través de interfaces de servicios.
2. Los equipos se deben comunicar entre sí a través de estas interfaces.
3. No habrá otra forma de comunicación aceptada.
4. Sin importar qué tecnología usen, estas reglas se deben cumplir. A Bezos no le interesa.
5. Todas las interfaces sin excepción, deben ser diseñadas pensando en ser expuestas al resto del mundo... Sin excepción!
6. Cualquiera que no haga esto, será despedido
7. Gracias, y tengan un buen día
Algo parecido sucedió con Facebook, en 2007, tres años después de ser fundada. En contraste, curiosamente Google+ que es de 2011, salió al aire sin una sola API. Tres meses después lanzaron solo una gran MEGA API que muestra todo lo que un usuario ve. Lo que la sigue mostrando como un Silo.
En fin… esos componentes de los que nos habla el señor Bezos, son los que hoy conocemos como servicios, y esa arquitectura es la que conocemos como SOA y es la que ha dado origen a conceptos como Infraestructura como Servicio (IaaS), Plataforma como Servicio (PaaS), Software as a Service (SaaS) y Cloud Computing.
Una vez logramos que nuestras aplicaciones no sean silos complicados de administrar y extender, tanto para tener más funcionalidades como para soportar más usuarios, empezamos a observar que necesitamos hardware adecuado para soportar estas instancias. Un hardware monolítico de ninguna manera podría aprovechar un software diseñado para poder crecer y ser cada vez mejor.
Así nace el concepto de IaaS que permite a los usuarios tener disponibles un montón de máquinas en internet para que en ellas pongamos los OS que necesitemos y encima de ellos nuestras aplicaciones. Esto se comenzó a conocer como la nube. Lo bueno, es que son máquinas arrendadas y solo nos cobran lo que consumimos. Además podemos instalar lo que queramos. Lo malo, es que como hay que poner sistemas operativos y demás, son difíciles y costosas de administrar. Amazon es uno de los pioneros y grandes proveedores de IaaS.
Uno como desarrollador soñaría mejor en tener cientos de miles de máquinas en la nube listas para nuestra mega aplicación, sin necesidad de preocuparnos del sistema operativo ni mantenimiento ni nada de eso. Y es allí donde nace PaaS. Windows Azure de Microsoft, es uno de los pioneros y grandes proveedores de PaaS. Obviamente el software que ponemos sobre Plataforma como servicio, en general se presenta como Software como Servicio (SaaS) dado que los costos de arrendamiento se trasladan a los usuarios finales quienes por ejemplo comienzan a pagar una mensualidad por los servicios del software que se prestan. Como se ve, el viejo esquema de licenciamiento se ve modificado, erradicando problemas de distribución, empaquetado, solución de errores, mantenimiento, etc. Además garantizando la posibilidad de atender a tantos usuarios como vayan llegando, siendo un servicio escalable y robusto.
Esto lo notó Amazon y hoy también está implementando su propuesta de PaaS junto a muchos otros proveedores. Pero también resulta cierto que a veces, de acuerdo a la complejidad de la aplicación generada, se hace necesario poder administrar el sistema operativo sobre el cual corre, así sea esto más costoso. Es por esto, que Azure ya está implementando también alternativas de IaaS.
Todo lo anterior responde a que hemos notado que son mejores instancias baratas que se puedan activar a discreción, de acuerdo a las exigencias que las aplicaciones van teniendo. Pero esto requiere un diseño de aplicación pensado en el patrón shared-nothing, donde cada instancia dentro de un tier no comparte nada con otras instancias del mismo tier. Esto es básico para PaaS y SaaS.
En síntesis, los mayores proveedores están pensando en varias alternativas para tener hardware como servicio en el que nos sea muy barato poner nuestros servicios con una cantidad de instancias de cómputo “ilimitada” que pueda crecer de acuerdo a nuestros requerimientos y que nos permita ofrecer un servicio robusto en el cual si una instancia cae, las otras siguen respondiendo, mientras la caída es reemplazada. Los silos, están OUT.
Windows Azure nos ofrece muchas ventajas sobretodo a nosotros desarrolladores de .NET, porque hacer aplicaciones para la nube es muy natural y familiar; no hay que aprender un montón de técnicas o lenguajes nuevos y tenemos el soporte y la seguridad que nos ha dado siempre Microsoft.
Por ejemplo, en Windows Azure tenemos diversos tamaños para las instancias de cómputo sobre las cuales queremos poner nuestro software. Hay desde instancias Extra Grandes de 8 cores de 1.67GHz cada uno y 14GB de RAM hasta pequeñas con 1 sola CPUs y 1.75GB de RAM.
El hecho de que se diga que es mejor unidades baratas de cómputo que un solo silo poderoso y costoso no quiere decir entonces que lo mejor sea escoger siempre instancias pequeñas. O sea, ya definimos que no vamos a poner el software en una sola instancia… así que nos falta determinar cuál es el tamaño que deberán tener las instancias que compondrán el sistema. Y esto se hace de acuerdo a las características de nuestra aplicación. Por ejemplo si es una aplicación que necesita responder a muchos usuarios peticiones poco complicadas, es mejor tener muchas instancias pequeñas. Pero si por el contario son más bien pocos los requests pero con una demanda de cómputo alta, es mejor escoger instancias más grandes. Experiencia, intuición y sobretodo muchas pruebas, nos mostrarán cuál es la mejor alternativa.
Una de las inclusiones de Windows Azure en los últimos tiempos, fueron las instancias extra small. Estas instancias son muy baratas. Solo valen a 4 centavos la hora que estén encendidas. Tienen 768MD de ram y la CPU es compartida. Esto no quiere decir que sean como los servidores compartidos típicos de internet. Esto, en virtud a que no están compartiendo el disco duro asignado, ni las unidades de memoria, ni el OS, ni el App Server ni el Web Server. Lo único que se comparte, son los cores de cómputo. Las instancias extra small son recomendadas sobretodo para pruebas de concepto o funcionalidades muy básicas, teniendo en cuenta sus características. En general para aplicaciones de línea de negocio, es mejor comenzar a analizar desde las pequeñas hacia arriba.
Post Complementarios:
Windows Azure: Compilado de Recursos
Agradecimientos a: @afwilliams y @julitogtu por provocar el post 