« Nos vemos en iCities | Inicio | El Canarias7 busca blogueros »

09/04/2008

El futuro es distribuido: Google App Engine

Mi amor por Python comenzó hace ya algunos años, cuando Iván Juanes, un colega del Grupo de Usuarios de Linux de Canarias (GULIC) le prestó un libro a mi hermano sobre este lenguaje. Echándole un ojo, quedé prendado de este lenguaje que no te hacía sentir estúpido (algo que siento al programar en Perl). Su sencillez, su belleza matemática, me cautivaron. Durante meses estuve tentando de programar Blogalia en Zope, el único framework web para Python que existía en aquel entonces. Pero Zope era todo lo contrario que Python y al final utilicé PHP. Años más tarde llegó Ruby on Rails, y la comunidad Python se sintió menospreciada ;) Y poco después llegó Django, y otros tantos, que aliviaron la situación y potenciaron el uso de Python en entornos web.

Hoy Google ha presentado su servicio escalable de aplicaciones: tú haces la aplicación y ellos la alojan en su nube de servidores. El servicio se llama Google App Engine. El Ornitorrinco Enmascarado da más detalles en Google App Engine - Python más útil que nunca y Error500 en Google App Engine frente a los web services de Amazon:

«Amazon y el resto de actores de las plataformas como servicio tienen motivos para preocuparse. Google entra en el terreno de juego, con algunos puntos muy buenos a pesar de que se trata de una beta que tiene todavía que crecer mucho. Como empresa, hoy más que nunca, Google se asemeja cada vez más a los gigantes que han dominado épocas de la tecnología de la información como han sido IBM y Microsoft».

El único lenguaje de programación disponible de momento para Google App Engine es Python, y uno de los framework recomendados es Django. De ahí la euforia de los pythoneros (incluído yo ;)

Ahora vayamos al fondo del asunto. Esta es una de las noticias que he encontrado más interesantes en mucho tiempo en lo relativo al futuro del web. Para cualquiera que se haya enfrentado al desarrollo de una aplicación web, sabrá que el problema (una vez tienes un servicio funcionando y comienza a tener éxito) es hacer que crezca sin traumas. Por desgracia, muy pocos frameworks de desarrollo web solventan ese problema. Vi cómo TypePad pasaba de unos pocos miles a millones de usuarios, y los problemas de programación, infraestructura y hasta de recursos humanos que todo ello ocasiona. Por eso era algo crítico con Ruby on Rails o Django, porque no ofrecían nada muy diferente a lo que ya había: aumentaban la productividad de los desarrolladores, sí, pero dejaban los dolores de cabeza para más tarde (a los problemas de Twitter o La Coctelera me remito). El ideal de framework web, para mi, es uno que permita desarrollar una aplicación de forma tan fácil como hacerla crecer. Zope sí facilita el crecimiento en ordenadores distribuidos, pero desde luego, no le aplico el adjetivo de "fácil de desarrollar".

Hace tiempo que Amazon vio una oportunidad en ese nicho. Lanzó sus servicios S3 y EC2, para el almacenamiento y ejecución de sistemas operativos virtualizados en su inmensa red de ordenadores, de forma relativamente sencilla. Desde un punto de vista diferente, Facebook y Salesforce también han tentado a los desarrolladores para alojar las aplicaciones de terceros en sus servidores, aunque solo aquellas relacionadas con sus servicios.

Pero la oferta de Google va un paso más allá y pone a nuestra disposición su (casi) insuperable conocimiento sobre escalabilidad de servicios: desarrollamos nuestra aplicación web en CGI (y de momento en Python), la subimos a Google App Engine, y listo. En teoría ya no tendremos que pelearnos con el Apache, o el MySQL para que rindan como jabatos ante un enlace bienintencionado pero mortal de los Microsiervos (¡horror, avalancha de visitas!). Google App Engine es lo más cercano a mi ideal de framework web: fácil de desarrollar y fácil de escalar (más fácil imposible: ya se encargan ellos).

Google App Engine me parece un paso importante para los pequeños desarrolladores con ideas innovadoras. Desde hace algún tiempo a esta parte, la voracidad de recursos de las aplicaciones web superan con creces lo que un solo servidor da de si. No todos los programadores son buenos administradores de sistemas, y no todos los buenos administradores de sistemas son expertos en optimización de Apache, PHP o SQL. Esto obliga a los equipos a hacer una inversión no desdeñable en recursos informáticos y humanos. Estas limitaciones coartan la creatividad. Con App Engine, la inversión requerida será mucho menor en recursos humanos destinados a la escalabilidad y esperemos que las minutas de Google App Engine no sean disparatadas. La ventaja competitiva será importante.

Otros que deberían ponerse las pilas son los alojamientos tradicionales. Hace seis meses, un buen colega me preguntaba qué proyectos tenía en mente. Uno de los que más me atraían era justamente un centro de datos donde hacer realidad ese framework web ideal, porque los alojamientos tradicionales aún siguen pensando en términos de servidores individuales, y muy pocos ofrecen servicios de alojamiento de datos -y menos aún, aplicaciones- distribuidos. Es el cliente quien tiene que implementar su solución. Era necesario dejar de reinventar la rueda de la escalabilidad, una y otra vez. Google ha puesto encima de la mesa su propuesta. ¿Qué respuesta dará el mercado?

A corto plazo no creo que la cosa cambie radicalmente. Hay que hacer aplicaciones ad-hoc para Google App Engine. Pero se harán. Y a medio plazo aparecerán los MTOS, WordPress y Drupal listos para instalar en esta plataforma. Como estoy convencido de que la ventaja competitiva de usar Google App Engine para muchas empresas que aspiran al éxito en el web será importante, a medio plazo tanto la competencia directa de Google (Yahoo, Microsoft) como las empress de alojamientos deberán ofrecer alternativas. Yahoo ha estado impulsando una implementación libre de las tecnologías distribuidas de Google, llamada Hadoop. Sea con Hadoop o sin él, sospecho que aparecerán alojamientos compatibles con Google App Engine, que ejecuten las mismas aplicaciones pero ofrezcan a los clientes mayores garantías sobre la seguridad de los datos.

En fin. Cuestiones legales aparte, y no son menores, esta propuesta de Google me entusiasma. La web siempre ha sido un lugar donde pequeños grupos han podido competir de tú a tú con los grandes. Me encanta que esto vuelva a ser así.

PD: En la entrada del blog del App Engine correspondiente al 19 de abril, Google anuncia que en el futuro será posible migrar los datos hacia y desde su infraestructura, e invitan a participar en el debate sobre qué formatos son los más adecuados.

TrackBack

URL del Trackback para esta entrada:
http://www.typepad.com/t/trackback/15294/27932884

Listados abajo están los enlaces de los weblogs que le referencian El futuro es distribuido: Google App Engine:

» El futuro es distribuido: Google App Engine desde i Microsiervos
Análisis [Leer más]

» Lo próximo ... ¿los datos? desde Reflexiones e irreflexiones
Ya sugeríamos el tema hace unos días en Las cifras de Youtube (y también las mías) y me lo recuerdan unos cuantos enlaces que estaba recopilando y la entrada de Bret Taylor, We need a Wikipedia for data. Los buscadores se están quedando con la capa su [Leer más]

Comentarios

Yo creo que puede que no sea tan bueno que Google nos controle todo. Si estás bajo su servidores posiblemente también te ponga condiciones con la publicidad y me da que las aplicaciones que hagas no sean compatibles con la mayoría de los hostings ¿no? por lo que dependerás de ellos siempre y si tu web te funciona muy bien tendrás que seguir aceptando sus condiciones.

No sé, igual me equivoco.

No, no es bueno. Por eso creo que la interoperabilidad, la migración de datos y aplicaciones, debería estar encima de la mesa como una de las prioridades en estos y otros desarrollos. Mayor garantía y control por parte de los usuarios es lo que pueden ofrecer empresas de alojamiento más pequeñas. De todas formas, no creo que se pongan estrictos en cuanto a la publicidad, especialmente si se paga por el servicio que ofrecen.

Fantástica noticia, el hecho de poder quitar el "morir de éxito" en cualquier planificación no está nada mal.

Gracias por el análisis Victor. Explicas lo complejo de manera sencilla.

Al leer tu entusiasmo pienso en que una de las consecuencias de esto es que Google continuará atrayendo talento ¿verdad?

Un saludo,
Álvaro

Gracias por el enlace, Victor. Espero que podemos vernos en iCities.

He estado jugando un poco con el Google App Engine y la verdad es que está fantástico. Por el tema de la "quedarte prisionero" de Google yo no me preocuparía, la verdad, puedes hacer tu aplicación usando el framework de Django, lo que significa que correrá en cualquier sitio donde lo tengan instalado.

Álvaro: Bueno, lo de la atracción googlera no sé si lo decías por mi o en general (en mi caso no sé si encajo en una empresa tan grande, ni si tengo nada que aportar por ahí que no hagan ya otros ;) Pero en general, sí creo que Google continuará atrayendo a gente. En este caso concreto, la oferta de Google, de momento, es inmejorable y va a atraer a muchos desarrolladores. Pero seguro que hay cosas mejorables, y Google puede servir de inspiración a otra gente, incluso de pequeñas empresas. Especialmente creo que la demanda de plataformas escalables para los alojamientos va a crecer, a riesgo de quedarse obsoletos.

Ornitorrinco: ¡Nos vemos en iCities! Vaya puntazo que se ha marcado el Ayuntamiento de Candelaria. La prisión de Google no va a estar tanto en el código de aplicación como en las APIs que ellos darán y sobre todo en los datos. Esperemos que den facilidades para la migración de su sistema a otros sitios.

Tengo que probarlo, pero por lo visto para los datos se usa el BigTable de Google en lugar de MySQL (o tienes servicios MySQL externos).

Por lo que he estado leyendo idea subyacente que hay en la escalabilidad es la misma que hay tras el rey de la escalabilidad: PHP y su filosofía share nothing. Parece muy interesante, pero en principio me atrae más el EC2 y otro tipo de soluciones intermedias.

La paradoja de Google es interesante: futuro distribuido pero concentrado por ellos; sin libro de reclamaciones, sin interacción directa si hay problemas pero con un funcionamiento suave, amigable y cariñoso :)

SegFault: Si, en lugar de usar SQL tienen algo similar pero más limitado. En Amazon lo llaman Simple DB. El EC2 es mucho más flexible, y por tanto te ofrece posibilidades casi infinitas. Sin embargo, tengo entendido que las virtualizaciones no pueden guardar su estado. Y por otra parte, EC2 no es muy diferente de cualquier otro alojamiento por que sigues sin tener a nadie que te resuelva el problema de cómo escalar la aplicación web. Tampoco tiene que ser todo blanco o negro. Se me ocurren aplicaciones que podrían utilizar EC2 para algunas cosas y App Engine para otras.

fernand0: Para nosotros, pero sin nosotros. ¿"Net-o-pismo" ilustrado? };)

Ornitorrinco: no es tan fácil como "crear la app. en Django y ya está". Para eso, primero tendrán los de Django que crear un backend para BigTable (que no es trivial), porque de entrada hemos perdido los modelos y con ellos se pierden muchas otras cosas. Léase el artículo de Marty Alchin al respecto: ahora mismo se pueden usar las sesiones en Django si usas trunk y alguien escribe un "session engine" que use Datastore, pero te quedas sin las aplicaciones admin o comments, por ejemplo, pero también muchas otras de terceros.

En general decía!!

Interesante post,

gracias.

Ya queda menos para Icities.

Un saludo,
consultoracanaria.blogspot.com

Publicar un comentario

Si tiene una cuenta en TypeKey o TypePad, por favor Iniciar sesión

Acerca de

  • Biografía
    Consultor de tecnologías web, especializado en blogs y software libre. Creador de Blogalia y editor de Barrapunto.

  • Jabber: rvr@jabber.org

Flickr

  • www.flickr.com

Qué hago/leo