Portabilidad: Siguiendo la especificación

En Coding the Architecture abrieron un debate muy interesante hace unos días. Es ese tipo de debate en el que miras hacia atrás y ves inevitablemente como tu opinión ha ido cambiado con el tiempo, ya se hacia un lado o hacia el otro. Y es que al final, cada uno contará la historia como le haya ido en la feria.

Hace ocho años, era todo acerca de la portabilidad. Acerca de la especificación. La portabilidad era la gran baza de JEE, y cualquiera que se mantuviese dentro de los límites de la especificación estaba a salvo. ¡Qué gran consuelo cuando tecnologías como EJB 1.1 te garantizaban un camino amargo y tortuoso! Con el tiempo, el debate sobre portabilidad se ha aligerado mucho, y el no seguir la especificación es como el hombre del saco, que te asusta las primeras veces pero que cuando ves que funciona y no pasa nada, pues pierde toda su importancia.

En mi caso, como el de Simon Brown, mi opinión también ha ido cambiando con el tiempo. Pero un poco al contrario. Hace años yo era partidario de no seguir la especificación si llegabas a un punto en el que te estaba restringiendo demasiado. Todavía recuerdo discusiones airadas sobre este tema con amigos y compañeros de trabajo que opinaban justamente lo contrario. El tiempo me ha enseñado que no hay una verdad única respecto a este tema, y que como casi todo, realmente dependerá en el problema que tengas que solucionar, pero que si realmente decides apartarte de la especificación, este debe ser un factor como otro cualquiera que deberás balancear y sobre el que deberás ponderar riesgos y ventajas.

Por ejemplo, hace tiempo, trabajando en un proyecto me encontré con varias partes de una gran aplicación que utilizaban threads directamente para realizar ciertas operaciones. Estas operaciones incluían escrituras en base de datos o envio de mensajes entre otras cosas. ¡Herejía! ¡Uso de threads en managed-systems! El desarrollo había continuado adelante porque era rápido y porque nunca había pasado nada. Sin embargo, a medida que la carga del sistema aumentaba, se pudo observar que se empezaban a perder mensajes, que había transacciones que no se completaban o se hacía rollback de repente, y otro número de efectos insospechados.

El problema era que se habían apartado demasiado de la especificación, y los efectos eran inesperados. Es así de fácil. No estás en la especificación, no tienes garantía de nada. ¡Si es que a veces no la tienes ni cuando sigues la especificación! La solución en este caso fue aprovechar que el servidor implementaba la specificación commonj y devolver esos Threads al contexto que le pertenecían, el contenedor. Eso solucionó todos los problemas.

Ser consciente de que te pueden pasar estas cosas es algo importante a la hora de hacer la decisión de restringirte o no a la especificación. Otro factor muy importante que he podido ver con el tiempo es el negocio al que se dedique la compañía, y como se va a vender la aplicación que se está creando. Muchas compañías que facturan productos ofrecen soluciones basadas en plataformas comunes como Oracle, WebSphere, WebLogic, a la vez que ofrecen otras soluciones de bajo coste basadas en MySQL, PostgreSQL o JBoss. En este caso, es importante mantenerse lo más cerca posible de la especificación, ya que cualquier opción especial que utilizemos la tendremos que reimplementar tanto para la plataforma premium como para la Open Source.

Otro caso con el que me encontrado es con productos que están bajo un servidor de aplicaciones en contreto y necesitan ser migradas a otro para entrar en determinado sector. Un ejemplo típico sería el entrar en la banca donde en algunos sitios te exigirán IBM WebSphere como plataforma de despliegue.

En fin, que al final, como mencionan en los comentarios, es un balance entre los planes de futuro que haya en la aplicación en cuanto a portabilidad y los problemas que nos encontremos al desarrollar. Si existe la posibilidad de despligue en múltiples plataformas, entonces es mejor ir con cuidado; en caso contrario, siempre se puede quebrantar un poco más las normas, pero siempre siendo conscientes de las posibles consecuencias en cuanto a efectos inesperados.

Cuil, ¿amenaza para Google?

Comentan en SiliconRepublic que Tom Costello, un irlandés graduado por el Trinity College, y su esposa ex-empleada de Google, acaban de lanzar hoy mismo un buscador que aparentemente es una amenaza real para Google. Se trata de Cuil cuya principal vaza para amenazar la hegemonía de Google es la de indexar el contenido de las páginas web y no sólo la lista de keywords.

Como destacan en la noticia de SiliconRepublic, Cuil no es el primero en intentar amenazar a Google. Wikia ya lo intentó a principios de año pero fracasó estrepitósamente, especialmente debido a todo el hype que se había creado en torno a este buscador. Ya que no es sólo que no funcionara bien, sino que la disponibilidad era irrisoria debido al masivo número de visitas que recibían. En eso parece que han estado listos los chicos de Cuil ya que al menos yo no me he enterado de que existía, y en caso de enterarme habría sido una muy mala señal porque a mi estas noticias me llegan más bien de rebote.

Bueno, el caso es que a pesar de haber hecho bien, parece que todavía tendrán que afinar un poquillo con las búsquedas. Puestos a buscar, porque no agrandar el ego de uno mismo y buscarse en Cuil, así que me dispuse a buscar "Martin Perez". Y no sé, me da que o bien el algoritmo de enlazar imágenes con resultados no está bien, o bien lo están mostrando al azar, pero lo que está más claro que el agua (al menos para mi) es que este no soy yo:



Perdonando este lapsus, parece que la interfaz de usuario al menos es innovadora, y los chicos tienen 24 millones de dólares para mejorar, así que a ver si se crea un poquillo de competencia en la web que empieza a aburrir un poco.

Mensajería, escalabilidad, transacciones y tolerancia a fallos

Uno de los principios más importantes de la escalabilidad es el procesado asíncrono de datos. En una llamada síncrona, todo punto de integración constituye un nuevo riesgo, una nueva dependencia, un nuevo riesgo de quedarse bloqueado esperando por un recurso que nunca llegará o por un hueco en ese ansiado pool de conexiones que se nos ha quedado pequeño.

Por otra parte, uno de los principios más importantes de la integridad de datos es la transaccionabilidad. Si juntamos ambos conceptos, mensajería y transaccionabilidad, entramos en un nuevo mundo de retos y problemas, que unas veces serán sencillos de solucionar y que otras veces requerirán otra serie de artimañas más avanzadas para la gestión de errores.

Es sobre esto último de lo que trata un excelente artículo de Udi Dahan publicado en la MSDN. El autor recorre los problemas más comunes que nos encontramos en la integración de sistemas utilizando mensajería y como afrontarlos y resolverlos de manera robusta. Entre los temas tratados:

• Persistencia de mensajes: Es decir el configurar nuestro broker de mensajería para que almacene, normalmente en base de datos, los mensajes de modo que se puedan reenviar posterioremente en caso de algún problema.


• Consistencia transaccional: ¿Qué pasa si enviamos un mensaje y avisamos a un tercer sistema de ese cambio pero de pronto se hace un rollback del mensaje? El soporte de transacciones en los brokers y el uso del commit en dos fases resuelve este problema, pero a veces es overkilling.


• Uso de colas de errores: Enviamos un mensaje ... y falla; lo volvemos a enviar ... y falla; probamos otra vez... vuelve a fallar. ¿Qué hacemos? Podemos seguir y seguir (y en el 99.99% de los casos seguirá y seguirá fallando) lo que consumirá importantes recursos de nuestro sistema, podemos lavarnos las manos e imprimir la traza de error, o podemos enviarlo a una cola de errores, donde más tarde los revisaremos, lo cual parece una muy buena opción.


• Tamaño de los mensajes: Aquí el autor hace un excelente análisis sobre la diferencia entre procesar miles de mensajes pequeños y unos cuantos cientos de mensajes enormes.
  

  TimeToProcess(BigMessage) >> N x TimeToProcess(SmallMessage) where
  Size(BigMessage) == N x Size(SmallMessage)

  
  Los requisitos del procesado de mensajes grandes en cuanto a validación (CPU, memoria), almacenamiento en caso de mensajería duradera(CPU, disco), o congestión de red (optimización de paquetes) son mucho más exigentes y a menudo la única solución es el partir el mensaje original en mensajes mucho más pequeños y sencillos de procesar.

En resumen, en mi opinión excelente artículo para el que le gusten los temas de mensajería, procesado asíncrono de datos y transacciones, y lectura recomendada.

El centro de datos y el baño de las chicas

From: ---- --------
Sent: Monday, May 5, 2008 4:37 PM
To: Everyone
Subject: Server Room Access

Hi all.

As you all are aware, we have new tenants that have moved into
the 2nd floor suites. The access to the server room is now via
the women’s bathroom.

There will be a sign on the woman’s door that can be changed
from OPEN to CLOSED and vice versa.

Should you need to enter the server room, please change the sign
to CLOSED. Once you are done, please change it back to OPEN.

Once you enter the bathroom, you will be able to access the
server room via the handicapped stall. Please close the stall
door prior to entry, just in case someone doesn’t see that the
bathroom is closed.

I know this isn’t ideal, but if we adhere to this protocol, I
don’t think anyone will be disrupted.

Thanks! Let me know if you have any questions.

Via Pingdom y DailyWTF.

Emprendedores, SeedCamp y la importancia de validar una idea

A través de Web 2.0 Ireland he llegado a un post realmente interesante de Saul Klein.

El artículo no deja de ser un post publicitario de SeedCamp, y de como este foro puede ser una buena herramienta para validar las ideas de potenciales emprendedores. Me quedo especialmente con una parte del mismo:

In today's environment, if you are in your 20s and you put [society's] [your parent's] economic fears aside, there has never been a better time to be a first-timer.

Y es que aunque los emprendedores ahora mismo se enfrentan al gran problema de que parece que todo esté ya inventado, de que hay una competencia enorme y de que las compañías poderosas se hacen cada vez más y más poderosas e intentan abarcar más y más, lo cierto es que nunca ha sido tan barato el montar un negocio y nunca ha habido tantos recursos disponibles ya sea en forma de librerías, frameworks y utilidades Open Source (como Java, LAMP o RoR), en forma de alojamiento de gran rendimiento y muy barato (como Amazon EC2/S3) o en forma de enormes plataformas gratuitas para ejecutar nuestros programas (como Google Apps Engine).

Una de las cosas que lamento más es el no haber intentado algo hace cinco años, cuando había tantas cosas todavía sin inventar. Ahora ya me ha pasado el arroz de los 20s, pero quien sabe si en los 30s habrá un poco más de suerte. En estos momentos en los que la recesión aprieta, y los jóvenes ya no están obligados a meterse en una hipoteca porque la vivienda siempre sube, quizás tenga más sentido que nunca el tomarse un descanso, olvidar el yugo del ladrillo y emprender.

Resulta también muy interesante que en la cena del The Accelerator Group que se comenta en el post 12 de las 15 startups que se reunieron estuvieran utilizando Amazon Web Services o probando Google App Services. Todo el mundo estaba usando LAMP, Python; Django o Ruby; y por supuesto todo el mundo estaba usando o pensaba usar f8 o OpenSocial; y parece que todos estaban pensando también en el nuevo iPhone.

En mi caso, os voy a contar un secretillo. Tengo algo. O bueno, más correctamente tenemos algo. No estamos en el grupo de RoR (aunque algunos se dediquen también a ello), si no en el de Groovy y Java. Sólo voy a dar una pista, la palabra clave es empleo. Y realmente espero que pronto (posíblemente Otoño) tengáis la oportunidad de validar nuestra idea :)

Algunas notas sobre el proceso de desarrollo en Linkedin

Tenía por aquí entre las cosillas pendientes de publicar unas transparencias sobre el proceso de desarrollo en LinkedIn que presentaron en la JavaOne de este año.

| View | Upload your own

A mi LinkedIn es uno de los sitios que peronalmente me gusta más, especialmente desde que le dieron el cambio de imagen hace unos meses. Entre las cosas más destacadas de la presentación:

• Ciclos de desarrollo de 2 a 4 semanas.


• Los requisitos se dividen en pequeñas tareas con las que se rellenan tarjetas para cada desarrollador.


• ¡¡Minimizar las reuniones!!


• Test Driven Development


• Más de 6500 tests de unidad e integración. Más de 500 tests de HTMLUnit.


• El sistema de integración continua tiene más de 20 nodos. No se trata sólo de integración continua sino que ahí también se realizan los smoke tests.


• El testing de integración puede llevar demasiado tiempo. Aquí easymock se muestra como una mejora importante.


• 99% Java: Spring, ActiveMQ, Quartz, HTTPClient, Lucene, Grails, Jetty, DWR, jUnit, HTMLUnit, Hudson, Eclipse+Mylyn, EHCache. - Me llama la atención la ausencia de Hibernate o cualquier otro ORM. ¿JDBC Template "a pelo"?


• Más de un millón de líneas de código, con ¡20 branches activas! Uso intenso de genéricos.


• 50 ingenieros, 8 equipos. - Viendo el impacto de esta red y la importancia que ha adquirido, ¿no os esperaríais más?

La presentación sigue con notas sobre la arquitectura de LinkedIn, que también son interesantes para los que no conozcan los fundamentos básicos sobre los que se sustenta, es decir el mover la integridad a un segundo plano y el mantener toda la red de contactos de todo el mundo en memoria. El año pasado ya ponía algunos comentarios sobre el tema.

¿Es Google el nuevo malo de la película?

En este blog hay bastantes entradas sobre Google, probablemente como en la mayoría de blogs sobre informática. Esta compañía ha aportado tanto a la informática y es tan, tan, tan poderosa que es casi imposible el dejar de hablar de ella. Pero como suele pasar en estas compañías, a medida que van ganando poder, van perdiendo simpatizantes, y Google no es una excepción.

Greg Linden comenta en su blog que lo mismo pasaba con Amazon cuando él trabajaba allí, allá por el 2000, y muestra diferentes referencias a artículos de prensa atacando a Google, todos bastante recientes, incluyendo uno de hace un par de días donde en el New York Times presentan a Google como una especie de tirano más preocupado en ahorrar costes (¿qué raro en una empresa, no?) que de mantener los actuales beneficios de sus empleados.

El caso es que normalmente esto no me llamaría la atención, si no fuese que justamente este fin de semana, cuarioseando en boards.ie (que son unos foros realmente importantes en Irlanda, hasta el punto de ser referenciados en la radio o de que profesionales de diferentes tipos ofrecen consultas grauitas en los mismos ) me encontré un hilo sobre trabajo donde gente que trabaja en Google da sus impresiones, tanto positivas como negativas, aunque parece que predominan estas últimas. Como sabéis, Google tiene los cuarteles generales en Europa localizados en Dublin

Esta opinión es realmente interesante, y muestra (si asumimos que es real) las fuertes diferencias entre puestos técnicos y no técnicos en la compañía. Otros hilos hablan de la enorme competencia dentro de la empresa, la importancia de relacionarse, y en resumen muchas cosas lejos de la imagen idealizada que pudiese tener mucha gente de la compañía. Pero ojo, no os quedéis sólo con lo malo porque también hay opiniones buenas, y los beneficios que se obtienen trabajando en Google son únicos (aunque por ahora no sea más en forma de acciones).

¿Qué os parece a vosotros? "An average large company", ¿como comentan por ahí? Sea como sea seguro que merece la pena trabajar ahí aunque sólo sea un tiempo para aprender de la experiencia.

RPC: ¿Correcto o Conveniente?

Pincha aquí, pincha allí, he llegado a un excepcional artículo que publica Steve Vinoski en el número de Julio/Agosto de la revista Internet Computing del IEEE. El artículo se titula Convenience over Correctness y por suerte está disponible en PDF. Este artículo es de lo mejorcito que he leido desde hace bastante tiempo, y probablemente lo mejor que ha caido este año en mis manos.

Steve Vinoski ha sido una de las referencias en cuanto a computación distribuida, muy conocido en el mundo de CORBA, escribió una de las biblias de esta plataforma. Sin embargo de un tiempo para aquí Steve reniega de todo lo que tenga que ver con RPC y se ha convertido en un acérrimo defensor de los lenguajes dinámicos y también de erlang.

La verdad es que me pongo a leer el artículo, y no sabría que quotes pegar en este post. Son tantas las verdades escritas que da pena quedarse sólo con una frase. Quizás lo fácil sea escoger la que viene resaltada en el artículo mismo:

We have a general-purpose imperative programming-language hammer, so we treat distributed computing as just another nail to bend to fit the programming models.

Steve critica enormemente en el artículo a los lenguajes tradicionales y la comoditización que se ha hecho de RPC, un paradigma que funciona enormemente bien en redes locales pero que a la hora de moverse a Internet se olvida de factores tan importantes como la latencia, la tolerancia a errores o la escalabilidad del medio de transporte, entre otros, y que asume que todo funcionará bien y sin ningún tipo de fallos.

La carencia de constructores en los lenguajes tradicionales para especificar todos estos aspectos es una de las críticas que más resalta Steve, abogando por paradigmas como REST+HTTP que permiten especificar aspectos como la cacheabilidad de un servicio de manera sencilla.

Al mismo tiempo otro de los centros gravitacionales del artículo es la computación distribuida y la necesidad de evolucionar hacia lenguajes de programación como erlang que huyen de la inocencia del modelo RPC y que al tiempo que ofrecen constructores tan simples como "Pid ! Message" (envía el mensaje al proceso especificado por el Pid) ofrecen todas las ventajas asociadas con la computación asíncrona y distribuida.

La discusión sobre el artículo en su blog resulta también extremadamente interesante y además hay varios enlaces a otras columnas similares del mismo autor.

Por cierto, al que le interese puede ver también entrevista de InfoQ.

Tuneando transacciones con Spring

Hace unos días escribía sobre la disponibilidad de las charlas de la SpringOne 2008. Una que he leido recientemente es la de Jurgen Holler, Transaction Choices for Performance, y en la que se entra en detalle sobre los diferentes tipos de transacciones en Spring y sobre como evitar las transacciones XA en la medida de lo posible.

Muchos de los que leen este blog sabrán lo que es XA, aunque supongo que otros no. Básicamente es una especificación que define como sincronizar el acceso a recursos totalmente diferentes dentro de una misma transacción, para lo que se utilizar un gestor de transacciones global. Un ejemplo sería el realizar desde un mismo método un acceso a base de datos y enviar un mensaje a algún broker de mensajería. XA te garantiza que el método se ejecutará preservando las propiedades ACID entre las diferentes llamadas.



En el screencast de arriba( y esto es una prueba y una excusa para probar este servicio ) os muestro un caso muy típico en el que se necesitaría sincronizar una base de datos y un servidor de mensajería. El método A actualiza la base de datos, envía un mensaje a una cola, realiza un proceso y termina su ejecución. Mientras tanto, en otra parte del sistema, un consumidor lee asíncronamente el mensaje en B y consulta la base de datos. ¿Cuál es el problema? Pues que como la cola de mensajería y la base de datos tienen sus propios gestores de transacciones, resulta que es muy probable que el mensaje llegue a B cuando la transacción en A todavía no se ha persistido en la base de datos, con lo que el consumidor estaría leyendo un valor incorrecto (ver phantom reads si no se es familiar con este concepto).

Utilizar XA soluciona este problema ya que un gestor de transacciones global se encargá de sincronizar todos los recursos de forma que por ejemplo el mensaje no se envie hasta que no se haya hecho commit de la transacción (aunque en realidad dependería de la implementación del gestor transaccional). A simple vista utilizar XA parece claramente una buena idea. Sin embargo, hay un problema muy importante, XA es enormemente lento. Muchísimo más lento que utilizar transacciones simples ( o que no usar transacciones ). Jurgen desmonta unos cuantos mitos sobre las transacciones XA en su presentación:

Me permito traducir los puntos:

• Una aplicación empresarial crítica y seria necesita transacciones XA: No es cierto, muchas aplicaciones empresariales no utilizan para nada transacciones XA.


• Una mapeo objeto-relacional correcto requiere el uso de XA: No es cierto, los mapeadores objeto-relacional normalmente operan con JDBC más un sistema de caché propio.


• Para combinar JDBC y JMS las transacciones XA son obligatorias: No es cierto, muchas aplicaciones empresariales utilizan JMS con transacciones nativas o ACKs.


• Los gestores de transacciones modernos están optimizados para ofrecer el mejor rendimiento: No es cierto, las garantías que XA exige son costosas y no pueden ser optimizadas de forma tan sencilla.

Siguiendo con la presentación, la principal recomendación de Jürgen es que una de las formas para solucionar el problema planteado arriba es sincronizar de manera nativa la cola de Spring con el gestor transaccional que utiliza el DataSource de forma que el mensaje sólo se enviará cuando se termine la ejecución del primer método y se haga commit de la transacción lo que tiene la ventaja de no usar XA y tener un mayor throughput.

Es curioso además que hoy hablando con alguien, me comentaba que algunos bancos no estaba interesados en absoluto en utilizar XA, y aconsejaban a sus proveedores el no incurrir en este tipo de transacciones ya que eran demasiado costosas para sus servidores que albergan tantas y tan heterogéneas aplicaciones. No estoy muy seguro de lo que hay de cierto en esto, pero puede que tenga sentido :)

Dos productos Open Source interesantes saliendo de una tienda de viajes online

Leyendo InfoQ he visto que Orbitz, una compañía de venta de viajes online, curiosamente ha lanzado dos frameworks como Open Source.

Uno es ERMA del que a pesar de la presentación en la JavaOne, que aunque yo no sería partidario de implementar este tipo de frameworks en una empresa teniendo cosas Hyperic, Wily o insideApps que pueden cubrir muchas de las necesidades, siempre está interesante alternativas para el procesado de eventos. En InfoQ hablan también de Esper que parece realmente interesante.

El otro es Graphite, que personalmente lo encuentro más interesante porque, su motor, whisper, supone una alternativa a RRDTool (n su página tienen una discusión sobre las diferencias entre ambos motores), y siempre está bien disponer de alternativas, especialmente Open Source. En InfoQ comentan que lo utilizan para manejar información agregada de 70000 métricas lo cual no está del todo mal, aunque tampoco especifican cuanta memoria o hardware se necesita para ello. En el wiki quizás haya más información.

Por cierto, he visto que uno de sus autores, Ray Krueger, es también el creador de un plugin para integrar memcached como caché de segundo nivel en Hibernate. Ni idea de como funcionará, pero si alguien se anima a probarlo, me encantaría oir sobre los resultados.