Sistemas distribuidos – Falacias de la computación distribuida Parte 2

Falacias de la computación distribuida

Artículos relacionados:

• Sistemas distribuidos – ¿Conoces que es el Teorema CAP?
• Sistemas distribuidos – Falacias de la computación distribuida Parte 1

Introducción

Las falacias de la computación distribuida son ideas erróneas que se tienen acerca del desarrollo distribuido  y que no se presentan al momento de desarrollar una aplicación monolítica. Una aplicación monolítica es a una aplicación que se despliega en un solo nodo o servidor. Muchas veces al desconocer estos puntos descuidamos aspectos importantes de una aplicación distribuida que no tomamos en cuenta en el desarrollo hasta que llega el momento del despliegue.

En la semana me estuvieron preguntando mucho: ¿Por qué se compara a la programación orientada a objetos con la programación en red o distribuida, si yo creo aplicaciones en red usando POO? Creo que una comparación más  acertada es la siguiente: aplicaciones monolíticas vs aplicaciones distribuidas; esto quiere decir aplicaciones que nacen para ser desplegadas en un solo servidor (monolíticas)  vs aplicaciones que nacen para ser desplegadas en varios servidores (distribuidas). A la final usar POO es un medio para construir cualquiera de estos dos tipos de aplicaciones.

Aplicación monolítica vs Aplicación distribuida

Falacias de la computación distribuida

Las falacias de la computación distribuida son 8 y en el artículo anterior vimos las 4 primeras:

1. The network is reliable: la red es confiable.
2. Latency is zero: la latencia es nula
3. Bandwith is infinite: el ancho de banda es infinita
4. The network is secure: la red es segura

A continuamos revisaremos las 4 restantes:

5.  Topology doesn’t change: la topología no cambia

Topology doesn’t change

Es común que cuando desarrollemos asumamos cosas acerca de la topología en la que se va a desplegar el sistema dentro de nuestro código. La topología es la forma en como fue diseñada la red que son un conjunto de nodos interconectados. En lugar de poner todo esto en nuestro código, es mejor construir el sistema en piezas que puedan ser configuradas para que coincidan con la topología en la cual se despliega.

6. There is one administrator: existe un solo administrador

There is one administrator

Cuando construimos una aplicación distribuida el programador es el único administrador ya que todo está en su pc, pero una vez en producción alguien más se va a encargar de administrarlo.  Es un hecho que no solo una persona va a tomar el control del sistema, probablemente sea alguien más que tome el control de la red, otra tome la administración del servidor y finalmente otra la ejecución de las aplicaciones. En casos de hosting en la nube el administrador  probablemente no conoce que aplicaciones se están ejecutando, de modo que debemos desarrollar aplicaciones que permitan a cada administrador poder manejar la parte del sistema que necesita.

7. Transport cost is zero: el costo del transporte es cero

Transport cost is zero

Dentro de un proceso crear un objeto no cuesta nada, todo el costo involucrado es solo un poco de memoria y la memoria es barata, pero en un sistema distribuido enviar un mensaje cuesta dinero. Para que se puedan enviar mensajes por la red debemos tenerla operativa, por lo tanto se le tiene que pagar a personas, electricidad y comprar espacio, de todo esto sale el costo por mensaje que es el actual costo de ancho de banda. Al momento de desarrollar es fácil olvidar que estamos trabajando en un ambiente de pruebas en el que cada mensaje que se envía se va a transformar en dinero.

8. The network is homogeneous: la red es homogénea

The network is homogeneous

Primero, no siempre las aplicaciones con las que vamos a trabajar están desarrolladas sobre la misma tecnología, el mismo lenguaje o sobre el mismo framework. Segundo, no siempre las aplicaciones exponen su información usando los mismos protocolos y configuraciones, unos pueden usar HTTP o TCP y otros pueden correr bajo 32 o 64 bits. En el caso de usar el protocolo HTTP la información expuesta puede estar en formato XML o JSON. Por lo tanto nuestro aplicativo debe tener en cuenta sus necesidades para saber cómo debe exponer su información.

Conclusiones:

Sun Microsystems y L Peter Deutsch crearon una lista de errores comunes que cometían los programadores que empezaban a desarrollar aplicaciones distribuidas. Esta lista está formada por 8 falacias: La red es confiable, no hay latencia, el ancho de banda es infinito, la red es segura, la topología no cambia, existe un solo administrador, no hay un costo de transporte y la red es heterogénea. Finalmente, en lugar de hablar de POO vs programación distribuida un término más adecuado puede ser aplicaciones monolíticas versus aplicaciones distribuidas.

Referencias:

• Pluralsight – Patterns for Building Distributed Systems for The Enterprise
• Fallacies of Distributed Computing Explained
• Wikipedia – Fallacies of distributed computing

Metal Tip:

Este artículo lo escribí escuchando la canción Brothers of metal de la banda Manowar de Estados Unidos, les comparto el enlace.

Happy coding and Stay Heavy lml