Microserviços em Código Aberto: A Perspectiva da Equipe

No mundo do desenvolvimento de software, os Microserviços viraram moda. Eles são serviços pequenos e independentes que podem ser desenvolvidos e implantados sozinhos. Isso significa que podem crescer e se adaptar sem bagunçar o sistema todo. Muitos especialistas acham que cada equipe deve cuidar de um microserviço. Ou seja, um desenvolvedor trabalha com uma equipe e é responsável por um microserviço só. Essa abordagem é bem recomendada, principalmente em Projetos maiores que envolvem muitos Desenvolvedores.

Já no software de código aberto, onde qualquer um pode contribuir, a situação pode ser diferente. Os desenvolvedores costumam entrar em projetos e trabalhar em várias partes sem atribuições de equipe rígidas. Este artigo investiga se a ideia de "um microserviço por desenvolvedor" rola em projetos de código aberto.

#A Ideia por trás dos Microserviços

Os microserviços são estruturados para separar diferentes funções do software em partes menores. Cada parte, ou microserviço, tem uma tarefa específica. Isso facilita o gerenciamento e o desenvolvimento do software, porque as equipes não precisam se preocupar com como as mudanças em uma parte vão afetar as outras. Além disso, os microserviços podem ser atualizados e melhorados de forma independente.

Muitos especialistas dizem que os microserviços ajudam a gerenciar grandes equipes. Ao dividir o software em partes menores, a comunicação diminui. Isso quer dizer que equipes maiores podem trabalhar em partes diferentes ao mesmo tempo sem pisar nos pés uns dos outros.

Por causa disso, é sugerido que cada microserviço seja "propriedade" de uma única equipe. Se várias equipes trabalham no mesmo microserviço, isso pode gerar confusão e ineficiências. Para seguir essa ideia, espera-se que os desenvolvedores contribuam apenas com um microserviço de cada vez.

#O Estudo

Para ver se a ideia de "um microserviço por desenvolvedor" é real em projetos de código aberto, foi feito um estudo. Esse estudo focou em 38 projetos de código aberto que usavam microserviços. Os pesquisadores analisaram as Contribuições dos desenvolvedores e quantos microserviços cada um trabalhou.

O objetivo principal era descobrir com que frequência os desenvolvedores trabalhavam em mais de um microserviço e se isso alinhava com a sugestão de que cada desenvolvedor deveria se concentrar em um único microserviço.

#Perguntas da Pesquisa

O estudo buscou responder duas perguntas principais:

1. Quão bem a prática de "um microserviço por desenvolvedor" é seguida em projetos de código aberto?
2. Diferentes funções de desenvolvedores respeitam essa prática de forma diferente?

#Projetos Selecionados

Os pesquisadores escolheram seus projetos a partir de uma lista de 145 projetos validados baseados em microserviços. Eles garantiram que cada projeto tivesse pelo menos dois microserviços e que esses microserviços tivessem tido atividade recente. Assim, os projetos selecionados representavam trabalhos ativos e em andamento.

No total, 38 projetos foram analisados, que incluíam 379 microserviços distintos.

#Coleta de Dados

Para coletar informações sobre as contribuições dos desenvolvedores, os pesquisadores examinaram o histórico de commits de cada projeto. Cada registro de commit inclui a data e hora, o nome do autor e detalhes sobre quais arquivos foram alterados. Ao relacionar essas mudanças com os microserviços a que pertenciam, os pesquisadores puderam rastrear qual desenvolvedor trabalhou em qual microserviço.

#Análise de Dados

Com os dados coletados, os pesquisadores analisaram quantos microserviços cada desenvolvedor contribuiu. Eles observaram dois aspectos:

1. Quantos microserviços tinham desenvolvedores compartilhados trabalhando neles?
2. Quantos desenvolvedores trabalharam em mais de um microserviço?

Uma parte essencial da análise incluiu identificar se um desenvolvedor que trabalhou em um microserviço pulou para outro sem voltar. Essa distinção ajudou a avaliar se a prática de "um microserviço por desenvolvedor" estava realmente sendo respeitada ou não.

#Descobertas

#Respeito pela Prática

O estudo descobriu que apenas dois dos 38 projetos seguiram consistentemente a ideia de "um microserviço por desenvolvedor". A maioria dos projetos tinha desenvolvedores que trabalhavam em vários microserviços ao mesmo tempo. Isso mostra que muitos desenvolvedores não estavam limitados a um único microserviço de cada vez.

#Funções dos Desenvolvedores e Contribuições

O estudo também investigou como diferentes funções dentro das equipes de desenvolvimento respeitavam a prática. Esperava-se que funções específicas, como DevOps, estivessem envolvidas em vários microserviços, enquanto desenvolvedores principais se concentrariam principalmente em serviços únicos.

No entanto, foi descoberto que muitos contribuidores, independentemente de suas funções, frequentemente trabalhavam em vários microserviços. Alguns projetos mostraram um padrão onde um único desenvolvedor era responsável por vários microserviços, enquanto em outros, múltiplos desenvolvedores trabalhavam em todos os microserviços disponíveis. Isso variou bastante entre os diferentes projetos, mas destacou uma tendência clara de que a abordagem de "um microserviço por desenvolvedor" não era a norma.

#Tipos de Projetos

Os projetos foram categorizados com base em seus padrões de contribuição:

1. Projetos One-Dev-ALL-MS: Esses tinham um desenvolvedor cobrindo todos os microserviços, enquanto os outros contribuíam em apenas alguns. Isso aconteceu em 16 dos 38 projetos.

2. Projetos Multi-Dev-ALL-MS: Nesses projetos, múltiplos desenvolvedores contribuíram para todos os microserviços. Isso foi visto em 10 dos 38 projetos.

3. Projetos Multi-Dev-SOME-MS: Nenhum dos contribuidores cobriu todos os serviços, nem seguiram a regra de "um microserviço por desenvolvedor". Esta categoria incluiu 12 dos 38 projetos.

4. Projetos One-MS-per-developer: Projetos onde cada desenvolvedor só trabalhava em um único microserviço eram raros.

#Entendendo o Comportamento dos Desenvolvedores

Diversas técnicas foram usadas para avaliar o comportamento e as contribuições dos desenvolvedores nesses projetos. Os pesquisadores queriam entender quais funções contribuíam mais ou menos para os microserviços. Eles usaram um método chamado Análise Fatorial Exploratória para agrupar contribuidores com base em suas atividades de codificação.

#Funções dos Desenvolvedores

A análise revelou que diferentes tipos de contribuintes mostraram comportamentos variados. Por exemplo, contribuidores individuais que gerenciavam todos os microserviços contribuíram significativamente mais do que aqueles que compartilhavam a carga de trabalho. Esses projetos com um desenvolvedor tinham um foco mais forte em documentação e responsabilidades de frontend.

Por outro lado, projetos com múltiplos contribuintes compartilhavam a carga de trabalho de uma maneira que reduzia as contribuições gerais de cada desenvolvedor. Em geral, projetos com muitos desenvolvedores costumavam ter muitas contribuições sobrepostas entre microserviços, indicando que as funções não eram bem definidas.

#Razões para as Descobertas

As descobertas podem ser atribuídas a vários fatores:

• Dinâmica de Código Aberto: Desenvolvedores em projetos de código aberto frequentemente contribuem voluntariamente, sem papéis ou obrigações fixas. Eles podem focar em questões ou recursos específicos, em vez de se prenderem a um único microserviço. Essa flexibilidade permite um alcance mais amplo nas necessidades do projeto.

• Falta de Estrutura de Equipe Clara: Em muitos projetos de código aberto, não há estruturas de equipe rígidas como vistas em ambientes corporativos. Isso pode levar os desenvolvedores a assumirem várias tarefas com base em seus interesses ou habilidades, em vez de um microserviço definido.

• Escalabilidade vs. Organização: Muitos projetos adotam uma arquitetura de microserviços principalmente por motivos de escalabilidade. Manter limites rígidos como sugerido pode não se encaixar bem no ambiente de software de código aberto, que é dirigido por voluntários.

#Implicações para a Prática

Os pesquisadores concluíram que a estratégia de "um microserviço por desenvolvedor" não é comumente observada em projetos de código aberto. A flexibilidade que vem com as contribuições voluntárias permite que os desenvolvedores trabalhem em muitos serviços, mas pode reduzir a eficiência que o modelo de microserviço promete.

Também é observado que esse padrão pode ser visto como uma desvantagem para uma escalabilidade eficaz, sugerindo que alguns projetos poderiam se beneficiar de uma abordagem mais organizada, especialmente à medida que crescem.

#Trabalho Futuro

O estudo fornece uma base para investigações futuras sobre colaborações de desenvolvedores em projetos de código aberto. Pesquisas futuras poderiam focar em entender como a formação espontânea de equipes ocorre com base nas necessidades do projeto. Analisar a comunicação e as interações em conjunto com as contribuições de código poderia revelar mais sobre como os desenvolvedores se agrupam naturalmente em torno das tarefas.

Outra área de pesquisa é explorar as implicações da dinâmica de funções e como elas mudam no contexto das necessidades evolutivas do projeto. Isso poderia levar a uma melhor compreensão de como organizar efetivamente os esforços de desenvolvimento de código aberto.

#Conclusão

Em resumo, a suposição de que cada desenvolvedor deve trabalhar em apenas um microserviço em projetos de código aberto frequentemente não é praticada. Muitos desenvolvedores contribuem para múltiplos microserviços, refletindo a natureza flexível e orientada por voluntários do desenvolvimento de software de código aberto. Este estudo destaca a necessidade de mais exploração sobre como essas dinâmicas se desenrolam e como podem ser gerenciadas para melhorar os resultados do projeto. As descobertas enfatizam as diferenças no comportamento dos contribuidores e as implicações que isso tem para a arquitetura de microserviços no contexto do software de código aberto.