Distribuir o no distribuir, esa es la cuestión…

Tanto en el mundo real como en digital en raras ocasiones podemos encontrar un escenario de negociación de más por más. Como ya sabemos es mucho más frecuente encontrarnos con un más por menos. Es habitual tener que negociar hasta llegar a un equilibrio entre las partes que componen un sistema. Las ecuaciones que gobiernan el universo del desarrollo de software se componen de variantes como rendimiento, coste de desarrollo, coste de mantenimiento, escalabilidad…que deberemos equilibrar para llevar al proyecto a buen puerto.

La distribución es uno de esas variantes. De echo es una de las más representativas. Desde el primer momento debemos tener en cuenta que distribuir objetos no es gratuito. Esta característica es atractiva por poderosa pero conlleva un alto impacto en el coste de desarrollo y mantenimiento así como en el rendimiento. Desde el punto de vista de arquitectura, debemos tener en cuenta las implicaciones de la distribución y valorar de manera «aséptica» todas las alternativas. Muchas veces he visto diseños que se podrían definir como «Sueño del arquitecto, pesadilla del desarrollador».

Una regla sencilla puede ser «No distribuyas nunca la aplicación». Si el mundo fuese un «poco» más simple y esta regla fuese válida en cualquier circunstancia, asunto terminado. (Me ha dado un escalofrío solo de pensarlo…).

Por lo tanto en ocasiones debemos distribuir de manera obligatoria, pero cuando?
Básicamente cuando no nos quede más remedio, como por ejemplo:

  • Una de las separaciones más obvias es la tradicional entre clientes y servidores de software.
    Los PCs son diferentes nodos y comparten repositorios de datos. Esto nos obliga a separara procesos que se comunican, siendo cliente/servidor la típica división entre procesos.
  • Una segunda división ocurre a menudo entre la parte servidor de las aplicaciones y la base de datos (esa gran desconocida…) 
    Por supuesto puedes hacer correr tu aplicación en el mismo proceso de la base de datos utilizando elementos como procedimientos almacenados, pero en muchas ocasiones esto no es practico (por decirlo de alguna manera…). Debemos tener en cuenta que aunque el servidor y la base de datos corran en la misma máquina, lo hacen en procesos diferentes. Una vez que debemos comunicar diferentes procesos pagamos la mayor parte del coste de la distribución.
    Por supuesto los servidores de SQL están diseñado para estas practicas de modo que podamos minimizar el coste.
  • Otra clásica separación en procesos suele ocurrir en los sistemas Web entre el Servidor Web y el Servidor de Aplicaciones. Normalmente asociado a aspectos de seguridad relacionados con exponer al exterior solo la parte Web reduciendo así la superficie de ataque posible.
  • Emplear paquetes de software hace frecuente tener que realizar distribuciones entre procesos por las diferencias entre los proveedores. En ocasiones utilizan sus propios procesos así que de nuevo estamos distribuyendo. 
  • Por último puede existir razones de peso por las que es necesario dividir el software de servidor. Eso sí, debemos asegurar muy bien de que es estrictamente obligatorio. No nos queda otra que dividir nuestro software en componentes remotos con interfaz de grano grueso. No vamos a hacer las mismas llamadas que si no estuviese distribuido, verdad…??
    Si tienes dudas sobre esto, puedes continuar leyendo sobre el tema en SOA != Client Server +  WCF

Como conclusión podemos decir que distribuir es una característica muy potente pero con un lado oscuro del cual debemos siempre tener en cuenta. Siendo conscientes de las implicaciones y valorando los riesgos podemos hacer llegar nuestro software hasta cotas más exigentes.