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

http://www.apache.org/licenses/LICENSE-2.

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:

  1. Tratamiento masivo de datos. Parcialmente ya se tiene con la base de datos casi ilimitada
  2. 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.
  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…: confirmado también.
  4. 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😉