Hace poco más de una semana, pero me lo pasé bien y aprendí algunas cosas tanto de la sesión como de los debates en el CloudCamp de Los Ángeles. Propuse, y finalmente dirigí, una sesión sobre escalado de datos. En realidad, la propuse como "Scaling Your Data: Tanto antes como después de necesitarlos".
Parte de la razón por la que lo propuse es que hubo una discusión sobre el teorema CAP durante la propuesta de sesiones, y lo que se dijo estaba un poco fuera de lugar. CAP se discute bien en muchos sitios, (un buen blog es de Jonathan Gray, CTO y cofundador de Streamy. CAP son las siglas de Consistencia, Disponibilidad y tolerancia a Partición de red. Curiosamente, mucha gente siguió intentando hacer de la última P rendimiento o introducir rendimiento en la mezcla. El rendimiento (o al menos las ventajas y desventajas que conlleva) se tratan mejor en otro conjunto de letras W+R>N. En las instalaciones de Microsoft en el centro de Los Ángeles había una sala dedicada principalmente al escalado de datos. La primera sesión corrió a cargo de .... y trató sobre el teorema CAP. Al principio fue un poco polémico, ya que había algunas afirmaciones de que se podían obtener los tres con un uso juicioso de la tecnología de Microsoft, pero a través de la discusión en la sala terminamos en el lugar correcto y de acuerdo unos con otros. La sesión fue dirigida por Abhijit Gadkari, de ZimbaTech. A continuación, el propio SoCalDevGal (Lynn Langit) hizo una presentación sobre SQL Azure. Desde luego, aprendí un poco sobre lo que ofrece Microsoft y lo que piden sus desarrolladores. Incluso aprendí algunos nuevos acrónimos de tres letras :) SQL Azure es la base de datos relacional alojada como servicio de Microsoft. De la presentación, quedó claro que inicialmente Microsoft no estaba planeando un almacén de datos alojado compatible con SQL (lo que los haría más como SimpleDB de Amazon o BigTable de Google como se accede a través de Google App Engine). Al final, los comentarios de los clientes les llevaron a proporcionar todo el SQL posible, incluida la integración con todas las herramientas para desarrolladores de Microsoft. Curiosamente, Microsoft sugiere la fragmentación de datos a escala. Esto se debe en parte a que el producto inicial está limitado a bases de datos de 10 GB. SoCalDevGal dejó muy claro que se trataba de una limitación inicial y que había que ceder en algunos aspectos para poder cumplir el calendario. La otra parte realmente interesante sobre SQL Azure, que me pareció pertinente dado el resto de la discusión, fue la aparente decisión de hacer de SQL Azure un sistema CA, en lo que respecta a CAP. Incluso pedí que se verificara, y esa era de hecho la intención. La razón por la que esto es tan importante para mí es que la decisión de diseño aquí, junto con la replicación a través de centros de datos, significa que la única manera de hacer esto correctamente es desconectar el sistema (o una parte de su seguridad) en el caso de que un centro de datos se corte de la 'red. Dado que todos los datos están en al menos dos centros de datos, y no se sabe cuáles, es posible que los centros de datos sean más que "pares", lo que significa que una partición completa de un solo centro de datos podría significar una interrupción de al menos dos, y tal vez más. Esto es bueno para sus usuarios en el sentido de que es completamente compatible con sus aplicaciones, pero también significa que podría haber un "momento CNN" algún día, lo que significa que un par de fallos de telco dejarán fuera de línea a un gran número de clientes de SQL Azure. Para que no se malinterprete, esto no es una crítica a la tecnología de Microsoft o alguna deficiencia que deberían haber superado. Simplemente fue una decisión de diseño tomada por el equipo de SQL Azure. Aquí es donde está la "ingeniería" en nuestra disciplina... hay compensaciones en cualquier diseño. La última sesión de la tarde en la sala acabó siendo la mía. Hice una rápida presentación de mí mismo y una rápida evaluación de quién había siquiera mirado en cosas como memcached, gearman, Haoop HBase, Cassandra y similares. Resultó que casi nadie había pensado en esto. Creo que esto se debe, en parte, a que Microsoft hizo un gran trabajo a la hora de colocar a los asistentes en los asientos para este evento. Debido a la experiencia del público con este tipo de cosas, dirigí la sesión como un ejercicio un poco cerebral para entender por qué alguien puede querer buscar diferentes formas de almacenar datos. Estoy seguro de que no lo he cubierto todo, pero he afirmado algunas razones:
- Escala - Trasladar parte de la inteligencia a los clientes en una arquitectura informática distribuida simplifica la división de componentes y, por tanto, su escalado. También resulta mucho más fácil acercar la caché al lugar donde se utilizan los datos, lo que ayuda a escalar.
- Productividad de los desarrolladores - Esto es válido en ambos sentidos, ya que tener que aprender una nueva forma de almacenar y recuperar datos es una mina de productividad, pero poder evolucionar las estructuras de datos y los mecanismos de persistencia sin tener que declarar nunca cambios en un modelo de datos (implicar a los DBA, etc.) es liberador.
- Disponibilidad - Para algunas clases de aplicaciones, puede tener todo el sentido que la mayoría de los datos estén disponibles, aunque una pequeña parte no lo esté actualmente.
- Distribución geográfica - Si se empieza a pensar en los datos de forma un poco diferente, resulta fácil distribuirlos geográficamente.
Tendré que escribir más sobre esto en un futuro no muy lejano. He estado estudiando muchos trabajos anteriores (incluso algunos artículos académicos) y hay algunas ideas interesantes por ahí. p.d.: los chicos de TechZulu grabaron la sesión. Puede que esté en su sitio web en algún momento... He comprobado el enlace pero aún no está.
