Acesse nossa Plataforma

O assunto sobre microsserviços vem ganhando rapidamente um grande espaço em mídias sociais, blogs, discussões, conferências e meio corporativo. Nesta série de posts, vamos entender como essa arquitetura funciona, seu design, construção, deploy e também construir uma pequena aplicação de e-commerce para exemplificar e demonstrar o funcionamento básico de uma arquitetura baseada em microsserviços.

Nossa série sobre microsserviços está divida em 4 partes:

Parte 1 - Conceitos
Parte 2 - Design Patterns e melhores práticas
Parte 3 - Projeto ecommerce
Parte 4 - Deploy
Parte 5 - Monitoramento

Hoje vamos tratar sobre os conceitos em microsserviços. Mas antes de entrarmos no assunto de microsserviços, temos que entender primeiro os motivos pelos quais elevaram seu crescimento bem como os fatores que motivaram a comunidade a criação deste estilo de arquitetura.

Sistemas Monolíticos

Bom, não precisamos nem voltar muito no passado, mas se olharmos para algumas soluções existentes hoje no mercado, conseguimos notar grandes aplicações que são chamadas de "monolíticas":

"Monolithic, in information technology, means either very large (and possibly imposing) or composed all in one piece, depending on the particular context; the term is used in different ways to describe integrated circuits, organizations, applications and storage systems, among other things."

Basicamente são aplicações onde todos os seus componentes e funcionalidades estão combinados dentro de uma única aplicação e arquitetura.

Microsserviços - Arquitetura Monolítica


Aplicações monolíticas começaram pequenas e com o passar do tempo, naturalmente foram crescendo e recebendo novas features, alterações para atendimento às legislações, novos módulos, sem contar o time de devs aumentando e ficando cada vez mais difícil de manter, dar manutenção e evoluir essa aplicação bem como escalar para que atenda satisfatoriamente a todos os usuários.

Isso é natural, mas em determinado momento, dependendo de como a aplicação monolítica foi sendo evoluída, podemos nos deparar com algumas dificuldades como por exemplo:

  • Escalar verticalmente para atender vários usuários ao mesmo tempo de forma elástica;
  • Aplicação é muito grande e complexa para o correto entendimento;
  • Adição de mudanças rápidas e corretas são mais difíceis;
  • Disponibilidade, em casos de falhas, toda a aplicação poderá ficar indisponível;
  • Velocidade de startup time;
  • Versionamento e atualização da solução precisa ser realizada como um todo;
  • Adoção e experimentação de novas tecnologias.

Claro que existem também pontos positivos, principalmente em aplicações pequenas, legadas e que possuem pouca demanda:

  • Simples de desenvolver;
  • Fácil de testar;
  • Deploy da aplicação descomplicado;
  • Monitoramento simplificado.

Não podemos esquecer também que, várias empresas de sucesso como Netflix, Spotfy, Twitter, Amazon ou Linkedin iniciaram seus negócios com soluções baseadas em monolitos, essa abordagem é chamada de "Monolith first", onde a idéia principal é que, segundo Martin Fowler, você deve começar um sistema de forma monolítica para que, a medida em que a aplicação for crescendo, poderá ser dividida em micro serviços, desta forma, temos uma melhor percepção da necessidade de decomposição da aplicação.

Arquitetura de Microsserviços

A arquitetura de microsserviços entra como uma forma de resolver esses grandes problemas, consiste basicamente na separação de uma estrutura monolítica em micro partes ou microsserviços que funcionam de forma independente se comunicando entre si.

Mas antes mesmo da entrada de microsserviços, aplicações monolíticas foram sendo "quebradas" em partes para uma arquitetura distribuída, essas que eram importantes para o negócio e se tinha a necessidade que funcionassem de uma maneira sustentável e escalável a medida do necessário. Essa abordagem começou na época da entrada do SOA (Service Oriented Architecture), onde podemos dizer que essa fragmentação era feita em mini serviços.

Um dos grandes percursores também foi o cloud computing, em que foi possível aplicar toda essa estrutura de uma forma mais simplificada, rápida e sem a necessidade de custo inicial com infra on premise. Assim, empresas foram experimentando e tendo a percepção dos benefícios que esse conjunto entregava, percebemos nessa mesma época também um grande crescimento de serviços sob demanda como Netflix, Spotfy, AWS.

A medida em que novas demandas computacionais foram surgindo, principalmente a necessidade de arquiteturas que fossem elásticas, e que permitissem aos usuários gerenciar de forma principalmente econômica e sob-demanda seus recursos existentes, microsserviços se mostrava como algo muito promissor, combinado com a adoção de cloud e de um rico ferramental, começou a ficar mais fácil distribuir aplicações em pequenas estruturas e executá-las em paralelo.

Martin Fowler, define microsserviços sendo, "The microservice architectural pattern is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API" - Martin Fowler.

Nessa figura, podemos notar que o sistema monolíto foi fragmentado em partes, sendo que cada microsserviço possui sua camada de negócio independente. Para o usuário final isso é imperceptível, sendo que a arquitetura trabalha como um ecossistema entregando ao negócio uma solução única.

Arquitetura de Microsserviços - API Gateway


Muitos profissionais principalmente os que estão iniciando na área, se deparam com algumas dúvidas, como por exemplo:

Devo utilizar microsserviços?

Depende muito do problema que você quer resolver, também se sua empresa está preparada para implementar essa arquitetura que embora seja ágil, depende de uma equipe com um bom conhecimento teórico e prático. Além de vários benefícios que essa arquitetura entrega, também existem alguns trade-offs, estes que também devem ser avaliados cuidadosamente. O fato é que não existe certo ou errado, muito menos uma receita de bolo para adoção de microsserviços.

Microsserviços seria um SOA melhorado?

Não, apesar de ambas serem uma arquitetura orientada a serviços, existem muitas diferenças.

SOA possui um foco em ESBs que são usados para integrar aplicações monolíticas, onde estas aplicações são expostas através de Web Services que geralmente utilizam XML sob o protocolo http para comunicação. Já Microsserviços possui um estilo totalmente diferente, onde poderão ser combinadas diferentes linguagens de programação, frameworks de desenvolvimento e tecnologias de data-storage.

Quais as vantagens e desvantagens dessa arquitetura?

Vantagens de Microsserviços

  • Permite a entrega contínua e implantação de aplicativos grandes e complexos - Equipes multifuncionais trabalham para lidar com todo o ciclo de vida de uma aplicação e um modelo de entrega contínua.
  • Melhora da manutenibilidade - Cada serviço é relativamente pequeno e assim se torna fácil de entendê-lo e alterá-lo;
  • Melhor testabilidade - serviços são menores a mais rápidos de testar;
  • Deploy - Serviços podem ser implantados independentes sem prejudicar o funcionamento de toda a aplicação;
  • Diversidade de tecnologia - Cada microsserviço poderá ser desenvolvido com diferentes stacks;
  • Aumento da Resiliência - Em caso de falhas de um microsserviço, partes da aplicação ainda continuarão funcionando;
  • Escalabilidade - Aspecto chave dos microsserviços, permitindo a expansão de uma única função ou serviço sem ter que redimensionar toda a aplicação. Serviços que são mais críticos para o negócio podem ser implantados em vários servidores, aumentando a disponibilidade e desempenho sem impactar em outros serviços;

Desvantagens de Microsserviços

  • Desenvolvedores precisaram lidar com uma complexidade adicional para criação e distribuição dos sistemas;
  • Comunicação entre serviços - Desenvolvedores precisam escolher e implementar um mecanismo de comunicação inter-serviços;
  • Testes de integração entre serviços assim como os testes end-to-end são mais difíceis e importantes como jamais foram;
  • Complexidade no deploy - Principalmente em ambientes produtivos podem ser mais complexos e delicados, uma implantação rápida e segura exige um custo maior;
  • Particionamento dos databases - Você precisa atualizar múltiplos databases que são mantidos por diferentes serviços, desafio grande onde precisa-se pensar em escalabilidade, resiliência e disponibilidade.
  • Monitoramento robusto - Como você está orquestrando vários serviços, um monitoramento robusto é obrigatório para saber quando um serviços falhar ou até mesmo uma máquina cair;
  • Aumento do consumo de infra - A medida em que novos serviços vão sendo implantados ou escalados, estes que são executados em sua própria VM (ou equivalente, o qual é necessário para isolamento das instâncias), necessitam de mais recursos de memória, processador e HD;

E sobre o custo?

O custo para desenvolver uma solução baseada em microsserviços é mais alto comparado a um monolito, você tem mais complexidades, vai precisar de um time mais preparado tecnicamente, um conhecimento e uma infraestrutura mais avançada. Entretanto, o custo para manutenção é mais barato, em alguns cenários é até mesmo a única forma de se dar uma boa manutenção.

Qual o tamanho de um microsserviço?

Não existe um limite de quão grande ou pequeno deve ser um microsserviço, a palavra 'micro' é alvo de constantes definições do que a constitui. Mas uma abordagem interessante sobre o tamanho de cada microsserviço é a regra da Amazon sobre o "two time pizza", onde todo o time consegue ser alimentado por duas pizzas. O fato é que, a decomposição deve ser pensada levando em consideração o que uma arquitetura de microsserviços propõe, por exemplo:

  • Cada serviço tem uma única responsabilidade;
  • Cada serviço é pequeno o suficiente para ser criado por uma pequena equipe trabalhando de forma independente;
  • Não devem estar acoplados de forma forte e podem evoluir independente;
  • Se a comunicação entre duas funcionalidades de serviços diferentes gerar excesso de mensagens, isso poderá ser um sintoma de que essas funções pertencem ao mesmo serviço;
  • Os limites entre cada serviço não podem criar problemas de consistência e integridade dos dados.

Quais as principais ferramentas e frameworks usados em microsserviços?

Existe atualmente um ferramental bem rico que nos ajudam a lidar com essa arquitetura (alguns inclusive open source), tornando-a cada vez mais fácil e intuitiva, cada uma com uma proposta diferente para um determinado contexto, por exemplo:

Banco de Dados: Não somente em microsserviços, mas em qualquer projeto deve ser aplicado e avaliado o Teorema de CAP, criado para tratar sobre os comportamentos de bancos de dados em sistemas distribuídos.Um dos mais populares para uso com microsserviços é o MongoDB, noSQL apresenta uma boa performance além de uma boa capacidade de escalonamento horizontal.
API Gateway: LinkApi, NgInx, Kong, Tyk.io.
Logs e Monitoramento: Elastic, Logstash, Kibana.
Containers: Docker e Kubernates.
Deploy: Rapid Deploy, Code Deploy, Elastic Box.
Mensageria: RabbitMQ, Kafka.
Segurança: OAuth2, SAML, 2Factor, SonarQube, Veracode.
Gerenciamento de Configuração: Ansible, Chef, Puppet.

Posso usar microsserviços on premise?

Sim, apesar do cloud ter sido um dos grandes precursores para a evolução dos microsserviços sem contar a facilidade de uso, é possível sim fazer o uso de microsserviços on premise.

Claro que dessa forma você terá uma complexidade maior de gerenciamento, por exemplo gerenciar a escalabilidade, onde em cloud já existem recursos prontos para identificar um número X de requisições e escalam os serviços proporcionalmente a demanda.

Em breve lançaremos a sequência dessa série sobre microsserviços. Enquanto isso, aproveite para aprender mais sobre APIs e integrações em nosso blog, confira esse artigo dicas para melhorar a esxperiência de consumo de APIs.

Agende uma conversa e saiba como podemos te ajudar