Multi-tenancy: diseñando con la escalabilidad en mente

Me ha gustado mucho un artículo que un compañero me ha pasado sobre el concepto de multi-tenancy. Se podría definir como la habilidad para ubicar varios clientes dentro de la infrastructura de una aplicación. Por otra parte, también me ha gustado una entrada de Jose Manuel Suarez en su blog en la que habla de optimización vs. hardware. Pensándolo esta tarde, me he dado cuenta de que, aunque no lo parezca a simple vista, existe bastante relación entre ambas entradas.

Como Fred Chong comenta en su blog, conseguir multi-tenancy es un trabajo duro. Por ejemplo, supongamos que tenemos una aplicación empresarial relativamente típica con un par de servidores web, un par de servidores de aplicaciones y un par de bases de datos, y que decidimos hacer nosotros el hosting de la aplicación. Realizar el hosting de la aplicación es mucho más práctico para la empresa proveedora de software ya que evita muchos problemas como el despliegue o la gestión de parches de cliente, al tiempo que hace más fácil la automatización; sin embargo, al mismo tiempo añade mucho coste en cuanto a infraestructura.

Por ejemplo el caso anterior está bien para un único cliente, ¿pero qué pasa cuando tenemos 5 clientes? En ese caso ya empezamos a hablar de 10 servidores web, 10 servidores de aplicaciones y 10 bases de datos a gestionar, y eso siempre que algún cliente no exija sistemas de demostración en cuyo caso las cifras pueden crecer todavía más. Excluyendo la administración, esto plantea dos problemas principales: el coste del hardware y el coste de las licencias de todo el software que estemos utilizando (servidores de aplicaciones, sistemas de monitorización, motores especiales como por ej. sistemas de comunicación para entornos financieros, sistemas de mensajería, etc.). ¿Qué pasa si estos 5 clientes son pequeños y no compensa el mantener esta infraestructura para ellos?

Esta es una de las razones por las que en aplicaciones complejas la aproximación "slashdot" o "youtube" de añadir servidores no funciona demasiado bien, ya que el escenario es más complejo.



El diagrama de aquí arriba muestra las diferentes técnicas que pueden aliviar el problema de multi-tenancy. Las técnicas están ordenadas por densidad, siendo las de más arriba las que permiten compartir más clientes dentro de nuestra infrastructura, y las de más abajo las que menos clientes permiten compartir.

No voy a entrar demasiado en detalle en las diferentes técnicas, porque eso es otra historia, pero básicamente cada una de esas técnicas tiene un coste asociado. Ya sea en cuanto a necesitar soluciones propietarias, o ser complejo de mantener, o ser funcionalidades específicas de un sistema operativo. Por ejemplo, la virtualización es una solución excelente para solucionar el problema de multi-tenancy pero tiene el problema de que el número de máquinas virtuales que podremos alojar en un servidor físico es limitado y a mayores tenemos el coste de las licencias (o del mantenimiento) del sistema de virtualización que utilicemos.

Y bueno, entonces, ¿cómo se puede arreglar todo este embrollo?

La solución ideal es crear aplicaciones que puedan utilizar varios clientes a la vez. Si la aplicación es muy grande, entonces se debería dividir en diferentes módulos independientes entre sí y que pudiesen ser compartidos por diferentes clientes. Por ejemplo, un sistema de trading financiero podría tener por una parte en un servidor la gestión de las carteras de los diferentes traders, en otro servidor la gestión de las órdenes de compra y venta de todos estos traders, y en otro servidor la gestión de informes para los clientes y los bancos.

Esto es lo que Fred Chong llama "Shared Application Instance", el compartir porciones de una aplicación con diferentes clientes. Esta es la aproximación que permite la mayor densidad de tenancy en un sistema, y la que ofrece la mejor escalabilidad. En estos sistemas, denominados comúnmente no-homogéneos, es mucho más sencillo gestionar los recursos del sistema. Por ejemplo, si sabemos que la gestión de órdenes necesita más recursos que la generación de informes, podemos dedicar servidores más potentes a alojar el cluster del sistema de órdenes mientras que reservaremos servidores más modestos para el reporting.

El problema, y ahora es cuando vuelvo a enlazar con el post de Jose Manuel, es que migrar una aplicación existente para que pueda dividirse y servir a diferentes clientes es algo muy complejo y muy costoso si la aplicación no se ha diseñado desde un principio para ello. En muchos casos estaríamos ante un reto casi tan complejo como el tener que reimplementar la aplicación. Ahí está la importancia de diseñar y crear una arquitectura desde un principio pensando en la escalabilidad. La optimización prematura siempre es algo malo, pero no lo es sin embargo el diseño en busca de la escalabilidad y el rendimiento. El diseño en busca de escalabilidad puede que no de frutos en los primeros meses, puede que añada complejidad lógica en el sistema (por ejemplo con desacoplamiento de APIs y módulos, uso de sistemas de mensajería, etc.), pero a largo plazo, cuando el sistema crece, y cuando hay más clientes a los que servir, es cuando se ven realmente los beneficios.

Vaya ladrillo que me ha quedado. Felicidades si has sido capaz de llegar hasta aquí :-)

ApacheCon 07 y web frameworks

Haciendo mis lecturas diarias he descubierto que ya están disponibles las transparencias de la ApacheCon 07 que se celebró hace unos días. Se pueden descargar desde este enlace.

En InfoQ destacan la charla de Matt Raible en la que hace una comparativa de los diferentes frameworks web disponibles en estos momentos para el desarrollo de aplicaciones. Esta comparativa es la continuación de una mítica comparativa que el mismo autor realizó en 1994. Como pasa el tiempo.

Una de las curiosidades de la nueva charla de Matt es que consta de dos versiones. La primera fue la que envió para la conferencia (que creo que ya la había visto en alguna parte). La segunda versión es la que realmente presentó. El motivo para presentar una charla diferente es que en un inicio él pensaba hablar de frameworks que ha utilizado pero después se dio cuenta de que creaía que muchos de esos frameworks ya no tendrían mucho éxito en el futuro así que los eliminó y los sustituyó por otros más prometedores.

En particular se cayeron de la lista Stripes, Spring MVC y Tapestry (parece que los autores lo acosan en su blog :D). En fin, curiosidades aparte, los frameworks que compara son: Flex, Grails, GWT, Seam, Struts 2 y Wicket. ¿Será ese el futuro?

La lista de la verguenza: Top 100 Software vendors

Hoy no iba a postear más. Es sábado y con uno ya era suficiente. Sin embargo tras encontrar en Navegapolis un enlace al informe Truffle 2007 sobre el que informaba el blog de Sin Seguridad IT, pues no he podido evitar el abrir esta entrada.

Os invito a leer el informe. Se trata de las 100 empresas vendedoras de software en Europa con mayor facturación en el año 2006. ¿Cuántas empresas españolas creéis que hay? .... mmm .... Sí, seguro que algunos ya lo habéis adivinado: NINGUNA.

Hace meses hacía una pregunta abierta: ¿Dónde están las empresas de software en España?. Era una pregunta resultado a la locura "blogosférica" general por la que todo el mundo preguntaba por dónde estaban los programadores, sin darse cuenta que el problema real es muy diferente y mucho más grave.



Hector Montenegro Director de Tecnología de Microsoft Ibérica se hace un montón de preguntas interesantes en su blog acerca de este tema. Vale la pena leerlo.

En mi humilde opinión, y me voy a repetir porque es algo que ya comentaba en susodicho post sobre la falta de empresas, el problema está en la raiz, es decir, en como funciona el sector de software en España. El sector de IT en España está basado en la consultoría y los servicios mientras que otros países apuestan realmente por la innovación y el desarrollo. Sí. Las famosas siglas I+D que tanto se utilizan en España para vender proyectos pero que a la hora de la verdad nadie ve ni íes ni des por ninguna parte.

En nuestro país lamentablemente gustan mucho los proyectos llave en mano, la personalización para el cliente, el hacer dinero fácil sin pensar en generar productos reales. Muchas personas se están preguntando el por qué no se matricula la gente en las carreras de informática hoy en día. Sinceramente, hoy por hoy no sé si yo mismo me re-matricularía sabiendo que mi futuro va a estar en una empresa de servicios sub-contratado o tri-contratado y sabiendo que mi software no llegará a ver la luz nunca porque el proyecto ha fracasado, o que en el mejor de los casos lo se quedará ahí dándole utilidad a unas cuantas personas de un departamento.

Lanzo una pregunta a todos los que trabajan en consultoras y empresas de servicios. Investiguen un poco y escriban en un papel el nombre de los productos que se encuentran en el catálogo de software que sus empresas ofrecen al público. ¿Cuántos productos han salido? 0,1, ... 5, que más da. En fin, por algo son empresas de servicios, ¿no? Lo malo es que en España parece que es lo único que hay.

Yo sé que ahora me voy a meter en un terreno muy fangoso, pero un tema que me hace gracia es el del intrusismo. Cuando comento por aquí lo que pasa en España con este tema me miran como si les estuviese tomando el pelo. "Mmm... they want to have professional bodies. That's pretty weird.". Vamos, que no se lo pueden creer. Y es que yo no veo que en Europa haya semejante debate como el que hay en nuestro país. Pero claro, en estos paises se hace software, se fomenta a la economía exportando productos, se crean puestos de trabajos permanentes desarrollando software, y se puede estar haciendo software con 40 años porque es un trabajo muy reconocido y que da dinero.

Nosotros, mientras tanto, seguiremos peleándonos en lugar de buscar soluciones al problema real. Seguiremos vendiendo el pan de hoy sin preocuparnos en como fabricar un pan que dure más días. Y bueno, quizás algún día hasta puede que sólo los informáticos podamos firmar los proyectos llave en mano, así colaboraremos un poquito más para seguir en el top 999.

Reemplazando Flash con Applets y comparación de rendimiento con otras tecnologías

En las últimas jornadas Javaa las que asistí, uno de los temas recurrentes en las charlas que tenían que ver algo con el interfaz de usuario es el interés de Sun por resucitar a los Applets.

A pesar de que con las mejoras de rendimiento en los últimos JDKs cada vez es más común ver Applets en las páginas web, lo cierto es que ésta es una tecnología que tendría que haber tenido mucho más éxito del que ha tenido. Sun tuvo en su momento la llave para triunfar en la Web, pero me temo que no la aprovechó, mientras que otras compañías como Macromedia (y ahora Adobe) sí que supieron encontrar su hueco en el mercado. Sí, los Applets ahora van relativamente bien, pero todavía te puedes encontrar con muchos problemas molestos, incompatibilidades, y un sinfín de pequeñas cosillas que te hacen perder mucho el tiempo.

Por eso David Brackeen creó PulpCore, cuyo lema lo dice todo: "Java applets that don’t suck". Se trata de un motor de renderizado y animación 2D con licencia BSD y orientado a la creación de juegos para la Web y centrado en algo que Sun olvidó en su momento: el obtener una buena experiencia de usuario.



Lo mejor para comprender qué es Pulpcore es echarle un vistazo a las demos, en especial a Milpa, aunque hay varias interesantes. PulpCore está basado en un motor de escenas que permite crear animaciones muy al estilo Flash, pero aprovechando las ventajas de Java.

En bubblemark.com tienen un análisis de rendimiento de diversas tecnologías RIA. En mi PC Pulpcore realmente arrasa con unos 200 fps, mientras que los diferentes sabores de Flash y Java se quedan muy por detrás con menos de 50fps.

¿Qué os parece? A mi se me ocurren bastantes utilidades para esta librería, especialmente para aplicaciones Web 2.0

Historia sobre una aplicación en JRuby on Rails de Oracle

Hace poco Oracle anunció el lanzamiento de Oracle Mix, la que según afirman es la aplicación más grande desplegada con JRuby on Rails.

Ayer, Rich Manalang, escribía una entrada en el blog de desarrolladores de Oracle en la que relataba lo que ha sido el camino hasta tener esta aplicación en producción.

Rich explica como después del éxito de Connect, la red social de Oracle se pusieron a trabajar en una aplicación para la Oracle OpenWorld. Tenía que hacerse en seis semanas, la aprobaron y contrataron los servicios de ThoughtWorks que puso cuatro desarrolladores con experiencia.

La lectura es interesante, aunque probablemente la parte más jugosa es la del rendimiento. Me permito traducir.

Después de tener las máquinas preparadas comenzamos a hacer los primeros despliegues de JRuby. El rendimiento era terrible. Entre 20-40 req/sec. en un único servidor de aplicaciones. Parece que no había activado algunos de los parámetros de producción (parámetros estándar para despliegues ruby). Conseguí 80 req/sec. en un único servidor... mejor, pero no suficiente. Al mismo tiempo, Ola y el equipo de JRuby encontraron algunos cuellos de botella interesantes dentro del código de JRuby. En un día o dos, Ola y el equipo habían parcheado el código y estabamos ya funcionando sobre las 150-200 req/sec. Después de que el servidor se calentase un poco las cosas se pusieron realmente interesantes... los números subieron un montón (400-600 req/sec).

Para mi una de las conclusiones que saco es que a pesar del desarrollo rápido, estas tecnologías están un poco inmaduras para determinadas cosas. A fin de cuentas, el hardware no era malo del todo: 4 máquinas doble núcleo, con 12 Gb de RAM, la base de datos era Oracle 10g y es de esperar que estuviera bien configurada :-) y aún así parece que hubo que tunear bastante. Y no todo el mundo se puede permitir el tener 4 consultores de ThoughtWorks on-site durante seis semanas. ¡Que estos ingleses trabajan más que por el bocadillo!

Este proceso que relatan es el que se está viendo en la mayor parte de lenguajes dinámicos surgidos durante los últimos años. Al final, todo tiene su tiempo. Esta gente con recursos y posibilidades va haciendo despliegues importantes y con sus recursos encontrando cuellos de botella y aportando parches. Poco a poco los lenguajes se van haciendo maduros, las máquinas virtuales funcionarán cada vez mejor, y pasarán a ser de consumo público.

Ahora bien, supongo que después todo el mundo los empezará a utilizar, dejará de ser especial el trabajar en ellos, y habrá que buscarse otra cosa mejor ;-)

Notas sobre la arquitectura de Linkedin

Una de las sesiones más jugosas de la pasada QCon 2007 fue la que presentaba la arquitectura de Linkedin. He hecho un pequeño resumen de la información que se puede encontrar en la presentación de Jean-Luc Vaillant, CTO y cofundador de la web.

Pongo aquí algunas notas que se pueden extraer de las transparencias muy al estilo High Scalability.

• 16 millones de miembros. Más de 1 millón de nuevos miembros por mes. Teniendo en cuenta que la web salió al público en 2003 habrá que asumir que esa tendencia se produce en los últimos meses.


• 50% de miembros son de fuera de los Estados Unidos.


• 30% de los miembros acceden a su cuenta cada mes. Sería interesante saber un dato sobre miembros activos cada día.


• 180 empleados.


• Da beneficios desde el 2006. Este dato también es bastante interesante.



• Principalmente es código Java, y también algo de C++ y Ruby.


• El sistema de producción es Unix (Solaris), y el de desarrollo es Mac OS X


• Oracle 10g para bases de datos críticas. MySQL para el resto.


• Utilizan Spring, ActiveMQ, Tomcat, Jetty y Lucene.



• Los diferentes algoritmos sociales ejecutados no funcionan demasiado bien BD. La única forma de obtener un buen rendimiento es ejecutándolos en memoria.


• Las aplicaciones y los diferentes grafos en memoria se sincronizan con la base de datos utilizando un algoritmo propio (databus) implementado sobre funcionalidades propias de Oracle. Tuvieron problemas con otras aproximaciones tradicionales como JMS o multicast que derivaban en el problema de commit en dos fases.


• Ese databus lo han implementado sobre HTTP con balanceo de carga. Hay un pool de trabajadores que acceden a base de datos para no sobrecargarla con demasiadas peticiones. Ningún cliente accede directamente a la base de datos.


• El sistema de caché es aparentemente propio. No nombran ningún producto en concreto.


• Índices especializados para consultas concretas


• Los diferentes motores de grafos son entidades en si mismas. Tienen un servidor RPC por el que reciben peticiones, varios sistemas para ejecutar algoritmos, un motor de persistencia para almacenar datos en disco y una librería de acceso al databus.


• Problemas al implementar el patrón de bloqueo read/write. 100% CPU. Problema: si una lectura lleva demasiado tiempo, la escritura tiene que esperar y bloquea al resto de lecturas. La solución fue migrar a un algoritmo copy-on-write.


• Determinadas redes crecen demasiado. Solución: comprimirlas para poder seguir manteniéndolas en memoria.

Nota: Justo después de escribir esto, he visto que alguien ha escrito también sobre ello.

Transparencias de QCon San Francisco 2007

QCon celebró hace unos días un evento muy interesante en San Francisco y han sido tan amables de subir todas las charlas y ponerlas a disposición del público. Bueno, realmente las charlas aparecen con un candado al lado así que no sé si se supone que iban a tener contraseña. Las de la QCon 2007 de Londres estaban protegidas, pero el caso es que en esta ocasión se pueden descargar libremente, al menos por ahora.

Así que aprovechad si queréis porque hay algunas interesantes.

Transparencia ante ataques de seguridad

Ayer se me ocurrió entrar en el blog de la compañía con la que recientemente he contratado un servidor virtual. Esto de los blogs está ya tan extendido que en muchas compañías ya es práctica habitual. Nada más entrar me topo con esto:

A very important update for everyone! It appears that earlier today a third party gained access to our mywebpayment.com billing system. Upon determining that there might be a security breach we immediately terminated the access to everyone by disabling the billing website. At this time we’re still uncertain as to the total scope of the data they accessed. We are going to be as transparent as possible about what happened, what our plans are to correct it, and also how we plan to make sure that this never happens again.

Ups. Nudo en la garganta. La nota sigue:

To start with it appears that the breach was made through some malware/spyware installed on an employee’s office computer. His username and password for the billing system were stored in a document unencrypted on his computer. This information was used to access parts of our billing system that, in retrospect, should have been protected better.

Esos programas que nos descargamos por ahí...

We are certain that credit card numbers were not exposed, however we do know that a limited number of email addresses and plain text passwords were exposed. We highly recommend that if your PayPal password was the same as your Spry password that you immediately change it. While no paypal passwords are ever provided to us, it is likely that many users have chosen the same password for their paypal account and their account at Spry...

Vale. Yo he pagado con Paypal y mi password es diferente, así que aparentemente estoy a salvo, o eso espero.

El caso es que me ha llamado la atención que el ataque haya sido expuesto de forma tan abierta. Por mi parte un diez para ellos por hacer públicos este tipo de ataques, ya que a fin de cuentas seguro que nos ibamos a enterar por otros medios. Siempre es mejor ir con la verdad por delante. De este modo futuros clientes saben que en caso de haber algún problema se sabrá por el blog de la empresa. Ahora bien, tirón de orejas porque el blog no ha sustituido al email, al menos que yo sepa, y no me ha llegado ningún tipo de notificación al correo electrónico.

Quizás es que quieren aumentar las visitas de su blog :)

Caso friendster: ¿Fueron los programadores o los directivos?

En High Scalability siempre ponen noticias interesantes sobre rendimiento, escalabilidad, fiabilidad, etc. Pero hace unos días, publicaron la noticia de el fracaso de Friendster a la hora de escalar e indirectamente ha derivado en una discusión sobre quién tuvo la culpa del fracaso. ¿Quién no supo escalar, programadores o directivos?

El enlace de High Scalability nos lleva a una entrevista en Venture Beat en la que Jim Scheinman (ex-Friendster y ex-Bebo) comenta que Friendster falló a la hora de escalar. Más concretamente, que al ser una compañía pionera, afrontó muchos retos que no pudieron resolver debido a la inexperiencia y a la inhabilidad para escalar tecnológicamente.

For me, it basically came down to failed execution on the technology side — we had millions of Friendster members begging us to get the site working faster so they could log in and spend hours social networking with their friends. I remember coming in to the office for months reading thousands of customer service emails telling us that if we didn’t get our site working better soon, they’d be ‘forced to join’ a new social networking site that had just launched called MySpace…the rest is history.

Ahora bien, John Allspaw que trabajaba en el equipo técnico de Friendster en la época está en desacuerdo con Jim. John afirma que actores como que la gente tuviense que registrarse para simplemente ver páginas, o empeñarse en crear un cliente de mensajería instantánea en esa época y que nunca vio la luz, o calcular en tiempo real los 3 o 4 grados de confianza de tus amigos, fueron decisivos para estrangular tecnológicamente a una compañía y le permitiron escalar en lo que quería realmente la gente: utilizar su web.

- Once your social network was built on Friendster, there was little left to do, and there was a lot of floundering around guessing as to what could be added to the site to keep users engaged. An integrated IM platform was worked on in-house for months until finally scrapped as a lost cause. Then a couple months later, restarted the project as an outsourced/managed application. Features that were intended on harnessing the reputation/suggestions that were built-in to the social graph were only talked about, never materialized. (i.e., like Yelp!)

Mientras tanto, Jonathan Abrams, fundador de Friendster comentaba hace poco sus nuevas aventuras en Wired y también hablaba sobre la escalabilidad y Friendster. Jonathan hablaba en este caso sobre como en sus proyectos actuales están evitando hacer un uso excesivo de AJAX para no caer en errores del pasado:

There are some things on Socializr that look like Ajax, but actually are not. They're using JavaScript, they're providing a dynamic-feeling user interface, but they're actually not asynchronously requesting data from the server. Most of the data is sent in the initial page request, and then there's a more dynamic user experience, but we're not making a lot of asynchronous calls. And that's deliberate, to address scalability concerns, because of having gone through the Friendster experience.

Another thing is that I think some of the ways people are using Ajax now actually makes the user experience worse, rather than better. There are so many sites where you click on something and they use that thing where the background fades and then this window pops up in a sort of modal dialog, and it's completely intrusive. It poses an unnecessary delay, because you have to wait for this animation to happen that really adds no real value. It's just a trendy Ajax effect that everybody seems to be copying from each other. And, you know, that's not what our style is.

La verdad es que se pueden aprender muchas cosas tanto del éxito como del fracaso. Ahora bien, probablemetne andarse echándose las culpas unos a otros no sea lo más oportuno. Por los comentarios de las diferentes historias, me inclino a pensar que el problema en la época fue más bien de dirección que tecnológico, a fin de cuentas ya había empresas en esos momentos afrontando problemas similares de carga. ¿Vosotros qué creéis? Sea como sea está claro que debieron aceptar la oferta de 30 millones de dólares que en su momento hizo Google.

Patrones de acceso y las 10 mejores maneras de estropear la escalabilidad y fiabilidad de Java

Ayer estuve viendo el video que han publicado en Parleys de Cameron Purdy en la JavaOne 2007: "Top 10 Ways to Botch Enterprise Java Applications", y lo cierto es que es una charla muy recomendable. En la línea de la presentación que ya hiciera en la JavaOne del 2006 "Top ten ways to create a real J2EE disaster" y de la que ya hablara en mi abandonado blog en inglés (lagrimilla, sí, ... pero que verguenza de inglés).

Aquí hay un buen resumen de la charla así que me puedo ahorrar casi todos los comentarios. El caso es que el patrón número 10 me ha recordado mucho lo que hacemos, ya que es exactamente uno de los problemas que tenemos, y es de eso de lo que quería hablar. Se trata de la importancia de tener en cuenta los patrones de trabajo de una aplicación, es decir, que si uno simplemente asume que todos los datos son iguales y los trata por igual se puede llevar una sorpresa.

Como comenta en la transparencia 11, el negocio de Foreign Exchange se basa en la compra y venta de divisas. Sin embargo, la realidad es que la mayor parte de las operaciones se realizan sobre euros y dólares ya que es donde hay más volumen comercial. ¿Cómo afecta esto? Os pongo un ejemplo.Un sistema de Foreign Exchange normalmente tendrá un montón de órdenes en el sistema puestas por los traders para comprar y vender, ganar posiciones o retirarse. Esas órdenes se procesan en tiempo real con cada latido del sistema con lo que se genera tal enorme carga de CPU que se ha de distribuir la evaluación entre diferentes nodos de un cluster.

Ahora bien, si alguien que no conoce el negocio se pone a diseñar el sistema puede decidir que la evaluación de cada par de divisas se haga en un nodo del cluster. La consecuencia es que el 40% de la CPU la consumirá una única máquina que será la que evalue el par EUR/USD, mientras que a lo mejor otras 20 máquinas están consumiendo el otro 60% del volumen del mercado evaluando órdenes para divisas que no son tan utilizadas.

No me enrollo más. La charla son 50 minutillos y la verdad es que vale la pena.

Dryad, la alternativa a MapReduce de Microsoft

En un comentario a la entrada anterior sobre GigaSpaces, Diego apunta que las arquitecturas existentes para trabajo en grid son todavía insuficientes por ser demasiado explícitas obligando a las compañías a invertir mucho tiempo en gestionar algoritmos de computación distribuida.

Parece que lo mismo pensaron en Microsoft cuando estaban diseñando Dryad, una abstracción creada sobre los fundamentos del álgebra relacional y el algoritmo Map and Reduce de Google y que permite la ejecución distribuida de grafos de trabajos en clusters. Ellos explican mejor lo que hace:


Dryad is quite expressive. It completely subsumes other computation frameworks, such as Google's map-reduce, or the relational algebra. Moreover, Dryad handles job creation and management, resource management, job monitoring and visualization, fault tolerance, re-execution, scheduling, and accounting.

La idea del framework es que el programador se dedique simplemente a preparar el grafo de trabajos y que el cluster Dryad haga el resto. Lo interesantes de Dryad son las abstracciones que ofrece. Parece que es capaz por ejemplo de ejecutar el mismo trabajo en varios nodos y quedarse con la salida del que acaba más rápido, o reejecutar un trabajo si se produce algún error, etc. Uno de los ejemplos que ponen es como integraron Dryad con SQLServer para ejecutar los planes de las queries de manera distribuida en un cluster Dryad.

Michael Isard de Microsoft Research dio una charla en Google bastante interesante y en la que explica como funciona el framework. Por cierto, no deja de ser curioso esto de que los ingenieros de Microsoft den charlas en Google :)

Si os interesa entrar en más detalle también tienen esta publicación: Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks

GigaSpaces ofrece gratis su plataforma a Startups

Hoy me he sorprendido leyendo que GigaSpaces ha decidido ofrecer su plataforma XAP (Xtreme Application Platform) a Startups por el módico precio de ... 0€!!! tal como se puede leer en el FAQ del recientemente lanzado GigaSpaces Start-up Program. Nati Shalom, fundador de la compañía y Geva Perry también hablan de este programa.

Wow! La verdad es que este anuncio sí que es sorprendente. Pocas veces una empresa decide regalar sus productos sin ningún tipo de restricción ni de funcionalidades ni temporal, para uso en producción, en cualquier número de CPUs y en cualquier número de servidores, etc. Parece que no hay trampa ni cartón. Bueno, sí, hay una, la empresa para optar a esta oferta no puede haber ganado más de 5 millones de euros en los 12 meses antes de aplicar a esta oferta. ¿Y que pasa en cuanto la empresa llega a los 5 millones de euros? Pues nada. Santa Rita Rita, lo que se da no se quita. Una vez entregada la licencia ésta dura de por vida y tanto da los beneficios que tenga la Startup en un futuro.

Lo único problemático es que GigaSpaces se reserva el derecho a aceptar o no a una empresa dentro de este programa. Pero de todos modos esta tiene que ser una opción muy, pero que muy atractiva para muchísimas compañías que estén empezando. Yo, desde luego si tuviese una Startup no perdería esta oportunidad. GigaSpaces es un producto que se está utilizando hoy por hoy en muchísimos sistemas que requieren enormes cargas de computación y prácticamente es ubicuo en los grandes bancos de inversión y compañías dedicadas al software financiero.

Ahora bien, una vez que uno se recupera del "shock" de ver como una compañía como GigaSpaces decide regalar su producto, uno se pregunta ¿por qué? Se me ocurren varias ideas. Por una parte, GigaSpaces propone un modelo de computación radicalmente diferente a J2EE, que aunque no es algo que sea completamente incompatible, lo cierto es que siempre añade un grado de complejidad especialmente a la hora de integrarse con todos los sistemas J2EE existentes. Quizás la adoptación del producto no sea la esperada y con este sistema esperan adquirir más adeptos. La otra idea que se me ocurre es que Oracle esté regalando Tangosol y que los clientes no compren GigaSpaces porque Oracle ya les da gratis algo similar. Esto no sé si será muy probable porque la adquisión de Tangosol ha sido demasiado reciente y ya se sabe que estas cosas requieren un cierto tiempo de adaptación.

Pero vaya, sea la razón que sea, pues que es una ganga señores. ¿Alguien que vaya pedir una licencia?

IJTC 2007, día 3

Bueno, este es el último post de esta serie sobre la Irish Java Technology Conference, un poco con retraso por eso del fin de semana.

La primera ponencia a la que fuí el pasado Viernes fue la de Richard Bair sobre "Filthy Rich Clients". La ponencia fue muy interesante. Es la misma que presentaron Chet Haase y Romain Guy en la JavaOne 2007 en la que presentaban montones de trucos para incrementar el rendimiento de Swing y que se pueden encontrar también en el libro que lleva el mismo nombre. Hubo montones de demos y efectos especiales, y también mucho código fuente explicando todos los trucos. La principal conclusión que saqué es que está claro que una empresa necesita una o dos personas que se dediquen exclusivamente a estas cosas ya que la diferencia entre aplicaciones que tengan estos pluses de efectos y rendimiento y las que no lo tienen es simplemente abismal.

A continuación pude disfrutar de la charla de James Strachan, "Enterprise Messaging with ActiveMQ". Me encanta este hombre. Sus ponencias son realmente amenas. ActiveMQ realmente es un producto muy interesante y ofrece montones de características que suman valor añadido a una solución JMS. Muy buena.

El siguiente ponente fue Dejan Bosanac, el autor del libro Scripting in Java y que habló de "Scripting with Balance in Design and Performance". Bueno, o al menos lo intentó, porque realmente hubo poco scripting y menos balance, design y performance. Una pena porque el tema era interesante.

Finalmente, acabé las sesiones con Ronan Gerarthy de Microsoft Ireland que presentaba una ponencia titulada "Application lifecycle management in a Java/.NET environment" y que también resultó bastante interesante. No era sobre Microsoft en sí misma sino como era el proceso que venían siguiendo y las herramientas que utilizaban.

Nos explicó como usaban el Team Foundation Server de Microsoft para gestionar el ciclo de vida de los proyectos y como se podían utilizar diferentes herramientas como Microsoft Project, o Microsof Excel para actualizar la información de los proyectos almacenada en TFS. Finalmente mostró como los desarrolladores, incluso desde Java podían utilizar Teamprise para mantener al día toda la información de su trabajo accediendo al TFS desde Eclipse con esta herramienta.

La ventaja fundamental era que se podían utilizar las herramientas que la gente estaba más acostumbrada a utilizar (PMs, BAs, desarrolladores, etc.) y que después con el SQL Server instalado en TFS y sus funcionalidades de Data WareHouse se obtenían informes mucho más indicativos de la salud de los proyectos y que permitían diagnosticar rápidamente el estado de los mismos.

Y todo esto fue lo del último día. En general creo que ha sido un evento bueno y aunque se podían mejorar algunas cosas pues ha valido mucho la pena. Habrá que ver el año que viene que tal.

IJTC 2007, día 2

Hoy estoy un poco de malas porque tenía un montón de notas cogidas y perdí el bloc de notas. Y claro, como es un cine cuando fuí a recogerlo ya habían pasado las de la limpieza y no había rastro de él. En fin, que mejor excusa para hacer este resumen.

El día de hoy ha estado realmente bien. Un poco de falta de organización, pero que demonios, las charlas fueron muy interesantes y además había descanso después de cada charla con comida y bebida a cuenta de la organización, así que nada de lo que quejarse. La verdad es que todas las charlas a las que he ido me han gustado, y aún así me quedaron un par de charlas a las que me habría gustado ir. Pero es que había tres tracks diferentes con cinco charlas cada una y no se podía ir a todo :(

Comencé el día escuchando a Simon Cook con su "Java Update". Era la primera de la mañana y no había mucha gente, pero estuvo interesante de todos modos. Trató las novedades de Java 6 y Java 7, y lo más interesante para mi fue los últimos 10 minutos que los dedicó a petición de la sala a hablar de Java Realtime. No hay mucho que destacar. Más o menos la charla se centró en lo mismo que comentaba ayer, es decir la presencia cada vez más destacada de los lenguajes de scripting, y el convencimiento de que la máquina virtual ejecutará diferentes lenguajes en el futuro.

También habló bastante sobre el consumer JRE y explicó con detalle como funcionará. Como muchos ya sabréis el nuevo plugin carga las clases bajo demanda; se carga un núcleo principal y después el plugin va cargando las clases que no encuentra con lo que se consigue un tiempo de lanzamiento mucho mejor. Eso sí, un "Hola mundo" ocupa 1Mb. Al final de la charla le comenté los problemas que habíamos tenido con los applets y parece que esta carga bajo demanda no debería afectar. Otra cosa interesante es la nueva API de despliegue. Es una librería de javascript que permite especificar exactamente las versiones del JRE que queremos utilizar para cada aplicación en concreto.

La siguiente charla a la que fuí fue la de Richard Bair. Realmente una persona muy simpática que hizo la charla muy amena. Estuvo hablando sobre el consumer JRE, nuevamente protagonista, pero también sobre Java 2D y JavaFX. Mostró un montón de demos y también algo de código JavaFX que realmente promete. Parte de su charla se centró en resaltar que los applets pueden tener una nueva oportunidad con JavaFX. Ya que a pesar que se supone que con Java 6 la experiencia es mucho mejor pues con Java FX se intentará disponer de APIs que realmente se echan de menos para competir con flash como son un buen soporte de SVG, facilidad de uso de Java 2D y sobre todo librerías para tratamientos de media, en especial videos. Una de las notas interesantes es que el API de video se está diseñando ya especialmente pensada sobre JavaFX como un requisito fundamental, y que sólo en una versión posterior se verá como integrarla mejor con aplicaciones normales.

La tercera charla fue la de Guillaume Laforge sobre Groovy. Guillaume explicó los fundamentos de este lenguaje y las ventajas de que funciona directamente sobre la máquina virtual como el poder utilizarlo como motor de scripting para reglas, o el mezclar objetos Java y Groovy sin ningún límite, o el utilizar en Java features que todavía no están ni planeadas para el futuro, y este tipo de cosas. También se paró un poco en las desventajas como la pérdida de rendimiento.

Fue interesante uno de los casos de éxito que comentó, Mutual of Omaha, una empresa del Fortune 500 y en la que implantaron un motor basado en Groovy y en el que se desplegaron más de 50.000 líneas de código Groovy. Lo más interesante es que en el despliegue de código participaron tanto desarrolladores principiantes, como expertos, como, y he aquí lo interesante, personas que no tenían ni idea de programar. Casos como éste parecen demostrar, al menos en teoría, la utilidad de este lenguaje para la creación de DSLs y su capacidad de ser utilizados por no-programadores. En Internet buscando el nombre de la empresa, que no me acordaba, he encontrado otro listado con casos de éxito de Groovy.

La cuarta charla fue la de Stephen Farrell que se llamaba "Delivering Scalable, Lighweight Mobile Java technology to Millions of Users". Esta fue interesantísima. Stephen nos contó como trabajan en NewBay y nos habló del reto que era proporcionar contenido a millones de móviles y sobrevivir en el intento. Básicamente, esta compañía se dedica a almacenar, gestionar y proporcionar acceso, a modo de aplicaciones sencillas como blogs, a imágenes, videos, SMSs, llamadas, etc., y cualquier tipo de contenido que los usuarios pueden enviar a sus proveedores.

Lo que hace especial a estos escenarios es que conforme las redes mejoran, y los fabricantes de móviles añaden megapixels y megapixels, los retos aumentan. Hasta nos comentó que internamente manejan la medida de "sh1tabyte" que viene a significar "a shit a load of bytes" :-) Su stack se basa en Open Source y Java: Lucene, Hibernate, Spring Web Flow, Struts, SwiftMQ, JMagick, etc. y nos explicó algunos de los trucos que utilizan como evitar el almacenar estado, el desplegar diferentes funcionalidades de trabajo de imágenes en diferentes servidores, etc. Realmente muy interesante.

Y por último vi a James Strachan hablando sobre Apache Camel. Espectacular ponente. Realmente lo hizo muy bien, y su charla fue muy amena. Puedo decir que entré sin saber realmente lo que era Apache Camel y que ¡salí convencido de querer utilizarlo! ¿Alguien lo ha utilizado? Porque en serio, parece un API espectacular. En teoría es una implementación de los patrones del libro Enterprise Integration Patterns construida sobre Spring, y compatible con un montón de sistemas diferentes.

Creo que Apache Camel se merece uno, dos, o tres post en si mismo. La idea de definir tener todos esos endpoints y definir un bean en Spring (o una línea de código Java) para copiar objetos de una cola a un fichero; leer datos de un tópico, transformarlos con JAXB y pasar volcar esos objetos a base de datos; o leer datos de IBM MQSeries, transformarlos a javabeans, convertir eso en texto con freemarker y enviarlo por email, y todo ello definirlo en una única línea de código o en un par de líneas de configuración XML es simplemente demasiado tentador como para no echarle un vistazo. Realmente me dejó impactado.

En fin, que me parece que ha sido un día muy productivo. Salgo con varias ideas interesantes que me gustaría probar. A ver si el día de mañana es también productivo en cuanto a ideas.

IJTC 2007, día 1

Ayer fue el primer día de la Irish Java Technology Conference, y aunque no puedo decir que haya estado muy bien, tampoco ha estado muy mal (sabéis que soy gallego, ¿no?).

Uno de los aspectos negativos (o no, según como se mire) es que se notaba que es un evento organizado por aficionados. El sitio no acompaña mucho para un evento de este sitio, un cine, aunque hay que decir que las salas son enormes y con muy buen sonido. Sin embargo, claro, los stans están en unos sofás, la gente que va al cine está por el medio, y todas estas cosas. Kudos de todos modos para la organización por ofrecer consumiciones gratis ;-)

Respecto a las charlas, pues me esperaba un poco más. Primero fue Joel Spolsky que era al que yo quería ver, pero resulta que al final volvió a dar la charla que ya había visto en el 2006. Eso sí, estaba actualizada. En lugar de poner de ejemplos a Angelina Jolie y Brad Pitt ponía a David y Victoria Beckham; en lugar de comparar un iPod con un Creative Zen, comparaba su teléfono (no recuerdo la marca) con un iPhone y volvía a poner el ejemplo de tener menos funcionalidad y de que el iPhone no tiene batería. Mismas fotos, misma música, mismos videos, ... Una pena, para mi claro, porque otra gente sí la disfrutó.

Finalmente hubo un panel bastante interesante pero que se hizo un poco largo. Se sacaron a la mesa varios puntos como la ausencia de soporte de Java en los últimos lanzamientos de Apple, los lenguajes de scripts, la facilidad de uso de la plataforma, vamos más o menos lo típico. El tono de fondo fue un poco crítico, que más o menos es lo que estamos ya acostumbrados en los últimos años.

Yo me quedaría especialmente con un punto que sacó Shaun Smith de Oracle y es que la gente ahora sale del colegio o de la Universidad y prefiere hacer cosas en otros lenguajes como Ruby, PHP, Python que en Java; que hay ciclos en los lenguajes y que poco a poco éstos se hacen más y más complejos dificultando mucho la entrada de las nuevas generaciones que como consecuencia migran hacia lenguajes más sencillos (e.g. Ruby), y que es algo que ya pasó en el pasado y que parece que está pasando ahora mismo. Todo esto derivó un poco en recalcar que en un futuro la plataforma evolucionará hasta permitir la ejecución de lenguajes más sencillos de manera nativa en la JVM de forma que se pueda aprovechar los billones de líneas de código existentes pero utilizando lenguajes más sencillos y productivos.

A ver como va el día de hoy.

Amazon S3 en Europa, 10 millones de objetos y algunas notas

Leyendo el blog de Diego Parrilla me entero de que Werner Vogels, CTO de amazon, ha anunciado que ya es posible contratar los servicios de S3 usando servidores que estén en Europa. Buenas noticias para todos los negocios que estaban ya utilizando S3 y que tendrán un buen empujón a sus estadísticas de rendimiento y latencia (suponiendo que se pueda migrar fácilmente de USA a Europa si ya eres cliente, algo que es de esperar), y también para todo el que planease utilizar los servicios de S3 para aplicaciones orientadas al mercado europeo.

No hay duda que los servicios de Amazon están siendo un éxito. Ayer leía que ya hay más de 10 billones de objetos almacenados en su servicio S3, cifra realmente impresionante y que ya citó Mike Culver en la charla que dio en Dublin hace una semana.

John O'Shea tiene un muy buen conjunto de notas sobre esta charla y en las que se pueden leer algunas curiosidades como que las imágenes de sus servicios están basadas en Fedora 4, que el servicio de Flexible Payment Service sólo disponible en USA lo estará también en Europa en un futuro y que Amazon S3 no coloca automáticamente las cabeceras de caché (ETag, Last-Modified), algo un poco "dodgy" como dirían por aquí.

OpenSocial, ¿lanzamiento prematuro?

Tras el anuncio de OpenSocial y los primeros alagos no han tardado en aparecer las críticas debido a la falta de seguridad de la API. Techcrunch ya anunciaba que habían hackeado la primera aplicación en 45 minutos, y hoy vuelven a anunciar otro hack más.

En un artículo en RegDeveloper critican también la falta de seguridad de la plataforma y citan para ello varias referencias, además de citar a la plataforma OpenQabal que pretende hacer lo mismo que OpenSocial y que ya había sido anunciada con anterioridad aunque evidentemente sin el mismo impacto publicitario.

A veces los lanzamientos dirigidos por acciones de la competencia (se rumorea que el lanzamiento de OpenSocial se ha acelerado debido al golpe de efecto de Microsoft con Facebook) pueden salir mal. ¿Será el caso de Google? Yo no lo sé, pero me da a mi que Google está por encima del bien y del mal en cuanto a todo esto.

Sobre feeds y la protección de contenidos

Hoy, no recuerdo bien como he llegado a un producto que me ha llamado la atención. Se trata de Attributor un producto que rastrea Internet buscando violaciones de contenido, es decir, sitios que agregan directamente tus feeds buscando sacar un beneficio monetario, personas que copian tus artículos y los publican como si los hubieran hecho ellos, videos o imágenes utilizados sin permiso, y todo este tipo de cosas.

Evidentemente todos queremos proteger nuestros contenidos, especialmente si nos ha costado bastante trabajo el generarlos. Por cierto, que esto me recuerda una anécdota en la que un amigo me alertó de que alguien había publicado un artículo en la revista de una empresa bastante importante muy parecido a un artículo que publicamos yo y Alberto hace ya demasiado tiempo (por cierto, fenomenal cambio de look en jh, pero es una pena que mucho del contenido antiguo se haya perdido). Investigando un poco me encontré que esta persona había copiado y pegado literalmente partes del artículo montando un collage al que le había puesto su nombre.

Pereo en fin, eso es otra historia. El caso es que al leer en este producto que Reuters parece que lo va a utilizar me ha recordado lo sensibles que son estas compañías con sus servicios y las oportunidades de negocio que pueden surgir en torno a ello.

Más concretamente, en las últimas semanas he comprobado en mi propia piel las pocas facilidades que te ofrecen estas compañías a la hora de proporcionarte acceso al contenido que generan. Uno que es inocente al principio piensa, "nada, acceso por RSS y listo". Pues no. Cualquier cosa menos soluciones sencillas: autenticación, bloqueo de IPs que puedan acceder al contenido, construcción de proxies para desplegar el contenido utilizando un API propietaria que prevenga el convertirse en hub de la información de estas compañías.

Más o menos eso ha sido con lo que me he encontrado estas últimas semanas, y la verdad es que parece que hay por ahí un hueco en el mercado, o al menos dentro de los feeds para mercados financieros en los que es realmente importante el ser el primero en obtener la información para obtener una ventaja competitiva. La mayor parte de servidores de feeds disponibles del mercado parten de un supuesto "optimista" que es que "todo el contenido es público", así que podría haber por ahí un hueco para un servidor seguro, con encriptación, certificados, firmas, autenticación, APIs, bloqueos, etc. Me da la impresiónás de alguna compañía estaría seguramente interesada, tanto proveedores de noticias como clientes de estos proveedores.

Ahí queda la idea por si alguien se anima :-) , aunque quizás ya conozcáis algún producto similar....

Una razón algo más técnica para no escribir métodos largos

Hoy en día creo que más o menos todo el mundo tiene claro que escribir métodos muy largos es una mala práctica. Nos lo dicen en la universidad, nos lo dicen en los libros de programación, de ingeniería del software, de patrones o de refactorización. Los paquetes de métricas y de detección estática de errores nos avisan de que nuestros métodos son demasiado largos y el jefe nos echará una buena bronca si ve que hacemos un método de 5.000 líneas.

Aún así, cuando uno está programando siempre hay esos momentos en que se siente un poco vago con algún método al que va añadiendo cosas y cosas, porque total, estamos haciendo sólo un boceto, ¿no? El problema es que esos bocetos se convierten en la versión definitiva (doy fe, que tengo un par de métodos grandes por ahí que verguenza me dan) y ahí ha quedado. Pero bueno, funciona, ¿no?. Y no lo va a tocar nadie nunca jamás de los jamases, ¿no?, ¿qué hay de malo entonces?. Pues sí, incluso creyéndonos que nadie verá ese código nunca, hay algo que puede ser malo:

Hoy en día los lenguajes populares se ejecutan en máquinas virtuales. Estas máquinas virtuales disponen de optimizadores que traducen el bytecode de nuestros programas en código máquina, pero que además realizan numerosas optimizaciones sobre el mismo para obtener mucho más rendimiento. Estas optimizaciones no sólo se limitan a reordenaciones, inlining y todas estas cosas sino que en algunos lenguajes como Java (no sé si en otros, supongo que sí) se almacenan mapas de objetos en los que se especifican donde se encuentran los objetos a los que apuntan las referencias: la referencia A está en un registro, la referencia B está en la pila, etc.

Dicha información se utiliza durante la recolección de basura para acelerar la ejecución. Si no se dipone de esos mapas de objetos en el momento de la recolección, el recolector los tendrá que crear por si mismo. Para crear estos mapas, el recolector trata de simular la ejecución del método en relación a la posición de la referencia que se pretende recolectar. A métodos más grandes, simulaciones más complejas. Por cierto, que además la simulación depende de en que línea salte la GC así que aunque los mapas se guardan, ésto no sirve de mucho si el método es grande.

¿Y qué tiene que ver esto con el tamaño de los métodos? Pues resulta que Java tiene un límite para el tamaño de los métodos a los que el JIT aplicará optimizaciones. Si los métodos sobrepasan ese límite no pasarán por el JIT, y por lo tanto estos mapas de objetos no se generarán, y por lo tanto la recolección de basura será mucho más larga de lo que debería ser. Más concretamente el límite son 8000 bytes de bytecode. Para deshabilitar este límite en la máquina virtual de Sun, se puede usar la opción "-XX:-DontCompileHugeMethods". Pero ojo, esto no es una buena idea ya que lo más probable es que el JIT también sufra a la hora de optimizar, a fin de cuentas si el límite lo han puesto así será por algo. Así que mejor refactorizar y hacer más métodos y más pequeños.

Bueno, ahora igual he engañado a alguno que estará pensando. ¡Qué listo es Martín, cuanto sabe! Pues no. Todo esto no me lo he encontrado, ni lo he vivido, ni nada de nada. No es más que un resumen, bueno más bien una traducción porque me ha quedado bastante largo, de lo que cuenta el genial Jon Masamitsu en su blog, en el que ha publicado una entrada en la que explica algunas experiencias que le han pasado con clientes, relacionadas con parámetros raros de la máquina virtual. Entre estas experiencias está la de un cliente que veía que los tiempos de GC eran enormes y que no sabía por que, pero que de pronto descubren que comentando el código los tiempos de GC son mucho menores.

Pues ya sabéis, ahroa si alguna vez habláis con alguien sobre esto de los métodos largos, y os dice que eso de la refactorización no son más que chorradas, os podéis sacar de la manga esta explicación que es de las de dejar con la boca abierta.

Los sin sentidos de VMWare respecto al Open Source

O quizás debiera haber titulado este post "Los sin sentidos de Diane Greene...". Dian Greene es la CEO de VMWare y que durante estos dos últimos días ha recibido feroces críticas de The Register a raiz de una entrevista que mantuvieron con ella recientemente.

En la entrevista la dejan fina. Pero, en una entrada de hoy mismo, tampoco se quedan cortos. VMWare es ya la quinta empresa de software más valiosa del mundo, (se excluye IBM y Google) al menos siguiendo las valoraciones de la bolsa de Nueva York, y tras dos meses en la bolsa ha roto toda las expectativas y su capitalización en mercado ya es de 38 mil millones de dólares.

Pero parece ser que el éxito lleva a la extravagancia (tener una cascada en la sala de reuniones parece suficientemente extravagante) y que los medios dudan de la capacidad de Diane para dirigir la compañía por su falta de diplomacia y de saber estar ante los medios.

Y es que la CEO de VMWare no se corta a la hora de atacar a sus competidores y en especial de despreciar al Open Source con sus últimas declaraciones:

"What we want to do is fund ourselves to be able to build new stuff. If you're purely open source, there is no way you can do new stuff."

Parece que a pesar de ser la niña bonita de Wall Street, VMWare tiene miedo de Xen, compañía que arrasa en el mundo de los servidores virtuales y que poco a poco, y sin hacer tanto ruido se está haciendo con parte del mercado. Como resaltan en la columna de opinión que destacaba anteriormente, lo cierto es que VMWare está actualmente en una posición en la que no tiene que hacerle guiños a nadie, pero ¿es realmente necesario embarcarse en este tipo de luchas?

IJTC 2007 en Dublin

Por fin hay un evento importante sobre IT en Dublin, porque han sido dos años bastante escasillos.

Se trata el IJTC 2007. Un evento Java organizado por el grupo de usuarios de Java de Dublin y al que aunque muchos de los participantes son locales sí que vienen algunas personas conocidsa como Joel Spolsky (Fog Creek), James Strachan (Apache), Emmanuel Bernard (Hibernate), Guillaume Laforge (Groovy) o Mark Proctor (Drools).

Se trata de un evento de pago, aunque no demasiado caro. Unos 190 euros online. No está mal para tres días de conferencias y una agenda movida. Una de las cosas más curiosas es que el evento se va a celebrar en un cine. El formato de las salas es muy bueno para este tipo de eventos, pero tengo curiosidad por saber si han dejado sin cine a toda la zona (bastante céntrica y unos cines muy populares) o si los asistentes estarán mezclados con adolescentes cargados de palomitas y gominolas.

Bueno, esperemos que haya más iniciativas como esta.