Granjas, fábricas y nubes, el futuro de la computación

Según Julio Guijarro y Steve Loughan ambos miembros del grupo de investigación que tiene HP en Bristol ese es el futuro de la computación distribuida. Julio y Steve han publicado el pasado Diciembre una presentación muy interesante en la que hablan de como los modelos de servidor único y de un cluster de servidores han quedado obsoletos en favor de un modelo de granja con cientos de servidores donde el sistema de ficheros es distribuido y el almacenamiento y la CPU se alquila. Se trata de una infraestructura ágil, como ellos la denominan, y que tenderá en el futuro a una gran fábrica de grids con decenas de miles de servidores



Esta evolución se sustenta en la base de que las arquitecturas actuales han anulado ciertas asunciones que en el pasado eran verdaderas pero que Julio y Steve afirman que ya no lo son. Pongo la lista a continuación ya que aunque es posible que no se esté de acuerdo de todo me parece un buen resumen sobre las consecuencias arquitectónicas que tienen algunas tendencias actuales.

Arquitectura: Virtualización. Asunciones que ya no son ciertas:

• Los sistemas permanecen activos por enormes espacios de tiempo.


• Crear un nuevo sistema es caro y lento.


• Duplicar un sistema existente es algo muy caro.


• Los sistemas deben controlarse manualmente.


• Los relojes están sincronizados.


• La RAM nunca se "swappea".


• Las máquinas que están en ejecución no pueden ser movidas y/o clonadas.

Arquitectura: Granjas de servidores. Asunciones que ya no son ciertas:

• El fallo en un sistema es un evento inusual.


• El 100% de disponibilidad se puede conseguir.


• Los datos siempre están cerca del servidor.


• Se necesita acceso físico al servidor.


• Las bases de datos son la mejor forma de almacenamiento.


• Necesitas tener millones de euros para ser un competidor en tu rama.

Arquitectura: Map/Reduce. Asunciones que ya no son ciertas:

• Es difícil trabajar con terabytes de datos.


• El código se ejecuta siempre en una única máquina.


• El código ejecutado secuencialmente es mejor que el código ejecutado en paralelo.


• La mejor forma para almacenar los datos es con sistemas RAID.


• Las bases de datos son mejores que los sistemas de ficheros.

Arquitectura: Sharding. Asunciones que ya no son ciertas:

• Una única granja puede escalar hasta el infinito.


• Necesitas proporcionar 100% de disponibilidad al 100% de tus usuarios.


• Cambios en la aplicación cambian la totalidad del esquema de base de datos.

El análisis realizado me ha parecido muy interesante. El argumento central de la presentación es que la computación poco a poco se está conviertiendo en una commodity, como las granjas que nos preparan la comida o las fábricas que nos hacen la ropa.

Sistemas sobre los que he estado hablando continuamente en los últimos meses, como S3, EC2, la nueva SimpleDB o Hadoop han cambiado la forma de entender la computación distribuida y, concretando en el caso de Amazon, proponen un modelo de renting muy atractivo que permite a pequeñas startups ponerse a la altura de grandes corporaciones.

Por cierto, que no lo había comentado, Julio Guijarro es el líder del proyecto SmartFrog, que personalmente no conocía y que tiene como objetivo el proporcionar una tecnología que describa sistemas de software distribuidos como colecciones de componentes manejables y activables. Por la descripción se me antoja como algo similar a Dryad de Microsoft. Eso sí, éste está liberado bajo licencia LGPL.

Quiero mi consola de administración

Uno de los artefactos por el que claramente apuesta el libro que recomendaba hace unos días es el ofrecer una consola de administración para las aplicaciones.

La idea, con la que estoy completamente de acuerdo, es muy sencilla. Lo malo es que a pesar de estar totalmente de acuerdo, siempre he acabado por no hacerlo, en cualquiera de los trabajos en los que he estado. Shame on me! La verdad es que al final he caido siempre en la vieja práctica de crear un interfaz de usuario muy amigable para administrar el sistema. Sin embargo, el hacer esto tiene normalmente varios problemas:

• Suelen ser aplicaciones Swing o web que simplemente acceden directamente a los servicios. Por lo tanto si los servicios cambian las aplicaciones deben de cambiar.
• Tienen asociado un coste de mantenimiento importante. Cada vez que se cambia algo (punto anterior) y cada vez que se añade una nueva funcionalidad, es necesario el crear nuevas páginas o ventanas con nuevos interfaces de usuario para administrar esta parte nueva del sistema.
• Es una solución propensa a errores. Incluso cuando tu backend esté perfectamente probado, pasas a lidiar con todos los errores asociados a un framework de creación de interfaces de usuario: Swing, Java Server Faces, Seam, Struts, SWT/JFace, ...
• Hacer pruebas es complicado. Probar los servicios es fácil, simplemente un conjunto de tests unitarios y tests de integración y listo. Pero si le vas a ofrecer un interfaz de usuario de administración al usuario final entonces tendrás que probarlo. Y esto nuevamente tiene asociados unos costes importantes.
• No son scriptables. Este tipo de UIs están bien para usuarios, pero no para administradores, que como bien dice el nombre al final deberían realmente ser las personas que utilicen las interfaces de administración. Un administrador va a preferir cien mil millones de veces algo con lo que pueda hacer scripts y automatizar tareas que una interfaz de usuario que por muy bonita que sea le obligue a crear uno a uno todos los usuarios del sistema.
  
  Esta probablemente sea una de las razones más poderosas para basar el sistema de administración algún sistema de comandos que sea scriptable. Te permite automatizar tareas tediosas, crear tus propios scripts de mantenimiento, replicar sistemas de manera sencilla, y realizar un sinfín de tareas que de otro modo serían demasiado complicadas.

En fin, estas son algunas razones y supongo que os darán una idea de los problemas asociados. Yo mismo, ahora que estoy peleando para sacar una versión de actualización de jLibrary, me encuentro con que sufro para mantener el interfaz de usuario. Para mi, ya no es sencillo juguetear con pantallas de administración como esta:



Sí, es una pantalla muy bonita, pero mantenerla me implica todo lo explicado anteriormente: Mantener los widgets, lidiar con cosas como "que si migro a Eclipse 3.2 entonces han cambiado los widgets y tengo que modificar el código para que las listas salgan con borde porque ahora ya no salen", asegurarme de que no hay errores, etc. Si por el contrario tuviese una simple consola de comandos con funciones como crearUsuario, crearRol, añadirUsuarioAGrupo todo se limitaría simplemente a llamar a esos métodos y punto.

Probablemente una de las mejores formas de crear una consola de administración es simplemente codificar una pequeña aplicación que exponga todos los métodos de nuestro servicio de administración en forma de comandos. Hay una ventaja adicional asociada a esto, que es que una vez que tengamos diferentes scripts creados, estos servirán como tests de integración del sistema por lo que realmente se están matando dos pájaros de un tiro: tests de integración y administración.

Ahora bien, en caso de tener tiempo (y ahora entro en la parte concreta de Java) probablemente nos convenga seguir la aproximación que servidores de aplicaciones como BEA WebLogic o IBM WebSphere siguen. Esto es, envolver nuestro sistema de administración en una serie de MBeans que sean los que expongan las operaciones. Estos MBeans invocarán a nuestro sistema de administración. Una vez se tiene esto, se crea una consola de administración sencilla utilizando algún lenguaje dinámico (por ejemplo WebLogic utiliza Jython; WebSphere jacl and jython) que simplemente ejerza de wrapper entre el usuario y los MBeans, por ejemplo exponiendo todos los MBeans en forma de objetos python que el usuario pueda invocar.

Si se consigue un sistema como este nos encontraríamos ante el entorno ideal de administración. El paso siguiente es aprovechar esos MBeans para exponer el entorno de administración en otros formatos, pues por ejemplo una consola web (como hacen WebLogic y WebSphere), o incluso aplicaciones de escritorio.

Una ventaja adicional a todo esto es que los MBeans se pueden exponer también hacia sistemas de gestión SNMP utilizando alguna librería de transformación JMX-SNMP, de modo que el estado de nuestro sistema de administración puede ser monitorizado con cualquier herramienta que soporte SNMP.

En fin, aquí dejo un diagramilla que me he currado mientras escribía esto.

Recovery-Oriented computing

Recovery-Oriented Computing (ROC) es (más bien era) un proyecto de investigación para la creación de servicios altamente fiables en internet. ROC se centra en la recuperación ante fallos, de hecho asume que no importa lo sólido o robusto que sea el software o el sistema analizado, ya que siempre existirá la posibilidad de fallo (humano, hardware, software).

Sus tres leyes básicas son:

• Las tasas de fallo de software y hardware son significantes y siempre aumentan.


• Los fallos no se pueden nunca predecir por completo de antemano.


• El herror humano, especialmente durante mantenimiento, es una de las mayores fuentes de errores.

Fuentes:
The Berkeley/Stanford Recovery-Oriented Computing (ROC) Project.
Wikipedia.