Microsserviços

Fui abordado por um Flatiron Coach que trabalha em Relações com Funcionários sobre uma empresa que estava interessada no meu currículo e queria uma entrevista. Gostei muito da entrevista e pude fazer perguntas que deram uma ótima visão.

Uma pergunta que fiz foi sobre o futuro da empresa e a abordagem com sua tecnologia. O entrevistador respondeu falando sobre um possível caminho, que era adotar microsserviços. Eu não sabia muito sobre isso, mas definitivamente ouvi e vi essa palavra da moda por aí. O entrevistador gentilmente falou mais sobre isso e por que pode ser benéfico para o crescimento futuro. Então, decidi pesquisar mais sobre microsserviços e os prós e contras de usá-los.

Micro. Serviços. O que?

A arquitetura de microsserviços nos permite criar aplicativos altamente escaláveis ​​e flexíveis, dividindo o aplicativo em serviços distintos que implementam funções de negócios específicas. Esses serviços, muitas vezes chamados de “frouxamente acoplados”, podem ser criados, implantados e dimensionados de forma independente.

Cada serviço individual se comunica com outros serviços, por meio de APIs, o que permite que sejam escritos em diferentes idiomas ou em diferentes tecnologias (embora muitos profissionais desencorajem isso). Isso não é como uma arquitetura monolítica em que os serviços são intrinsecamente interligados e são dimensionados apenas juntos.

Por que Microsserviços?

Em minha pesquisa, vi que essa arquitetura se tornou muito popular devido às suas características modulares que permitem flexibilidade, escalabilidade e eficiência no desenvolvimento.

A arquitetura de microsserviços ganhou popularidade porque suas características modulares levam à flexibilidade, escalabilidade e esforço de desenvolvimento reduzido. As plataformas de nuvem também permitem que microsserviços e funções sejam dimensionados de inatividade para alto volume e vice-versa, enquanto os clientes pagam apenas pela capacidade de computação que usam.

Convoque os Benefícios

• Liberdade para desenvolver e implantar serviços de forma independente.
• Pode ser desenvolvido por uma equipe bastante pequena.
• O código para diferentes serviços pode ser escrito em diferentes idiomas.
• Fácil integração e implantação automática (usando ferramentas de integração contínua de código aberto).
• Fácil de entender e modificar para desenvolvedores, portanto, pode ajudar um novo membro da equipe a se tornar produtivo rapidamente.
• Os desenvolvedores podem fazer uso das tecnologias mais recentes.
• O código é organizado em torno dos recursos de negócios.
• Quando a alteração é necessária em uma determinada parte do aplicativo, apenas o serviço relacionado pode ser modificado e reimplantado.
• Melhor isolamento de falhas: uma falha de microsserviço não impede que os outros serviços funcionem.
• Fácil de dimensionar e integrar com serviços de terceiros.
• Nenhum compromisso de longo prazo com pilhas de tecnologia fixas.

• Devido à implantação distribuída, os testes podem se tornar complicados e tediosos.
• O aumento do número de serviços pode resultar em barreiras de informação.
• Sendo um sistema distribuído, pode resultar em duplicação de esforços.
• Quando o número de serviços aumenta, a integração e o gerenciamento de produtos inteiros podem se tornar complicados.
• Além de várias complexidades da arquitetura monolítica, os desenvolvedores precisam lidar com a complexidade adicional de um sistema distribuído.
• Requer muito mais comunicação e cooperação entre diferentes equipes (isso nem sempre é tão fácil).