Hace lo que parece décadas, yo era ingeniero de software en Autodesk y fui el impulsor de la función CUI en AutoCAD.
Para los que no recuerden tanto, esta función introdujo una nueva interfaz de usuario para personalizar las barras de herramientas y los menús de AutoCAD. Sus primeros lanzamientos fueron difíciles, pero finalmente se convirtió en una función sólida dentro de AutoCAD.
Una de las principales quejas en la primera versión de AutoCAD era que el diálogo era demasiado lento para responder. Investigando un poco sobre esto, encontré que la gente que había estudiado esto había encontrado que cualquier cosa que tomara más de 800 milisegundos era un retraso notable para un usuario. Me enfrenté al reto de reducir el tiempo de inicio del diálogo de 1500ms a 800ms.
Pensé: "¿En serio? ¿700ms van a suponer una diferencia significativa en la vida de alguien?"
Por cierto, logré ese objetivo de reducir la latencia, y ese fue el principio del fin de mi carrera en el desarrollo de software básico... pero esa es una historia para otro día 
.
Avancemos hasta 2014 y bat365 me trajo a bordo para mejorar la compatibilidad con las aplicaciones que el sector de la ingeniería civil utiliza habitualmente. A medida que aprendía más sobre el funcionamiento de bat365 , la gente no paraba de hablar de la latencia de la WAN, del lento rendimiento de la red de AutoCAD y de cómo intentaban reducir los tiempos de transferencia en 100 ms, y pensé: "¿En serio? ¿100ms van a suponer una diferencia significativa en la vida de alguien?"
La realidad es que sí, todo importa. Lo que parecen pequeños incrementos de tiempo pueden sumarse a retrasos significativos que cuestan una cantidad importante -especialmente si se consideran las horas facturables- en el transcurso de un año. Incluso los pequeños retrasos que se producen con regularidad, o en malos momentos, pueden provocar la frustración de los usuarios finales.
Por qué la latencia tiene un impacto tan grande
Cuando bat365 empezó a admitir archivos de AutoCAD, las empresas que acudían a bat365 en busca de ayuda llevaban años intentando que la apertura de archivos DWG a través de la WAN funcionara.
La tendencia de las empresas de arquitectura, ingeniería y construcción a crecer mediante adquisiciones ha dado lugar a menudo a múltiples sucursales, por lo que es lógico que quieran contar con personal especializado en los proyectos siempre que lo necesiten, independientemente de dónde se encuentren.
La opinión generalizada de la época era que los archivos DWG eran grandes y que, por tanto, se necesitaba más ancho de banda para transferirlos. Cuando eso no ayudó, se probaron los aceleradores WAN, pero las cosas no mejoraron mucho.
Cuando bat365 analizó la actividad, nos dimos cuenta de que la mayor parte del tiempo invertido en abrir archivos no estaba en la transferencia de los datos. Era en todas las llamadas de operación de archivos que tenían que ocurrir a través de una larga distancia.
Cuando una aplicación como AutoCAD abre un archivo DWG, los datos que necesita no están todos contenidos en ese archivo. Más bien, tiene que abrir muchísimos archivos de apoyo, como fuentes, tipos de líneas y archivos de formas.
A esto hay que añadir la ruta de búsqueda de AutoCAD, que busca archivos de soporte en muchas ubicaciones.
A esto hay que añadir el número de llamadas que realiza Windows entre la máquina cliente y el servidor por cada archivo que abre.
Además, hay que añadir todos los xrefs que no son más que otros DWG, que también abren fuentes, tipos de línea y formas.
Ahora, puede empezar a ver cómo al abrir un archivo DWG se obtiene lo siguiente:
1 DWG X 20 archivos de soporte X 5 rutas de búsqueda X 20 llamadas a Windows X 10 xrefs = ¡20.000 transacciones!
Si se abre un archivo DWG en el que la máquina cliente y el servidor están en una LAN con menos de 1ms de latencia, estas 20.000 transacciones tardan menos de 20 segundos normalmente. La mayoría de la gente no se lo pensaría dos veces si AutoCAD tardara 20 segundos en abrir un archivo complejo con varias referencias externas.
Una conexión de costa a costa en Norteamérica suele ser de 100 ms o menos (lo mismo ocurre en la mayoría de los continentes). Así que es fácil engañarse pensando que 80ms de latencia no son nada. Es prácticamente imperceptible para el ciudadano medio.
Incluso 10 transacciones a 80ms siguen siendo insignificantes para el usuario medio.
Pero cuando tienes 20.000 transacciones que realizar, y cada una de ellas está sujeta a latencia, estás esperando un total de 1.600 segundos para que se abra un archivo, es decir, ¡26 minutos y 40 segundos!
Cómo bat365 supera la latencia en la red de área amplia (donde otras soluciones fallan)
bat365El enfoque de la empresa para resolver la latencia en la WAN es mantener la gran mayoría de estas llamadas locales en la máquina del cliente. Así, si ejecuta su sistema CAD en su ordenador portátil o de sobremesa, se conectará a un archivador bat365 en su misma LAN.
Ahora, cada una de esas 20.000 transacciones vuelve a tener menos de 1ms de latencia y, con un flash totalmente SSD, los tiempos de apertura suelen estar por debajo de los 10 segundos.
Del mismo modo, si trabaja en una VDI en la nube, puede conectarse a un archivador bat365 justo al lado en la nube y conseguir la misma latencia de menos de un milisegundo.
Bloqueo de archivos en tiempo real y sin latencia
bat365 crea un sistema de archivos global, CloudFS, que conecta tantas oficinas globales como tenga una empresa y les permite operar como si todos estuvieran en la misma oficina.
Como tal, CloudFS tiene que gestionar el bloqueo en cualquier número de ubicaciones. Esto da lugar a cierto tráfico WAN, pero como bat365 es el sistema operativo en el archivador, puede mantener el tráfico WAN al mínimo. bat365El enfoque de CloudFS de mantener un único bloqueo para cada archivo y moverlo de archivador a archivador significa que si el bloqueo ya existe en el archivador para el archivo que se está abriendo, prácticamente no tiene que haber tráfico WAN para abrir el archivo.
También significa que el bloqueo de archivos tiene lugar en tiempo real, comportándose igual que si el usuario estuviera trabajando con un archivo almacenado en el NAS local, accediendo a él a través de la red de área local.
Lo mismo ocurre cuando se guarda un archivo. Dado que casi todas las transacciones se producen con un archivador local a través de una conexión de menos de un milisegundo, los guardados se producen de forma rápida y eficiente.
El resultado es un rendimiento de los archivos de AutoCAD que parece local, aunque el propio archivo se encuentre en un almacenamiento centralizado en la nube proporcionado por AWS, Microsoft Azure, Google Cloud o incluso un proveedor de nube privado (en las instalaciones).
Lo que comenzó como una forma de resolver el lento rendimiento de la red de AutoCAD fue la génesis del trabajo a distancia
Avancemos de nuevo hasta principios de 2020 y me encontré -junto con todo el equipo de bat365 - ayudando a algunas de las mayores empresas de arquitectura, ingeniería y construcción del mundo a realizar la transición al trabajo a distancia con gran rapidez.
El año 2020 será conocido para siempre como el año en que la inversión en tecnología de sistemas de archivos en la nube global dio sus frutos de forma inequívoca.
bat365 podría permitir ya que las operaciones críticas de archivos, como el bloqueo de archivos y el bloqueo de rangos de bytes, se realicen en tiempo real, mientras toda una organización trabaja con un conjunto de datos basado en la nube. Cuando las empresas de todo el mundo enviaron a sus empleados a casa, me di cuenta de que este era quizás el mejor ejemplo que habíamos tenido de por qué superar la latencia en la WAN es realmente importante.
Ahora, no sólo teníamos que lidiar con la WAN, sino también con las conexiones personales a Internet.
Anteriormente, bat365 solía instalar archivadores (normalmente máquinas virtuales) en las instalaciones para almacenar en caché los archivos de uso frecuente y proporcionar un rendimiento de baja latencia.
En 2020, simplemente colocamos esos archivadores en las regiones de la nube, las más cercanas a donde las empresas los necesitaban. Estas instalaciones de baja latencia ayudaron a muchas de las mayores empresas de AEC del mundo a realizar la transición al trabajo remoto sin ralentizar notablemente el rendimiento de los archivos de AutoCAD.
Estoy especialmente orgulloso de algunos de nuestros clientes de AEC más antiguos -Mead & Hunt en Madison, WI y Garver en North Little Rock, AR son dos grandes ejemplos- por haber logrado los mejores años de su historia en 2020 a pesar de todos los retos a los que se enfrentaron. Igualmente, empresas como C&S, Fluor, WSP y Gensler han mantenido un rendimiento constante a pesar de tener que realizar la transición de grandes plantillas globales al trabajo remoto en cuestión de semanas.