Resumiendo los principios de diseño de la construcción de software

Hoy he tenido que hacer el ejercicio de resumir los principios de diseño que yo creo que deben dirigir un proceso de construcción de software. Después de bastante reflexión me he quedado sólo con cuatro. Los siguientes:

  1. KISS (Keep it simple, stupid). Creo que nunca valoraremos lo suficiente el valor de simplificar todo lo posible los sistemas que construimos.
  2. No construyas si puedes usar algo que ya existe.
  3. Entrega (parte de) el producto cuanto antes a sus usuarios, sigue construyéndolo apoyándote en los comentarios de los usuarios.
  4. La interfase del usuario debe ser web, siempre.
  5. La interfase del usuario es un animal totalmente distinto. Debe diseñarla y construirla un equipo de especialistas en interfases de usuario y debe estar totalmente desacoplada de la lógica de la aplicación.

¿Qué opináis?.

eBay procesa 5.700 millones de invocaciones al mes a su API

Últimamente ando involucrado en varios proyectos en los que debo analizar la arquitectura de sistemas de información de grandes multinacionales. Un denominador común de estos proyectos es que tarde o temprano recibo la tópica respuesta “con nuestros inmensos volúmenes eso no es posible”.

Siempre reacciono de la misma forma, preguntando cuáles son (cifras) esos enormes volúmenes y muy a menudo resulta que la respuesta no está muy a mano. La enormidad es una sensación que no se concreta en cifras.

Y entonces llego a artículos como éste (la fuente original es ésta) en el que se informa de que eBay atiende mas de 5.700 millones de invocaciones mensuales a su API y pienso – esto si que es volumen y no los que gastamos por aquí – 🙂

En este otro artículo podéis encontrar información acerca de cómo eBay es capaz de hacer esto. Para los impacientes, el stack tecnológico es Java, IBM WebSphere Application Server y Oracle Enterprise Server; nada demasiado cool 😉. Lo cool está en la forma de usarlo, lo estrictos que son en el cumplimiento de los principios de diseño. Algunas pinceladas:

  • La base de datos es el cuello de botella, hay que llevarse todo el proceso posible a las capas superiores (incluso joins).
  • La estrategia de escalado es horizontal.
  • El desacoplamiento es vital. Integración asíncrona entre los componentes.
  • Hay que virtualizar todos los componentes posibles. Reduce las dependencias de los elementos físicos y facilita el despliegue y la evolución de la plataforma.

RAIDb

RAIDb (Redundant Array of Inexpensive Databases) es un concepto propuesto en Septiembre de 2003, por Emmanuel Cecchet, Julie Marguerite y Willy Zwaenepoel y recogido en un documento de 27 páginas de lectura obligada.

En este documento los autores definen el concepto de RAIDb como una extensión del concepto de RAID (Redundant Array of Inexpensive Disks) aplicado a los repositorios de datos y presentan la implementación que han realizado de su concepto bajo el nombre de C-JDBC.

El problema a resolver es la escalabilidad de las bases de datos y la propuesta es hacerlo de forma horizontal utilizando hardware (y software) de bajo coste.

Tradicionalmente se ha avanzado mucho en la escalabilidad de las capas superiores de una arquitectura de sistemas de información moderna (multi-capa). Así el escalado de la capa de presentación (servidores web) y de la capa de aplicaciones/procesos (servidores de aplicaciones) está bastante bien resuelta. Mientras que la escalabilidad de la capa de datos normalmente se aborda mediante el escalado vertical (agrupaciones con un número de nodos pequeño, típicamente 2, y muy potentes).

Así es “fácil” encontrar instalaciones en las que existen centenares de servidores web atendiendo la presentación, decenas de servidores de aplicaciones ejecutando la aplicación/los procesos y un macro-cluster de base de datos soportando todo eso.

Ese macro-cluster acaba siendo la hardware más potente del fabricante de turno (IBM pSeries, Sun Fire Enterprise Server 25K, HP Superdome, etc.) con decenas de procesadores (sino cientos), cantidades ingentes de memoria y de almacenamiento. En estos clusters casi siempre y por definición, la mitad de la capacidad de proceso está desperdiciada. En un cluster de 2 nodos cada uno de los nodos tiene que ser capaz de asumir la carga completa del cluster ante la caída del otro nodo. Esto significa que se intenta mantener la carga del cluster de forma que ninguno de sus nodos supere el 50% de carga y, por lo tanto, el otro 50% de su capacidad no se usa en condiciones normales.

El planteamiento de RAIDb es llevar el concepto de escalabilidad horizontal a la capa de datos. Permitir el escalado horizontal (añadir más servidores, más pequeños, más baratos) de una forma sencilla, eficaz y económica. RAIDb viene a cubrir las necesidades de escalabilidad y de tolerancia a fallos de la capa de datos.

Al igual que en el caso de RAID, los creadores de RAIDb identifican tres tipos de agrupamiento: RAIDb-0, RAIDb-1 y RAIDb-2. RAIDb-0 es un modelo en el que las bases de datos se particionan pero no se distribuyen (no hay redundancia), RAIDb-1 implica un mirrorring completo de las bases de datos (redundancia completa); mientras que RAIDb-2 define un escenario de replicación incompleta de las bases de datos.

Adicionalmente los autores identifican distintos subtipos: RAIDb-1ec, RAIDb-2ec

Relación rendimiento/tolerancia a fallos de las distintas variedades de RAIDb

En el documento mencionado no solo se explica y define todo lo dicho hasta ahora, sino que también recoge información acerca de un conjunto de benchmarks realizados por los autores (concretamente han utilizado el benchmark TCP-W) y que ilustran las capacidades de escalado de las distintas alternativas dependiendo del número de nodos en el cluster.

 

raidb-02.gif

Como os decía antes os recomiendo la lectura del documento original.

Nuevos palabros: REST y SOA

Hace ya algún tiempo que oigo hablar de REST y tenía en mis marcadores un par de entradas al respecto pendientes de leer.

Para introducirnos, REST significa REpresentational State Transfer y se trata de un estilo de de hacer las cosas basado en el principio de que todo debe ser accesible vía una URI. Fundamentalmente este concepto se aplica a las entidades de un sistema, los datos.

Por otro lado ROA significa Resource Oriented Architecture y se aplica a aquellos sistemas cuya arquitectura sigue el concepto de REST.

Si deseais produndizar más en estos temas os recomiendo empezar por aquí: