Computación en la red, alias Nube

Tenía pensado publicar un artículo sobre la computación en la nube sobre lo prematura, poco portable, muy orientada a marketing, ... que es y otros tópicos pero, tras una reorganización de la información de que disponía, creo que es más útil y práctico el enfoque opuesto: los conceptos y arquitectura comunes de los más importantes proveedores de computación en la red.

CPD, una especie en extinción en las empresas
By RobH (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

Primero, hay que recordar los 3 tipos / niveles básicos de proveedores de servicio:

• Infraestructura como servicio, donde el proveedor pone el CPD, las conexiones de red, la forma de crear servidores virtuales, la gestión de bajo nivel,... y nosotros nos encargamos de todo lo demás, desde maquetar una máquina (aunque pueden darnos algunas maquetas preconfiguradas). Aquí hay muchos proveedores, muchos de ellos que ya existían antes de la nube, y ofrecían servidores a empresas. Ahora, con la virtualización, han entrado grandes nombre como Amazon.
• Plataforma como servicio, donde el proveedor nos pone máquinas interconectadas, que ejecutarán una serie de "tareas de trabajo", que se repartirán entre ellas el supuesto trabajo, se crearán y destruirán a necesidad,... Por ejemplo Heroku y su modelo de "workers".
• Software como servicio, es el más habitual para el usuario final, ya que aquí el proveedor pone hasta el software, la configuración,... y el usuario solo tiene que poner sus datos. Ejemplos serían casi cualquier aplicación web que se nos ocurra, desde el antiguamente llamado Google Docs, pasando por un Dropbox, hasta un Evernote.

Pirámide de servicios

Servicios de computación en la nube

Además de un incremento en la velocidad de las comunicaciones y un aumento de las necesidades de computación de las empresas / particulares, 2 tecnologías se han adueñado de nuestros CPD en los últimos años para que la computación en la nube se haya incrementado tanto:

• virtualización. Dentro de una máquina creamos máquinas virtuales, simulando una máquina completa. Originalmente esto sólo se hacía por motivos de demostraciones o educativos, pero con el ascenso en importancia y el añadido de instrucciones e infraestructura en las máquinas para facilitar la virtualización, se ha convertido en una tecnología muy habitual en nuestros CPDs. VMWare sería la marca más conocida en este mundo.

Virtualización. La máquina virtual (Guest) corre sobre el Sistema operativo Host

• particionado. Dentro de una caja / chasis / sistema, tenemos diferentes CPUs, memoria, acceso a disco,... todo tipo de recursos en diferentes cantidades. Podemos, ya sea estáticamente o dinámicamente asignar varios de dichos componentes a diferentes particiones, cada una de ellas correspondiéndose con un "ordenador". Todos los grandes proveedores de informática empresarial tienen productos de este tipo como IBM ( LPAR), Sun / Oracle (LDOM),... basados en un hipervisor que lo gestiona todo y conoce todo el sistema y las diferentes particiones que lo componen.

Particionado. Apenas una fina capa gestiona el reparto de recursos hardware para cada partición

Servicios en general

Una arquitectura general de computación en la nube, habitual entre los proveedores más conocidos es la siguiente:

Diagrama general de computación en la nube

Donde podemos apreciar:

• Un equipo de desarrollo / administración prepara una / varias aplicaciones, mientras determina el espacio de funcionamiento que tendrán, así como la afinidad geográfica que necesitarán (podemos querer tener procesos / máquinas cercanos o replicados en algunos o una ubicación).
• Dependiendo del modelo de uso que hayan elegido ( infraestructura o plataforma), crearán máquinas virtuales en el proveedor o harán el deploy desde su entorno de desarrollo con la herramienta al efecto que haya provisto su proveedor
• A la hora de lanzar procesos / configurar máquinas,... hay que determinar también que otros recursos del proveedor se emplearán, principalmente de almacenamiento y de comunicaciones entre procesos (lo más habitual es que haya gestor de cola de mensajes).
• Durante la ejecución de los procesos / máquinas, podemos monitorizar su estado, dar de alta / baja algunos de ellos,...

Dichos proveedores habituales suelen:

• permitir la ejecución de Java, .Net, PHP y Python.
• proveer de recursos de almacenamiento variados, aunque casi siempre habrá almacenamiento crudo (ficheros), SQL (base de datos), y noSQL (algún tipo de map-reduce, bigdata,...)
• gestor de colas. Para conseguir la paralelización de tareas y el asincronismo, suele haber un gestor de colas que, mediante el empleo del publicador - consumidor podrá aprovechar toda la capacidad de cómputo contratada
• Tanto Amazon como Microsoft Azure, permiten configurar servidores virtuales, a partir de maquetas predefinidas con Windows, Linux,... (Amazon lo llama AMI)
• Ambos tienen herramientas para hacer deploy de aplicaciones, a modo de worker desde el entorno de desarrollo del cliente.
• Varios de los proveedores emplean Git o similares para gestionar las versiones de workers que hubiera ejecutándose en la nube.

Apartado especial se merece Heroku que, a todos los servicios que ofrecen los demás proveedores, añade:

• lenguajes alternativos par los workers: Ruby, Scala, Clojure, Node.js,...
• Permite configurar los  workers con  recursos de otros proveedores, como por ejemplo, emplear el sistema de almacenamiento de Amazon S3, con la gestión de las credenciales necesarias,...
• arquitectura más abierta que otros
• excelente documentación y ejemplos

Computación especializada

 Aunque la computación en red es genérica, han surgido soluciones especializadas para diferentes tipos de datos. Uno de los más conocidos es el de las granjas de render, que funcionan:

1. Hemos desarrollado nuestro proyecto infográfico en nuestras máquinas
2. Elegimos proveedor de computación
3. Adaptamos nuestro proyecto a una combinación de aplicaciones - plugins compatible con las que provee nuestro proveedor de computación
4. Subimos nuestros datos al proveedor y contratamos una cantidad de servidores + software (suelen ser bastante precisos en las previsiones de precio)
5. Esperamos a que termine el proyecto
6. Descargamos los resultados

Como vemos, la clave, para que todo funcione, es que en nuestras instalaciones hayamos podido preparar nuestro proyecto para un entorno casi idéntico al que luego habrá en la red de computación. No es lo mismo un 3DMax + Final Render que un Maya + VRay.

Ejemplos:

• www.foxrenderfarm.com , los servidores no son virtualizados, con lo que tenemos toda la información sobre la potencia disponible, y disponemos de un listado completo de software disponible, versiones y plugins.
• www.renderrocket.com , una de las más usadas en Hollywood. Donde se nos provee de una serie de servidores reales, fijos, más la posibilidad de aumentar mediante nube, con proveedores que ellos ya tienen relacionados.
• www.renderfam.fi , es un caso especial, ya que solo soportan un software, blender, y la potencia de computación es muy variable, ya que se basa en emplear ordenadores de voluntarios, que unas veces habrá más y otras menos, pero como es un servicio gratuito, pues no se puede pedir mucho. En este caso se parece a proyectos más conocidos como SETI para el análisis de señales en busca de vida extraterrestre empleando ordenadores caseros.

Ejemplos en España

En España, aunque parezca mentira, también tenemos proveedores de computación en la red.

• 1and1, además de una gran cantidad de servicios de hosting, webs,... tienen un servicio de cloud. Permiten crear máquinas virtuales, a partir de maquetas predefinidas con Windows o Linux. Aunque es genérico, en todo momento parece que va algo dirigido hacia un tipo de hosting, más que la computación pura y dura.
• arsys, además del típico servicio de hosting, tiene un servicio de cloud. Su servicio se asemeja sobre todo a "Infraestructura como servicio", permitiéndonos levantar decenas de servidores virtuales en un momento. También tiene un servicio extra de almacenamiento masivo.

Casos de éxito

Diferentes empresas, con diferentes negocios, y orientadas a diferentes productos emplean computación en la nube para aportar su valor añadido:

• Netflix, Foursquare y Reddit se ejecutan en la red de computación de Amazon
• Pixar realizó una prueba de concepto en Microsoft Azure para renderizar alguna de sus películas en 2011
• Dreamworks colaboró con HP en la elaboración de varias películas de animación, llegado al final de alguna película a tener 0 servidores Dreamworks en sus instalaciones.

Estandarización

Pero no todo son infraestructuras diferentes, recursos diferentes, APIs diferentes, en el mundo de la computación en red.

Ya ha habido varios intentos de, añadiendo una capa intermedia, crear un único API para varios proveedores. Por ejemplo libcloud, es una API realizada en Python, que nos permite, con las mismas llamadas, acceder a recursos de almacenamiento de Amazon S3 o de Google Cloud Storage, o hacer el deploy de nuestra aplicación en Rackspace, Amazon,... Lo mismo hace deltacloud, aunque en este caso esta hecho en Ruby. Pero cada uno tiene su propio API, incompatible entre si. Pasamos de depender del API de nuestro proveedor al API del producto intermedio que hayamos elegido.

El Open Grid Forum ha creado la Open Cloud Computing Interface (OCCI) intentando lo casi imposible: unificar APIs pero permitir la diferenciación de los proveedores. Para ello, ha incluido en OCCI una forma de preguntar por los servicios disponibles siendo un API modular pudiendo incluir más o menos funcionalidad, centrándose en Infraestructura como Servicio.

OCCI - Nueva capa intermedia

Y ya hay una serie de implementaciones abiertas como:

• OpenStack, gestionado incialmente por rackspace y la NASA, esta dividido en varios módulos / proyectos, realizados en Python, incluyendo una aplicación web para la gestión global (horizon), gestión de la seguridad (keystone), un controlador de la Infraestructura como servicio (nova),...
• OpenNebula, multitud de empresas relacionadas con este proyecto (IBM, Telefónica, Akamia, RIM,...). Permite mezclar recursos de nuestro CPD local con los de la nube. Centrado totalmente en la Infraestructura como Servicio, con una amplia documentación. Un proyecto madura, que ya esta incluido como paquete en algunas de las distribuciones Linux más conocidas.

OCCI se basa en unas llamadas HTTP, en modo REST, con lo que emplean directamente GET, POST, PUT,... del protocolo HTTP, direccionando los recursos como URIs, simplemente, conteniendo capacidades de Red, almacenamiento y computación.
Se divide en 3 módulos:

• Core, seríe el nucleo básico de funcionalidad y tipos de datos
• Infraestructura, extensiones para la gestión de Infraestructura como Servicio.
• HTTP Rendering, indica como se manejan todos los APIs indicados, mediante sistema HTTP REST.

Conclusión

Como resumen general, podemos decir que la computación en red, alias nube, es una tendencia cada vez mayor, más apoyada por los proveedores y fabricante, que permite dimensionar dinámicamente las infraestructuras de una empresa, y que poco a poco va madurando:

• A nivel de sistemas, una Infraestructura como servicio nos dará mucha tarea, evitando solo la parte más cercana al CPD físico, pero hay que seguir gestionando las m´quinas, versiones,....
• A nivel de aplicaciones, el patrón de trabajo más importante es el de worker, muy conocido, empleado a través de colas de mensajes.
• Para los usuarios, cuando son nubes especializada, pueden darnos un servicio muy útil, rápido y disponible para unos requisitos puntuales, pero debemos asegurarnos de la compatibilidad de versiones.

Puede ser una excelente vía para completar los recursos de computación de nuestro CPD en momentos puntuales, pero nos hace perder parte del control de nuestros datos, ya sea por motivos técnicos ( políticas de backup, acceso a los datos), o por motivos legales ( la LOPD puede afectarnos si los datos que se mueven son personales).