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

Falacias de la computación distribuida
Falacias de la computación distribuida

Artículos relacionados:

Introducción

Al inicio de los 90’s los ingenieros de Sun Microsystems y L Peter Deutsch crearon una lista de errores comunes que cometían los nuevos programadores cuando aplicaban la computación distribuida. Esta lista fue conocida como Fallacies of computing distribuited y tiene como objetivo dar a conocer las diferencias que existen entre la programación orientada a objetos (object oriented programming) y la programación de red (network programming). Además, señalan que traer los conceptos de la programación orientada a objetos al momento de desarrollar un sistema distribuido nos puede llevar por un mal camino.

OOP vs Network Programming
OOP vs Network Programming

Falacias de la computación distribuida

Las falacias de la computación distribuida son 8 y las vemos a continuación:

1. The network is reliable: la red es confiable.
The network is reliable
The network is reliable

Esta falacia está relacionado con el teorema CAP, especialmente con la tolerancia a la partición. Muchas de las tecnologías con las que trabajamos ocultan el hecho de que estamos usando la red para enviar solicitudes a diferentes maquinas. Por ejemplo: si usamos WCF, es muy fácil hacer una llamada a un servicio web dentro de un método, solo se necesita llamar a la clase proxy creada. Las llamadas a métodos que se encuentran entre objetos son confiables. Cuando hacemos la llamada a un objeto sabemos que este recibirá los parámetros, ejecutara el método y devolverá un resultado, entonces el cliente seguirá trabajando. En el caso de que el método lance una excepción, el cliente capturara la excepción y realizara las acciones apropiadas. Pero no se puede decir lo mismo de las llamadas a servicios web o de cualquier comunicación que se realice sobre la red. Cuando se usa un servicio web no hay garantía que el servicio reciba la petición y cuando retorne un valor no estamos seguros que el cliente reciba el resultado. Si ocurre una excepción, a veces es difícil saber si fue por causa de un problema en el servicio web o simplemente ocurrió algún tipo de falla en la red. Debemos entender que las excepciones que ocurren en la programación orientada a objetos no son las misma que cuando nos comunicamos por la red, por lo tanto debemos controlar las fallas de comunicación entre los nodos. Una petición puede fallar en su camino al servidor o peor aún la respuesta puede fallar cuando regresa al cliente, si ocurre un error en este punto un cliente no puede detectar, en la mayoría de casos, que lado fallo si el mensaje fallo en su camino al servicio o en el regreso al cliente.

2. Latency is zero: la latencia es nula
Latency is zero
Latency is zero

Hacer una petición a otro servidor toma tiempo, en la programación orientada a objetos esto casi no es un problema. Cuando se envía una petición a una maquina remota, tenemos que estar atentos al tiempo total que toma un responder una petición, esto es conocido como latencia. Mientras esperamos la respuesta nos encontramos en un estado de limbo hasta el retorno de la petición, siempre y cuando no ocurra un timeout por exceder el tiempo máximo de conexión. El problema que ocurre cuando se lanza un timeout es que no conocemos el estado en que acabo la petición: no sabemos si se llegó a ejecutar con éxito o no. Muchos sistemas que desarrollamos trabajan bien cuando se encuentran en modo local (localhost), pero no se comportan de la misma forma cuando son desplegados en ambientes reales, esto se puede dar porque ha ocurrido alguna de estas dos falacias.

3. Bandwith is infinite: el ancho de banda es infinita
Bandwith is infinite
Bandwith is infinite

Cuando se llama a un método no existen problemas con el envió y la recepción de los parámetros. No nos preocupamos si se trata de una lista grande o un documento XML el parámetro siempre llega a su destino, ya que solo se comparte el lugar en la memoria donde se encuentra, por ese motivo es que no es complicado. Pero en un sistema distribuido no existe el concepto de memoria compartida de modo que se tiene que enviar todo el contenido, ya sea una lista grande o un documento XML. Un error común que comentemos los programadores es que simplemente copiamos todo el objeto en un simple petición, recordemos que mientras más grande es la petición aumenta la probabilidad que esta falle. Por lo tanto al trabajar con un sistema distribuido los mensajes necesitan partirse en bloques. Ahora debemos tener algo más en cuenta que al partir el mensaje en bloques cada uno va individualmente al servidor, por cada uno existe una latencia y estas latencias aumentan el tiempo. De modo que debemos hacer un balance entre la latencia y el ancho de banda y tenemos que escoger el balance correcto para hacer a nuestro sistema más confiable.

4. The network is secure: la red es segura
The network is secure
The network is secure

Un sistema distribuido puede ser atacado de formas que no se replican en un sistema monolítico. Existen más vulnerabilidades cuando el mensaje viaja por la red y estas vulnerabilidades pueden ser aprovechadas por un atacante. Por lo tanto, debemos buscar formas de como proteger nuestra aplicación ya que al atacante solo le basta encontrar una debilidad para que pueda atacar a nuestro sistema y exponer sus vulnerabilidades. Este no solo es un problema de aplicaciones expuestas en Internet, actualmente existen muchas aplicaciones empresariales que  están construidas con la creencia que al encontrarse en una red interna no van a sufrir problemas de seguridad, pero esto no es verdad la red interna tampoco es segura y la mayoría de los ataques ocurren ahí.

En el siguiente post veremos las 4 falacias de la computación distribuida restantes.

  • 5.  Topology doesn’t change: la topologia no cambia
  • 6. There is one administrator: existe un solo administrador
  • 7. Transport cost is zero: el costo del transporte es cero
  • 8. The network is homogeneous: la red es homogénea
Referencias:
Metal Tip:

Este artículo lo escribí escuchando la canción Metal Invasion de la banda Freedom Call de Alemania, les comparto el enlace. Happy coding and Stay Heavy lml

Anuncios

2 comentarios en “Sistemas distribuidos – Falacias de la computación distribuida Parte 1

  1. Interesante artículo! Espero la segunda parte!

    Lo único que señalaría es que no acabo de compartir esta contraposición -no es el único sitio donde lo he escuchado- entre programación orientada a objetos y programación distribuida. La programación orientada a objetos es un paradigma cuya base es la modularización del código, herencia, polimorfismo, encapsulación, bajo acoplamiento y la abstracción: todo ello es perfectamente aplicable -si así se desea- en la programación distribuida. La O.O no habla (o al menos no tengo constancia de que hable) de que las entidades que va a manejar el sistema esten en la misma máquina, se ejecuten remotamente, etc…

    Le gusta a 1 persona

    1. Hola, creo que en lugar de hablar de POO vs programación distribuida un término más adecuado puede ser aplicaciones monolíticas versus aplicaciones distribuidas. A la final usar POO es un medio para construir cualquiera de estos dos tipos de aplicaciones.
      Saludos

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s