Hace un par de días publiqué la noticia de que Google había lanzado una nueva y revolucionaria tecnología llamada Google App Engine, y les prometí darle seguimiento con un artículo futuro, el cual están leyendo ahora mismo.

Noten que antes de continuar, recomiendo que se lean el artículo citado en el párrafo anterior.

Brevemente, el Google App Engine es una tecnología que permite de manera bien sencilla la creación de aplicaciones altamente distribuidas y paralelizadas que toman ventaja de la mismísima infraestructura en donde funcionan las aplicaciones de Google.

Examinemos ahora con un poco más de profundidad que compone al Google App Engine, y qué es exactamente lo que le ofrece al arquitecto o programador de aplicaciones.

Para empezar, el Google App Engine consiste de un SDK de tan solo 2.4MB, que contiene un runtime para el lenguaje Python, un servidor web integrado para servir las aplicaciones, y una implementación local que da la impresión de uno tener acceso directo a BigTable o hasta GFS. Es decir, un entorno completo de desarrollo local.

Este entorno no es un entorno visual, sino que es un conjunto de herramientas de linea de comando que se integran con cualquier editor de código que tengas (en la presentación que dieron por ejemplo, el ingeniero utilizaba TextMate en una Mac con OS X). Esto permite que el SDK pueda funcionar no solo en Windows, Linux o OS X, sino que en cualquier plataforma para donde exista un interpretador de Python, lo que significa desde Java, hasta Windows Mobile o hasta la Commodore Amiga.

Noten que aunque Python es el primer lenguaje de programación soportado, que la infraestructura del Google App Engine es totalmente agnóstica al lenguaje de programación, ya que todo es hecho a través de APIs bien definidos que pueden ser accedidos desde cualquier lenguaje. En estos momentos Google le está preguntando a la comunidad que le sugiera cuáles deberían ser los próximos lenguajes a soportar.

En mi opinión sin embargo, no tardará en que surjan herramientas que permitan que uno desarrolle completamente dentro de una página web, para de esa manera uno tener el entorno de desarrollo de uno en cualquier lugar del mundo con solo acceder a una página (a ver si uno de los lectores de eliax se anima a hacer esto, la verdad que es relativamente fácil tomando el SDK como base).

Entonces, cuando descargas el SDK, escribes tu aplicación en Python (y a propósito, incluyen unos excelentes frameworks para hacer templates (plantillas) que permiten diseñar la lógica independiente de la parte visual de la aplicación), lo próximo es probarla. Para esto utilizas el mismo SDK que actúa como un Google App Engine local en tu máquina.

Después que depuras tu aplicación, escribes un comando y esta se sube al Internet y empieza a funcionar dentro del Google App Engine real, tomando ventaja de toda la infraestructura de Google para escalar automáticamente dependiendo de la carga de usuarios en determinado momento.

Algo curioso es que el Google App Engine no te da acceso a escritura directa a GFS, por la sencilla razón de que tu aplicación está verdaderamente distribuida entre los cientos de miles de servidores de Google, por lo que ni Google mismo sabe en dónde está tu aplicación en determinado momento dentro de GFS. Esto es en realidad buena práctica, pues te obliga a almacenar cosas con BigTable.

Hablando de BigTable, este es posible que sea el cambio más radical de Google App Engine en relación a otras tecnologías antes que ella, pues deshace por completo el concepto de Base de Datos Relacional, eligiendo en vez de eso un modelo que escala independientemente del esquema de la base. Se podría decir que BigTable es más una base de datos orientada a objetos que relacional, pero tampoco es eso.

Con BigTable, por ejemplo, no existe el concepto de unir tablas con JOINs. Sí, oyeron bien, no existen JOINs en el Google App Engine. Uno diría pero cómo puede ser eso, pero lo cierto es que tiene mucho sentido romper con las relaciones entre tablas para escalar un sistema.

En el momento que uno crea relaciones directamente en una base de datos, en ese momento uno está poniendo un límite a la escalabilidad a esta. Para los veteranos, piensen que lo que Google hace es poner no solo cada tabla en un servidor diferente, sino que cada fila y hasta cada columna. Es mas, no existen conceptos de tablas, filas o columnas, sino que más bien objetos que toman pares de Nombre y Valor.

A bajo nivel sin embargo, hasta los mismos valores pueden estar (y lo están siempre) en más de una máquina a la vez, gracias a GFS, quien por motivos de eficiencia (romper paquetes de datos grandes en muchos pequeños), redundancia y escalabilidad los distribuye a través de todos los servidores de Google en el mundo.

Sin embargo, Google sabe que esto es algo tan radical para uno adaptarse, que aunque sea mejor que tablas relacionales para escalar, que debía hacer algo para allanar la ruta de aprendizaje, y para tal fin Google creó a GQL.

GQL, que aunque no es definido en la literatura de Google podemos asumir significa Google Query Languaje, es un substituto de SQL (Structured Query Language), que aunque no ofrece toda la sintaxis de SQL, sí ofrece buena parte de su poder, y hace que obtener objetos almacenados en BigTable sea relativamente fácil de entender.

El otro componente del Google App Engine es uno al que se accede por una página web en Google, en donde puedes administrar tus proyectos y aplicaciones. Con esta herramienta web, es posible manejar todas las versiones de tu aplicación, que son alojadas en Google, para de esa manera poder volver en cualquier momento a versiones previas de tu código. Esta herramienta además te sirve para compartir tu código con otros desarrolladores, para que entre todos trabajen de manera distribuida por Internet.

Sin embargo, una de las cosas más útiles es el poder monitorear en tiempo real tus aplicaciones, sabiendo exáctamente como se comportan según la carga que le ponen los usuarios finales. Esto por sí solo es una herramienta invaluable para cualquier desarrollador de software, y más cuando uno se da cuenta que el grado de granularidad que el Google App Engine le da a uno es inmenso, pues uno puede ver hasta cómo reacciona un determinado URL de tu aplicación a la carga, para así uno poder optimizar mejor.

Como pueden empezar a ver, el objetivo de Google con el Google App Engine no fue solo uno, sino que varios, específicamente:

- Hacer fácil programar aplicaciones ultra-escalables.
- Utilizar su misma infraestructura para tales aplicaciones.
- Ofrecer un sistema integrado que haga todo lo que necesita todo programador, es decir, desde un SDK para crear y simular las aplicaciones, hasta ofrecer alojamiento, control de versiones, monitoreo y optimización.

Después que uno hace la digestión de todo esto, es entonces cuando uno se da cuenta de muchas otras cosas mas, como es el hecho de que esto hace absolutamente obsoleto el ritual de uno tener que durar un par de días configurando una PC o servidor para que su sistema operativo (sea Linux, Windows o OS X), su web server (sea Apache o IIS), su base de datos (sea MySQL, Postgress o MS SQL Server), y su plataforma de aplicaciones (sea PHP, JSP, ColdFusion, ASP o Ruby on Rails) funcione perfectamente. Y esto sin tomar en cuenta los costos de tales equipos, software, conexión a Internet, ingenieros que mantengan todo en orden, etc.

No solo eso, sino que el simple hecho de la existencia de cosas como Linux, Windows, Apache, PHP, MySQL, Subversion, etc, es irrelevante porque el Google App Engine no es que simplemente las haga obsoletas, sino que irrelevantes pues no son necesarias.

A los que leyeron hasta aquí y entendieron bien estos últimos dos párrafos, espero que estén entendiendo el impacto, potencial y revolución que representa el Google App Engine para todo el mundo de la informática.

Y aquí viene lo mejor: Google está haciendo todo esto disponible de manera totalmente gratuita.

Según Google, de manera gratuita obtendrás para cada aplicación (y puedes crear todas las aplicaciones que desees cuando esto salga al aire) 500MB de almacenamiento, 10GB de ancho de banda por día, y 200 millones de megaciclos de CPU diarios, lo que según Google es equivalente a groso modo a una aplicación que genere unas 5 millones de páginas web accedidas mensualmente.

Aparte de eso, aun alojes las aplicaciones con Google, Google te cede todos los derechos para que tu mantengas propiedad y derechos reservados a tu aplicación. Nota además que Google te provee un subdominio para tus aplicaciones, pero incluye soporte nativo para ligar tu propio domino en Internet con las aplicaciones alojadas en el Google App Engine de manera totalmente transparente.

¿Qué obtiene Google de esto? Pues mucho.

Para empezar, puede establecer el estándar por defecto de aplicaciones por Internet, lo que le da mucho con que jugar en el futuro. Además, las aplicaciones que sobrepasen su límite tendrán que pagar (si lo desean) por la cantidad adicional de recursos que utilicen, y dado el tipo de aplicaciones que uno puede ejecutar en este entorno del Google App Engine, pueden estar seguros que veremos todo tipo de aplicaciones asombrosas que comerán ancho de banda, espacio en disco y ciclos de CPU como para hacer que Google tenga que crear un banco para poder guardar todo ese dinero.

Pero no crean que esto es beneficio solo para Google, pues si tú mismo logras crear una aplicación que tenga tanta demanda, es casi seguro que has creado una mina de oro y si juegas tus cartas bien le sacarás más dinero a esto que el mismo Google te sacará a ti.

Pero eso no es nada. Estas mega-aplicaciones que sin duda surgirán es casi seguro que recurrirán al modelo de anuncios para incrementar sus ingresos, ¿y adivinen quién proveerán ese servicio? Lo más seguro que sea Google AdSense que presentará todo bien integrado con el Google App Engine en su momento oportuno.

Sin embargo, esto regresa otra vez a ti, pues mientras más anuncios y clics genere tu aplicación, más dinero para Google, pero más dinero para ti también. En otras palabras, Google está no solo creando una revolucionaria plataforma tecnológica, sino que además una simbiosis de negocio con los que la utilicen, para que todo el mundo se beneficie.

Ahora, ¿cuáles son las cosas que hay que pensar bien antes de adoptar al Google App Engine? Pues para empezar, todos los que la utilicen necesitan una cuenta con Google (no gran sorpresa ahí), aunque viendo la otra cara de la moneda está el hecho de que Google maneja por ti todo lo que es el login, seguridad y manejo de identidad en tus aplicaciones, de manera automatizada.

Por otro lado está la gran pregunta: ¿De verdad será tan fácil programar para el Google App Engine, lo suficiente como para que veamos un éxodo de programadores migrar de otros entornos hacia esta nueva plataforma? Sin programadores no hay aplicaciones, y sin aplicaciones no hay negocio, por lo que todo el peso de esta gran aventura de Google descansa sobre la idea de asumir que las herramientas, y la nueva manera de pensar a la hora de crear aplicaciones, serán asimiladas por los desarrolladores de todo el mundo, y esto está por verse (aunque si tuviera que predecir, diría que no habrá falta de programadores para el Google App Engine).

Otra cosa es, que uno obviamente estará dependiendo de Google toda la vida para alojar nuestras aplicaciones, siendo la única opción que tenemos el ejecutar la aplicación localmente en un entorno Python, aunque con mucho menos escalabilidad.

Este tema de la dependencia de Google me hace ponderar la posibilidad de que en un futuro Google abra y libere la especificación técnica del Google App Engine para que terceros como GoDaddy (actualmente la empresa de alojamiento de páginas web y aplicaciones web más grande del mundo, y una empresa que sin duda sufrirá desde que todo el mundo descubra que también puede alojar simples websites estáticos en el Google App Engine, gratuitamente) puedan ofrecer el servicio de Google App Engine en sus propios servidores. Sin embargo, no cuenten con eso, al menos no al corto plazo.

¿Y cuáles serían los efectos del Google App Engine en el resto de la industria?

Primeramente y como mencioné anteriormente, esto hace irrelevante y obsoleto muchísimos tipos de tecnologías actuales como son servidores de aplicaciones, bases de datos, sistemas de versiones de código fuente, y en cierta medida hasta sistemas operativos que sirvan aplicaciones.

El Google App Engine es en mi opinión el concepto que debió tomar Microsoft para su próxima versión de Windows hace varios años atrás, un entorno para aplicaciones totalmente basado en Internet y con soporte para ejecutar localmente de ser necesario. Se podría decir que así como Microsoft popularizó el desarrollo de aplicaciones de escritorio, y por tanto Windows, con la creación de Visual Basic y su facilidad de uso, así mismo Google piensa popularizar la creación de aplicaciones en Internet, en su plataforma Google App Engine, con herramientas igual de sencillas que Visual Basic.

Esta tecnología del Google App Engine es además en lo que Sun Microsystems hace 10 años atrás debió evolucionar su concepto de Jini y JavaSpaces, que hasta la fecha sigue siendo una de las tecnologías más sorprendentes (y simples) de todos los tiempos, pero que nunca generó tracción debido a un mal enfoque en aplicaciones de escritorio en vez de aplicaciones puramente distribuidas.

Es también en lo que debió haberse convertido Yahoo Pipes, del cual no he oído mucho últimamente. Es además algo que debieron haber pensado empresas como SAP, Oracle o Apple.

Sin embargo, solo fue necesario los cerebros de Google para sacar esto al mercado, y es la razón por la cual en mis predicciones de estos últimos dos años Google continúa siendo (junto con Apple) la empresa más innovadora del momento.

Palabras adicionales para los más técnicos: Los más veteranos en este campo de aplicaciones distribuidas es posible que mencionen a Amazon Elastic Compute Cloud (Amazon EC2) con el Amazon Simple Storage Service (Amazon S3) y SimpleDB, como algo similar al Google App Engine, pero la realidad es que son dos cosas absolutamente diferentes.

Lo que Amazon EC2 ofrece es una manera de virtualizar tus servidores alojados en Amazon. Es decir, te ofrecen tantos servidores Linux pre-configurados como tu desees pagar, de manera virtual, con muchas características interesantes como fail-over, redundancia y cosas por el estilo, pero al final del día lo que obtienes es un servidor con Linux, para el cual creas una aplicación tradicional con las herramientas tradicionales, y es 100% tu responsabilidad y labor el diseñar la aplicación de tal manera que escale a la demanda que se le imponga.

En cuanto al Amazon S3 y SimpleDB, son los servicios que más se parecen a BigTable, pero tienen que ser gestionados directamente y explícitamente por ti a través de tecnologías de Servicios Web (XML, WSDL, etc).

Además, Amazon te cobra por el más mínimo uso que le des a estos servicios.

Previamente en eliax: Google lanza revolucionario "Google App Engine" (con varios enlaces a recursos de interés para técnicos)

Los curiosos es posible que quieran leer mis predicciones #23 y 24 para este año en este enlace.

A los que le interesen este tipo de análisis, en este enlace pueden leer todos los análisis publicados anteriormente en eliax.

autor: josé elías