Etiquetas
Actualización: No todo el framework de Django es compatible, justamente una de las partes más importantes para no depender de las cuentas de Google no se puede usar por incompatibilidad del modelo de datos: la gestión de autentificación de usuarios 😦 Afortunadamente se puede modificar o reimplementar el módulo para que sea compatible con el Bigtable de Google.
Hace unos días comentaba del posible nuevo servicio que Google presentó hace unas horas, el Google Web App. Miré todo el vídeo de presentación, la documentación y pedí el alta. Por supuesto ya se habían cubierto las 10.000 cuentas que ofrecían, así que estoy en cola (como Toni Aloy, otro fan de Python y Django –fue el que me terminó de convencer, de él me fío mucho– que también habla del tema).
Como ya comenté antes, tiene su parte «tenebrosa»:
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.
Aún así me alegró bastante lo que he visto, está muy bien parido. Aunque hay cosas de mi wishlist que todavía no se saben –los esquemas de precios– hay otra que se confirma: tener una base de datos persistente similar a la de Amazon, pero con más posibilidades.
Por otro lado una ventaja importante para mí. Justamente este cuatrimestre cambié, de un día para otro, lo que doy en la optativa de Administración de Sistemas Operativos.
Hasta el curso pasado daba una introducción a Perl, lenguaje que se debía usar para la segunda práctica de la asignatura. Este curso cambié a Python y opcionalmente Django. Esta noticia acaba de darme la alegría del día, la decisión ha estado acertada, no sólo porque sea «compatible» con Python, sino porque asegura aún más el futuro a largo plazo del Python (incluso Guido, su creador, está en el equipo) y afianza el modelo de framework del Django.
Pues resulta que Google Web App está basado todo en Python 2.5 –aunque introducirán más lenguajes para que sea «neutral», aunque el Python seguirá siendo el principal–. Está soportado el 100% de Python, lo único que han limitado de la librería estándar es el acceso de ficheros –no pueden existir en Google, está todo distribuido– y la de threads –toda la aplicación ya funciona naturalmente en threads–.
No sólo eso, el sistema de desarrollo es mucho más simple –aunque más limitado al estar exclusivamente orientado a aplicaciones web– que Amazon EC2+S3. Se trata de un framework de desarrollo muy similar a Django con un sistema de almacenamiento –Datastore– similar a SimpleDB. Y nada más, ni máquinas virtuales, ni espacio de almacenamiento como S3.
Google te provee el SDK que lo instalas en tu ordenador (compatible GNU/Linux, Windows y Mac), ¡y sí es software libre! (aunque era de suponer estando Guido van Rossum involucrado en su desarrollo).
GOOGLE APP ENGINE SDK
=====================
Copyright 2008 Google Inc.
All rights reserved.Licensed under the Apache License, Version 2.0 (the «License»);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
Está todo programado en Python, incluye Django, e implementa hasta el Datastore. Cuando lo has probado en tu ordenador simplemente lo subes con los comandos incluidos en el SDK y con el mismo usuario y contraseña de tu cuenta en Google.
Simple, efectivo, potente y lo que te bajas a tu ordenador es software libre –y es de suponer que gran parte de ese mismo código es el mismo que se ejecuta en Google–.
El framework de desarrollo de Google es muy similar a Django, e incluye también Django, de hecho el sistema de definición del modelo de datos y los templates son exactamente los mismos. Como soportan todo el Python puedes incluir y subir los frameworks o módulos que te interesen.
Pero incluso es más sencillo que Django, ya que pueden cambiar el modelo de datos en cualquier momento y no preocuparte de nada más. Éste es uno de los problemas de Django, sobre todo comparado con Rails. Si haces modificaciones de datos en tu servidor de desarrollo el Django puede crearte de nuevo toda las tablas, pero si tienes un servidor en producción tenías que hacer los cambios manualmente y con mucho cuidado.
El Datastore no es una base de datos relacional, no permite joins debido a la naturaleza distribuida de las tablas. Una tabla puede estar en un conjunto de servidores y otras en otros, desarrollar algoritmos distribuidos que permitan los joins es muy complicado, sino imnposible todavía, por lo que hay que solucionarlo en la aplicación –aunque los que estamos acostumbrados a desarrollar en web, especialmente con MySQL, ya no nos cuesta mucho diseñar las consultas de esta manera–.
El lenguaje de consulta a la base de datos es el GSL, es muy similar al SQL, permite cláusulas where sobre varias columnas, ordenar por uno o varios campos, incluso soporta transacciones con funciones del módulo db.
También soprta la autentificación de Google –es muy simple de usar, por lo que supongo habrá muchos web que obligarán a tener cuenta en Google 😦 –, conexiones a URL externos y envío de correo vía Gmail. Esto es lo que hay actualmente, prometen que iran agregando más módulos y servicios, ya han prometido que pondrán alguna manera que puedas hacer tratamiento masivo sobre la base de datos desde tus propios ordenadores, no sé si lo harán por copia o publicarán un API para acceso externo.
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 se empiezan a vislumbrar algunas de los cambios que había predicho antetiormente cuando tenía la bola de cristal en marcha:
- Tratamiento masivo de datos. Parcialmente ya se tiene con la base de datos casi ilimitada
- Programación distribuida y multiprogramación masiva con modelos como el map-reduce. Supongo que ya se usa automáticamente, posiblemente el el acceso a la base de datos. La base de datos es Bigtable, y como explican en el paper, está implementado sobre el sistema de ficheros distribuido GFS, el formato de ficheros es su SSTable y usan replicación soportada por el servicio Chubby y el algoritmo Plaxo.
- 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…: confirmado también.
- Los lenguajes dinámicos serán los reyes (Python, Ruby, …). Confirmado ya con el Python.
Del tema de la base de datos me llama mucho la atención a la repetición del patrón que se presenta incluso en los cambios de paradigmas científicos según Kuhn: la simplificación del modelo porque el anterior ya se había vuelto intratable de tan complejo y difícil.
Con la arquitectura actual de hardware y base de datos fundamentalmente centralizadas hemos exprimido al máximo –en potencia y complejidad– al modelo relacional+SQL. De golpe esa arquitectura se nos hizo muy compleja para escalar o replicar para el balanceo de carga o la alta disponibilidad. Parecía que la complejidad se haría cada vez peor. Pero no, está ocurriendo lo contrario.
Primero hubo que cambiar radicalmente la arquitectura de la plataforma, en esto ha reinado Google con su cantidad masiva de «ordenadores baratos». Una vez que esa arquitectura está madura el software se adapta a ella, pero en vez de hacerse cada más complejo se simplificó radicalmente, como el caso del DataStore de Google o de SimpleDB de Amazon.
¿Quién hubiese predicho hace diez años que a estas alturas haríamos este aparente viaje hacia atrás?
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.
Sonará casi a apostilla de Enrique Dans, pero es que me dejó francamente alucinado 😉
Estoy completamente de acuerdo contigo, yo también lo he comentado en el blog, la verdad que espero ansioso esa invitación a probarlo, tengo un proyecto, que podría iniciar por ahí, a ver que tal.
La mejor noticia es el apoyo directo a Django, que creo que al final incluirán completamente, el tema de las joins me preocupa, estoy demasiado acostumbrado a trabajar con ellas que ni se me ocurre como hacerlo sin ellas.
A repasar como trabajar sin joins… 😀
Pingback: EnGuillem! » Blog Archive » Google App Engine
Por fin alguien que me lo cuenta para que lo entienda. Acabo de ver que un programa de vídeo esta hecho en Python y creo que me voy a poner ahora mismo a aprenderlo. También he visto que funciona en mi N95… y programar para el móvil me pone cachondo muahaha sobretodo con la manía que le tengo a Java.
La verdad es que no tenia la mas remota idea de para que se podría querer la gente ¿un grid? de este tipo a la hora de programar pero explicando que puedes tener sql y demás ya le veo sentido. En plan servidores ¿que otros usos tendrá? Como tu dices, es lo que siempre he deseado (y comentado anteriormente aquí mismo)
Por cierto, yo nunca suelo usar joins 🙂 siempre me pareció una complicación innecesaria de queries y rendimiento. Aunque no sabia nada de optimización, ni bases de datos relacionales… para que voy a mentir… no programo ni indentando el código, ni creado clases, así que con eso os lo digo todo… complicarme yo y complicar el código…
«Por cierto, yo nunca suelo usar joins 🙂 siempre me pareció una complicación innecesaria de queries y rendimiento. Aunque no sabia nada de optimización, ni bases de datos relacionales… para que voy a mentir… no programo ni indentando el código, ni creado clases, así que con eso os lo digo todo… complicarme yo y complicar el código…»
Ivan
Esto que dices..es una broma, verdad? (si no, q miedo das…)
No, no lo es muahahaha si que doy miedo xDDD me he dado cuenta pero no se porque jajajaja
Cuanto tienes 100 usuarios concurrentes en un servidor de 75$ lo que menos haces es usar esas cosas 😉
No puedes meter 50kb de una clase en memoria en cada impresión de pagina, no puedes tal, no puedes cual. Hasta los espacios alivian una carga considerable 😉 necesitas cache, compresión de los jpg, quitado de espacios, uso amplio de css, de js/ajax…
Google ya lo predijo unos 5 años atras, mediante la introducción del primer grid comodity computing, donde decían que la programación paral.lela era realmente demasiado compleja y era mejor aplicar una visión del tipo «Divide y vencerás», y por lo que veo fué una desición acertada.
Me encantaría usar el servicio de google web apps pero me asusta un poco los derechos que obtiene google por usar su servicio:
«By submitting, posting or displaying the Content on or through the Service you give Google a worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute such Content for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy. Furthermore, by creating an Application through use of the Service, you give Google a worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute such Application for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy».
Es decir: Cualquier contenido publicado o mostrado google tendrá derecho en usarlo, reproducirlo, adaptarlo, modificarlo y publicarlo sin ningún problema. Por lo tanto, según lo entiendo no es buena idea usar google web apps para realizar un proyecto empresarial que su valor esté en el contenido y usuarios obtenidos.
> Es decir: Cualquier contenido publicado o mostrado google tendrá derecho en usarlo, reproducirlo, adaptarlo, modificarlo y publicarlo sin ningún problema.
«for the sole purpose of enabling Google to provide you with the Service»
Asumiendo buena fe, supongo necesitan o quieren la autorización expresa para poder copiar, distribuir y ejecutar tu programa en sus servidores. Hay comentarios en Slashdot sobre el tema, uno de ellos muestra que tu mantienes todos los copyrights y derechos sobre tus programas.
También me ha parecido entender lo mismo. Tu mantienes el copyright y derechos, pero no me queda claro si compartes el copyright cuando publicas el contenido, buscaré más información sobre el tema.
Creo que es importante ya que el valor de un proyecto en internet se basa tanto en la aplicación como (y mucho más) por los usuarios y sus contenidos.
Ricardo, ¿ha te has planteado si menéame, a la larga, pueda usar el Google Web App? 😉
Ivan
Otra pregunta (si no es muy indiscreta)… que servicio web tienes que tenga esa carga?
No se como puedes mantener una aplicacion con esas «tecnicas» que usas…
Por cierto, mirate http://www.slicehost.com/ que por 70$ te da unas maquinas muy majas…
Pingback: » Google App Engine
#5, no caigamos en la justificación de malas praxis bajo el paraguas de la supuesta eficiencia y/o optimización. Últimamente me da la sensación que es una tendencia en boga, y creo que es un concepto equivocado al máximo.
Como diría Tanenbaum: «La ontogenia recapitula la filogenia»
Buenas, ¿recomendais algún libro/biblia para empezar con Python y Django?
Merci.
15
Si ya sabes programar, Dive into Python: http://www.diveintopython.org/
Si te vas a comprar un libro, «Core Python Programming»
Para Django, sin duda: http://www.djangobook.com/
Independientemente del impacto que tiene el lanzamiento Google, creo que tendremos en breve un impacto más callado pero igualmente positivo para el desarrollo web: el desarrollo empresarial en frameworks como Django y en Python.
Hasta ahora, y lo he vivido en mis carnes, se programaba en Java no porqué fuera la herramienta adecuada para el desarrollo del producto, sinó porqué en caso contrario el consultor de turno te descalificaba porque estabas utilizando una lenguaje «no estandard».
Me veo venir dentro de poco hordas de consultores encorbatados recomendando Python y Django proqué es lo que utiliza Google.
Independientemente de que no debemos perder la perspectiva e identificar la herramienta y el lenguaje adecuado para cada proyecto, lo que sí nos da este anuncio es una herramienta más que no debemos estar justificando innecesariamente. Ahora ante la pregunta de «quien emplea eso» la respuesta no puede ser más potente: Google y miles de desarrolladores.
A parte de eso, la gente que actualmente no conoce Python y se acercará a este lenguaje para poder probar el sistema, seguramente quedará prendado por la potencia y sencillez de lenguaje. Conozco a algún desarrollador PHP que otro que cuando le hemos presentado el tandem Python+Django para desarrollar «ve la luz», no és una cuestión de fe, es cuestión de productividad y potencia de desarrollo.
Google App Engine nos permitirá dar el paso más fácilmente hacia las empresas, que aunque sigan utilizando bases de datos relacionales (que tampoco hay que matarlas, oiga) encontrarán que la gente formada en la utilización de Google Apps, puede desarrollar aplicaciones web y desplegarlas en una fracción del tiempo que se necesita para hacerlas en otros lenguajes de programación, y ya no hablemos de su mantenimiento posterior.
15-16
Y para los ansiosos http://www.arrakis.es/~rapto/AprendaPython.html, python instantáneo. En medio día a programar en Python se ha dicho 🙂
Es una buena introducción para los que ya saben programar. Después tanto la documentación de Python como la de Django veréis que son de lo mejorcito que corre por la web.
Esto de Google me anima a ponerme ya mismo con Django y Python.
He estado probando/usado otras plataformas de software libre, pero todas hasta el momento en PHP. No le veia demasiado sentido el ponerme a estudiar Python, ya bastante ocupado estaba con otras cuestiones. Pero ahora mi percepción cambia.
Pingback: Loogic Links 132 Loogic.com Blog Archive
Ger. Ya no tengo el servicio, lo cerré por decisión propia, estaba quemado (yo). Tenia mensajero instantáneo (refresco de 1seg), búsqueda con muuuuchas opciones (60 categorías sólo para imagenes) y de muchos tipos, blogs-comentarios, permisos de acceso, conversión de video on-the-fly, upload ilimitado (en el de 75$) y bastantes cosas mas. Al final el video lo tuve que quitar como sección y dejarlo solo dentro de los perfiles, se estaba convirtiendo en pornotube (ya tenia mas contenido de esa temática que ellos) en vez de «badoo» y amistad como era mi idea… no me gusta ni censurar, ni tener una web porno. El problema mayor era la falta de memoria.
Kr0n no era por gusto, hice pruebas dentro de mis limitaciones. Fíjate que me salia mas «rentable» hacer un query para elegir archivos (60 categorias con opción de obligatoria, opcional y prohibida [UDF]) meterlo en un array en memoria y luego hacer otro query. Me quedé flipando. Con eso 0.02, con subquery o joins 30 segundos… parece que se volvía como loco rastreando todo una y otra vez por cada fila, incluso con indices bien puestos. Aunque ya te digo, no soy un experto en sql. La mayoría de sitios donde he leído ponen hincapié en bases de datos relacionales y creo que es el camino porque cuando la tabla es MUYYYY grande un solo dato pesará mucho menos que todos juntos pero lo que arreglas por un lado lo pierdes por otro y usando cacheado a disco no se yo que es mas rápido. Hay que pensar que estructura viene mejor para lo que vas a hacer exactamente. Yo aprendo cagandola y como autodidacta, todo hay que decirlo.
galli Vaya y yo que me he comprado esta mañana el de Anaya porque no encontraba otro en español… eso de aprender de cero algo en ingles me resulta complicado, siempre estoy dudando en si habré entendido bien lo que pone y si estará todo mal.
He leído por ahi que python es peor para web porque es mas lento ¿sabiendo php no merece la pena no? Lo de utilizar la indentacion en vez de los corchetes me ha dado miedo… A mi es que eso de usar clases de 200kb para hacer un «hello world» pues me parece un horror. Aunque ya voy colando por el aro en aprender cosas así por el tema de las compatibilidades. Me parecería una pesadilla crear una web hoy día incluyendo hasta microformatos. Cada día da mas miedo hacer webs…
Pingback: David Esperalta
Pingback: Google App Engine, el mejor amigo de los desarrolladores web » eConectados
Pingback: Sólo se la valora con el tiempo « Ricardo Galli, de software libre
Pingback: Python: El tipping point ya está aquí | morenosan
Pingback: La era de las plataformas como servicio » Ricotero's Blog
Pingback: Entradas en las blogosferas.67 - Carrero Bitácora de los Hermanos Carrero, David Carrero Fernández-Baillo y Jaime Carrero Fernández-Baillo.
Pingback: Dominar la plataforma… « Ricardo Galli, de software libre
Pingback: Persistencia de Amazon « Blog de JoseMPelaez
Pingback: Pequeña historia del fracaso de un proyecto personal derrotado por FriendFeed (por goleada, y sin siquiera salir al campo) « Ricardo Galli, de software libre