Google App Engine, el mejor amigo de los desarrolladores web

App Engine
Desde que presentaron App Engine el otro día, he estado leyendo opiniones y he estado probándolo (en local). Ya sabéis que no me gusta lanzarme a la piscina a hacer valoraciones demasiado precipitadas. Antes de hacer la mía, algunas que he ido compartiendo a través de Google Reader.

Experimenting with Google App Engine, este ex-ingeniero de Google que fue el PM de este proyecto de Google antes de irse y fundar FriendFeed, lo ha estado probando creándose un blog. Sus conclusiones:

I don’t think this blog will ever get millions of page views, but it is pretty cool that it could in theory :) I didn’t have to configure anything. I didn’t need to make an account system to make an administrative section of the site. And the entire blog is less than 100 lines of code. I deployed by running a script, and I was done. No machines, no “apt-get install”, no “sudo /etc/init.d/whatever restart”, nothing.

I am impressed. The App Engine team has done a fantastic job, and I think they have already changed the way I do hobby projects.

The next logical question is: would I run a real business on infrastructure that is so different than everyone else’s? If I change my mind about App Engine, what are my options? I am hoping a number of open source projects spring up as alternatives to lower the switching costs over the next year. I will be very interested to see how many startups take the leap and run on App Engine entirely in the meantime.

El futuro es distribuido: Google App Engine, Víctor R.Ruiz comenta lo interesante que le parece este proyecto:

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”.

Early notes on GoogleApps, Dave Winer comenta sus primeras impresiones sobre este servicio, y a lo que le recuerda:

Now, what Google announced is really exciting! I’m not kidding. It’s even better than I hoped. Yes, it’s only Python, but IBM’s PC-DOS was only BASIC and Pascal when it first came out, and it didn’t matter. Yeah, I preferred C, but I coded in Pascal because that’s what you had to do to get an app running. What you’re going to see here that you’ve never seen before is shrinkwrap net apps that scale that can be deployed by civillians. That’s a mouthful, but that’s what’s coming. Why? Because here is a standardized platform that can be stamped out in the billions of units. Maybe Google can’t do it, but the perception is that they can. Who is willing to stand up and say Google hasn’t nailed scaling? What PCs did in the 80s, Google is doing now. PCs took the black magic out of owning a computer. Now Google is taking the black magic out of operating a scalable web app. Python is the new BASIC.

Google Web App, muy simple y potente, Ricardo Galli muestra lo impresionado que está:

En resumen, técnicamente brillante, sobre todo por su simpleza. Además asegura total escalabilidad, replicación y persitencia tanto de la aplicación como de la base de datos, el problema fundamental de las máquinas virtuales de Amazon EC2.

Además, es fundamental para un programador, no te tienes que preocupar de instalar y configurar sistema operativo, software o base de datos. En realidad no te tienes que preocupar ni de que ocurra una avería. Simplemente a programar. Como explica Guido en el vídeo de presentación, era lo que siempre deseaba, pero que el tema de instalación y configuración siempre había sido una molestia enorme para los programadores.

Google App Engine frente a los web services de Amazon, Antonio Ortiz avisa a Amazon que tiene que preocuparse y mejorar sus Web Services:

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.

Google App Engine: History’s Next Step or Monopolistic Boondoggle?, en Read/Write Web celebra este lanzamiento aunque cuestiona que se le compare directamente con los Amazon Web Services cuando son 2 cosas diferentes, aparte de otras cuestiones como elegir sólo Python:

Services like App Engine may very well represent history’s next logical layer of abstraction, taking several onerous obstacles off of the to-do list of application developers. That means developers can focus on other things and leverage greater resources than they may have had access to otherwise. Google-sized economies of scale can beat just about anyone on price and in theory it bodes well for uptime.

Tras poner las valoraciones de estas personas, da cosa poner lo que uno piensa; pero para eso es mi blog ;-) .

Centrarse en desarrollar

Uno de los mayores problemas que he sufrido a la hora de hacer aplicaciones web es la carga del servidor, el tener que estar tocando para que funcione bien y no se sobrecargue. Un ejemplo de ello fue escuchando.es, estaba hecho en Ruby On Rails. Obviamente no estaba bien optimizado, pero es que se caía una y otra vez y eso que entraba poca gente. Ahora con WordPress también he tenido problemas con MediaTemple porque hacía consultas demasiado lentas y he tenido que cambiar algunas cosas de plugins y cacheo. Por eso, el tener un servicio como Google App Engines que me permita desarrollar aplicaciones web sin preocuparme de escalar alquilando múltiples servidores, de estar configurando Linux, Apache o MySQL; es algo que se agradece muy y mucho. Permite centrarse en mejorar tu producto, sin despistarte en otros temas.

Escalabilidad – Base de datos

La palabra clave es escalabilidad, y es algo que leeréis múltiples ocasiones en esta entrada. El uso de la base de datos de Google (alias BigTable, creada por ellos para su buscador) es imprescindible para que pueda escalar. MySQL está muy bien, pero todos conocemos los problemas que da cuando se le pide demasiado; que hay que empezar a poner varias bases de datos replicadas. Desde Google han tomado una visión opuesta, y la verdad es que me parece la más lógica. No sé los expertos que dirán.

Por ejemplo, a la hora de mostrar los comentarios en una entrada o foro; la concepción más normal (al menos para mí hasta ahora) era tener una tabla con los comentarios con un campo user_id; y luego una tabla con los usuarios. Y a la hora de mostrar los comentarios hacer un JOIN entre ambas tablas para coger el nombre del usuario a partir del user_id. Esto implica que haya mayor carga en la lectura de la página.

tabla_comentarios: id, user_id, comentario, date
tabla_usuarios: id, nombre, web

SELECT c.comentario, c.date, u.nombre, u.web from tabla_comentarios as c INNER JOIN tabla_usuarios as u ON c.user_id = u.id

Sin embargo la concepción que aplica Google es la de crear las tablas para que la lectura sea rápida, perjudicando la creación y actualización que es donde aumentaría la carga. Las tablas serían más grandes, la información estaría duplicada y habría que tener cuidado a la hora de actualizar para no dejar nada desactualizado.

tabla_comentarios: id, nombre, web, comentario, date
tabla_usuarios: id, nombre, web

SELECT nombre, web, comentario from tabla_comentarios

Hasta hace unas horas lo más normal me parecía el primer modelo, pero ahora me inclino por el segundo. ¿En las webs hay más actualizaciones o lecturas? Depende de lo que haya habrá que escoger un modelo de base de datos u otro. Pero creo que la mayoría de las webs tienen muchas más lecturas, por eso usamos sistemas de cacheo. Ahora bien, ¿entonces por qué la mayoría de webs/manuales/libros usan/recomiendan el primer modelo? Dejo la pregunta en el aire…

Python

Mucha gente se queja de que sólo permitan Python por ahora, seguramente a muchos de ellos no les gustará que el código tenga que estar bien tabulado/identado para funcionar. Pero cuando lo probé no me disgustó para nada, y me lo puse en temas pendientes. Ahora puede ser una excusa para ponerse a ello (en verano mejor dicho, que ahora toca aprobar todas para irme lo más limpio posible a Chicago). Soportar Django es sin duda un fuerte impulso a este framework hecho en Python, aunque por lo que he estado viendo hay que cambiar unas cuantas cosas (como los modelos de la base de datos) asi que no tengo claro ese “soporte”. Ya han hecho un tutorial sobre cómo usar Django bajo App Engine.

Integración con las cuentas de Google

Algunos ven el peligro de que Google se intente convertir en el nuevo Passport. No creo que suceda, aunque sí que es cierto que Google ofrecerá este servicio gratis (dentro de unas cuotas) para que más y más gente use sus otros servicios perjudicando a Microsoft y Yahoo. Por ejemplo con Gmail. Si muchas aplicaciones creadas en este servicio permiten enviar y recibir emails mediante las APIs de Gmail, mucha gente estará tentada a mudarse. Pero de hecho ya hay soporte OpenId, y el proyecto OpenSocial deberá abrir más información.

SDK

Este es un punto muy importante ya que permite programar en local tus aplicaciones comprobando que funcionan y ver sus fallos, incluso montando un servidor de prueba. Yo me bajé el otro día el SDK y he estado cacharreando y me ha gustado bastante. Sin duda parece que la palabra SDK está de moda. Acabaremos hartos de tantos SDKs.

¿Y qué pasa con los Web Services de Amazon?

Son parecidos pero diferentes y mejores. Me explico. En los diferentes servicios que ofrece Amazon tu puedes contratar espacio web sólo, o base de datos, o capacidad de procesamiento; o todo junto. La pega es que hay que estar configurándolo, y aunque no es muy complicado hay que ponerse a ello. Lo que ofrece Google es algo más simple, que está configurado por lo que sólo tienes que dedicarte a desarrollar tu aplicación web.

Puntos negativos

Más que puntos negativos son preguntas que Google tendrá que ir respondiendo. ¿Sólo Python o permitirán Ruby y PHP? ¿Permitirán tareas cron o habrá que tener un servidor externo para que las invoque? ¿El plan de precios después de la beta? Y como comentan en alguno de los artículos a los que he enlazado, hay que tener en cuenta que si programamos para el SDK que da Google en su App Engine no podremos mudarnos a un servidor propio; asi que a la hora de diseñar la aplicación web habrá que elegir si confiamos ciegamente en Google o nos cubrimos las espaldas.

Resumen

Hay que esperar a comprobar que este sistema de cloud computing funcione correctamente y escale tan bien como proclaman; pero tiene toda la pinta de que va a convertirse en un punto de inflexión a la hora de desarrollar aplicaciones web. Yo ahora mismo estoy expectante a ver que lleguen las primeras pruebas serias, pero sobre el papel es magnífico. Iremos viendo más experiencias.

Para más detalles, miraros la documentación que ha hecho Google, el tutorial de un libro de visitas (Lo podéis hacer en local, no hace falta que os hayan dado la invitación) o los vídeos de la presentación de App Engine.

Actualización

Otra opinión que muestra sus recelos con App Engine, debido a que Google empieza a controlar demasiado y quiere convertir Internet en su GoogleNet.