Acabo de ponerme a leer la prensa matutina de la red y en ella destaco la noticia que recalca el periódico en portada: El ‘cerebro’ del metro crece para guiar trenes sin conductor de la L-9.

Parece ser que Barcelona empieza a asomar la patita por debajo la puerta en materia de nuevas tecnologías. Es curioso el titular porque si necesitan 2 plantas más para abastecer de inteligencia la nueva línea 9 no me imagino que pasará cuando ha alguien se le ocurra ampliar la infraestructura.

Me gustaría destacar que la noticia habla de la palabra "cerebro". Y no se… a mi me suena a sistema centralizado… Y no me gusta. No quiero hacer suposiciones sin conocer el detalle,  pero espero que a alguien se le haya ocurrido disponer de un soporte descentralizado, aunque solo sea como otra medida de protección en caso de emergencia, porque todos sabemos que si el cerebro falla…

Quien sabe, quizás les falto ThinkInGrid…

Ando unos días buscando información sobre el tema. El otro día me entró el gusanillo mientras pensábamos en nuevos recursos que añadir a nuestro catálogo de "plugins" para el middleware. Y es que, como ya sabéis (Y si no lo sabéis ahora es el momento), soy Ingeniero de Telecomunicaciones y de entre los temas que más me atrajo en mi dorada época estudiantil, las redes ópticas y las nuevas arquitecturas definidas sobre ellas.

Las redes ópticas actuales constan de un elevado número de capas que otorgan la capacidad de manejar perfiles determinados de información, lo que estaba tendiendo a redes demasiado específicas y difíciles de gestionar. Pero a algunos  iluminados se les encendió la bombilla y  pensaron que las redes debían simplicarse, evitando funcionalidades redundantes entre capas. Esto derivo hasta llegar a tener solo dos.  Esto ha permitido desarrollar un plano de control común, y entre algunos protocolos de gestión, se encuentra GMPLS.

GMPLS es el resultado del trabajo entre Optical Internetworking Forum, Optical Domain Service Interconnect consortium y la Internet Engineering Task Force que pretende estandarizar un protocolo que pueda servir para todo tipo de tráfico. La clave se encuentra (y aquí os empezará a sonar a Grid) en la capacidad que tiene la capa de control de extender la topología de la red y la gestión del ancho de banda a lo largo de todas las capas para lograr un sistema eficiente que integre servicios y transporte.

Siguiendo con la filosofía Grid, GMPLS necesita tres componentes básicos para su correcto uso:

1. Exploración de recursos: se obtiene información acerca de los recursos de red tales como conectividad o capacidad de los enlaces. Los mecanismos utilizados para diseminar esta información de estado se basan en una extensión del Internet Gateway Protocol (IGP).
2. Selección de ruta: se utiliza para seleccionar una ruta apropiada a través de la red óptica inteligente en base a unas ciertas restricciones impuestas por el entorno y las limitaciones de la capa física.
3. Gestión de ruta: incluye distribución de etiquetas, así como establecimiento, mantenimiento y terminación de ruta. Estas funciones se realizan por medio de un protocolo de señalización extendido como Resource Reservation Protocol for Traffic Engineering (RSVP-TE) o Constraint-routed Label Distribution Protocol (CR-LDP).

Estos tres componentes deben estar diseñados para su correcta utilización independiente entre si, permitiendo a las operadoras diseñar sus redes en consonancia con su modelo de negocio.

Aquí entra ThinkInGrid y nuestros componentes desarrollados. Queremos llegar a desarrollar un plugin capaz de virtualizar los datos provenientes de una red óptica. Esto debería permitir a empresas mucho más especializadas desarrollar productos o proyectos a medida para gestión de redes troncales:

• Uso de información descentralizada y distribuida por la red.
• Uso del plano de inteligencia artificial para optimizar y automatizar procesos de control y balanceo de carga.
• Monitorización de red añadiendo un plano de decisiones automatizadas.
• Desarrollo rápido y estandarizado de aplicaciones mediante el Framework.
• Creación de mecanismos de colaboración entre operadoras o empresas complementarias.
• Generación de nuevos modelos de negocio. Lo que permite una clara diversificación de servicios.

Bueno, creo que la cosa está clara. ¿Algún directivo de Telefónica, Wanadoo, Jazztel, Ono, etc en la sala y que quiera desarrollar la idea con nosotros? Las líneas de teléfono y de mail quedan abiertas :).

Entre línea y línea de código son comunes los brainstorming entre el grupo de trabajo con el humilde propósito de descargar nuestras apretadas mentes y porqué no, encontrar esa idea que nos expulse del anonimato.

Hoy le ha tocado el turno a las arquitecturas ad hoc. Para quien no sea entendido en el tema, os comentaré que estas infraestructuras pretenden inhibir el concepto de nodo central para tender a un entorno en el que todos los recursos estén en igualdad de condiciones, o lo que es lo mismo, los elementos en una red, comparten las funcionalidades de cliente/servidor por igual.

Actualmente, uno de los máximos exponentes que se ha popularizado gracias a la implantación en un sinfín de "gadgets" es el sistema Bluetooth, que ha facilitado la interconexión entre dispositivos sin necesidad de pasar por entornos centrales, lo que ha facilitado saturaciones, colapsos, mal humor, etc.

Pues si señores, en ThinkInGrid hemos, estamos y vamos a seguir pensando en el concepto mientras desarrollamos nuestro entorno MIDDLEWARE - FRAMEWORK con el objetivo de descentralizar al máximo las "Funciones Grid" y de esta forma aprovechar las ventajas que proporciona las redes Ad hoc tanto en protección contra errores, transmisión de información, etc.

Nuestro Middleware basándose en estos conceptos proporciona una arquitectura muy ligera a cualquier estructura de recursos heterogéneos (Ordenadores, SCADAs, PDAs, camiones, dispositivos domóticos, etc.), sobre cualquier tipo de comunicación: Wireless, bluetooth, satélite, Powerline Communications, etc.; y mostrándose dentro de la misma estructura de información para nuestro FRAMEWORK, lo que permitirá a nuestros clientes afrontar infinidad de problemas (proyectos) de origen variante en un entorno homogéneo de análisis y desarrollo.

Por otro lado el FRAMEWORK, entre otros, proporciona los protocolos de protección de errores, descubrimiento de recursos, seguridad y gestión de colas que todo sistema Ad Hoc necesita. Todo embalado en un elegante sistema orientado a servicios (SOA) y que ha de facilitar el desarrollo estructurado de cualquier entorno empresarial.

En resumen, veamos las ventajas que proporciona durante la fase de desarrollo de un proyecto:

• Reducción de tiempos de análisis. –> El desarrollo se define siempre para un mismo entorno.
• Generalización de problemas –> Para un programador, la forma de utilizar un recurso CPU será igual que para utilizar un recurso EMBOBINADORA .
• Fácil adaptabilidad de los equipos de desarrollo –> El desarrollo siempre se realiza sobre una misma plataforma
• Disminución de impactos –> Si el entorno es conocido, los riesgos son fácilmente cuantificables.
• Minimización de desviaciones. –> Si el entorno es conocido, las desviaciones son medibles.

En resumen, REDUCIMOS COSTES en los proyectos de desarrollo. Y aún nos falta por contabilizar el beneficio económico derivado de la propia aplicación o las ventajas técnicas que adquirirá el proyecto por el uso de nuestros entornos.

Nunca el pensar en entornos ad hoc fue tan fácil, con ThinkInGrid ese día ha llegado.

Estos días de meteorología variable en Barcelona desde el equipo de desarrollo de ThinkInGrid andamos ultimando la primera fase de nuestro entorno Grid. Como primer paso, a partir de ahora, eludiremos la palabra computing, en clara alusión a nuestra orientación a cliente y no a tecnología, tal y como se empieza a insinuar en los post de Albert y Diego.

Nuestro siguiente paso, utilizar dicho entorno para adaptar una aplicación ya existente a este nuevo modelo. Con esto, la búsqueda de varios objetivos:

• Testear la arquitectura desarrollada.
• Testeo integrado y funcional del entorno.
• Testeo de los primeros servicios desarrollados y desarrollo de nuevos servicios básicos no contemplados en fase de análisis.
• Empezar a realizar valoraciones prácticas de las mejoras que aporta el desarrollo realizado. Que mejor forma que acercarnos al cliente con números reales y no solo con propósitos
• Primera aplicación grideada con nuestro Framework y que corre sobre nuestro Middleware.
• Medir la convergencia con otras arquitecturas Grid pero que cumplen con los estándares.

Para dicho acometido, se está valorando la utilización de alguna herramienta colaborativa. Lo primero que se nos viene a la cabeza es el uso que se le está dando a dichas herramientas, que hasta el momento no está mal, pero estoy seguro que aún es insuficiente. Según la RAE COLABORAR: "Trabajar con otra u otras personas en la realización de una obra.".  Puntualizo con un sinónimo que nos aporta: CONTRIBUIR, lo siento, pero me encanta. Ahora yo modifico la definición para nuestro propósito: "Trabajar con otro/a u otros/as departamentos u organizaciones para la realización de una obra".

Si se empieza a pensar en la definición lo primero que se te pasa por la cabeza es: compartir ficheros, foros, interlocución on-line vía chat, etc. que no está mal, pero vamos, que me sabe a poco. ¿Se os ha encendido la lucecita? A nosotros si.  Y con nuestro entorno estamos pensando en:

• Compartición de potencia de cálculo en una organización virtual. (1 problema contra 100 cpu’s = solución rápida y fiable).
• Compartición de recursos (Yo invierto en una herramienta de análisis biomédico y vosotros aportáis a la herramienta vuestras BBDD –> Todos le sacamos la máxima rentabilidad).
• Compartición de servicios (Yo se mucho de análisis de genoma, pero no puedo dedicar más personas a tu proyecto, te cedo el uso de mis servicios específicos para que explotes la información).
• Toma de decisiones en tiempo-real (colaboración entre 10 empresas, no nos podemos reunir cada semana para decidir que hacer en tareas del día a día. Porque no automatizamos decisiones con inteligencia artificial en función de parámetros económicos, estratégicos, humanos, etc.).
• Monitorización de la contribución (¿Como repartimos el pastel después de la colaboración? ¿Quien se ha mojado más el culo por esta idea? ¿Como saber con quien volver a trabajar?).
• Y podríamos seguir…

Sin duda esta reflexión me ha llevado a creer y darme más argumentos para defender que nuestras herramientas llevan un buen camino si son lo suficientemente generalistas para poderse adaptar rápidamente a cualquier sector y son lo suficientemente concretas para aportar mejoras reales en entornos determinados. Porque por mucho que alguien se encabezone, la colaboración entre empresas de biomedicina nunca requerirá de las mismas necesidades que una colaboración entre entidades financieras.

El viernes 30 de junio tuve la oportunidad de ir a presenciar el proyecto final de carrera de Lluís Ribes, uno de los miembros activos de Grid Cat, el grupo de investigación de donde han salido parte de los socios de Think In Grid .

El proyecto se basa en el estudio para la implementación de un mercado de recursos Grid, donde el precio de los mismos es oscilante dependiendo de varios parámetros de uso (rendimiento, tipología del recurso, popularidad del recurso, etc.) y la regulación de los mismos es realizada por una entidad central.

Personalmente, fue una grata sorpresa, ver como Lluís no solo fue capaz de realizar un estudio teórico, sino que mostró un interesante prototipo de herramienta de gestión (con los problemas que Murphy suele dar en estos casos), donde se pudo observar como el precio de los recursos variaba en función de la demanda que tenían y la calidad de los mismos, lo que hizo la presentación más atractiva de cara a los diferentes oyentes.

Es bueno ver como de vez en cuando se realizan proyectos totalmente enfocados a un entorno empresarial, huyendo, por así decirlo, de una perspectiva más universitaria.

Desde ThinkInGrid solo nos falta felicitar a Lluís Ribes, y esperar que ahora que ha acabado su aventura universitaria no deje abandonado todo su trabajo realizado con Grid Computing.

Desde que en 1998 Ian Foster definió la tecnología Grid Computing, son muchos los que como Oracle, IBM o HP han comenzado a realizar proyectos para convertirse en punto de referencia en el sector. Un punto de referencia al optimizar su tiempo mediante utilización eficiente de los recursos informáticos excedentes en una red corporativa.

Y yo me pregunto… ¿Realmente ese debe ser el camino a seguir? No dudo de que tanto una gran organización como una pyme, decidirán a utilizar su infraestructura para obtener mejoras de tiempo en sus procesos críticos y suprimir sus cuellos de botella. Todo ello sin la necesidad de una gran inversión y con garantias de un rápido retorno del desembolso realizado. Pero, ¿nos debemos plantear si el factor económico es determinante?

La respuesta es: SÍ. Este debe ser, a corto plazo, el hito a conseguir por cualquier compañía que quiera seguir siendo competitiva. Pero tengo el convencimiento que Grid Computing nació para cubrir muchas más necesidades y espectativas. Ian Foster solo pidió infraestructuras descentralizadas, uso de estándares abiertos y el uso de sistemas de calidad de servicio para garantizar el éxito de Grid Computing.

Eso nos abre todo un abanico de posibilidades, donde destaco, por encima de todas el concepto de Organización Virtual, que permitirá acercar las empresas a los clientes finales, o disminuir distancias entre proveedores. Incluso destruir las barreras tradicionales de burocracia y comunicación que actualmente creo rotundamente que impiden la mejora en infinidad de procesos. Ofrece también la posibilidad de coordinar recursos de diferente índole (PC’s, sistemas domóticos, pda’s, sistemas de seguridad, etc.).

En definitiva, la proliferación de aparatos electrónicos que coordinados entre si han de ser capaces de cambiar la concepción que tenemos del mundo actual. Y por debajo de ellos, usada de cimiento, una infraestructura ideal de coordinación y comunicación… Grid Computing.