Melhores Práticas para Conectores de Grande Escala

Definimos uma estratégia de conector em grande escala como aquela que produz mais de 5000 Unidades de Trabalho no BWX por solicitação de sincronização. Uma unidade de trabalho no BWX é uma combinação de um arquivo + etapa de fluxo de trabalho + par de idiomas. Então, um projeto com 5 arquivos, 2 etapas de fluxo de trabalho (Tradução + Revisão) e 5 idiomas resultará em 50 unidades de trabalho. Você pode ver como não é tão difícil ultrapassar 5000 Unidades de Trabalho quando você começa a multiplicar essas variáveis. É tentador querer centralizar tudo em um único projeto, mas nossa experiência mostra que, com conectores de grande escala, agrupar projetos por par de idiomas é a melhor maneira de prosseguir. Isso pode parecer apenas uma questão de como você escolhe definir um projeto, mas vai muito além disso. Neste artigo, vamos analisar o impacto desta decisão em termos de:

1. Brokeragem de Mensagens
2. Resolução de problemas
3. Mitigação de riscos
4. Fila/desempenho
5. Potencial de automação
6. Facilidade de gerenciamento
7. Escalabilidade

Message Brokering1) A mensageria cresce exponencialmente com conectores de grande escala. Nós vimos conectores que criam mais de 1MM mensagens por solicitação de sincronização. Isso resulta em uma tremenda atividade do servidor e problemas de desempenho que podem ser mitigados dividindo projetos por localidade. Solução de problemas2) Isso está diretamente ligado à mitigação de riscos. Mas na localização, frequentemente encontramos problemas que são restritos a uma determinada região e como isso afeta a análise, segmentação e pré/pós-processamento de um determinado conjunto de arquivos. Ao desmembrar entre locais, você pode criar Expressões Regulares específicas do local, regras de processamento, segmentação que proporcionam muito mais flexibilidade no que diz respeito à arquitetura geral. Em vez de trabalhar restrito com correções que funcionam em todos os lugares, você pode iterar com base na localidade e, no final, alcançar um padrão de comportamento mais maduro e previsível quando trabalhar com base nas localidades. Mitigação de riscos3) Ao desacoplar projetos em um por localidade, você irá mitigar os riscos de gerenciamento, pois se algo der errado em uma determinada localidade, isso não significa que todo o mecanismo de solicitação de pull/delivery esteja comprometido. Você pode isolar e naturalmente compartimentalizar problemas. Isso pode não parecer uma coisa durante o SOP, mas quando surgem problemas inesperados (e eles sempre surgem na localização), você ficará grato por ter construído uma casa de tijolos em vez de uma feita de palha. Queuing/Performance4) Em vez de alinhar 150.000 elementos para processamento, por exemplo, você pode alinhar 15.000 elementos dez vezes. Novamente, isso não parece ser uma grande diferença, já que você acabará processando os mesmos 150.000 elementos, mas ter a flexibilidade de processar em série versus em paralelo ou oportunisticamente conforme desejado oferece muito mais flexibilidade, bem como largura de banda de desempenho. Potencial de automação5) Normalmente, as decisões e fluxos de trabalho do projeto serão assimétricos entre as localidades. Separar projetos por localidade lhe proporciona uma flexibilidade muito maior em termos de potencial de automação a longo prazo. Você pode ter um cenário em que você tem parâmetros completamente diferentes, bem como conjuntos de dados, quando você se segrega por localidade, em oposição a consolidar todos os elementos juntos. Management6) Este também é contra-intuitivo. Do ponto de vista de gestão, a consolidação é geralmente a melhor prática para uma governança melhor. Mas em conectores de grande escala, o oposto é verdadeiro. Um projeto naturalmente filtrará por localidade, permitindo que diferentes gerentes de projeto possuam partes diferentes do projeto com mais facilidade, reduzindo o uso de filtros para gerar relatórios e criando maior simplicidade no acompanhamento do que está acontecendo por localidade. Escalabilidade7) Com conectores em grande escala, você chegará a um ponto em que simplesmente se torna impossível escalar agrupando todas as unidades de trabalho em um único projeto. Ao separar, você estabelece o framework para um programa que é mais fácil de escalar a longo prazo. Lembre-se de que as coisas se multiplicam quando se trata de unidades de trabalho e mensagens. Ao separar por localidade, você elimina uma das grandes variáveis multiplicadoras, permitindo que você escale muito mais facilmente. Conclusão: Existe uma ilusão de que a consolidação é melhor. Uma pull-request por projeto facilita a vida de todos. Embora isso seja verdade para conectores de pequena escala, isso se desfaz em conectores de grande escala. Nosso objetivo é sempre entregar as soluções mais elegantes e confiáveis para nossos clientes e vimos repetidamente que, em situações de grande escala, dividir e conquistar é o caminho a seguir.

Consolidando em um único projetoSeparando por localidadeO projeto inteiro tem um status de 0 ou 1O status pode ser estratificado por localidadeAnálise singular, filtragem e estrutura de RegExFramework flexível por localidadeFila de uma única via por projetoFila flexível e processamento distribuído naturalmenteFiltragem por localidade dentro do projetoUm passo a menos de filtragemRegras de automação que funcionam em todos os casosParâmetros e dados de automação específicos da localidadeTodos os ovos em uma cesta do ponto de vista de riscoRisco distribuído entre as localidadesComplexo de isolar e solucionar problemasUm fator a menos de grande variabilidade tornando mais fácil solucionar problemas