Esta é uma breve digressão na atual série de artigos sobre como evitar a introdução de serviços para várias entidades. Uma conversa interessante no jantar levou a pensamentos que eu decidi escrever.

Lei de Amdahl

Em 1967, Gene Amdahl argumentou contra a computação paralela. Ele argumentou que o crescimento da produtividade é limitado porque apenas parte da tarefa pode ser paralela. O tamanho do restante da "parte seqüencial" difere em tarefas diferentes, mas está sempre lá. Este argumento ficou conhecido como a lei de Amdal.

Se você criar um gráfico de "aceleração" da tarefa, dependendo do número de processadores paralelos alocados a ela, verá o seguinte:


Este é um gráfico assintótico para um fragmento que não pode ser paralelizado (a “parte seqüencial”), portanto, há um limite superior para a aceleração máxima

De Amdal para USL

O interessante da lei de Amdal é que, em 1969, havia realmente muito poucos sistemas multiprocessadores. A fórmula é baseada em outro princípio: se a parte seqüencial da tarefa for igual a zero, essa não será uma tarefa, mas várias.

Neil Gunther expandiu a lei de Amdahl com base em observações das medições de desempenho de muitas máquinas e desenvolveu a Lei de Escalabilidade Universal (USL). Ele usa dois parâmetros: um para "competição" (que é semelhante à parte seqüencial) e o segundo para "inconsistência" (incoerência). A inconsistência está relacionada ao tempo gasto na restauração da consistência, ou seja, uma visão geral do mundo dos diferentes processadores.

Em uma CPU, a sobrecarga de negociação ocorre devido ao cache. Quando um núcleo modifica uma linha de cache, ele diz aos outros kernels para recuperá-la do cache. Se todos precisam da mesma linha, gastam tempo carregando-a da memória principal. (Esta é uma descrição ligeiramente simplificada ... mas, de uma forma mais precisa, ainda há o custo da negociação).

Todos os nós do banco de dados incorrem em custos de coordenação devido aos algoritmos correspondentes e ao salvar a sequência de dados. A penalidade é paga ao alterar dados (como no caso de bancos de dados transacionais) ou ao ler dados no caso de repositórios finalmente acordados.

Efeito USL

Se você criar um gráfico USL, dependendo do número de processadores, uma linha verde aparecerá:


A linha roxa indica que a lei de Amdahl preveria

Observe que a linha verde atinge um pico e depois diminui. Isso significa que há um certo número de nós nos quais o desempenho máximo. Adicione mais processadores - e o desempenho é reduzido . Eu vi isso em testes de estresse reais.

As pessoas geralmente querem aumentar o número de processadores e aumentar a produtividade. Existem duas maneiras de fazer isso:

1. Reduza a parte seqüencial
2. Reduza os custos de aprovação

USL em grupos humanos?

Vamos tentar a analogia. Se a “tarefa” computacional é um projeto, podemos representar o número de pessoas no projeto como o número de “processadores” que executam o trabalho.

Nesse caso, a parte seqüencial é um trabalho que só pode ser realizado sequencialmente, passo a passo. Este pode ser um tópico para um artigo futuro, mas agora não estamos interessados ​​na essência da parte seqüencial.

Parece que vemos uma analogia direta com os custos da reconciliação. Independentemente do tempo que os membros da equipe gastam na restauração de uma visão comum do mundo, os custos do alinhamento estão presentes.

Para cinco pessoas em uma sala, esses custos são mínimos. Desenho de cinco minutos com um marcador no quadro-negro uma vez por semana, aproximadamente.

Para uma equipe grande em vários fusos horários, a multa pode crescer e formalizar. Documentos e orientações. Apresentações para a equipe e assim por diante.

Em algumas arquiteturas, a reconciliação não é tão importante. Imagine uma equipe com funcionários em três continentes, mas cada um está trabalhando em um serviço que usa dados em um formato estritamente definido e cria dados em um formato estritamente definido. Eles não precisam de consistência com relação a alterações nos processos, mas precisam de consistência com relação a quaisquer alterações nos formatos.

Às vezes, ferramentas e idiomas podem alterar os custos da reconciliação. Um dos argumentos a favor da digitação estática é que ela ajuda a interagir em equipe. Em essência, os tipos de código são um mecanismo para traduzir mudanças em um modelo do mundo. Em um idioma digitado dinamicamente, precisamos de artefatos secundários (testes de unidade ou mensagens de bate-papo) ou precisamos criar limites em que alguns departamentos raramente restauram a consistência com outros.

Todos esses métodos visam reduzir os custos de coordenação. Lembre-se de que o dimensionamento excessivo causa uma diminuição na taxa de transferência. Portanto, se você tem altos custos de coordenação e muitas pessoas, a equipe como um todo trabalha mais devagar. Vi equipes onde parecia que podíamos cortar metade das pessoas e trabalhar duas vezes mais rápido. Os custos de USL e reconciliação agora ajudam a entender por que isso está acontecendo - é mais do que apenas remoção de lixo. Trata-se de reduzir a sobrecarga da troca de modelos mentais.

No The Loop of Fear, me referi às bases de código em que os desenvolvedores sabiam da necessidade de mudanças em larga escala, mas tinham medo de causar danos acidentalmente. Isso significa que a equipe superinflada ainda não chegou a um consenso. Parece muito difícil conciliar após a perda. Isso significa que é impossível ignorar os custos de coordenação.

USL e microsserviços

Na minha opinião, a USL explica o interesse em microsserviços. Ao dividir um sistema grande em partes cada vez menores, implantadas independentemente uma da outra, você reduz a parte seqüencial do trabalho. Em um sistema grande com um grande número de participantes, a parte seqüencial depende da quantidade de esforço para integrar, testar e implantar. A vantagem dos microsserviços é que eles não precisam de trabalho de integração, teste de integração ou atraso na implantação sincronizada.

Mas o custo da correspondência significa que você pode não obter a aceleração desejada. Talvez a analogia seja um pouco tensa aqui, mas acho que é possível considerar mudanças na interface entre microsserviços como exigindo reconciliação entre equipes. Se isso for demais, você não obterá os benefícios desejados dos microsserviços.

O que fazer sobre isso?

Minha sugestão: veja a arquitetura, a linguagem, as ferramentas e a equipe usada. Pense em onde o tempo é perdido para a reconciliação quando as pessoas fazem mudanças no modelo sistêmico do mundo.

Procure lacunas . Lacunas entre os limites internos do sistema e divisões dentro da equipe.

Use o ambiente para comunicar alterações, para que o processo de reconciliação ocorra para todos, não individualmente.

Veja as comunicações da sua equipe. Quanto tempo e esforço são necessários para garantir consistência? Talvez faça pequenas alterações e reduza a necessidade?