¿Cómo sería el Google Web Services?

Etiquetas

amazon, aws, cloud computing, google web services

Dave Winer lanzó el rumor que Google ofrecería un servicio similar al Amazon AWS. Luego dice que Google no debería cobrar nada por esos servicios ya que le daría muchas más ventajas en sus contratos e integraciones.

Yo no estoy seguro que deba ser tan así, basta que solucione algunos de los problemas que nos hacen prohibitivos el uso de Amazon Web Services a la mayoría de nosotros:

• No cobrar por la transferencia de datos de servicios como Amazon S3. Google tiene una infraestructura de comunicaciones muy grande repartida por todo el mundo, no le sería ningún esfuerzo.
• En el servicio similar al SimpleDB, permitir filas con longitud de textos aleatorios y búsqueda full-text sobre ellos. Con la experiencia de Google en bases de datos complejas y búsqueda, tampoco es un big deal.
• No cobrar por el uso de CPU de las transacciones a SimpleDB.
• No cobrar por el sistema de cola de mensajes similar al SQS.
• Reducir un 50% el precio de la hora de máquinas virtuales, con esto el coste mejoraría casi en todos los casos al de un servidor dedicado. No obstante, aunque los precios sean similares al de Amazon EC2 ya resultaria conveniente al poder contar con los servicios de base de datos (SimpleDB), almacenamiento (S3) y mensajes (SQS) de forma gratuita.

Lo bueno de que Google entre en el mercado, es que Amazon seguramente bajará sus precios para aproximarse a lo que comentaba –creo que es casi obvio que es una barrera de entrada importante elcoste de esos servicios–.

¿Lo malo?

Que toda las utilities, o servicios básicos, estarán en manos de pocos gigantes- Eso ya pasó con otros servicios como la electricidad, el teléfono, agua o gas. Por lo que seguramente se avecinan intervenciones gubernamentales en estos mercados de cloud-computing.

Sea como fuese, la «informática de servidores» de dentro de diez años poco tendrá que ver con la actual. Ya comenté antes en el blog, pero repito mis recomendaciones sobre qué debería estudiarse en las carreras, o al menos que deberíamos estudiar los informáticos para estar actualizados:

1. Tratamiento masivo de datos. La precisión perderá el valor primordial y absoluto que tiene hoy en día en la informática tradicional. Ganará importancia la capacidad de obtener aproximaciones de inmensa cantidades de datos (los vídeos de Youtube son casi un ejemplo paradimático, por naïve y fácil de entender).
2. Programación distribuida y multiprogramación masiva con modelos como el map-reduce (el map-reduce es heredado de los lenguajes funcionales como el Lisp, seguramente veremos la introducción de modelos más sofisticados de este tipo en casi todos los lenguajes dinámicos).
3. Las base de datos relacionales no serán relativamente tan importantes –como lo son hoy– por sus características relacionales+ACID, otras adquirirán más relevancia: free form, bajas latencias, creación automática de índices de acuerdo a los patrones de consultas, clustering/particionado, distribución y replicación.
4. Los lenguajes dinámicos serán los reyes (Python, Ruby, Perl, incluso el PHP, algunos dicen que el Javascript 2/ECMAScript Edition 4 será competencia dura, aunque también tienen sus discusiones y piden incluso que se pythonise), pero los «exquisitos» usarán lenguajes funcionales específicamente orientados a sistemas concurrentes y distribuidos, como Erlang.

Ya está por hoy. Apago mi bola de cristal.

Probando Amazon EC2, es todo GNU/Linux, con Xen

Etiquetas

amazon, cloud computing, ec2, s3

Tenía la intriga de saber cómo funciona Amazon Elastic Compute Cloud por varios motivos, fundamentalmente académico —dicen que es la siguiente «revolución» y que Google no tardará en imitarlos– y ver también si podría servir para el Menéame –sí, sirve– y para los que quieran comenzar con proyectos en Internet –es genial–.

Tenía el interés en aprender porque la información que se encuentra en los blogs o en las noticias en general se habla muy poco de los detalles técnicos. Así que anoche me puse en ellos y no me acosté hasta las 6 de la mañana hasta tener bien claro como funciona.

Así me pude dar cuenta que en realidad se trata del bien conocido Linux con el Xen. Nada más y nada menos. Pero con una diferencia fundamental: te puedes crear nuevas instancias –i.e. máquinas virtuales– o destruirlas en cuestión de segundos desde tu propio ordenador con las utilidades de línea de comando Java que te bajas de Amazon.

Además tiene otras ventajas, puedes elegir la «potencia» y «tamaño» de la máquina que quieres, y se facturará de acuerdo a ella. Por ejemplo la más simple es una equivalente más o menos a un núcleo Opteron de 1.2 GHZ (en las pruebas que hize me va un 30% más rápida que un Xeon 3 GHz de 64 bits que tenemos de backup para el Menéame). Hay tres tamaños diferentes, la simple mencionada (de 32 bits), una «dual» de 64 bits y una equivalente a cuatro núcleos de 64 bits.

La facturación es por hora, la simple son unos 0.1 dólares por hora que esté en marcha, la siguiente a 0.4 dólares y la de cuatro núcleos a 0.8 dólares (más impuestos/IVA).

Por defecto y si sigues las intrucciones de instalación te instala una Fedora Core 4. Pero puedes usar otras imágenes de colaboradores y no oficiales y que incluyen hasta Ubuntu Gutsy de 32 o 64 bits.

Cada «imagen» está definida por un XML (llamado «manifiesto») almacenado en el sistema S3 de Amazon, estos «bundles» son llamados AMI. Para poner en marcha una nueva instancia sólo tienes que indicar el AMI que quieres usar, por ejemplo para la Ubuntu de 32 bits sólo he tenido que ejecutar desde casa el comando;

ec2-run-instances ami-ed22c784 -k keypair1

Nota: el «keypar1» es una clave RSA para poder acceder luego como root vía ssh a la nueva instancia, el usuario root no tiene password.

Otra ventaja importante es que una vez has personalizado la imagen con el software y las configuraciones necesarias es muy fácil crear una nueva imagen y su AMI correspondiente, almacernalo directamente en S3 (te facturan por espacio) y luego usar ese AMI personalizado para poner en marcha nuevas instancias.

En resumen, el servicio EC2 es de servidores virtuales Linux-Xen, pero gestionado enteramente por tí, ellos te cobrarán por el uso que haga de CPU, almacenamiento (si guardas AMIs o datos en S3) y trafico de Internet.

Si lo que buscas es un servidor para inciar un proyecto, es tu opción. Pero haz los cálculos, la máquina simple te costará por mes:

0.10 dólares * 24 * 30 = 72 dólares ~= 52 euros

A eso debes sumar el tráfico, si transfieres unos 500 GB te costará 90 dólares (unos 65 euros).

Y ahora como siempre la opinión. Esto explicado así no parece gran cosas, sobre todo para los que conocíamos el Xen. Pero la forma de administrarlo y crear y destruir «maquinas virtuales» en pocos minutos –además se puede automatizar con scripts que analicen la carga, por ejemplo– es otra innovación importante. Y todo junto seguramente cambiará radicalmente la forma en que trabajamos con «servidores» en Internet. Ya lo dicen los blogs y la ya conocida frase cloud computing.

Y todo esto se hizo con software libre.

Es más, creo que hubiese sido imposible llegar a este nivel y escala con software privativo. Pero claro, siempre habrá alguno que diga «con el software libre se copia, no se innova, larga vida al software privativo» sólo porque está alucinando con el iPhone (y posiblemente con las bellas nalgas de Steve Jobs).

Actualización: Leyendo los foros me dí cuenta de un problema importante. Los datos de cada máquina virtual sólo persisten durante la existencia de la misma, si ésta se detiene se pierden todos los datos. Han reportado casos de algunas «desapariciones» de instancias (una persona reportó tres en varios meses). Por lo tanto estás obligado a mantener copias de seguridad o datos replicados en otras instancias.