Alguns contrapontos sobre as vantagens the micro serviços que vejo repetidas mas nao sao necessariamente "bem assim":
A manutenção se torna mais fácil por se trabalhar com partes menores de código e que não vão gerar problemas nos outros serviços do sistema.
Isso pode ser uma desvantagem, pois em micro serviços realmente desacoplados, não temos visibilidade dos impactos que uma mudança pode acarretar. E quando problemas acontecem, temos agora a complexidade adicional de debuga-los em um ambiente distribuido. Entao nao e necessariamente uma vantagem. A forma de se mitigar isso e ter uma suite de testes robusta, o que se aplica a monolitos ou microsserviços, o que não é exclusividade de uma arquitetura ou outra.
Cada parte do software pode ser desenvolvida com a tecnologia que melhor se encaixa nela, sem a necessidade de ter o projeto todo usando uma única linguagem, por exemplo.
Imagine que você é responsável pela equipe que suporta tal solucao. Mesmo com microsserviços, se o stack eh consistente (mesma linguagem/ferramentas/infra), então em teoria todo o time pode suportar toda a solucao, e mudanças no time sao mais faceis de se lidar. Agora, se apenas Bob conhece a tecnologia do serviço X, e Bob fica doente, ou se muda para Tonga, você necessariamente terá de procurar alguém para substituir Bob.
E claro, existem raríssimas exceções em que faz sentido otimizar um serviço para tecnologias especificas, mas (em minha parca experiência) não é um fator especialmente comum.
Fazer o deploy de um micro serviço é muito mais simples, facilitando a chegada de atualizações à produção.
Fazer deploy de um microsserviço não elimina a necessidade de coordenar com servicos upstream/downstream, que podem não tolerar a indisponibilidade do microsserviço em questão, o que no caso nao depende de o serviço ser micro ou monolito, mas de outras considerações que independem dessa escolha. Algo que facilita o deploy de um serviço, seja mono ou micro, eh que o ecosistema seja construido para tolerancia a falhas, onde a indisponibilidade de um componente, por exemplo, não afeta o funcionamento de outros.
A escalabilidade está presente, de forma que se torna possível expandir apenas os microsserviços desejados conforme a necessidade daquele momento.
Ha 20 anos atras, escalabilidade era realmente um bicho papão, segundo o qual se um erro na capacidade necessária para um sistema teríamos que comprar novos servidores, o que levava semanas (meses), e era um processo realmente burocratico. Nos vivemos a era de cloud, escalabilidade e também elasticidade.
É incomparavelmente mais simples escalar sistemas em nuvem, tanto vertical quanto horizontalmente.
Isso sem citar que escalabilidade não é inerente a micro servicos. Já vi exemplos de soluções que faziam apenas uma coisa, em um unico processo, mas funcionava com bloqueios que efetivamente impedia sua escalabilidade horizontal (que é preferida em um número considerável de casos)
O que quero dizer aqui é que a margem que se tem entre uma versão inicial de um monolito e o momento em que sua escalabilidade se torna um problema dificil de se resolver na nuvem é consideravelmente maior hoje em dia.
Em tempo, gostei da estrutura do artigo, espero que continue escrevendo, e recomendo escrever em inglês também, pois a audiência aqui é maior.
Olá dmondev!
Fico feliz que tenha gostado da estrutura do artigo e agradeço também por compartilhar suas opiniões e informações.
Como eu disse durante o texto, o que escrevi foi resultado do meu estudo então de fato não tenho todos conhecimentos sobre o assunto. Entendi seus contrapontos e acredito que realmente nenhuma arquitetura vai ser perfeita para 100% dos casos, sempre haverá desvantagens e situações onde as vantagens não são tão efetivas...
Mas enfim, novamente agradeço por participar da discussão e trazer novas informações :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Oi Vitor,
Alguns contrapontos sobre as vantagens the micro serviços que vejo repetidas mas nao sao necessariamente "bem assim":
Isso pode ser uma desvantagem, pois em micro serviços realmente desacoplados, não temos visibilidade dos impactos que uma mudança pode acarretar. E quando problemas acontecem, temos agora a complexidade adicional de debuga-los em um ambiente distribuido. Entao nao e necessariamente uma vantagem. A forma de se mitigar isso e ter uma suite de testes robusta, o que se aplica a monolitos ou microsserviços, o que não é exclusividade de uma arquitetura ou outra.
Imagine que você é responsável pela equipe que suporta tal solucao. Mesmo com microsserviços, se o stack eh consistente (mesma linguagem/ferramentas/infra), então em teoria todo o time pode suportar toda a solucao, e mudanças no time sao mais faceis de se lidar. Agora, se apenas Bob conhece a tecnologia do serviço X, e Bob fica doente, ou se muda para Tonga, você necessariamente terá de procurar alguém para substituir Bob.
E claro, existem raríssimas exceções em que faz sentido otimizar um serviço para tecnologias especificas, mas (em minha parca experiência) não é um fator especialmente comum.
Fazer deploy de um microsserviço não elimina a necessidade de coordenar com servicos upstream/downstream, que podem não tolerar a indisponibilidade do microsserviço em questão, o que no caso nao depende de o serviço ser micro ou monolito, mas de outras considerações que independem dessa escolha. Algo que facilita o deploy de um serviço, seja mono ou micro, eh que o ecosistema seja construido para tolerancia a falhas, onde a indisponibilidade de um componente, por exemplo, não afeta o funcionamento de outros.
Ha 20 anos atras, escalabilidade era realmente um bicho papão, segundo o qual se um erro na capacidade necessária para um sistema teríamos que comprar novos servidores, o que levava semanas (meses), e era um processo realmente burocratico. Nos vivemos a era de cloud, escalabilidade e também elasticidade.
É incomparavelmente mais simples escalar sistemas em nuvem, tanto vertical quanto horizontalmente.
Isso sem citar que escalabilidade não é inerente a micro servicos. Já vi exemplos de soluções que faziam apenas uma coisa, em um unico processo, mas funcionava com bloqueios que efetivamente impedia sua escalabilidade horizontal (que é preferida em um número considerável de casos)
O que quero dizer aqui é que a margem que se tem entre uma versão inicial de um monolito e o momento em que sua escalabilidade se torna um problema dificil de se resolver na nuvem é consideravelmente maior hoje em dia.
Em tempo, gostei da estrutura do artigo, espero que continue escrevendo, e recomendo escrever em inglês também, pois a audiência aqui é maior.
Cheers !!
Olá dmondev!
Fico feliz que tenha gostado da estrutura do artigo e agradeço também por compartilhar suas opiniões e informações.
Como eu disse durante o texto, o que escrevi foi resultado do meu estudo então de fato não tenho todos conhecimentos sobre o assunto. Entendi seus contrapontos e acredito que realmente nenhuma arquitetura vai ser perfeita para 100% dos casos, sempre haverá desvantagens e situações onde as vantagens não são tão efetivas...
Mas enfim, novamente agradeço por participar da discussão e trazer novas informações :)