Las 8 falacias de la computación distribuida

La necesidad de aumentar las capacidades de procesamiento dio lugar al nacimiento de la computación distribuida. Para que un sistema se pueda comunicar con otro esto debe de hacerse por medio de una red de datos, que puede tener diversas arquitecturas y protocolos. Ahora … ¿Qué tanto podemos asumir que esa red de datos que sirve de medio de comunicación siempre responderá perfectamente sin crear “problemas” para nuestra computación distribuida ? La pregunta anterior siempre debe ser tenida en cuenta antes de diseñar sistemas distribuidos, como por ejemplo: los Microservicios.

En la década del 90, dentro de la empresa Sun Microsystem (ahora parte de Oracle), L Peter Deutsh, creador de GhostScript definió que era un patrón común presente en desarrolladores que empiezan en el mundo de la programación/computación distribuida asumir un grupo presunciones que más tarde traen consigo errores y mal funcionamiento de las aplicaciones; inicialmente eran 7 elementos relacionados al comportamiento de la red que no eran tenidos en cuenta en el diseño y puesta en operación de los sistemas. En 1994 el fundador de Java James Gosling agregó una octava; más tarde se formalizó como las 8 falacias de la computación distribuida.

Para los que no lo tengan claro, según la RAE:

Del lat. fallacia.

1. f. Engaño, fraude o mentira. No lo creas, es una falacia.

Real Academia Española

Falacia 1: La red es confiable

Se asume que la red es confiable; lo cierto es que pueden ocurrir situaciones que hagan que la red de datos deje de estar, por ejemplo: cortes en la corriente eléctrica, fallos en el proveedor de servicios, fallos en los equipos de interconexión, saturación por volumen de tráfico, etc. Las aplicaciones deben ser diseñadas teniendo en cuenta este tipo de situaciones, por ejemplo aplicando prácticas como reintentos. Ver: 1, 2.

Falacia 2: La latencia es cero o no es importante

Si bien es cierto que cuando trabajamos en una LAN controlada con equipos de interconexión de altas velocidades es muy probable que no tengamos problemas de latencia que puedan afectar el desempeño de nuestras aplicaciones, sin embargo la realidad es que en la práctica es probable no sepamos las características del entorno donde se desplegará nuestra aplicación; más aún las aplicaciones deben desarrollarse lo mas optimizadas posible para poder saltear este tipo de problemas de latencia. En la actualidad cuando ponemos aplicaciones en producción en proveedores cloud como AWS, GCP o Azure puede pasar que instancias de aplicaciones se ejecuten incluso en zonas geográficas diferentes. Nunca debemos asumir que no tendremos problemas de latencia.

Falacia 3: El ancho de banda es infinito

La realidad es que cada día la velocidad de internet se incrementa cada vez más y el ancho de banda aumenta, pero también debemos tener en cuenta que el volumen de datos que se maneja en muchas ocasiones crece incluso más rápido que la tecnología de hardware que lo soporta; servicios streaming de videos para TV o llamadas son ejemplos de soluciones que demandan cada día más ancho de banda. Tengamos en cuenta además que si nuestra aplicación va a ser pública las condiciones de conectividad de los puntos más cercano a los consumidores por lo general son más modestas que las que se emplean en el entorno de desarrollo o despliegue de la aplicación y eventualmente pudiéramos tener problemas con el ancho de banda que terminarán degradando el rendimiento de nuestra plataforma.

Falacia 4: La red es segura

Este es probablemente el error más grande que cometemos como desarrolladores: No prestar demasiada atención a la seguridad de nuestra aplicación. Desde el primer día de un proyecto se debe tener en cuenta la seguridad como un aspecto fundamental para la construcción de un software. La fundación OWASP ofrece un grupo de directrices muy útiles para reforzar la seguridad de nuestras aplicaciones.

Falacia 5: La topología de la red no cambia

Aunque esta falacia en particular se ha ido superando con el paso del tiempo con el surgimiento de tecnologías como los sistemas de registro y descubrimiento, es un error común pensar que la estructura de la red no va a cambiar o que nuestra aplicación va a estar desplegada en un mismo lugar con una dirección IP fija. En los sistemas modernos esto ya no tiene lugar, a cada minuto se suben y bajan instancias de aplicaciones a demanda. A la hora de desarrollar aplicaciones debemos evitar el uso de direcciones hardcodeadas y de otras prácticas que aten nuestro aplicación a estructuras rígidas de la red.

Falacia 6: Existe un solo administrador

En la práctica en redes grandes o sistemas complejos no existirá un único administrador. Debemos preparar y diseñar software que pueda ser administrado por varias personas con la granularidad de los permisos que requiera.

Falacia 7: El coste el transporte es cero

Cuando tenemos sistemas distribuidos necesitamos llevar información de la instancia o aplicación A a la B. En la comunicación intervienen equipos de hardware que tienen un coste, sistemas de balanceo y ancho de banda. A nivel de software debemos pensar por otra parte como encontrar la forma más “barata” de comunicación entre A y B en cuanto al: Protocolo a usar, Mecanismo de serialización/deserialización que se va a emplear, etc. Si nuestra aplicación va a ofrecer servicio a los usuarios, por ej: aplicaciones móviles hay que tener en cuenta a nivel de diseño que se consuma la menor cantidad de datos del dispositivo móvil del usuario.

Falacia 8: La red es homogénea

Básicamente no podemos asumir que la red es homogénea, todo lo contrario. Las aplicaciones deben ser capaces de adaptarse y funcionar correctamente en diversos entornos.

Este artículo también lo tenemos en nuestro canal de Youtube, puedes verlo acá directamente:

Espero te haya gustado el artículo, acá te dejo el original en el blog de Oracle.