Etiquetas
La semana que viene tenemos la Menorca Techtalk organizada por Martín Varsavky. La lista de invitados de todo el mundo acojona bastante. Como hay una reunión en plan non-disclosure –no se permitirá ni bloggear, tomar fotos ni grabar lo que se hable allí– para presentar los proyectos individuales y pedir opinión y ayuda a los demás decidí presentar una prueba de concepto de mi vaporcito (comenzará como proyecto interno del Menéame, si no muere antes). Espero poder llegar, al menos con una versión mínima.
Teníamos problemas importantes de temas de «tiempo real» –más estrictamente, lograr bajas latencias–, escalabilidad, base de datos distribuidas y rápidas, etc.. Por eso se nos hacía muy difícil comenzar sin una financiación importante –que no conseguí–, pero Google App Engine de golpe nos soluciona gran parte de los problemas de plataforma. Ahora ya no nos hace falta grandes financiaciones ni resolver los problemas que ya lo tiene muy resuelto Google, además el lenguaje elegido fue Python, así que ya no había excusas para no intentarlo.
Hace unos días decidí que debía preparar una prueba de concepto que tendría múltiples objetivos, probar la plataforma, encontrar sus problemas y limitaciones, y pedir la opinión de los expertos –técnicos y de negocios– que estarían en Menorca.
Le dí muchas vuelta al tema de Django versus Google App Engine, la verdad es que el segundo es muy simple –con una curva de aprendizaje quizás más plana– pero también tiene sus limitaciones importantes, una de ellas, la más costosa y coñazo de implementar, es la gestión de usuario. Con Google es muy fácil, siempre y cuando estén dados de alta en Google 😦
De todas formas veía que Django en Google App es bastante complicado y aporta muy pocas ventajas, ya que el módulo de usuario y admin no puede ser usado por la incompatibilidad del modelo de datos, así que decidí hacerlo con Google App Engine pero intentando que por diseño y programación sea fácilmente portable a Django si hiciese falta.
Y allí me encontré con el problema.
Recién estoy aprendiendo y probando Google App, aunque pasé decenas de horas leyendo y casi estudiando todo lo que hay en Internet sobre el tema, debo decir que soy un completo n00b. En cuando a Python, sí, lo conozco, pero no soy un hacker Python y todavía me falta bastante para ser experto en el lenguaje –por ejemplo poder programar un par de horas sin necesidad de recurrir a la documentación–
Aquí viene lo que acabo de re-descubrir por enésima vez, aunque la edad debe también hacer mella. Es imposible hacer un buen diseño sin conocer perfectamente la plataforma sobre la que se desarrolla.
Puedes saber de qué va un MVC, pero cada uno de elos tiene sus particularidades, Django y Google App tienen además sus «manías» –al igual que Rails– que hay que conocer. Puedes saber muy bien la teoría y arquitectura de bases de datos relacionales, pero cada una de ellas tiene sus manías que afectan a la hora de desnormalizar o crear los múltiples índices necesarios [*] –si es que se puede o no lo empeora aún más– para mejorar el rendimiento en aplicaciones webs –es inevitable–. Pero es que además si programas en Google App Engine (o en Amazon SimpleDB para el caso), olvídate de mucho de lo que preasumes en bases de datos, ni siquiera son relacionales –pero sí son rápidas y distribuidas–.
[*] La base de datos del Menéame tiene –por ahora, espero que dure– 23 tablas y 60 índices diferentes.
A lo que iba, llevo más de una semana en plan diseño, y cada pocas horas –como máximo– tengo que replantearlo y rehacer partes importantes a medida que aprendo algo más de las posibilidades, o de las limitaciones de plaforma+lenguaje.
Hace muchos años que no participo del diseño de «sistemas tradicionales» y de problemas «bien conocidos» –la última vez que lo hice el estándar era el Gane/Sarson y el waterfall–, pero en sistemas cuya arquitectura es nueva y poco conocida es imposible hacer un buen diseño –más o menos detallado– sin conocerla y haberla experimentado en carne propia: i.e. haber hecho programas que exploren la mayoría de posibilidades. No es sólo que un método iterativo e incremental sea lo recomendable, no queda remedio.
El que afirme lo contrario miente como un bellaco, no lo ha intentado nunca, es un genio, o yo soy un subnormal 😉
Seguramente en tres o cinco años, cuando haya libros de texto –que no pequeños trucos, howtos o apuntes– sobre el tema ya no hará falta la experiencia en primera persona, pero espero que dentro de tres años estemos programando en arquitecturas más flexibles que el Google App o Amazon EC2+SimpleDB.
Además hoy mismo además experimenté en carne propia la ventaja que los métodos HTTP del REST, sobre todo GET, sean idempotentes. Lo intuyes, pero hasta que no te das con un martillo en los dientes no estás del todo convencido. Me duele toda la boca 😉
Moo
Como no teníamos ni tarjetas para dar –el año pasado hacíamos el ridículo escribiendo teléfonos y direcciones en servilletas– a Benjamí se le ocurrió reunir en una cuenta de Flickr a las fotos que pudimos rescatar de eventos y gentes relacioandos con Menéame y luego encargar las tarjetas a Moo. Quedaron muy chulas, además alegra ver a los amigos en el revés de las tarjetas. Estas son algunas de las que pude poner sobre un folio para sacar la foto:
No he visto nada de la TechTalk en el blog de Varsavsky, ¿este año es por invitación?
La verdad es que te entiendo, yo al final tendré que desarrollar en EC2 (por motivos de trabajo). y cuando me topé con que no hay bases de datos relacionales, pues me pasó como a ti, de todos modos, tenemos intención de probar con varias AMI, a ver que pasa (yo solo llevo 2 días trasteando), Asi que, cuando Google quiera/pueda darme mi espacio en App Engine, podré hacer un analisis de ambas plataformas. EC2, está claro que voy a tener que estudiarmelo y pegarme mucho con el, veremos el tiempo que me queda para App Engine. y para escribir algo al respecto 🙂
Recomiendas empezar primero con django para luego pasarse a google app engine? O aprender solo python e ir directamente a goole app engine?
#3 guillem, si vas a hacerlo en app engine, hazolo directamente. Conceptualmente es algo más sencillo que Django y sólo es completamente compatible –hasta donde he probado, incluso con los filtros como «variable | escape»– en el template, y la misma idea en el modelo de datos, luego varía bastante.
Básicamente la única diferencia en la arquitectura de Django (o Google App engine) y la de Rails es que el primero se acerca más a lo que es MTV y el segundo a MVC. Aunque estríctamente ninguno es un MVC clásico, puesto que usan más de un controlador.
En otro orden de cosas, entre Google App engine y EC2+S3+SimpleDB, me quedo con el segundo, pues te permite muchísimas más opciones además de que no se limita sólo a aplicaciones web básicas. Si necesitas persistencia siempre puedes hacer un volcado a S3 a intervalos determinados o incluso usar FUSE (sí, ya sé, el rendimiento no será óptimo). Aunque muchas veces se haya intentado implementar sitios web con la arquitectura típica de servidor web que hace peticiones a servidor de base de datos, hay ocasiones que lo que realmente se necesita es otro tipo de arquitectura. Tómese como ejemplo el de Twitter, que a primera vista uno pueda pensar que con varios servidores de base de datos y otros tantos web ya se soluciona el problema, sin embargo es más una aplicación de mensajería que otra cosa… y por eso han tenido que reescribir código fuera de lo que proporciona Rails, puesto que es un framework para desarrollo de «servidor web que ataca a servidor de base de datos».
¡Ave maria purísima!…
Y yo con estos pelos…;)
No te molestes; es una broma, a veces te leo, pero para alguien que simplemente hace un blog como buenamente puede, este lenguaje es como que me hablan en otro idioma…
#3, #4: Diox! Otro Guillem! Ya la hemos liado. Sabia que algún dia pasaria X’-D
No llegue a tiempo para probar Google App Engine pero de entrada prefiero EC2 por la utilización de web services para el control y manejo de la solución.
Marcos, enterpriseDb te ofrece la posibilidad de utilizar MySql y/o PostGre sobre Amazon, no sé te sirve esta solución. Por otro lado en breve podrás utilizar Bungee labs para desarrollar y desplegar aplicaciones.
Un saludo
«experimenté en carne propia la ventaja DE que…», experimentaste la ventaja DE algo. El dequeísmo es más feo, pero el queísmo también existe.
A mí por fin me ha llegado la invitación de Google App engine, pero todavía no sé python más allá de haber leído un par de tutoriales de media hora.
Ricardo, tú que seguramente has estudiado el tema de los costes monetarios de usar google app engine… sé que es gratuito hasta un cierto nivel, pero ¿cuánto cuesta si lo sobrepasas, por ejemplo en comparación con el uso de un servidor dedicado o de un cluster de servidores? ¿Es mucho más barato o solo te libras de lidiar con los problemas de escalabilidad, pero no del coste?
Es que para un aficionado, que un proyecto que en principio no va a tener ninguna fuente de financiación tuviera éxito y tener que pagar X00 euros al mes sería toda una tragedia.
Disclaimer: no soy informático, soy de otra ingeniería, la informática es solo una afición pero si hay alguien (si fuera de Valencia, muchísimo mejor, para poder vernos) interesado en portar una aplicación en php y mysql bastante sencilla (pero con potencial) que estoy haciendo al google appengine, este es mi email: hommerhauer@gmail.com. La base de datos tiene muchas tablas, y podría tener problemas de escalabilidad si tiene éxito (como cualquier proyecto de internet, supongo) aunque los datos no son muy voluminosos.
Ricardo, no me queda claro si uno usa el google app engine los usuarios deben registrarse con una cuenta google?
Eso se puede cambiar, supongo.
Ricardo (o quien quiera),
para alguien que quiere crear su proyecto en Google App Engine pero no conoce Python (todavía), ¿qué PASOS le recomendarías (además del «Getting started» de Google)? ¿Algún tutorial o libro de Python «a secas» para ir aprendiendo el lenguaje? ¿Conoces algo más orientado al Google App Engine?
Si alguien tiene curiosidad, el proyecto que tengo en mente se llama TALAIOT:
http://jordisan.net/modules/wordpress/2008/una-idea-para-un-proyecto-1-talaiot/
Gracias (ah, yo también me apuntaría a probar ese PanelR nuevo si hay posibilidad)
Jordina, sin duda alguna hazte el tutorial «Dive into Python»
¡Oído, cocina!
(sabía que haciéndote pasar por chica te ayudaban más, pero no sabía que también te podían «femeinizar» el nombre al mismo tiempo que te ayudan) 😉