Crear una comunidad de desarrolladores alrededor de tu producto es una tarea complicada. Pero necesaria para cualquier organización que desee que sus productos de código abierto alcancen el máximo de distribución. Los desarrolladores alrededor de tu producto y los desarrolladores del producto se retroalimentan en un círculo virtuoso que hace que el producto sea cada vez mejor, y por lo tanto se adopte con más intensidad. Este ciclo virtuoso tiene una velocidad inicial reducida, que aumenta conforme pasa el tiempo. Hay diversas maneras de aumentar la velocidad y conseguir la inercia necesaria para crecer, y el medio más directo es el incentivo económico a la comunidad de desarrolladores.

Abiquo es una startup de Barcelona dedicada al Grid y al Cloud Computing. Tienen diversas herramientas de código abierto que permiten desplegar Clouds, Calculo intensivo y almacenamiento masivo distribuido. Hoy su CEO Diego Mariño anunciaba en su blog que ofrecerá hasta 3000€ a aquellos desarrolladores que:

Adapten o desarrollen una aplicación o servicio sobre nuestra plataforma

El código resultante sea ofrecido bajo una licencia aprobada por la OSI (no esperamos ganar un duro revendiendo esto, simplemente poder utilizarlos como ejemplos sin restricciones)

Ofrezcan una completa documentación (en inglés como mínimo) tanto para usuario como para desarrollador

Y las razones que esgrime para esto son las siguientes:

Hace un mes que empezamos a liberar y estamos intentando generar una comunidad. Para ello, no sólo hemos de poner la infraestructura que lo permita, sino que además hemos de ofrecer otras muchas cosas. Entre ellas, ejemplos que demuestren que nuestra infraestructura funciona y sean útiles a otros para aprender.

En abiquo vamos saturados, por lo que he de contratar estos desarrollos en el exterior.

Además, los desarrollos más brillantes recibirán una oferta de trabajo. Esta iniciativa me parece novedosa en España, y espero que tenga una buena acogida. Aunque creo que un producto como el de Abiquo su límite no lo deberían marcar las fronteras, y deberían ofrecer este incentivo de forma global. Si 3000€ es un pellizco en España, supongo que será todavía más atractivo en China, Filipinas o India, por poner un ejemplo de granero de desarrolladores.

Actualización: Según indica en el blog corporativo, la oferta se ha abierto a cualquier desarrollador en cualquier parte del mundo.

Hace unos días en la lista de correo de cloud-computing alguien preguntaba sobre experiencias con MATLAB en La Nube. Cualquier que visite la lista verá que MATLAB soporta soluciones variopintas, con implementaciones de todos los colores en Grid.

Hoy leo que la misma persona que inició la conversación anunciaba que Mathworks había liberado un white paper explicando cómo usar MATLAB con Amazon Elastic Compute Cloud (EC2). El documento te lo puedes bajar aquí.

El documento explica cómo configurar las AMIs, además de explicar los pros y contras de la solución sobre EC2:

• Coste: pagas por lo que usas.
• Puesta en marcha: muy rápida, entre 6 y 8 horas de un administrador de sistemas sin experiencia con EC2
• Licencias: Ojo, necesitas una licencia por cada ‘Worker’ del pool.
• QoS: Es una cuestión importante ya que funciona sobre internet (obvio…)
• Rendimiento: La virtualización puede afectar a la entrada y salida, pero el verdadero problema es la latencia de red y el ancho de banda entre el entorno de escritorio y La Nube.
• Seguridad: Es necesario crear una VPN entre los ‘Workers’ y el entorno de escritorio.

¿Alguien lo ha probado?

No todo el Cloud Computing va a ser Amazon Web Services. Existen otras propuestas interesantes, y creo GoGrid es una de las que parece más profesional. Por poner un ejemplo, ofrecen balanceadores F5 dentro de su infraestructura, lo que en mi opinión es fundamental para poner en marcha tolerante a fallos. También el servicio de monitorización y soporte 24×7 es algo fundamental a la hora de establecer los niveles de servicio. 

Y dentro del mundo de las empresas de software que desarrollan software de infraestructura para el Cloud Computing uno de mis favoritos es GigaSpaces. Su producto eXtreme Application Platform (XAP) es una de las soluciones de Grid Computing para empresas que más implantación tiene. Simplificando su propuesta, ellos plantean que el modelo de separación de capas clásico propuesto en arquitecturas empresariales de presentación-negocio-datos no es válido si quieres implementar soluciones de alto rendimiento y altamente escalables. Ellos plantean otra arquitectura en la que cada nodo es autocontenido y por lo tanto escalar es sencillo ya que simplemente hay que añadir más nodos. Resumiendo, computación distribuida y Grid de datos de nivel empresarial. Por cierto que se basa en un standar Java muy olvidado como es JavaSpaces.

En esta nota de prensa anuncian que han unido sus fuerzas para ofrecer el ‘Santo Grial de las TI’: Si hay un pico de demanda importante, la combinación de ambas propuestas te permitirá soportarlo. Se me ocurren varios casos en los que puede ser interesante el uso de este tipo de soluciones elásticas, pero por ejemplo aquellos que necesiten realizar operaciones de liquidación y conciliación al cierre de un mercado o en fechas muy señaladas y con slots de tiempo muy reducidos que pueden beneficiarse de este tipo de soluciones. Tu sistema funciona unas pocas horas pero necesitas muchos ciclos de CPU para hacerlo. Si el mercado ha estado loco ese día y hay mucho volumen, pues más nodos del Cloud, que es Agosto y no hay moviento, pues solo contratas lo imprescindible.

¿Qué se os ocurre a vosotros?

Supongo que si estás leyendo este blog probablemente hayas recibido multitud de información sobre el proyecto Worldwide LHC Computing Grid (LCG). Si aún no te has enterado de lo que es, es la infraestructura de análisis y almacenamiento de los datos que toda la comunidad de Física de Alta Energía que use el LHC (El Gran Colisionador de Hadrones) va a utilizar.

El LCG fue diseñado para soportar la inmensa cantidad de datos que los experimentos generarán. Se habla de unos 15 petabytes accesibles a miles de científicos en todo el mundo. Cuando se empezó a gestar el proyecto del LHC, ya se vio que era inviable crear un gran supercentro de cálculo que centralizase el almacenamiento y el procesado de los datos. Inviable económicamente, quiero decir. Así que se pensó en algo que aprovechase la capacidad de almacenamiento y de procesado al que sí tenían acceso los centros de investigación locales de cada pais. La arquitectura está distribuida en 3 capas de procesado de la siguiente manera:

• Tier-0: Es el CERN Computing Centre. Todos los datos pasan por aquí, pero la capacidad de procesado es del 20% del total.
• Tier-1: En total siete centros de datos repartidos en varios países. Aproximadamente 30% de procesado.
• Tier-2: En total 140 sitios agrupados en 38 federaciones que proveerán del 50% de la capacidad e procesado.

Hace unos años tuve acceso a información de Oracle relativa al proyecto. Era realmente espectacular lo que estaban haciendo. He intentado encontrar esa información pero no la he podido localizar (sic), aunque probablemente fuese información sensible. El manejo de un conjunto de datos tan enorme alrededor de una arquitectura con Oracle 10g RAC era impresionante. Creo que es el único producto de código no-abierto de la arquitectura, lo cual dice mucho a favor de Oracle y su capacidad de cálculo. Por lo que me contaron MySQL también participaba de la arquitectura, pero no era el gestor que llevaba el peso del almacenamiento (bueno, lo contaban gente de Oracle, así que tampoco me fio mucho de lo que me contaron…).

He encontrado una bonita presentación sobre la arquitectura multicapa del LCG con Oracle, que aunque no es la que pude disfrutar, es interesante.