En un artículo reciente en eliax escribí un comentario en donde explicaba que no nos engañemos pensando que dispositivos móviles como el iPad o celulares iPhone/Android no serán capaces de manejar la dura carga de programas de procesos intensos que programas como Photoshop requieren, ya que existe una solución justo en el horizonte, y de eso se trata este artículo de hoy...

Desde los inicios de la computación ha existido un concepto de "procesamiento distribuído", lo cual en palabras sencillas no es más que tomar una tarea de trabajo de algún software, y distribuir su carga entre dos o más entidades.

Sin embargo, salvo ciertas excepciones bastante particulares, ese tema nunca ha sentado pie en el mercado de consumidores, y mi propuesta de hoy es decir que no falta mucho para que eso suceda, y en grande...

Algunos técnicos tratarán de corregirme diciendo que procesamiento distribuído ya existe, dentro de los CPUs y GPUs de nuestras PCs (e incluso celulares y el mismo iPad), en donde un procesador tiene ya varios núcleos y la carga es distribuída entre estos. Incluso está el caso en servidores más potentes y en super-computadoras en donde se utilizan no solo núcleos, sino que decenas, centenares o miles de procesadores para entre todos atacar un problema en particular.

Pero no estoy hablando de eso.

Estoy hablando a un nuevo paradigma de lo cual o nadie aun sea ha percatado que ya prácticamente poseemos la tecnología para hacerlo, o simplemente lo mantienen en secreto hasta tanto lo perfeccionen, y la mejor manera de explicarlo es con un escenario...

Imaginen que tenemos un futuro descendiente del iPad en nuestras manos, y que arrancamos la aplicación Photoshop en esta. Imaginen además que estamos cómodamente sentados en nuestra oficina en casa.

Imaginen ahora que abrimos una imagen inmensa dentro de Photoshop, y que deseamos aplicar un filtro que requiere bastante procesamiento bruto. En este punto, tenemos dos opciones:

1. Opción 1, la manera tradicional: El usuario debe esperar hasta tanto el filtro complete su trabajo, sea un par de segundos o incluso minutos.

2. Opción 2, de lo que se trata este artículo: Distribuir la carga a dispositivos cercanos vía conexiones inalámbricas (o alambradas de ultra-alta velocidad).

Con la opción #2, el iPad (o cualquier otro dispositivo de otra empresa) detectaría que en tu casa tienes un Apple TV, un iPod Touch, un iPhone y una MacBook Air, a los cuáles previamente habías autorizado para que interactúen con tu iPad, por lo que el iPad decide que necesita más ciclos de CPU para terminar la tarea más rápidamente, así que toma el software de Photoshop y distribuye la carga automáticamente de forma paralela en todos esos dispositivos, de modo que ahora no es solo el iPad el que ejecuta el filtro de Photoshop, sino que todos los dispositivos en tu hogar, terminando el filtro su trabajo en 1 segundo en vez de 1 minuto, de paso ofreciendo muchísima más velocidad que la versión de Photoshop que utilizamos hoy día en el hardware más potente que podamos imaginar.

Pero, ¿y cómo funciona esto y cuál es la magia o ingrediente secreto necesario para que esto funcione?

Pues lo primero, es que se necesita una plataforma estandarizada que permita que código se pueda enviar entre un nodo y otro de la red, y que sea ejecutable de forma transparente y sin problemas de compatibilidad, y da la casualidad que una empresa ha estado forjando una estrategia para hacer exactamente esto desde hace un par de años: Apple (aunque ya veremos más adelante quien más podría ofrecer algo similar).

Noten que hoy día un Apple TV, un iPod Touch, un iPhone y un iPad tienen todos el mismo hardware en su núcleo, y el mismo sistema operativo, tal cual predije hace 4 años sucedería, con la diferencia de que en ese entonces yo lo llamaba "OS X Mini" y ahora Apple lo llama "iOS".

Con iOS, y su primo OS X (los cuales se fusionarán en algo que llamo "iOS X", como predije el año pasado), Apple está en la envidiable posición de tener un sistema operativo escalable desde un mini reproductor de audio como el iPod Nano, hasta una super-computadora, utilizando el mismo hardware y software de base en todos estos.

Hablamos de un "enjambre" de iOS, en donde cualquiera de ellos podría tomar ventaja del poder de computación de todos los demás en la cercanía. Incluso me puedo imaginar a Apple vendiendo cajitas similares al AppleTV para este fin, a US$99 dólares, que se venderían por millones a una población de consumidores hogareños y profesionales que desean más velocidad cada vez más.

El otro ingrediente necesario es un arquitectura de intercomunicación de alta velocidad, sea inalámbrica o alambrada. La versión alambrada ya no tiene que esperar, pues está aquí y se llama Thunderbolt, y curiosamente fue ideada por Apple y desarrollada por Intel, que ofrece velocidades (en su implementación actual en la MacBook Pro) de 20Gbps de ancho de banda agregado, lo que es mucho más que suficiente para implementar el escenario que propongo.

Por otro lado, ya existe un estándar en proceso para el 2012 de WiFi a 1Gbps, así como ya se está experimentando con otras tecnologías inalámbricas de más corto alcance y con velocidades de hasta 15Gbps, por lo que lo mismo que podremos hacer de forma alambrada se podrá de forma inalámbrica próximamente (aunque recuerden que incluso 1Gbps es suficiente para este escenario).

Y el tercer ingrediente es una plataforma de software sobre la cual los programadores escribirían sus aplicaciones para que estas escalen natural y automáticamente para tomar ventaja de periféricos cercanos (o incluso lejanos con lineas de Internet de alta velocidad y de baja latencia) y distribuir sus cargas de trabajo.

Una vez más, Apple ha estado desarrollando esa tecnología bajo las narices de todo el mundo, y se llama Grand Central Dispatch (GCD), una tecnología que ha sido parte de OS X desde hace un par de años, y que en la superficie aparenta ser una herramienta para el uso de multi-núcleos, pero algo me dice que Apple tiene planes muchos más extensos para GCD, posiblemente alineados a mis predicciones en este artículo.

Ahora, algunas personas no-técnicas es posible que estén incrédulos ante la posibilidad de que esto se haga realidad a corto plazo, pero lo cierto es que desde hace años en el sector profesional existen decenas de herramientas que hacen esto, solo que de forma propietaria a un software en particular.

Por ejemplo, existe un concepto llamado un "render farm" (o "granja de renderizadores") que se utiliza muchísimo en software de renderización de 3D, en donde uno instala varias copias de un software especializado en varios servidores, y la carga de renderización se distribuye entre todos los nodos. Esto incluso existe en programas de edición de video no-lineal (como Final Cut Pro), así como para programas de edición de imágenes, arquitectura, etc.

Sin embargo, esos son casos aislados, y cada uno de esos render farms son especializados a un software en particular, en vez de ser soluciones genéricas. Noten que eso no significa que no existan soluciones genéricas, sino que las genéricas no han tomado tracción por varias limitaciones (como la falta de plataformas estandarizadas, etc).

Sin embargo, más allá de Apple hay una empresa que puede hacer algo similar, y esa es Google. Sucede que una de mis tecnologías favoritas de todos los tiempos, llamada Jini, fue creada para resolver específicamente este escenario del cual hablo hoy, pero Jini lamentablemente fue un caso más de una solución en busca a un problema demasiado temprano. Jini estuvo al menos una década adelantada a su tiempo (y a propósito, si eres un arquitecto de software, recomiendo no solo que aprendas sobre Jini, sino que sobre su tecnología hermana, JavaSpaces, que quizás sea una de las piezas de software más elegantes y sencillas que he visto en mi vida).

Pero he aquí lo interesante: Jini tiene sus raíces en el mismo corazón de los desarrolladores originales de Java, y hace apenas unos días (como reporté por Twitter) que "El Padre de Java", James Gosling, dejó a Oracle/Sun para irse a Google, cosa que muchos se preguntaban para qué. Pues como podrán ver ahora, yo ya tengo una muy buena idea...

La plataforma Android OS de Google es en realidad una plataforma mayoritariamente Java (Linux solo ofrece servicios de bajo nivel y es en teoría incluso reemplazable sin afectar la funcionalidad de los niveles superiores del Android OS), y ya me puedo imaginar algo similar a Jini en una futura versión del Android OS, el cual de forma similar al iOS de Apple, fue diseñado para al menos en su núcleo funcionar desde en celulares hasta en televisores y servidores. Así que imaginen a Google ofreciendo un estándar abierto en donde cualquier empresa pueda fabricar y/o ofertar una "caja de computación" similar al Apple TV pero para estos fines. Sería fenomenal...

Así que en mi opinión, tras bastidores, lo sepan o no estas dos empresas, ambas se encaminan rápidamente hacia lo que será una nueva batalla titánica por nuestros dispositivos en el hogar y en nuestros negocios.

Y no puedo hablar por ustedes, pero esto me emociona muchísimo y no puedo esperar a ver el día en que veamos anuncios de estas dos (u otras) empresas sobre estos escenarios. No lo duden, estamos viviendo los tiempos más emocionantes de la humanidad...

Nota a técnicos: Jini a evolucionado a convertirse en Apache River. También visiten la página oficial de Jini, y la especificación oficial de JavaSpaces.

autor: josé elías