Resultados encuesta evento escalabilidad

Hace un par de días creaba una encuesta para que ejerciese un poco de termómetro de las ganas de eventos para desarrolladores en España haciendo unas preguntillas sobre un futuro evento sobre escalabilidad.

Han pasado dos días y he creido que en lugar de guardarme los resultados para nosotros, puede ser interesante publicarlos y comentarlos entre todos (excepto la pregunta donde se preguntaba a quién le intresaría presentar algo). Los datos son interesantes. Vaya por delante que no quiero generalizar. Estos datos simplemente son una muestra de la opinión de 1. La gente que lee ese modesto blog, 2. La gente que nos sigue en Twitter a los promotores y 3. La gente que estáis en el grupo de escalabilidad. Vamos, que si nos vamos a una determinada empresa o administración pública y les preguntamos a sus programadores, pues igual los resultados son algo diferentes. Pero bueno, tras ese disclaimer y sin más dilación, voy con los resultados (click en las imagenes para agrandar).

Consulta sobre evento sobre escalabilidad.

Hola a todos. En el grupo de escalabilidad en español que tenemos en Google Groups, hemos decidido que es hora de pasar a la acción y montar un evento de escalabilidad. No será ahora, sino más bien dentro de unos meses, pero la idea es intentar que sea algo atractivo para la gente.

Así, tenemos que saber lo que a la gente le gustaría, en especial si queréis un evento empresarial pues saber a quién os gustaría ver, o que empresas os gustaría que fuesen, o si queréis un evento más relajado pues poder ir buscando patrocinio para unas cañas, y todo eso :)

Así que hemos preparado esta consulta para ver un poco por donde van los tiros. ¿Nos ayudáis?

Martin Fowler analiza la arquitectura de LMAX

Allá por Enero, escribía sobre la arquitectura de LMAX, una empresa que había desarrollado una aplicación para operar en mercados de derivados pero no sólo orientada a traders sino también al usuario final, y que presentaba unos números impresionantes. En InfoQ publicaron un video muy interesante donde los creadores de la arquitectura la explicaban en detalle.

Un amigo me ha pasado hoy este enlace, donde el mismísimo Martin Fowler ha hecho un análisis mucho más detallado sobre la arquitectura, complementado por notas que ha intercambiado por email con los autores. Si os interesa el tema de la escalabilidad y la computación de alto rendimiento entonces es un artículo que no os debéis perder.

HPCC Systems alternativa Open Source a Hadoop

Ayer apareció en todos los medios de comunicación, aunque yo me enteré por el grupo de escalabilidad en español (toma promo gratuita). Una compañía de Miami, LexisNexis ha anunciado que hará Open Source su tecnología de computación y análisis de datos HPCC Systems (High Performance Computing Cluster) a la que la prensa no ha dudado en tildar como el Hadoop Killer.

Los problemas de NoSQL

A través del Twitter de Miguel Ángel Pastor, ya mi referencia para estar al tanto de los temas de escalabilidad, llego a estas interesantes reflexiones sobre NoSQL que se publican en High Scalability.

Aparentemente, según comentan en el artículo, se están leyendo cada vez más opiniones negativas de personas que se han dado cuenta que no es oro todo lo que reluce dentro del mundo de NoSQL. Algo que por otra parte, tampoco nos debería extrañar a nadie ya que hay muy pocas tecnologías que sean sólo ventajas.

Cinco soluciones basadas en Lucene para Real Time Search

Hace unos días trascendió que Twitter había terminado su proyecto de migración para su backend de búsqueda en tiempo real (search.twitter.com). El proyecto había comenzado en la primavera del 2010 y terminó en Abril del 2011 así que tenemos, tal y como señala Javier Murillo en su análisis, un año para un proyecto desarrollado por un equipo de quince ingenieros.

Twitter tenía dos problemas para querer cambiar la arquitectura de su sistema de búsqueda y que hasta el momento estaba basado en el modelo clásico de base de datos relacional. Uno era el que describen en el post de este mes, y es la escalabilidad. Con Rails estaban atados a un thread por búsqueda y eso hacía que desperdicien CPU y recursos mientras se está realizando la búsqueda. Algo realmente importante cuando tienes 12.000 búsquedas por segundo y mil millones de búsquedas diarias. Para eso decidieron migrar a una arquitectura asíncrona basada en Netty tal y como explica el artículo.

Construyendo un motor de recomendaciones al estilo FourSquare

En el blog del departamento de ingeniería de FourSquare han publicado un post realmente interesante sobre como han construido su motor de recomendaciones de lugares.

Lo primero que comentan básicamente es la dificultad de este tipo de motores al tener gran cantidad de datos, en su caso 10 millones de locales, y necesitar por una parte computar la similitud de estos lugares, es decir agrupar los lugares en los que se come Sushi, o Churrasco, o donde se toca Jazz, y por otra parte ponderar estos resultados con las preferencias personales de los usuarios, es decir como los han puntuado o cuantas veces los han visitado y con que frecuencia, y las preferencias de sus amigos, es decir si tus amigos suelen ir a restaurantes Indios hay una gran posibilidad de que a ti también te interesen estos restaurantes.

Libros gratis sobre Node.js

Si hay un framework de moda ahora mismo ese es Node.js. Los que no lo conozcáis, Node.js se define a si mismo como un framework basado en JavaScript que utiliza una arquitectura asíncrona de eventos y que está pensado para la creación de aplicaciones escalables como servidores web.

Vayamos por partes porque a los más viejos del lugar este tipo de afirmaciones nos puede chocar bastante. Lo primero, a pesar de ser JavaScript, Node.js no se ejecuta en el navegador web sino que su sitio está en el servidor, como framework para el desarrollo de aplicaciones basadas en Server Side JavaScript.

Grupo sobre escalabilidad en español

Tal y como os comentaba ayer, los últimos días había estado comentando con Marc y Miguel Ángel Pastor la posibilidad de crear un grupo sobre escalabilidad, Hadoop, NoSQL, computación distribuida, etc.

La cosa ha surgido así como de casualidad. Miguel se pone en contacto conmigo preguntándome por listas o grupos sobre el tema; por otra parte, conozco a Marc que me cuenta que le gustaría potenciar la comunidad Hadoop en España, y ya lo demás es el poner en práctica mis habilidades de liante para que entre ellos dos monten un grupo en Google para ver si arranca esta comunidad :)

Hadoop y Hbase en Last.fm

La pasada semana este blog estuvo parado ya que estuve casi todos los días en Londres. Allí tuve la oportunidad de tomarme unas pintas con David Hernandez y Marc de Palol, ambos unos cracks que se encuentran viviendo y trabajando en la city.

El blog de David ya lo conocía. El que no conocía era el de Marc. Entre pinta y pinta estuvimos comentando como estaba la situación de los dos países, y muchos otros temas. Uno de ellos era como todos veíamos que Hadoop estaba dando fuerte y como se empezaba a usar más y más, también en España.

Consejos para crear aplicaciones de alto rendimiento

Siguiendo con el post anterior, sobre la presentación sobre LMAX en InfoQ, de mi resumen me restaba comentar los seis consejos que ellos daban para la creación de aplicaciones de alto rendimiento que fuesen capaces de gestionar un gran número de transacciones con una latencia muy baja.

Su máxima era: hoy en día con un único hilo puedes jugar con 3 billones de instrucciones por segundo. Con no hacer nada estúpido tendrás 10 mil transacciones por segundo sin problemas. ¿Pero cómo hacemos para no meternos en problemas? Aquí resumo sus consejos:

Consejos para gestionar 100K TPS con menos de 1ms. de latencia

Hace poco más de un mes publicaron en InfoQ una presentación muy interesante sobre como crear aplicaciones capaces de procesar un gran número de transacciones con una latencia muy pequeña.

Los autores de la presentación fueron Martin Thompson y Michael Barker y trabajan en LMAX. Esta copañía desarrolla lo que se llama un Trading Exchange. Este tipo de compañías ofrecen la posibilidad de comprar activos financieros al usuario final (i.e. nosotros) ofreciendo un pool de proveedores (agencias de trading, bancos, etc.) que compiten entre sí para ofrecerle al usuario el mejor precio. La idea es que si por ejemplo quiero comprar EUR/USD el sistema me va a ofrecer siempre la mejor oferta de entre los varios proveedores existentes en el trading exchange.

Elastic Beanstalk: Heroku para Java

Heroku es un servicio online englobado en lo que se conoce como PaaS (Platform as a Service), y que básicamente permite el desplegar aplicaciones Ruby en una nube de servidores que se escala automáticamente para satisfacer las necesidades de carga de las aplicaciones.

En Java (hasta donde yo sé) no había demasiados servicios similares. Está Stax que lo compró Cloudbees me imagino que con la intención de hacer algo similar a Heroku, y estaba por supuesto Google App Engine que es una plataforma que prometía mucho, pero que entre las limitaciones que impone y los problemas que sufrieron muchos desarrolladores por tratarse de una Beta que era una "verdadera Beta", pues no ha tenido toda la popularidad que se podría desear.

Lucene, Grids, Heaps y otras cosas del montón

En el penúltimo post explicaba la importancia en ciertos escenarios de que los objetos tengan una vida de corta duración. Only the good die young. Uno de esos escenarios es el caso en el que tengamos una Heap enorme, caso en el que la recolección de basura puede llevar mucho tiempo.

¿Y qué tamaño puede tener uno de esos Heaps tan enormes? Recuerdo hace años que tener un Heap de 512Mb ya era la caña. Después, cuando estabamos haciendo aplicaciones de trading hace ya casi cinco años, jugábamos con Heaps de 4gb, que no estaba mal pero ya resultaba bastante pequeño, pero era fruto sobre todo de las limitaciones de los sistemas operativos de 64 bits y en producción si que nos íbamos a 8, pero con la incertidumbre de no saber con exactitud que iba a pasar.

Notas sobre la arquitectura de Facebook Chat

En la línea de las notas de arquitectura que suelo publicar voy a escribir hoy un post con un resumen de notas que he ido sacando sobre un documento acerca de la arquitectura del chat de Facebook. Si os interesa el tema entonces os pueden interesar también las notas sobre la arquitectura de Facebook del año pasado. Empiezo.

En 2007 en Facebook se dan cuenta de que necesitan un Chat, seguir los mensajes entre muros es un infierno. El código surge en el 2007 de lo que en Facebook denominan un Hackathon, es decir quedarse los ingenieros durante toda una noche programando. No es hasta el 2008 cuando se manda el primer mensaje y lo lanzan oficialmente.

Las estadísticas del chat dan miedo:

• 800+ million user messages / day


• 7+ million active channels at peak


• 1GB+ in / sec at peak


• 100+ channel machines

La arquitectura de Netflix

Adrian Cockcroft, Cloud Architect en Netflix ha compartido unas transparencias en Slideshare bastante interesantes sobre el servicio de streaming de video Netflix.

Las transparencias están orientadas tanto a desarrolladores como a ingenieros de sistemas. Las notas que se sacan son bastante interesantes y son bastante densas, de hecho entran en bastantes detalles según comenta su autor en su propio blog para atraer a ingenieros a su equipo, ya que están contratando. Y vaya si están contratando. En su web tienen unas 100 posiciones abiertas ahora mismo. Como siempre me pasa, este post iba a ser una simple referencia pero ha terminado en una recopilación de notas.

Un día en el centro de operaciones de Facebook

Hace unos meses, Tom Cook, Ingeniero de Sistemas de Facebook daba una charla en el evento Velocity 2010 de O'Reilly donde describía como es el día a día dentro del servicio de operaciones del gigante americano de las redes sociales.

La charla comienza con algunas estadísticas que le quitan el hipo a cualquiera:

- La gente pasa 16000 millones de minutos diarios en Facebook
- Se comparten 6000 millones de piezas de contenido al mes
- Se suben 3000 millones de fotos al mes
- Hay un millón de implementaciones de Facebook Connect

A todo ello contribuye que 50 de los 100 sitios más visitados del mundo integren Facebook de algún modo, ayudando a llegar a los 400 millones de usuarios de este 2010. Para soportar esta carga de usuarios, Facebook tiene dos centros de datos. Uno en la costa Este y otro en la costa Oeste de Estados Unidos y están construyendo uno nuevo en Oregon. Todos sus servidores utilizan Linux y su distribución es CentOS.

Nada más comenzar la charla uno se da cuenta de que Facebook es un lugar donde la opinión de los ingenieros tiene realmente mucho peso, para bien o para mal. Está claro que no es trata de un lugar habitual. Algo que me ha sorprendido por ejemplo es que la propagación de parches y cambios a producción se hace con BitTorrent, moviendo ese código a más de diez mil servidores. Otro uso interesante de BitTorrent.


Pero hay cosas todavía más sorprendentes. Facebook está hecho en PHP. Sin embargo parece que el rendimiento llegó un punto en el que no era aceptable. Lejos de cambiar de plataforma, ya que a sus ingenieros les gusta PHP, crearon una herramienta interna para traducir el PHP a C++, compilándolo después con g++. El resultado fue un 50% de aumento en el rendimiento que podríamos trasladarlo, aunque no sea estríctamente así, a un 50% menos de servidores. Sea como sea, el crear un traducor de PHP a C++ no parece que sea el tipo de decisión recomendable para todas las compañías que quieran más rendimiento.

Otro modo que tienen de aumentar el rendimiento es utilizar cachés (Memcached) y una enorme cantidad de memoria RAM: más de 300Tb de datos en vivo en diferentes cachés. Utilizan MySQL en la base de datos. Sobre MySQL en Facebook ya puse unas notas hace un año en el post "Notas sobre la arquitectura de Facebook".

La principal conclusión que he extraido de esta charla es que Facebook es, sin ninguna duda, una de esas compañías dirigidas principalmente por el equipo de operaciones. Está claro el peso de este departamento en el proceso de desarrollo y producción. En mi experiencia, trabajar en este tipo de empresas puede llegar a ser un auténtico infierno en los casos en los que el equipo de producción esté demasiado aislado del equipo de desarrollo, en los casos en que los procesos de trabajo estén demasiado cargados de burocracia o en los casos en que el departamento de operaciones tenga excesivo celo en cuanto a la implantación de cambios y nuevas funcionaliades.


Facebook nuevamente es diferente. Tom Cook comenta en su charla como los ingenieros de operaciones se mezclan con los ingenieros de desarrollo para trabajar conjuntamente en los parches y funcionalidades. Asimismo, los desarrolladores adquieren plena autonomía y responsabilidad sobre sus actos, de modo que deben participar en todas las fases de despliegue y sentarse con el equipo de sistemas a la hora de pasar cambios a producción.

Una de las consecuencias de esto es que en Facebook han eliminado la capa de QA. Esto en mi opinión es un error, pero no cabe duda de que Facebook es un sitio diferente. Me imagino que todo el desarrollo de productos y parches estará dirigido por procesos controlados, pero desde luego la impresión que se extrae de la charla es que los ingenieros tienen poco más que barra libre para introducir cambios a su antojo sin el más mínimo control de calidad. Claro, uno después se explica como en funcionalidades que no son 'core' como puedan ser las aplicaciones Facebook, un día las cosas funcionan y otro no :-)


Pero entonces, ¿cómo suplen esta falta de control de Calidad? Con un gran énfasis en la monitorizacíon y la instrumentación. Todo lo que sucede en los servidores de Facebook está completamente controlado. Para ello disponen de herramientas internas o usan software Open Source como Ganglia, Nagios o CFEngine. Pueden controlar en cualquier instante el estado de cualquier servidor, rack, cluster o centro de datos. Además de resaltar la importancia de la monitorización y la instrumentación se hace relevante también el automatizar la reacción ante caidas de cualquiera de estos componentes, ya sea eliminando el nodo, reiniciándolo, etc.

Una cosa queda clara en la charla. En Facebook no se toman las operaciones a broma. Aunque nuevamente hay cosas muy desconcertantes en cuanto al control de calidad. En la charla muestran herramientas de comunicación interna que se utilizan para que todo el mundo en la compañía conozca el estado de los sistemas en cualquier momento independientemente de tu puesto en la compañía. Es algo sin duda fantástico. Pero asimismo cuando sucede un problema lo que se entiende de la charla es que lo resaltan en su portal interno de noticias y esperan a que ningún ingeniero introduzca código, ya que éstos tienen la capacidad de introducir cambios en cualquier momento. Esto no hace más que reafirmar en mi interior que Facebook no es una empresa tradicional, y que por el contrario ofrece ese sentimiento de funcionamiento bastante anárquico en ciertos aspectos.

Por último, os dejo el video por si interesa verlo vosotros mismos.

Yahoo lanza S4

Con un dominio muy molón Yahoo acaba de lanzar hace nada S4. Se trata de una "Distributed Stream Computer Platform" o para que nos entendamos, una librería/plataforma para procesar grandes cantidades de datos que van llegando continuamente en tiempo real.

Hace nada acaban de publicar una entrada en su blog presentando el proyecto. Se trata de llevar la filosofía que MapReduce y Hadoop han popularizado para el procesado de trabajos en batch al procesado de datos que fluyen en tiempo real. Ellos ponen el ejemplo del análisis mediante técnicas de aprendizaje por computador de miles de búsquedas por segundo realizadas por millones de usuarios diariamente en el buscador de Yahoo.

Todo esto de manera que sea distribuido, es decir que haya múltiples nodos que se dividan el procesado de ese flujo de datos; que sea escalable, es decir que para soportar el procesado de más información sólo sea necesario introducir más máquinas; y que sea tolerante a fallos, es decir que si algún nodo se cae, haya otro que sea capaz de procesar esos datos.

La plataforma es Open Source, la han liberado bajo la licencia Apache y está desarrollada completamente en Java.

Como escalar tu startup técnicamente

Poco os puedo explicar yo sobre eso, todavía estamos en la fase de escalar como negocio así que mucha escalación técnica aún no necesitamos. Pero por casualidad descubrí el otro día un video en vimeo muy recomendable donde gente de Doppler, exs de Twitter, Google, etc. explican como fue su proceso de escalabilidad que les han permitido llegar a donde han llegado.

Seedcamp Week '09. Day 3. Technical Panel from Seedcamp on Vimeo.

Tiene partes muy recomendables.

Sharding, ¿sí o no?

Facebook, Digg y muchos otros utilizan una técnica denominada Sharding para escalar.

El Sharding es una técnica que consiste en particionar los datos de tu base de datos horizontalmente agrupándolos de algún modo que tenga sentido y que permita un direccionamiento más rápido. Una agrupación típica puede ser por id por ejemplo: "los usuarios del 1 al millón están en esta base de datos"; o por nombre "los usuarios cuyo nombre va de la A a la E" están en esta base de datos".

Típicamente estos shards, agrupaciones o segmentos estarán localizados en tablas en diferentes bases de datos y localizaciones físicas. El Sharding no tiene por qué estar basado únicamente en una tabla y una columna, puede ser a nivel de todas las tablas. Por ejemplo podríamos decir "todos los datos de usuarios cuyo perfil está en los Estados Unidos los redirigimos a la base de datos del servidor en Estados Unidos, y todos los de Asia van a la base de datos de Asia".

El Sharding como tal mejora la escalabilidad y el rendimiento al agrupar menos datos en tablas más pequeñas por lo que los accesos serán mucho más rápidos. En caso de tener múltiples servidores en múltiples localizaciones, el basar el Sharding en la localización geográfica permite también disminuir considerablemente la latencia.

¿Cuándo se necesita hacer Sharding? Principalmente cuando el volumen de datos comienza a ser inmanejable. A tablas más grandes, más lentos son los accesos. No es lo mismo acceder a una tabla de diez mil usuarios que a una tabla de diez millones de usuarios. También comentan en el blog del que hablaré en breve que es bueno hacer Sharding cuando el volumen de escrituras es demasiado grande para un único servidor. En bases de datos, escrituras=bloqueos, bloqueos=contención de recursos, contención de recursos=mala experiencia de usuario, a parte del problema con la sincronización con slaves.

Todo esto viene a cuento de que en el blog de rendimiento de MySQL nos advierten de por qué no deberíamos hacer Sharding prematuramente. El problema principal es que Sharding se ha convertido en una palabra de moda. A fin de cuentas, si Facebook lo hace, ¿por qué no lo voy a hacer yo? Pues porque yo no tengo 120 millones de usuarios activos, ¿quizás?

Mi opinión es que en general estoy de acuerdo con el no hacer Sharding desde el principio, pero sólo si este va a impactar en la estructura de la base de datos. Es decir, dividir los usuarios de la A-E, la F-M, ... etc. a bote pronto parece como una mala decisión, al menos sin saber si vamos a tener cien usuarios o cien mil.

Pero planificar para Sharding no siempre tiene por que ser una mala decisión. En Java por ejemplo hay herramientas que nos lo facilitan. En general, el particionar por aplicación o por país además no son decisiones demasiado relevantes y que no tienen porque impactar el desarrollo en sobremanera, al tiempo que en el futuro facilitan enormemente la escalabilidad del servicio. Eso sí, hay que tener claro que a mayor número de shards mayor mantenimiento. No es lo mismo actualizar un índice en una tabla que hacerlo en cinco, especialmente porque al hacerlo en cinco es más fácil el dejarse uno olvidado.