Após extrair um microsserviço do sistema monolítico, segregando as bases de dados, com classificação apropriada de APIs internas e externas e instrumentação suficiente para observabilidade, é importante estabelecer indicadores que suportem a evolução arquitetural. Um das análises fundamentais acontece a partir da centralidade.
Centralidade
No âmbito da teoria dos grafos e da análise de redes, centralidade é uma medida de importância de um vértice em um grafo. Existem diferentes tipos de medidas de centralidade de um vértice num grafo que determinam a importância relativa, que permitem, por exemplo, estimar o quanto uma pessoa é influente dentro de uma rede social, o quão é importante uma sala dentro de um edifício e como é bem utilizada uma estrada dentro de uma rede urbana. Vários conceitos de centralidade foram primeiramente desenvolvidos na análise de redes sociais, e muitos dos termos usados para medir a centralidade refletem a sua origem sociológica.
Existem quatro medidas de centralidade que são amplamente utilizados na análise de rede: centralidade de grau, centralidade de intermediação, centralidade de proximidade e centralidade de vetor próprio.
Em sistemas distribuídos, indicadores de centralidade ajudam a determinar a importância relativa de um componente para a operação. Quanto maior a centralidade, maior a importância.
Veja também
Ferramentas, como o Jaeger, são excelentes fontes de informação para este tipo de análise.
Ter, em um ambiente produtivo, componentes com alta centralidade de grau indica acoplamento. Componentes com grau de entrada elevados (indegree) – ou seja, muito “consumidos” por outros componentes – convertem-se rapidamente em gargalos e, geralmente, são os pontos frágeis da estrutura. Componentes auto grau de saída elevados (outdegree) são, frequentemente, ofensores.
Na prática, analisamos a centralidade em duas perspectivas:
- estática – ignorando o número de interações, considerando apenas a existência de conexão entre os componentes
- dinâmica – ponderando o peso das conexões com base no número de interações, acumulado de response time, ou outra métrica mensurável.
Geralmente, a perspectiva dinâmica, analisando complexos de microsserviços e suas conexões como grafos direcionados e ponderados, produz insights mais valiosos.
***
Na medida em que um microsserviço amadurece, em análise dinâmica, deve haver redução de centralidade tanto do “bloco monólito” – que está sendo fragmentado – quanto dos recursos que este utiliza – principalmente o banco de dados.
***
Assumindo que 20% das features de um sistema correspondem a 80% do uso, uma estratégia de fragmentação de um monólito será tão mais impactante quanto for o ritmo de redução da centralidade “dinâmica” do código sendo convertido para microsserviços.
***
O surgimento de microsserviços com excessiva centralidade “estática” – ou seja, analisando a estrutura como um grafo não ponderado – é, geralmente, indicativo de falhas de design, como, por exemplo, a criação de “Entity Services Antipattern”
***
Componentes com maior centralidade, estática ou dinâmica, são aqueles que tem maior custo de manutenção, demandando mais cuidado para o deploy, maior cobertura por testes automatizados, sobretudo testes de integração.
