Lo que le falta a la grid scene para triunfar (I)
El grid hace ya poco más de diez años que existe. Al menos por lo que indican las referencias en los artículos técnicos, ya que hay referencias anteriores en el tiempo a conceptos muy similares. Diez años podría no parecer mucho, pero cuando hablamos de tecnologías de la información es un mundo. En este tiempo mucho es lo que se ha diseñado e implementado para dar soporte a la idea de unificar los recursos de una organización para aumentar su productividad. Sin embargo, esta idea, tan brillante sobre el papel, no ha acabado de despegar. ¿Por qué?
La razón principal reside en que no existe aún una herramienta definitiva y consolidada que aproveche el potencial del grid. Hay productos muy interesantes, como el GridServer de DataSynapse, pero no podemos afirmar todavía que tenga una amplia difusión. Esta escasez dificulta la popularidad de cara al target realmente importante, el de los usuarios finales, sepan de informática o no, que se pueden llegar a plantear la necesidad de tener un grid para su empresa. Ni siquiera el software para grid más extendido, Globus, está a la altura para convencer a este tipo de usuario. Globus no deja de ser un middleware, es decir, una aplicación que corre en una máquina para ofrecer sus recursos al exterior, y eso sólo si se trata de un ordenador con Unix.
Lo que realmente hace falta es un software que, aparte de exponer los recursos de cada ordenador, abstraiga la visibilidad de los mismos y permita al desarrollador trabajar con el grid como si fuera un único ordenador. Es decir, el grid tiene que dejar de ser, simplemente, una red en la que cada ordenador comparte sus recursos. En ese sentido, podríamos olvidarnos del grid y pensar en p2p. Hay que cambiar el chip: el grid ha de ser un supercomputador que tenga, como mínimo, la potencia agregada de los recursos de todas las máquinas que lo componen.
Yo tambien escribo 
Totalmente de acuerdo.
Mi matiz es, lo que hace falta es un lenguaje de programación y/o compilador en el que, programando como toda la vida, automáticamente se generen ejecutables / fragmentos de código que automáticamente sean distribuidos por todos los ordenadores que forman el grid (asi como los algoritmos sean partidos de forma optima o casi-optima).
Opción 1: abogo por un lenguaje como C++ que todo el mundo conoce (pero sin tener que usar ninguna libreria extra ni nada)
Opción 2: usar algún tipo de framework parecido a .NET en el siguiente sentido. Se compila el código a un lenguaje intermedio y, dependiendo de la arquitectura del grid, se recompila a nativo, optimizado para la propia arquitectura del grid, partiendo los algoritmos, etc… (asi que en runtime se redistribuye código para igualar la carga del sistema global, etc…).
Opción 3: Proporcionar librerias muy potentes y faciles de usar que hagan muy facil programar para grid.
Seguramente estas cosas ya existan de una u otra forma, así que probablemente lo que haga falta es disponer de algún tipo de plataforma grid pública y enseñar a la gente a usarla y conocer sus beneficios reales.
Conclusión: Yo voto por que el programador no tenga que pensar en cómo defragmentar sus algoritmos y/o distribuirlos entre las máquinas del grid y que éste disponga de una forma muy fácil de realizar sus tests y probar los programas antes de lanzarlos al entorno real.
PD: Mi conocimiento real del grid es 0, pero no por ello voy a dejar de opinar, que opinando y viendo las respuestas también se aprende 😉
amnio - julio 16, 2006 a las 11:27 am |
Amnio, vas por muy buen camino 😉
Diego Mariño - julio 18, 2006 a las 3:58 pm |