Il y a plusieurs dizaines d'années, j'étais ingénieur logiciel chez Autodesk et j'ai été l'instigateur de la fonction CUI dans AutoCAD.
Pour ceux d'entre vous qui ne se souviennent pas de cette époque, cette fonctionnalité a introduit une nouvelle interface utilisateur permettant de personnaliser les barres d'outils et les menus d'AutoCAD. Ses premières versions ont été difficiles, mais elle est finalement devenue une fonctionnalité solide d'AutoCAD.
L'une des principales plaintes de la première version d'AutoCAD était que la boîte de dialogue était trop lente à répondre. En faisant quelques recherches sur le sujet, j'ai découvert que les personnes qui avaient réellement étudié la question avaient constaté que tout ce qui prenait plus de 800 millisecondes constituait un retard notable pour l'utilisateur. J'ai été mis au défi de réduire le temps de démarrage de la boîte de dialogue de 1500 ms à 800 ms.
J'ai pensé : "Vraiment ? Est-ce que 700 ms vont faire une différence significative dans la vie de quelqu'un ?"
Au fait, j'ai réussi à atteindre cet objectif particulier de réduction de la latence, et ce fut le début de la fin de ma carrière dans le développement de logiciels de base... mais c'est une histoire pour un autre jour... 
.
En 2014, bat365 m'a demandé d'améliorer la prise en charge des applications couramment utilisées par le secteur de l'architecture et de la construction. Alors que j'en apprenais davantage sur le fonctionnement de bat365 , les gens n'arrêtaient pas de parler de la latence du réseau étendu, de la lenteur des performances réseau d'AutoCAD et de la façon dont ils essayaient de réduire de 100 ms les temps de transfert, et je me suis dit "Vraiment ? Est-ce que 100 ms vont faire une différence significative dans la vie de quelqu'un ?".
La réalité est que oui, tout cela compte. Ce qui semble être de petits incréments de temps peut s'ajouter à des retards significatifs qui coûtent cher - surtout si l'on considère les heures facturables - au cours d'une année. Même les petits retards qui se produisent régulièrement, ou à des moments inopportuns, peuvent être source de frustration pour les utilisateurs finaux.
Pourquoi la latence a un si grand impact
Lorsque bat365 a commencé à prendre en charge les fichiers AutoCAD, les entreprises qui s'adressaient à bat365 pour obtenir de l'aide essayaient depuis des années de faire fonctionner l'ouverture de fichiers DWG sur le réseau étendu.
La tendance des entreprises d'architecture et de génie civil à se développer par le biais d'acquisitions s'est souvent traduite par la création de multiples succursales. Il est donc logique qu'elles veuillent être en mesure de faire appel à des personnes possédant des compétences spécialisées pour les projets, chaque fois qu'elles en ont besoin, où qu'elles se trouvent.
À l'époque, on pensait que les fichiers DWG étaient volumineux et qu'il fallait donc simplement une plus grande largeur de bande pour les transférer. Lorsque cela n'a pas fonctionné, des accélérateurs de réseau étendu ont été essayés, mais les choses ne se sont pas beaucoup améliorées.
Lorsque bat365 a analysé l'activité, nous avons réalisé que la majorité du temps passé à ouvrir des fichiers n'était pas consacré au transfert des données. C'était dans tous les appels d'opérations de fichiers qui devaient se produire sur une longue distance.
Lorsqu'une application comme AutoCAD ouvre un fichier DWG, les données dont elle a besoin ne sont pas toutes contenues dans ce seul fichier. Elle doit plutôt ouvrir de très nombreux fichiers de soutien, tels que des polices, des types de lignes et des fichiers de forme.
Ajoutez à cela le chemin de recherche d'AutoCAD qui recherche les fichiers de support à de nombreux endroits.
Ajoutez à cela le nombre d'appels que Windows effectue entre la machine cliente et le serveur pour chaque fichier qu'il ouvre.
Ajoutez à cela toutes les xréfs qui ne sont que d'autres DWG, qui ouvrent également des polices, des types de lignes et des formes.
Maintenant, vous pouvez commencer à voir comment l'ouverture d'un fichier DWG donne les résultats suivants :
1 DWG X 20 fichiers de support X 5 chemins de recherche X 20 appels Windows X 10 xrefs = 20 000 transactions !
Si vous ouvrez un fichier DWG où la machine cliente et le serveur se trouvent sur un réseau local avec moins de 1 ms de latence, ces 20 000 transactions prennent généralement moins de 20 secondes. La plupart des gens n'y réfléchiraient pas à deux fois si AutoCAD prenait 20 secondes pour ouvrir un fichier complexe contenant plusieurs xréfs.
Une connexion d'un océan à l'autre en Amérique du Nord est généralement de 100 ms ou moins (ceci est également vrai pour la plupart des continents). Il est donc facile de se tromper en pensant qu'une latence de 80 ms n'est rien. C'est pratiquement imperceptible pour le commun des mortels.
Même 10 transactions à 80 ms restent insignifiantes pour l'utilisateur moyen.
Mais lorsque vous avez 20 000 transactions à effectuer, et que chacune d'entre elles est sujette à une latence, vous attendez maintenant un grand total de 1 600 secondes pour qu'un fichier s'ouvre - soit 26 minutes et 40 secondes !
Comment bat365 surmonte la latence sur le réseau étendu (là où les autres solutions échouent)
bat365Pour résoudre le problème de la latence sur le réseau étendu, l'approche de l'entreprise consiste à maintenir la grande majorité de ces appels au niveau local, sur le poste client. Ainsi, si vous utilisez votre système de CAO sur votre ordinateur portable ou de bureau, vous êtes connecté à un filer bat365 sur votre réseau local.
Aujourd'hui, chacune de ces 20 000 transactions a retrouvé une latence inférieure à 1 ms et, avec un flash entièrement SSD, les temps d'ouverture sont souvent inférieurs à 10 secondes.
De même, si vous travaillez sur une VDI dans le cloud, vous pouvez vous connecter à un filer bat365 juste à côté dans le cloud et obtenir la même latence inférieure à la milliseconde.
Verrouillage de fichiers en temps réel sans latence
bat365 crée un système de fichiers global - CloudFS - qui relie tous les bureaux d'une entreprise dans le monde et leur permet de fonctionner comme si chacun se trouvait dans le même bureau.
En tant que tel, CloudFS doit gérer le verrouillage sur un nombre quelconque de sites. Il en résulte un certain trafic WAN, mais comme bat365 est le système d'exploitation du filer, il peut limiter au maximum le trafic WAN. bat365L'approche de CloudFS, qui consiste à conserver un seul verrou pour chaque fichier et à le déplacer d'un filer à l'autre, signifie que si le verrou existe déjà sur le filer pour le fichier à ouvrir, il n'y a pratiquement pas de trafic WAN pour ouvrir le fichier.
Cela signifie également que le verrouillage des fichiers a lieu en temps réel, se comportant exactement comme si l'utilisateur travaillait avec un fichier stocké sur le NAS local, en y accédant via le réseau local.
Il en va de même pour l'enregistrement d'un fichier. Étant donné que la quasi-totalité des transactions s'effectue avec un filer local via une connexion inférieure à la milliseconde, les sauvegardes sont rapides et efficaces.
Le résultat est une performance des fichiers AutoCAD qui donne l'impression d'être locale, même si le fichier lui-même se trouve dans un stockage en nuage centralisé fourni par AWS, Microsoft Azure, Google Cloud ou même un fournisseur de nuage privé (sur place).
Ce qui a commencé comme un moyen de résoudre la lenteur du réseau d'AutoCAD a été la genèse du travail à distance
Avance rapide jusqu'au début de l'année 2020 et je me suis retrouvé, avec toute l'équipe de bat365 , à aider certaines des plus grandes entreprises d'architecture, d'ingénierie et de construction du monde à passer rapidement au travail à distance.
L'année 2020 restera à jamais connue comme l'année où l'investissement dans la technologie des systèmes de fichiers en nuage global a porté ses fruits sans équivoque.
bat365 pourrait déjà permettre d'effectuer en temps réel des opérations critiques sur les fichiers, comme le verrouillage des fichiers et des plages d'octets, alors que toute une organisation travaille à partir d'un ensemble de données en nuage. Lorsque les entreprises du monde entier ont renvoyé leur personnel chez lui, j'ai réalisé que c'était peut-être le meilleur exemple que nous ayons jamais eu de la raison pour laquelle surmonter la latence sur le WAN est vraiment important.
Nous n'avions pas seulement le réseau étendu à gérer, mais aussi les connexions Internet personnelles.
Auparavant, bat365 installait généralement des filers (généralement des machines virtuelles) sur place pour mettre en cache les fichiers fréquemment utilisés et fournir des performances à faible latence.
En 2020, nous avons simplement placé ces filers dans des régions en nuage, c'est-à-dire les régions les plus proches des entreprises qui en avaient besoin. Ces installations à faible latence ont permis à plusieurs des plus grandes entreprises AEC du monde de passer au travail à distance sans ralentir sensiblement les performances des fichiers AutoCAD.
Je suis particulièrement fier de certains de nos plus anciens clients AEC - Mead & Hunt à Madison, WI, et Garver à North Little Rock, AR, en sont deux excellents exemples - qui ont réalisé les meilleures années de leur histoire en 2020 malgré tous les défis auxquels ils ont été confrontés. De même, des entreprises comme C&S, Fluor, WSP et Gensler sont restées performantes malgré la nécessité de faire passer en quelques semaines une importante main-d'œuvre mondiale au travail à distance.