La típica discusión sobre escalabilidad en la web: Java vs. php, perl, ruby, etc...

La verdad es que el título de esta entrada no es demasiado original y simplemente viene a recoger lo que en mi opinión ha sido uno de los debates del mes en algunos de los sitios web que visito. El que empezó todo el lio fue Nati Shalom, CEO de GigaSpaces (de la que ya hablaba el otro día), que publicó un incendiario post con el título Why most large-scale Web sites are not written in Java.

Bueno, está claro que se trataba del típico post que iba a desencadenar una ida y venida de opiniones y en su momento no quise hablar de ello, pero creo que ahora es un buen momento. Y es que me parece que a raiz de este post pues ha surgido mucha información que hoy han recopilado en InfoQ. Concretamente, el post que se puede leer en Artima es bastante interesante y saca diferentes puntos clave dentro de toda esta historia como son:

• Muchos sitios web "high-scale" corren sobre Java. Ejemplos son ebay o amazon.


• Lenguajes como php, perl, ruby permiten crear rápido aplicaciones, y en la web el ser el primero es muy importante.


• Hay una gran diferencia entre las aplicaciones orientadas a la web y otro tipo de aplicaciones orientadas más al mundo de la empresa. Los requisitos son diferentes y como es de esperar los lenguajes escogidos serán diferentes. eBay no tiene los mismos requisitos que Facebook ni éste los de la Wikipedia. Un martillo no quita tornillos y un desatornillador no clava clavos (y si lo hace, lo hará peor).


• Cuando se lee algo hay que tener en cuenta los intereses del que lo escribe. Pongo esto por las contestaciones de Cameron Purdy que parecen sacar a la luz algo que no se ha hablado y es el interes de GigaSpaces por promocionar sus soluciones.

No sé si vosotros opináis lo mismo, pero personalmente con este tipo de discusiones a mi me resulta más interesante el resumen de los comentarios que la discusión en si misma, que ya se sabe de antemano que no tiene mucho sentido.

Linkedin para recruiters

Tenía pendiente comentar una cosilla que me ha venido pasando estas últimas semanas y que me parece interesante, y es que esta semana he eliminado mi teléfono móvil de Linkedin.

"Uy, ¡qué interesante! pensaréis."

O quizás aún mejor: "Hay que ser burro para poner el teléfono en Linkedin". Pues la verdad es que un poco sí.

Pero el caso es que era algo que no me vino mal hace meses, especialmente para que amigos recogiesen el teléfono, para que te llegase alguna oferta de trabajo esporádica, etc. Normalmente además las ofertas que te suelen llegar por Linkedin suelen ser más interesantes que las que te puedan mandar por haber subido tu curriculum a algún sitio de empleo, simplemente por el hecho de que Linkedin nunca fue una herramienta demasiado conocida por los recruiters, así que normalmente el que te ofrecía trabajo sabías por lo menos que era alguien bastante "espabilado".

Pero bueno, la verdad es que conforme ha avanzado este año el número de llamadas para ofrecerme trabajo se ha incrementado casi exponencialmente hasta convertirlo en una situación bastante molesta. La conversación con el último fue muy simpática:

- Hola, bla bla bla, esta compañía está muy interesada en este perfil y bla bla bla.
- Sí, perdone pero es que yo, la verdad, es que no estoy buscando trabajo.
- No, no hombre no te preocupes que no es nada malo. Es que mira, yo soy un HeadHunter. Tu no tienes la culpa de nada.
- Ya, pero es que no estoy buscando trabajo.
- Ya, ya hombre, pero es que estas cosas funcionan así. Bueno, ¿puedes mandarme tu curriculum y así se lo puedo enviar a esta empresa?
- Bueno, perdone, casi mejor que me mande un correo y si tal cuando busque trabajo ya me pongo en contacto con usted. Por cierto, ¿cómo ha conseguido mi teléfono?
- Linkedin.

Bueno, había que preguntar no fuera a ser que viniera por algún amigo. En fin, que la verdad es que si alguien está buscando trabajo, pues no es una mala idea registrarse en esta web. Bueno, no es por hacerle publicidad, pero supongo que con Facebook (que está de moda esta semana) y con otras como la española Neurona pero a menor nivel, pasará más o menos lo mismo.

Investigando un poquillo (sólo un par de googles) me he encontrado con algunos artículos sobre el tema, eventos e incluso un libro sobre recruiting en Linkedin.

Moraleja, mejor por email.

Grid vs. Spaces; Oracle Coherence vs. GigaSpaces

Ambos, Oracle Coherence y GigaSpaces, son dos de los productos más utilizados en el mundo de las finanzas, en especial en el ámbito de trading (equities, derivatives, funds, fx, ...). Ambos comparten la idea de poner los datos lo más cerca de la aplicación de manera que sea posible para minimizar la latencia asociada a la obtención de los mismos (i.e. acceder a base de datos, a un servicio remoto, etc.). Sin embargo, el transfondo e historia de ambos productos es diferente y merece la pena echarles un vistazo.

Por una parte Oracle Coherence es un producto que creó la compañía Tangosol adquirida por Oracle este mismo año. La compañía fue fundada en el 2000 por Cameron Purdy, alguien que desde siempre ha sido un asiduo participante en los foros más conocidos del sector, y que en su momento localizó una necesidad en el mundo de J2EE ante los problemas técnicos que presentaban tecnologías como EJB. En su momento fue también el principal impulsor del JSR-107 (JCache), JSR que siempre ha estado demasiado parado (muchos culpan al propio Cameron).

Por otra parte, GigaSpaces ha seguido siempre un camino paralelo y muy similar. Fundada tambiéen en el año 2000 por Nati Shalom se trata de un producto que inicialmente estaba orientado al mundo de Jini, posteriormente JavaSpaces; mundo en el que por cierto se ha convertido en una referencia.

Oracle Coherence es lo que ellos denominan memory "distributed data grid solution", vamos que es una cache distribuida. Estas caches se "pegan" a nuestros componentes y les sirven de cache de modo que no sea necesario acceder a una base de datos o cualquier otro servicio para obtener estos datos. Por detrás existe un complejo protocolo de comunicación para asegurarse que los datos siempre permanecen consistentes, que todo está sincronizado, y que siempre existen copias disponibles para garantizar la disponibilidad. Todo esto sin afectar realmente a la arquitectura de nuestras aplicaciones.

Por su parte, GigaSpaces sigue un camino mucho más rádical y propone que el tradicional modelo basado en capas es erróneo y no apto para sistemas escalables. El problema que plantean es que a la hora de escalar una aplicación empresarial es necesario escalar todas las capas (web, appserver, base de datos, ...), lo que se hace muy complicado. En su lugar proponen el despliegue de aplicaciones en lo que se llaman espacios. VMs dedicadas que contienen todas las capas en una misma VM y que no requieren ningún tipo de acceso externo (salvo quizás para persistir asíncronamente los datos). De este modo se minimiza enormemente la latencia y se consigue una escalabilidad lineal simplemente desplegando nuevas VMs. Para garantizar la disponibilidad se despliegan diferentes espacios y se sincronizan los datos entre los mismos.

Todo esto que comento aquí viene mucho mejor explicado en dos presentaciones que Niti Shalom y Cameron Purdy realizaron en la Spring One 2007. Ambas presentaciones están disponibles en Parleys y dejo los enlaces a continuación. Son realmente recomendable si os gustan estos temas.

Coherence an Introduction
Scalable as Google Simple as Spring (quizás un título no muy apropiado para la charla de GigaSpaces).

Videos sobre emprendedores en Loogic

En Loogic anuncian Loogic Video que como cuenta Javier Martín: "quiere ser una recopilación de vídeos relacionados con la Web 2.0, los emprendedores y los negocios de internet."

Muy buena iniciativa, aunque todavía no perfecta ya que se basea en YouTube, pero que a la que de todos modos ya se puede acceder desde este enlace.

Transparencias sobre diseño: FOWD 2007

Hoy, via vitamin he llegado a una presentación en video de Ryan Singer, diseñador en 37 signals, sobre como crear formularios web que atraigan a nuestros usuarios. La presentación la realizó en el FOWD (Future of Web Design) en Londres este ya pasado Abril.

Curioseando un poco en el sitio web de la presentación me he encontrado que todas las presentaciones están disponibles en formato PDF y también MP3 para poder escucharlas. El listado es un poco feo porque sólo pone la información sobre el autor y la compañía, y aunque hay compañías muy interesantes (flickr, technorati, delicious, google, ...) lo cierto es que se echan de menos las descripciones de las charlas.

Sea como sea dejo por aquí el enlace a las presentaciones.

Una nueva utilidad para monitorizar las máquinas virtuales Java

Ayer descubrí VisualVM que es una verdadera joya. Se trata de una aplicación que es capaz de descubrir los diferentes procesos Java que se ejecutan en una máquina, tanto local como remota, y que te ofrece montones de información interna sobre como están funcionando estos procesos.



VisualVM está preparado para funcionar sobre todo con Java 6. En realidad, es capaz de funcionar con Java 5 o Java 1.4, pero con estas dos últimas máquinas virtuales no obtendremos realmente mucha información.

Ahora bien, si estamos utilizando Java 6 entonces esta herramienta se convierte en fundamental. Ofrece muchísima información. Nada que no se pueda obtener con otras herramientas como jhat o jstat, pero lo mejor es que viene de forma gráfica y encima no hay que configurar nada en la máquina virtual, simplemente te conectas a ella y listo.



A mi lo que más me ha gustado es la facilidad para obtener un volcado de memoria o de threads simplemente con un click. Que maravilla. No os imagináis lo útil que es esto cuando estás ejecutando un Applet ya que normalmente suele ser bastante engorroso el andar habilitando JMX para usar JConsole, o habilitando agentes en la configuración de tu Java plugin, etc. etc. Por cierto, que esta herramienta es muy similar en funcionamiento y concepto a Mission Control de BEA de la que ya hablé hace tiempo.

¿Algún otro truquillo/herramienta que utilicéis?

Donde colocar tu centro de datos en USA

Navegando por ahí me he encontrado con un informe de John Rath que quizás a alguno le parezca interesante. Se trata de un análisis de cual es el mejor lugar de los Estados Unidos para colocar un centro de datos en base a diferentes tipos de catástrofes y su frecuencia en los diferentes estados de los Estados Unidos.

La verdad es que yo no planeo montar ningún centro de datos :-) pero lo cierto es que muchas de las gráficas que aparecen en el informe son realmente interesantes, como por ejemplo la frecuencia de tornados...



... o la de las inundaciones ...

Nuevos tipos de instancia en Amazon EC2

Los chicos de Amazon han decidido que ya es suficiente de tener un único tipo de instancias en Amazon EC2 y ahora proporcionan también instancias en los tamaños large y extra-large. Los detalles de los diferentes tipos de instancias se pueden ver aquí.

Esto vendría a ser un movimiento en respuesta a la buena acogida que están teniendo los servicios web de Amazon ya que cada vez aparecen más y más sitios web que los utilizan y a los que seguramente se les quedaban escasos las 20 instancias que Amazon permitía hasta el momento.

Si os interesa más sobre el tema podéis echar un vistazo a la guía de funcionalidades.

Buena charla sobre Hibernate en Dublin

El mes pasado ya comentaba que iba a haber un par de eventos interesantes en estas fechas. Hoy me pasé por el hotel Westin en Dublin para ver la charla de Emmanuel Bernard sobre Hibernate.

Estuvo bien. En la primera parte se dedicó a describir Hibernate Search y en la segunda parte describió los principales proyectos de Hibernate, los cambios que se esperan para el futuro, que no eran realmente no demasiados ni muy notables y es que el proyecto ya es muy estable, y en la última parte se dedicó a responer las preguntas de todos los asistentes, que por cierto había muchos.

Dejó caer algunas notas como que Seam estaba prácticamente a punto de estandarizarse como Web Beans y dejó caer que en el futuro es muy posible que se pudiese usar sobre Tomcat, o que Hibernate validator sería la implementación del JSR-303:Beans validation (aunque ya hablé hace tiempo de que Oval es muy superior).

Igual era que hacía mucho que no iba a ningún evento, pero se me hizo bastante ameno. Lástima no pasarse después por el Mint bar para hablar con la gente, pero todavía no tengo el cuerpo para muchos trotes.

Amazon Web Services Startup Challenge

¡Atención Startups y emprendedores!

Así, comienza el anuncio del Amazon Web Services Startup Challenge en el que Amazon premiará a la idea o aplicación más original y que haga mejor uso de sus servicios web con hasta 100.000$ en metálico, que no está nada mal.

Todos los interesados pueden presentar sus ideas/aplicaciones rellenando el formulario online, y asegurándose claro de que cumplen las reglas.

La fecha límite es el 28 de Octubre.

Linux en Wall Street

Menuda racha llevo. Vamos, que parece que desde hace un par de semanas no hay manera de mantener una regularidad en los posts. Nada más aterrizar de las vacaciones un virus me ha pillado por banda y me ha dejado literalmente KO durante dos días.

En fin, que por escribir algo se me ha ocurrido comentar algo que me dejé en mi último post sobre Wall Street. Ya os habréis dado cuenta por las transparencias del evento High Performance on Wall Street que Linux tiene realmente importancia ahí, especialmente para sistemas de computación en tiempo real.

Resulta que las mismas personas que organizan ese evento organizan también el Linux on Wall Street, donde obviamente Linux es el gran protagonista. Creo que no es un evento muy conocido en la blogosfera hispana ya que apenas me han salido resultados cuando he buscado gente que ya hubiese hablado de él. El caso es que las presentaciones parecen realmente interesantes y las podéis descargar desde este enlace.

Un trabajo... "interesante"

Un compañero de trabajo me ha mandado esta oferta para un desarrollador LAMP en la zona de San Francisco. Sin duda enormes retos en cuanto a escalabilidad y rendimiento. A simple vista parece un trabajo ... "excitante".

Un trocito aquí:

Finally, you have no problem serving up gigabytes and gigabytes of pornography. In fact, you find the challenge of pushing out a sustained 3Gb/s of pornography to be an extremely interesting engineering problem.

Y aquí la oferta por si a alguien le interesa.

Alto rendimiento en Wall Street

Bueno, aunque no he avisado algunos os habréis dado cuenta de la inusual inactividad de este blog. Se debe a que durante esta semana pasada he estado de mini-vacaciones, que han venido muy bien para cargar las pilas.

Una de las cosas que estuve haciendo antes de salir de vacaciones fue revisar unas presentaciones del evento High Performance on Wall Street. Las presentaciones las podéis descargar desde este enlace. Están en formato PDF, pero algunas se pueden escuchar que es lo realmente interesante.

En ellas se habla de las últimas tendencias en cuanto a rendimiento en Wall Street, que probablemente sea uno de esos lugares que marquen tendencias en para el futuro al menos en cuanto a temas de rendimiento, procesado de cantidades masivas de datos y latencia.

Escuchando las presentaciones se sacan varias conclusiones. Una es que ahora mismo no hay capacidad eléctrica para computar la cantidad de datos disponibles. No se trata ya de un problema de poder de computación de las CPUs si no más bien de cantidad de datos procesables por watio de energía. Comentan en alguna de las charlas que hoy por hoy es imposible procesar más datos sin dejar sin luz a todo Nueva York.

Al hilo del punto anterior, uno de los ponentes, que casualmente está muy familiarizado con el mundo Java, Cameron Purdy, apostaba por la orientación de las aplicaciones en Wall Street hacia los datos en lugar de hacia la CPU como una solución al problema del consumo de energía, al menos mientras que los green datacenters no estén todavía más extendidos. Este tipo de centros de datos en los que se apuesta por el bajo consumo fue otro de los temas de moda en la conferencia.

La virtualización y la computación en grid se plantean también como apuestas claras de futuro. Hay un par de ponencias disponibles sobre estos temas que resultan también interesantes.

Espero que os resulten interesantes.

Cuidado con los cables

¿Puedes cortar el cable rojo?



Montones de fotos de lios de cables. Via DataCenter Knowledge.

Findory: ¿Hasta donde debemos optimizar?

Parece que Findory, una startup creada en el 2004 y cuyo objetivo era el agregar información desde diferentes fuentes y personalizarla en base a los gustos de los usuarios ha anunciado que cerrará sus puertas el 1 de Noviembre.

Hasta aquí nada extraño, ya que lo de cerrar y crear compañías y productos está a la orden del día. Sin embargo lo que me ha llevado a escribir una entrada en este blog es un post de hace un par de días de su creador Greg Linden en el que explica los problemas que plantea el escalar un sitio web que pretende proporcionar contenido personalizado para cada uno de sus usuarios.

En el post, Greg explica como Findory consiguió obtener un espectacular rendimiento en estos últimos años, llegando a renderizar páginas únicas para cada usuario en menos de 100 ms. Para ello los datos de sólo lectura se replicaban en los servidores web y se almacenaban en BerkeleyDB, mientras que los de lectura/escritura utilizaban MySQL. En fin, que con esto consiguió crear un motor espectacularmente rápido e incrementar la escalabilidad de su sitio web, al tiempo que mejoraba la experiencia de sus usuarios.

Pero hubo un problema. La experiencia de sus usuarios se mejoró en cuanto a rapidez de acceso, pero no en cuanto a funcionalidades. Greg se pregunta en una muy valiente entrada hasta dónde tiene sentido optimizar.

Even so, I wonder if I have been too focused on scaling and performance. For example, there have been some features in the crawl, search engine, history, API, and Findory Favorites that were not implemented because of the concern about how they might scale. That may have been foolish.

Creo que se pueden aprender muchas lecciones de esta historia, pero me quedo sobre todo con que al final ser el más rápido no implica ser el que se lleva el gato al agua, sino que a veces es importante sacrificar algo de rendimiento y escalabilidad a costa de ofrecer más funcionalidades.