
Meilleures pratiques pour les connecteurs à grande échelle

Nous définissons une stratégie de connecteur à grande échelle comme une stratégie qui produit plus de 5 000 unités de travail dans BWX par requête de synchronisation. Une unité de travail dans BWX est une combinaison d'un fichier + d'une étape de workflow + d'une paire de langues. Ainsi, un projet avec 5 fichiers, 2 étapes de workflow (Traduction + Révision) et 5 langues se traduira par 50 unités de travail. Vous voyez comme il n'est pas si difficile de dépasser les 5000 Unités de Travail quand on commence à multiplier ces variables. Il est tentant de vouloir tout centraliser dans un seul projet, mais notre expérience montre qu'avec des connecteurs à grande échelle, regrouper les projets par paire de langues est la meilleure voie à suivre. Cela peut sembler être simplement une question de définition d'un projet, mais cela va beaucoup plus loin que cela. Dans cet article nous décortiquerons l'impact de cette décision en termes de :
- Courtage de messages
- Résolution de problèmes
- Atténuation des risques
- File d'attente/performances
- Potentiel d'automatisation
- Facilité de gestion
- Évolutivité
Courtage des messages1) La messagerie connaît une croissance exponentielle avec des connecteurs à grande échelle. Nous avons vu des connecteurs créer plus de 1 MM de messages par requête de synchronisation. Cela entraîne d'énormes problèmes d'activité et de performances du serveur qui peuvent être atténués en divisant les projets par paramètres régionaux. Résolution des problèmes2) Ceci est directement lié à l'atténuation des risques. Mais dans la localisation, nous rencontrons souvent des problèmes limités à une locale donnée et leur impact sur l'analyse. segmentation et pré/post traitement d'un ensemble de fichiers donné. En dissociant les paramètres régionaux, vous pouvez créer des RegularExpressions spécifiques aux paramètres régionaux, des règles de traitement, une segmentation qui offre beaucoup plus de flexibilité en ce qui concerne l'architecture globale. Plutôt que de travailler de manière restreinte avec des correctifs qui fonctionnent dans tous les domaines, vous pouvez itérer en fonction des paramètres régionaux et finalement atteindre un modèle de comportement plus mature et prévisible lorsque vous travaillez en fonction des paramètres régionaux.Atténuation des risques3) En découplant les projets en un par paramètre régional, vous atténuerez risques de gestion, car si quelque chose ne va pas dans un environnement local donné, cela ne signifie pas que l'ensemble du mécanisme de demande d'extraction/livraison est compromis. Vous pouvez isoler et naturellement compartimenter les problèmes. Cela peut ne pas sembler être une chose pendant le SOP, mais lorsque des problèmes inattendus surviennent (et ils le font toujours dans la localisation), vous serez reconnaissant d'avoir construit une maison en briques par opposition à une maison en foin. 150 000 éléments à traiter par exemple, vous pouvez aligner 15 000 éléments dix fois. Encore une fois, cela ne semble pas être une grande différence puisque vous devrez finalement traiter les mêmes 150 000 éléments, mais avoir la flexibilité de traiter en série par rapport à en parallèle ou de manière opportuniste comme vous le souhaitez vous donne beaucoup plus de flexibilité ainsi qu'une bande passante de performance. Potentiel d'automatisation5 ) En règle générale, les décisions de projet et les flux de travail seront asymétriques entre les paramètres régionaux. Séparer les projets par paramètres régionaux vous donne une plus grande flexibilité en ce qui concerne le potentiel d'automatisation à long terme. Vous pouvez avoir un scénario où vous avez des paramètres entièrement différents ainsi que des ensembles de données lorsque vous séparez par paramètres régionaux au lieu de consolider tous les éléments ensemble. Gestion6) Celui-ci est également contre-intuitif. Du point de vue de la gestion, la consolidation est généralement la meilleure pratique pour une meilleure gouvernance. Mais dans les connecteurs à grande échelle, c'est le contraire qui est vrai. Un projet filtrera naturellement par paramètre régional, permettant à différents chefs de projet de s'approprier plus facilement différentes parties du projet, réduisant l'utilisation de filtres pour générer des rapports et créant une plus grande simplicité en ce qui concerne le suivi de ce qui se passe par paramètre régional. connecteurs, vous atteindrez un point où il deviendra tout simplement ingérable d'évoluer en regroupant toutes les unités de travail en un seul projet. En vous séparant, vous établissez le cadre d'un programme plus facile à mettre à l'échelle à long terme. Rappelez-vous que les choses se multiplient lorsqu'il s'agit d'unités de travail et de messages. En séparant par paramètre régional, vous éliminez l'une des grandes variables multiplicatrices, ce qui vous permet de passer à l'échelle beaucoup plus facilement. Conclusion Il y a une illusion que la consolidation est meilleure. Une pull-request par projet facilite la vie de chacun. Bien que cela soit vrai pour les connecteurs à petite échelle, cela s'effondre dans les connecteurs à grande échelle. Notre objectif est toujours de fournir les solutions les plus élégantes et les plus fiables à nos clients et nous avons vu à maintes reprises qu'avec des situations à grande échelle, diviser pour mieux régner est la voie à suivre.
moins d'étape de filtrageRègles d'automatisation qui fonctionnent dans tous les domainesParamètres d'automatisation et données spécifiques aux paramètres régionauxTous les œufs dans un panier du point de vue des risquesRisque réparti entre les paramètres régionauxComplexe à isoler et à dépannerUne variable moins importante facilitant le dépannage