Esto básicamente es la Cloud Computing. Se basa en ofrecer ciclos de computación y almacenamiento como un servicio medible y facturable, de forma similar a la electricidad, el agua, o la telefonía. Esto permite a los sistemas adquirir o liberar recursos, bien más ciclos de reloj o almacenamiento, dinámicamente conforme sean necesarios.

Ambas compañías ofrecen a los desarrolladores de aplicaciones la posibilidad de ejecutar aplicaciones sobre entornos teóricamente más estables y seguros, y que permiten una gran escalabilidad. Esto es un punto a favor importante de ambas propuestas, ya que ofrece a los desarrolladores la opción de olvidarse en parte de los problemas de las plataformas y tener garantizada la escalabilidad de las soluciones.

Pero aquí se acaban las similitudes, por lo demás ambas soluciones son muy distintas. Por un lado Amazon ofrece un conjunto de soluciones tecnológicas que abarca un abanico más amplio que el de Google, aunque todas ellas de pago. Estas aplicaciones van desde el almacenamiento ofrecido por S3, la gestión de colas de mensajes de SQS, el almacenamiento de datos con SimpleDB y los servicios de computación propiamente dichos con Elastic Computing Cloud (EC2), con los que podemos crear máquinas virtuales. Por otra parte Google ofrece un espacio en el que publicar aplicaciones que se ejecutaran dentro de su plataforma y que deberán utilizar una API específica, así como sus sistemas se autenticación, su modelo de almacenamiento de datos basado en BigTable, y Python como lenguaje de programación.

Si como a mi te basta con la curiosidad de saber cómo funciona, a buen seguro tendrás curiosidad también por cómo hace Google para trabajar con cantidades tan ingentes de información y dar los resultados tan buenos que da, tanto en calidad como en tiempos de respuesta.

El documento incluye referencias a las principales técnicas, como Cross Site Scripting (XSS), Inyecciones SQL, Malicious File Execution(RFI) o Cross Site Request Forgery (CSRF), por poner unos ejemplos. En el documento se explica cada una de estas vulnerabilidades mostrando también la forma en la que se pueden evitar, por lo que su lectura es más que recomendable para toda persona implicada en el desarrollo de aplicaciones web.

En este artículo Theo explica algunas nociones básicas sobre los entornos de alta disponibilidad (HA - High Availability) y el balanceo de carga (LB - Load Balancing) y presenta una arquitectura basada en software libre que permite obtener estas características.

El artículo comienza mostrando las aproximaciones más frecuentes, basadas en la utilización de múltiples servidores formando un cluster para ofrecer la alta disponibilidad y de dispositivos intermedios (balanceadores) para realizar el balanceo entre los equipos del cluster. A partir de esto Theo muestra algunos de sus principales inconvenientes, relacionados principalmente con la utilización de dispositivos extra como los balanceadores, y presenta una arquitectura construida sobre software libre, utilizando Wackamole para ofrecer la alta disponibilidad, y el módulo de Apache mod_backhand, del cual es desarrollador el propio Theo, para la realización del balanceo de carga entre los servidores web del cluster.

El artículo ofrece buenas explicaciones de los conceptos implicados y muestra como no siempre es necesario disponer de hardware complementario extra para obtener HA/LB, que por otra parte suele ser bastante caro. El artículo aporta también una explicación interesante sobre las diferencias en cuanto al balanceo de carga que hace un típico balanceador, qué normalmente únicamente reparte las peticiones entre los equipos del cluster, y un balanceo de carga real, que realmente es un problema de asignación de recursos en función de un conjunto de equipos y su estado. Por último muestra también una explicación de cómo afecta la directiva de configuración de Apache keep-alives al rendimiento, algo que es interesante saber de cara a poder ofrecer el máximo rendimiento y disponibilidad.

Por lo que he leido hasta ahora sobre este método en Internet, la verdad es que tiene bastante buena pinta y parece bastante lógico. Bastantes veces me ha pasado tener tal cantidad de tareas abiertas a la vez que se hace imprescindible imponer algún mecanismo que permita ordenarlas y no olvidar nada. Siempre he utilizado métodos más o menos ad-hoc, como listas de tareas, outlook, la agenda de la PDA, mensajes de correo en GMail, etc. El problema es que siempre me he planteado estos métodos cuando me han hecho falta, por lo que no he tenido tiempo de perfilarlos y definirlos con cierto rigor. GTD ofrece un método que permite representar y gestionar todas las tareas diarias de forma que puedas llegar a todas, de hecho, en algún sitio he leido a GTD como la forma de conseguir días de 36 horas, posiblemente algo excesivo, pero un buen ejemplo de lo que pretende.

El método por si mismo ofrece únicamente unas directrices sobre cómo organizar tus tareas, pero no dice nada sobre como llevar esta gestión, por lo que puede hacerse en papel, con los famosos cuadernos Moleskine por ejemplo, o con herramientas ofimáticas como la agenda de la PDA, el Outlook, o aplicaciones específicas como ThinkingRock.

También existen herramientas online que pueden utilizarse para aplicar el método, como las herramientas gratuitas de Google Google Notebook, Google Calendar y Google Mail.

Pero de todas estas opciones, las que más me ha gustado es una aplicación online llamada Remember the Milk. La aplicación es una herramienta de gestión de tareas online que puede utilizarse también para aplicar GTD. Los motivos que la han hecho mi favorita han sido varios, como su gratuidad, su sencillez de uso, y fundamentalmente, la posibilidad de trabajar en desconectado.

Gracias a esta característica es posible incluir o modificar tareas estando desconectados, por ejemplo desde el portátil cuando no tenemos cobertura wifi, y sincronizar la información al conectarnos. Esto es posible gracias a la utilización de Google Gears, un software disponible para Windows, Linux y Mac, que una vez instalado permite, entre otras cosas, que aplicaciones web convenientemente desarrolladas aprovechen sus características para funcionar desconectadas y sincronizarse en la conexión.

Como en todo, no hay solución mágica que sirva para todos los casos y será determinante nuestra experiencia para estudiar las necesidades de cada caso concreto, y sopesar las diferentes opciones, sus características, riesgos y costes.

Una buena fuente de información para poder valorar todas estas alternativas es saber cómo lo hacen los grandes, como Amazon, Google, etc. Posiblemente la mayoría de nosotros no participe en la definición de una arquitectura similar, pero sus soluciones sí que pueden ser extrapolables, aunque sea a menor escala, a otros problemas de nuestro entorno. En High Scalability tienen información detallada sobre la arquitectura y las soluciones adoptadas en una buena parte de los proyectos más grandes de internet, como Amazon, Google, Flickr, Digg, etc.