Microserviços estrutura de projeto

[João Antônio Ferreira Siqueira]

Boa noite pessoal,

sabemos que a arquitetura de microserviço consiste em variou pequenos sistemas operando.

Gostaria de obter a opinião de vcs com relação a criação do projeto, por exemplo:

Abordagem 1:

Crio um projeto maven (Parent) e dentro dele modulo que modem ser os microserviços

Parent

|

|__ Module1 (Serviço 1)

|

|__ Module2 (Serviço 1)

|

|__ Module3 (Serviço 1)

Vantagem:

• Melhor organização, sendo que todos os serviços serão desenvolvidos em java (spring boot)
• Posso apenas criar um repositório no GIT

Desvantagens:

• Maior coplamento entre os projetos
• Não faço a menor ideia de como criar os jobs no jenkins para fazer a iteração contínua 

Abordagem 2:

Vou criando projeto completamente separados

Vantagens:

• Mais fácil para criar os jobs no jenkis sendo que os serviços estão separados

Desvantagens:

• Vou ter que criar vários repositórios no GIT, e se eu precisar criar mais de 20 serviços, terei 20 GIT repositórios?
• Acredito que separados ficam mais difíceis de organizar.

Enfim galera, tenho algumas dúvidas nessa estrutura inicial.

Alguém poderia, me ajudar?

Desde já agradeço a todos. 

[José Augusto]

Olá Antônio,

Minha sugestão vai mais pela primeira opção. Não necessariamente, por estar dentro do mesmo projeto, vai ser mais acoplado. Você pode configurar o Jenkins pra buildar kd serviço separado, mesmo que eles estejam dentro de um mesmo projeto.

Att,

Augusto Baltazar

--
Você recebeu essa mensagem porque está inscrito no grupo "java.ce" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javace+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para jav...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/javace.
Para mais opções, acesse https://groups.google.com/d/optout.

[João Antônio]

Obrigado pela resposta Augusto,

tbm prefiro a primeira opção pela organização. Mas tbm tenho algumas duvidas com relação ao jenkins, por exemplo, Como posso configurar o jenkins para que ele execute apenas modulos específicos?

Sei que posso criar jobs para cada modulo, mas como o projeto estar inteiro no GIT como o jenkins (target build agendado) saberá que o aquele determinado módulo deve ser executado?

Minha dúvida com relação ao jenkins e essa arquitetura é basicamente essa?

[Yuri Yarlei]

Assim, os microserviços tem a vantagem de executarem separadamente como um grande serviço unico, para que eles sejam microserviços de verdade eles precisam ser independentes, além de que cada um deve ter sua própria base de dados e devem se comunicar através de mensagens.

Fazer 20 serviços que dependam diretamente um do outro ou que estejam pendurados em uma única base de dados, não vai atender a arquitetura de micoserviços.

A vantagem dos microserviços é que eles podem ser em linguagens diferentes e usarem bancos diferentes.

Eu sugiro a opção 2, pode dar trabalho, mas é o que mais caracteriza a arquitetura de microserviços, não pense apenas no jenkis, pra isso serve uns cursos no udemy e tutoriais na net, pense no todo, é melhor fazer nessa arquitetura ou criar um sistema monolitico mesmo? Eu preciso de tudo isso? eu tenho como dar suporte? como fica a manutenção? É melhor usam uma linguagem só ou tem alguns serviços que ficariam melhor em outras linguagens? etc???

Att,
Yuri Adeodato.
Linkedin - https://goo.gl/TKJPg9

Em ter, 9 de out de 2018 às 23:22, José Augusto <tytor...@gmail.com> escreveu:

[João Antônio]

Olá Yuri,

seguindo essa abordagem como eu posso organizar projetos de deferentes linguagens em um único repositório GIT?

[Yuri Yarlei]

Como eles seriam independentes eu faria um repositório para cada, mas eu pesquisaria um pouco mais para procurar uma solução melhor.

Qualquer coisa vc poderia criar um repositório geral e cada sistema ficaria dentro de um subdiretório, ai os arquivos de configuração de ide, projeto, etc, ficariam apenas no diretório especifico de projeto e o diretório root seria apenas como um "aglomerador de sistemas".

Att,
Yuri Adeodato.
Linkedin - https://goo.gl/TKJPg9

[João Antônio]

O tbm pensei nisso e andei pesquisando um pouco. Encontrei a abordagem de GIT Submodules, onde eu tenho repositório dentro dele tenho módulos do com seus próprios .git.

Talvez isso possa ser uma solução.

[Rafael Ponte]

João,

Qual o tamanho da sua equipe?

Um abraço,

Rafael Ponte

TriadWorks | Formação Java
http://cursos.triadworks.com.br

[bruno brasil]

João 

Acho que antes de sair se aventurando em microservices você deveria se especializar mais sobre essa arquitetura, não é apenas em separar em vários serviços e um abraço.

Basicamente os pre-requisitos e desafios de implementar microserviços são:

- Service Discovery & Registration

- Configurações centralizadas

- Edge Services: Micro Proxies e API Gateways

- Roteamento e balanceamento

- Tolerância à falhas (Circuit Breakers)

- Security and Single Sign-On

- Complexidade Operacional

- Monitoração

- Distributed Tracing

- Cultura DevOps

Se vai usar o Spring Boot é um ótimo caminho, veja também sobre NetflixOSS afinal os cara são fera nisso.

Esse link explica melhor o que quero dizer: https://github.com/marcosbarbero/devcommerce2016-microservices-power-patterns-pains

Esse cara é fera tem palestra dele no Youtube do que fez na Netshoes com mais de 70 microserviços se não me engano.

Atenciosamente,
Bruno Brasil

https://brunobrasilweb.com

@brunobrasilweb

[João Antônio]

Olá Rafael, 

faço parte de uma equipe de 4 pessoas no backend.

Fala Bruno,

vc tem razão, tem muita coisa coisa que devo lê e estudar. Estou usando Spring Boot e a maioria dos itens listados já testei, mas com situações simples e exemplos básicos, nada em aplicações reais.

Comprei o livro Mastering Microservices with Java do Sourabh, realmente é uma desafio novo para mim.

[Rafael Ponte]

João,

Sua equipe é MUITO pequena para se pensar em Microservices. O principal motivador para adotar essa arquitetura foi (e ainda é) justamente escalar equipes! Estou falando de equipes muito grandes com dezenas ou centenas de devs e outros profissionais. A necessidade de escalabilidade técnica vem em segundo lugar.

Adotar microservices é estar ciente que você irá trabalhar com arquitetura de sistemas distribuídos. Certamente um dos modelos mais difíceis e complexos de se trabalhar na nossa área. Se você e sua equipe não tem experiência com integração continua (CI), entrega continua (CD), testes, deploy e processos automatizados, monitoramento e telemetria, provisionamento de ambientes e serviços simplificado, feedback rápido e continuo etc então adotar microservices será um tiro muito feio no pé.

Enfim, no geral vale mais a pena desenhar e modularizar seu monolítico apropriadamente e se, e somente se, houver necessidade de migrar para microservices você pode repensar a solução e fazer a migração incrementalmente com estratégias conhecidas no mercado.

Um abraço,

[João Antônio]

Rafael,

concordo em partes com você, com a questão de experiência você tem razão, minha equipe precisa realmente de um certo nível de maturidade para trabalhar com Microservices, mas a questão de equipes muito grande não é necessariamente verdade.

A distribuição da carga de trabalho e da execução também são pontos importantes. Eu posso ter uma equipe pequena mas que trabalha em projeto muito grande, da mesma forma podemos receber um novo colaborador e ele pode ser facilmente integrado ao projeto.

[bruno brasil]

João 

Boa sorte e sucesso se for fazer com microservices e não esquece de compartilhar sua experiência.

Como Rafael já disse pela a equipe e 20 serviços um melhor caminho seria o velho monólito, mas se o peso maior é o aprendizado ta valendo. 

Atenciosamente,
Bruno Brasil

https://brunobrasilweb.com

@brunobrasilweb

[João Antônio]

Obrigado Bruno,

acho que vale para agregar conhecimento, com certeza compartilharei a experiência com vcs.

Abraço.

[Rafael Ponte]

João,

Se você ler sobre as realidade das empresas (big players) que adotaram microservices vai perceber que essa foi a principal motivação deles. Infelizmente eles são obrigados adotar microservices porque não existe solução melhor para resolver esse problema (escalar times)!

Sobre distribuição de carga e trabalho você consegue isso com um monólito e práticas de modularização. Como você acha que essas empresas mantiveram software antes do hype do microservices?

Cuidado! Adotar microservices, que é um modelo arquitetural COMPLEXO e CARO, com o propósito de aprendizado é arriscado, ingênuo e as chances são que o peso dessa complexidade leve o projeto ao completo fracasso! Recomendo você ler sobre os problemas dessa arquitetura antes de tomar uma decisão do tipo!

Como o Martin Fowler diz:
“you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile” (https://martinfowler.com/bliki/MonolithFirst.html)

Enfim, invista numa boa modularização coberta por boas práticas de engenharia ágil como por exemplo testes automatizados e CI e você certamente estará em boas mãos.

Um abraço,

[João Antônio]

Muito obrigado Rafael,

realmente é muito arriscado se aventurar em uma arquitetura que não tem domínio, ainda mais quando não se tem nada palpável.

[Yuri Yarlei]

Eu acho que o problema maior de adotar a solução em microserviços é a parte do custo, ele deve ser bem planejado e estudado, como o Rafael disse, é um modelo arquitetural COMPLEXO e CARO.

Em relação a obter experiência eu também não arriscaria, a menos que o orçamento cobrisse o risco, o risco que eu digo é de não da certo e ter que volta a uma solução mais simples.

A parte de tamanho da equipe é bem relativo, 20 microserviços pequenos pode até não precisa de uma equipe grande, mas ainda assim precisa de uma infraestrutura diferenciada para manter os serviços ativos e isso custa caro.

Att,
Yuri Adeodato.
Linkedin - https://goo.gl/TKJPg9

[Johnatan Dantas]

Na minha opinião, se o projeto for pequeno ao meu ver a opção 1 se encaixaria perfeitamente, ou até um sistema monólito mesmo teria suas vantagens e desvantagens, mais se caso o projeto cresça seria ideal montar uma arquitetura de microservico junto a ele trás as complexidades, mais tbm trás suas vantagens.