Close

Microsserviços e arquitetura de microsserviços

Aprenda os prós e contras dos microsserviços e como eles diferem dos monólitos.

O que são microsserviços?

O termo “Microsserviços” é um termo moderno usado para descrever um padrão tradicional de “separação de problemas” dentro de um projeto distribuído e em rede. Os microsserviços são uma ideia que segue uma antiga filosofia Unix fundamental “de ferramentas pequenas e afiadas”. Ambos os conceitos se baseiam em outro padrão básico de ciência da computação de “composição”, o que significa que sistemas complexos são a soma de entidades combináveis de nível inferior.

Artigos de microsserviços

[CONTINUAÇÃO]

A composição ocorre por meio de todas as camadas de um projeto de software. No nível mais baixo, o “nível de unidade”, funções de código independentes individuais interagem entre si através de uma interface compartilhada para criar coleções ou “bibliotecas” de código. No nível do shell do sistema operacional, os comandos shell podem ser combinados para criar um pipeline de funcionalidade de nível superior. Os microsserviços são um nível de composição que acontece entre os Serviços Web. Um Microsserviço é um serviço web que é responsável por uma peça de lógica de domínio. Os microsserviços interagem uns com os outros através de protocolos de rede simples como REST para concluir ações, mas eles não têm conhecimento de como outros serviços funcionam internamente. Essa interação harmoniosa entre microsserviços é uma arquitetura de microsserviços.

A arquitetura de microsserviços ou (MSA) tem recebido muita atenção, pois as equipes de software estão procurando novas maneiras de melhorar seus fluxos de trabalho de versões. Amazon, Netflix e Ebay estão entre as empresas que estão adotando abertamente essa maneira de criar software e têm contribuído para a comunidade publicando sua própria experiência e desenvolvendo ferramentas que podem ajudar outras pessoas a adotar.

O princípio norteador dos microsserviços é construir um aplicativo dividindo os componentes de negócios em serviços pequenos que podem ser implementados e operados de forma independente uns dos outros.

Um diagrama mostrando como um cubo grande pode ser dividido em muitos cubos menores.

Os desenvolvedores podem então se organizar em equipes menores especializadas em diferentes serviços, com diferentes pilhas e implantações dissociadas. Essa separação de problemas e função independente dissociada permite práticas ágeis de desenvolvimento de software simplificadas, como entrega e integração contínuas.

Arquitetura orientada ao serviço (SOA) vs. Microsserviços

A Arquitetura orientada ao serviço e Microsserviços são dois tipos de arquiteturas de serviço web de ordem maior. Os microsserviços podem ser pensados como uma versão lite da SOA. A distinção entre os dois tipos de arquiteturas é a classificação burocrática dos tipos de serviço. A SOA tem 4 tipos de serviços básicos: serviços de Negócios, Empresarial, Aplicativo e Infraestrutura. Estes tipos definem as respectivas responsabilidades específicas do domínio dos serviços subjacentes. Comparativamente, os microsserviços têm apenas dois tipos de serviço: Funcional e Infraestrutura.

Ambas as arquiteturas compartilham o mesmo conjunto de padrões em diferentes camadas de uma empresa. A existência de MSA se resume ao sucesso do padrão da SOA. Portanto, o padrão MSA é um subconjunto da SOA. Aqui o foco principal é a autonomia de tempo de execução de cada serviço.

Aplicação monolítica vs. Microsserviços

Um diagrama mostrando a diferença entre monólitos e microsserviços na entrega contínua.

Os microsserviços dissociam os principais problemas específicos do domínio de negócios em bases de código independentes separadas. Uma arquitetura de aplicação monolítica pode ser pensada como o inverso dos microsserviços. Um monólito é uma base de código que une todos os problemas de negócios juntos. Os monólitos podem ser convenientes no início da vida de projetos para facilitar a sobrecarga cognitiva de gerenciamento de código e implementação. Assim tudo no monólito pode ser lançado de uma só vez.

A princípio, muitos projetos começam como um monólito e, em seguida, evoluem para uma arquitetura de microsserviços. Conforme novos recursos são adicionados a um monólito, pode começar a ficar complicado ter muitos desenvolvedores trabalhando em uma base de código singular. Os conflitos de código passam a ser mais frequentes e o risco de atualizações de um recurso introduzindo bugs em um recurso não relacionado aumenta. Quando esses padrões indesejáveis surgem, pode ser hora de uma discussão sobre uma migração para Microsserviços.

Como funciona a arquitetura de microsserviços

Considere um hipotético projeto de software de comércio eletrônico como um exemplo. Existem alguns recursos de negócios específicos de domínio claramente definidos. Sites de comércio eletrônico têm um sistema de autenticação para login e logout de usuários. Um carrinho de compras para armazenar uma lista de produtos nos quais o usuário está interessado. Um sistema de faturamento permite que os usuários paguem por suas compras.

Em uma Arquitetura de Microsserviço, esses domínios de negócios do exemplo seriam serviços independentes. Tome o sistema de faturamento como um exemplo específico. Dependendo da contagem de funcionários da empresa, pode haver uma “equipe de faturamento” dedicada que é proprietária do desenvolvimento e da garantia de qualidade deste microsserviço de faturamento. O microsserviço de faturamento teria seu próprio cronograma de lançamento e esquemas táticos de implementação. O serviço de faturamento disponibilizaria uma API documentada e versionada para que outros serviços pudessem se comunicar e utilizar sua funcionalidade.

Prós e contras dos microsserviços

+ Escalabilidade horizontal

Os microsserviços são distribuídos por natureza e podem ser implementados em clusters. Assim é possível ter escalabilidade horizontal dinâmica por meio dos limites de serviço. Se um Microsserviço estiver maximizando sua capacidade de carga, novas instâncias desse serviço vão poder ser implementadas logo no cluster que o acompanha para ajudar a aliviar a pressão.

+ Execução de equipe independente

As equipes de propriedade de microsserviços podem operar independentemente de outras equipes de recursos na organização. Assim novas funcionalidades podem ter execução e entrega mais rápidas.

+ Foco mais profundo na qualidade

A separação dos problemas comerciais em microsserviços independentes garante que a equipe de serviço que é proprietária desse serviço está concentrada na entrega completa da qualidade.

- Custos de infraestrutura exponenciais

Cada novo microsserviço que uma organização adiciona à sua implementação de produção vem com seu próprio custo de pacote de testes, esquemas táticos de implementação, infraestrutura de hospedagem, ferramentas de monitoramento e muito mais.

- Sobrecarga organizacional acrescentada

Um nível adicional de comunicação e colaboração é necessário para coordenar atualizações e interfaces entre equipes de arquitetura de microsserviços.

- Complexidade do ambiente de desenvolvimento

Quando um projeto é dividido em vários microsserviços, ele adiciona o desafio de reproduzir a arquitetura distribuída durante a configuração de desenvolvimento local.

Futuro dos microsserviços

A conteinerização e a implementação de contêineres, é um novo padrão de infraestrutura distribuída. Ferramentas como o Docker e o Kubernetes são usadas para empacotar um serviço em um “Contêiner” completo que pode ser rapidamente implementado e descartado. Essas novas ferramentas de infraestrutura são complementares à arquitetura de Microsserviços. Os microsserviços podem ser conteinerizados e facilmente implementados e gerenciados usando um sistema de gerenciamento de contêineres.

A adoção de microsserviços deve ser vista como uma jornada em vez de um objetivo imediato para uma equipe. Comece aos poucos para entender os requisitos técnicos de um sistema distribuído, como falhar normalmente e escalar componentes individuais. Então você pode extrair mais e mais serviços à medida que ganha experiência e conhecimento.

A arquitetura de microsserviços ainda é bastante jovem, mas é uma maneira promissora de desenvolver aplicativos e com certeza vale o exame, mas tenha em mente que pode não ser (ainda) uma boa opção para sua equipe.

Claire Maynard
Claire Maynard

Claire é uma veterana de marketing da Atlassian que trabalhou no crescimento, desempenho e marketing de produtos durante todo o seu mandato. No momento, ela impulsiona a estratégia de marca, conteúdo e go-to-marketing para o Confluence Cloud. Fora do trabalho, você pode encontrar Claire surfando, correndo ou experimentando novos restaurantes em São Francisco ou novas cidades em todo o mundo.