L. Peter Deutsch fundador de Aladdin Enterprises y más conocido como el creador de Ghostscript, afirmó que todo programador que empieza en el mundo de las aplicaciones distribuidas comete una serie de presunciones erróneas cuyo resultado se traduce en errores o reducciones substanciales del alcance del sistema. Estas presunciones, que inicialmente fueron 7, se conocen como las Falacias de la Computación Distribuida.
Como curiosidad esta lista fue elaborada inicialmente por Bill Joy y Tom Lyon y contemplaba 4. En 1994, Peter acuño las 7 falacias de la computación distribuida hasta que finalmente James Gosling, inventor de Java, añadió la octava. Todos ellos pertenecieron en su momento a Sun Microsystems.
Nótese la Ironía en la descripción de alguna de ellas.
1.- La red es confiable:
Sólo es necesario imaginarnos que estamos en un CPD repleto de “hierro” con luces verdes parpadeando funcionando a las mil maravillas. Si nos preguntan cómo es nuestro CPD todos diremos que es seguro, sin duda; no hay cables mal colocados por el suelo, todos van conectados a la UPS externa, la habitación está climatizada para evitar calentamientos y contiene filtros de aire para evitar partículas y muchísimas cosas más. Pero la realidad es que en un momento dado, una inclemencia meteorológica, un error humano o la simple actualización del software de algunos de los servidores pueden hacer que cualquier máquina, por mucho que insistamos en convencernos de que eso no es posible, puede dejar de funcionar. En tal caso, nos hemos preguntado alguna vez, ¿Qué sucedería si eso ocurriera? Pues sencillamente perderíamos Mensajes/Datos.
2. La latencia es cero; la latencia no es problema:
Empecemos definiendo que la latencia es el tiempo que tarda una llamada en cruzar la red. Este tiempo puede ser relativamente pequeño en una LAN, algo más importante en una WAN pero definitivamente significante en Internet. Una pregunta, ¿Hemos calculado alguna vez la diferencia entre la latencia en el acceso a memoria con la latencia de una Red? Evidentemente todos estamos de acuerdo en que es más lenta por Red, pero si os dijera que la diferencia es que la latencia por Red es (aprox.) una 1.000 veces más lenta que en memoria, ¿No deberíamos tenerla en cuenta? Tan sólo debemos plantearnos un escenario dónde hay un objeto remoto con varias propiedades. Si tenemos que acceder a cada una de las propiedades pagaremos el tiempo de ida y de vuelta a través de la Red por cada una de las llamadas.
3. El ancho de banda es infinito:
Bien, lo cierto es que el ancho de banda se incrementa año tras año gracias a las inversiones en infraestructura pero olvidamos una cosa: el tráfico de datos aumenta más rápidamente. Por tanto, sea cual sea el ancho de banda, si la cantidad de tráfico de datos es superior contemplemos la posibilidad de congestiones y si hay congestiones quizás no “lleguemos” en el tiempo inicialmente estimado.
4. La red es segura:
Si, la red seria 100% segura en el “hipotético” caso que únicamente estuviera conectada entre sí y no tuviera conexión con nada más. Desde el momento en el qué expones una parte de la misma conectadas a otras, dígase Internet, desde los Virus,Troyanos hasta usuarios malintencionados pasando por CD’s, DVD’s pueden ocasionar un agujero de seguridad en la red.
5. La topología no cambia:
A menos que un servidor caiga o tenga que ser movido a otra red o dominio o una aplicación pase a ser utilizada por usuarios móviles a través de la Red Interna o de Internet o tengamos que crear un túnel entre nuestro CPD y aplicaciones alojadas en “la nube” o tengamos que proveer o quitar el acceso por VPN para clientes, proveedores o trabajadores / colaboradores remotos. Cualquier aplicación con direcciones IP “hardcodeadas” tendrán consecuencias.
6. Hay uno y sólo un administrador:
Es probable en redes pequeñas; poco probable en redes grandes dónde además pueden estar geográficamente distribuidas y para más inri pueden pertenecer a empresas distintas. Imaginaos las consecuencias si además, unos son culés y otros merengues (más en los tiempos que corren) y comparten privilegios sobre algunas subredes.
7. El coste de transporte es cero:
Por todos es sabido que las inversiones en infraestructura en Hardware son gratuitas. Aunque tengamos por la mano y seamos unos expertos serializando y deserializando objetos estas operaciones tiene un coste. Ah! y el Hardware también. :-)
8. La red es homogénea:
Si queremos limitar nuestro sistema entonces la red será homogénea. Sin embargo olvidémonos de la tediosa interoperabilidad entre sistemas o plataformas. Si algún día viene un gran cliente potencial cuya plataforma operativa no sea compatible con nuestros protocolos y servicios propietarios no tendrá cabida. El Director General lo entenderá.
Conclusión
Medio en broma, medio en serio he opinado en base a mi propia experiencia sobre las falacias de la computación distribuida. No existe una fórmula mágica que las evite todas; simplemente seamos conscientes de su importancia y como mínimo, no las asumamos como ciertas.
Por último quiero compartir una frase de Leslie Lamport, de Microsoft Research, que describe de forma irónica las consecuencias de la Computación Distribuida:
“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.”
Más información | Fallacies of Distributed Computing
Imagen de | Galeria de Torley
