It's the data, stupid.

El martes estuve tomando un café con Luis, que para uno que conozco que es realmente emprendedor no le gusta que le definan con ese adjetivo. Él cree, como yo, que el futuro del proceso de conocimiento está en la gestión dinámica de recursos, los clouds. Es más; también coincido con él en que los clouds deben estar basados en estándares revisados por alguna organización con verdadero criterio como la W3C o la ISO.

Fijar un estándar llevará a todos los proveedores un buen rato y a los usuarios muchos disgustos. Cada gran proveedor usa una tecnología distinta y métodos propios para configurar claves, mandar imágenes de SO, gestionar dinámicamente las instancias... Cada uno intentará imponer como estándar su propio así que el riesgo que se corre es que cada uno termine imponiendo el suyo y terminemos con media docena de estándares parecidos pero distintos. Algunos recordarán lo que sucedió dentro de la ISO cuando se intentó estandarizar los formatos de documento de suite ofimática. Un desastre, vamos.

En lo que llevo de año natural he visto en primera persona o probado los clouds de Amazon, Google, IBM y Microsoft. Cada uno tiene sus ventajas e inconvenientes; hasta su propio método de facturación. Además todos han convergido a los precios de Amazon que parece ser el verdadero "elephant in the room".

En el laboratorio no tenemos un cloud porque no nos serviría para nada. Los clouds utilizan la virtualización para segregar recursos. Nosotros buscamos la agregación masiva de recursos porque un procesador o una porción de un disco duro no nos sirven absolutamente para nada. Pero si tenemos en cuenta que tenemos encerrados 700 procesadores y varios centenares de terabytes en un cuarto —por no hablar de lo que usamos fuera— sí me creo capaz de opinar sobre infraestructura en general.

Afortunadamente para nosotros, en temas de infraestructura los entornos científicos están varios años por delante de cualquier proveedor de servicios en la nube y han resuelto muchos de los problemas que estos grandes nombres de Internet tendrán que resolver. Los centros de supercomputación tienen mejores procesadores, mejores redes, mejores sistemas de almacenamiento y backup... Pero otra vez aparece el problema de la estandarización. Cada centro tiene sus reglas y opera de manera completamente distinta. Ni siquiera usan el mismo método para hacer login: ssh interactivo, ssh con par de claves, ssh interactivo con una cryptocard... También cada uno tiene su propio gestor de colas.

El problema es distinto pero parecido. No puedo coger un job que corre en Jugene y llevármelo al Mare Nostrum. De hecho no tengo ninguna garantía que lo que corre en un BG/P correrá en un Power o en un Xeon sin cambiar partes relevantes de la aplicación. En nuestro caso no habrá solución, ya sabemos que nunca se estandarizará el acceso a estas máquinas. De todos modos no es algo que sea imposible de solucionar, simplemente debes programar un poco más y abstraer tu aplicación de estas diferencias. Lo importante son tanto las diferencias sino que estén bien documentadas.

Lo que sí nos ha demostrado nuestro trabajo día a día es que, una vez ya has encontrado una solución subóptima para poder procesar, llegas al problema realmente importante. ¿Qué hago con mis datos? Parece que a todo el mundo se le está olvidando que lo importante de la informática son los datos. No pones a correr miles de procesadores durante millones de horas para llegar a un resultado como π/2. Generas un montón de bytes y un buen día tienes que hacer algo con ellos a parte de recordar dónde los tienes: moverlos, almacenarlos, distribuirlos...

Ahí es donde empieza la pesadilla de verdad. Cuando tienes que mover algo del orden de un terabyte —parece mucho pero es lo que cabe en un disco duro moderno, así que no es tanto— ya no puedes hacerlo con el navegador a través de tu ADSL guarrindonga. Más te vale hacerlo por un cable de fibra óptica con un protocolo específico si no quieres tener que partir tus datos en cachitos realmente pequeños. Y quien dice bajar, dice subir o mover de un sitio a otro.

Cuando miro la documentación de los proveedores de cloud están hablando de particiones de dos o cuatro gigas. Quizás es suficiente para guardar la contabilidad de una PYME pero es ridículo para una empresa de verdad o una PYME tecnológica. Y tampoco es verdad que la solución universal para los datos es una base de datos. Así se resuelve el problema de los datos en aplicaciones web, pero poco más.

Luego está el problema realmente importante. Los proveedores de cloud están en Carolina del Norte, Washington, Irlanda... ¿Cómo mando mis datos ahí? Cuando me traigo datos desde Alemania lo hago por el cable de fibra óptica que me dijeron que usara, con el protocolo que me recomendaron y entre dos centros de supercomputación para ir a 20 MB/s. Y si quiero traerme algo a Aeronáuticos ya puedo dar gracias a Rediris porque de otro modo ya me podría ir olvidando de tenerlos en "casa". Tampoco me serviría de mucho que un proveedor de cloud me dijera que está en Logroño si no hay un buen tubo hasta ahí. Al final la proximidad geográfica es sólo un tipo de proximidad. No uso mi PC para ver resultados porque hasta el array de discos tengo una fast ethernet, aunque sólo sean 20 metros de cable. Prefiero hacer login a un servidor conectado con el disco por 1.5m de fibra a 4 Gbps.

Los proveedores de hardware conocen el problema. El cálculo es fácil, lo realmente complicado es gestionar los datos. Si necesito cálculo me entiendo con el tío de ventas en una tarde. Si pido almacenamiento es probable que después de dos semanas aún no me hayan ofrecido lo que necesito (me ha pasado).

La solución a todo esto es tener un cloud relativamente cerca con una red lo suficientemente buena. Y esto no es tan difícil porque incluso las grandes ciudades de un país que lucha por crecer como España están cableadas con fibra óptica. Con esto bastaría con adoptar una solución N-Tier, como sucede con los centros de supercomputación. Un enorme CPD en Irlanda o en NC será una solución para algunos pero, por muy bien que lo vendan, no será una solución para todos. Pero contar además con un cloud más pequeño pero más cercano sí podría ser una solución para casi todos. Un servicio de nube realmente cercano no sólo puede proveer de cálculo y disco sino de otros servicios: escritorios remotos, sistemas operativos cloud como eyeOS... Podría abaratar significativamente el coste de IT de cualquier empresa, especialmente una PYME.

El problema de un sistema N-Tier es que para crearlo la estandarización es sencillamente imprescindible así que habrá que estar atentos a qué sucede con estos primeros pasitos de este mundo que está aún en pañales. Luego ya llegarán los problemas políticos como que venga Telefónica y se folle todo el negocio por intentar sacar cuatro perras más.

O quizás todo esto sea un cuento chino y el motivo por el que la nube tiene éxito es que todo el mundo odia la los administradores de sistemas.

Edit... No es necesario crear un cloud de la nada.

Cuando oyes a todo el mundo hablando sobre la nube desde el punto de vista del hardware siempre oyes a proveedores específicos que son capaces de ofrecer una cosa o otra. Amazon, Rackspace, Dreamhost, Arsys... Todos hablan de el negocio de convertirse en broker de recursos de su nube.

Este es el punto de vista de quien quiere ganar dinero con la nube. Es algo legítimo y no se les puede criticar pero no es la manera óptima de aprovechar dinámicamente recursos.

La gran ventaja de todo este middleware creado para la nube es que uno es capaz de abstraer el hardware de el dónde y el cómo así que a uno le da igual si una instancia se está ejecutando en Madrid o en Reijkiavik.

Antes de llegar al argumento de mi discurso pensemos un rato en el cloud de Amazon. Amazon tenía un enorme centro de datos necesario para mantener a flote su negocio de venta. Su equipo de infraestructura dimensionó todo para picos de compras como, por ejemplo, Thanksgivings. Esto implicaba que el resto del año los servidores estaban tocándose el escroto. Hoy uno lo haría al revés, diseñaría un gateway para soltar el excedente de conexiones a otro recurso pero ellos hicieron lo contrario: buscaron una manera de vender los recursos que les sobraban. Hoy son el mayor proveedor de recursos de hardware externos.

Creo que en España muchas empresas pueden seguir exactamente el mismo camino. Una vez ya manejas tu propia infraestructura de manera dinámica nada te impide ofrecerla al público. La tecnología actual permite hacer este tipo de ofertas sin que ello signifique un problema de seguridad. Entiendo que si le propongo a un banco que haga negocio dejando entrar a desconocidos en sus sistemas me tratarán de loco y después me echarán a patadas de sus oficinas pero lo harían sin justificación.

El coste importante de un servicio cloud son el edificio, los SAI, las PDU, la red de interconexión, los cables de fibra óptica armados hasta el switch gordo de Telefónica... Si tienes que dar servicio a 20K empleados seguro que tienes que construir algo así. El resto es más sencillo de lo que parece y, lo que es importante, también es relativamente barato.

Creo que es una situación win/win delante de las narices de todo el mundo.