EP.01 - Micro-serviços. Uma proposta de arquitetura resiliente, escalável, moldável, monitorável & automatizada

1. O QUE SÃO MICRO-SERVIÇOS

Micro-serviços, também conhecido como arquitetura de micro-serviços, é um estilo de arquitetura que organiza a aplicação em uma coleção de serviços com baixo acoplamento entre si e que implementam funcionalidades de negócio.

A Arquitetura de Micro-serviços facilita o processo de entrega e deploy contínuo de aplicações grandes e complexas, além de permitir que as empresas possam evoluir sua stack tecnológica gerando um grau baixo de impacto no negócio a cada mudança.

2. MICRO-SERVIÇOS NÃO É UMA BALA DE PRATA

A arquitetura de micro-serviços não e uma bala de prata. Ela tem muitas desvantagens, além disso, ao usar essa arquitetura há inúmeros pontos que você deve levar em consideração.

A maioria das aplicações existentes hoje em dia utilizam um modelo de arquitetura monolítico. Segue um link para se aprofundar um ponto sobre o modelo de aplicações monolíticas.

Esse tipo de arquitetura tende a ser mais rápida e menos complexa de se implementar se for pensado a curto prazo, porém a longo prazo o custo de manutenção acaba virando uma curva exponencial fazendo com que as empresas acabem gastando muito mais recursos para manter a aplicação em produção além de uma dificuldade muito grande com relação a melhorias que precisam ser implementadas.

Conforme mencionado mais acima, uma arquitetura de micro-serviços não se trata de uma arquitetura simples, ao contrário disso, geralmente se gasta bem mais recursos na arquitetura de cada de nova funcionalidade pois diversas questões precisam ser mitigadas com relação ao acoplamento entre os serviços.

Geralmente uma arquitetura de micro-serviços deve ser feita com base em um entendimento muito grande do domínio do negócio, portanto o uso de um padrão de projeto utilizando DDD (Domain Driven Design) é bem alinhado com a estratégia de micro-serviços e ajuda muito na separação do projeto em contextos com baixo acoplamento entre si.

Eu indico muito a leitura do livro "Domain-Driven Design - Atacando as Complexidades no Coração do Software (Eric Evans)". Esse é um ótimo livro sobre as técnicas de DDD porém se prepare pois ele é um pouco cansativo. O site da Infoq publicou um resumo desse livro em inglês nesse link e um desenvolvedor de São Paulo chamado Rodrigo Praga fez uma tradução no link aqui que não está 100% completa mas pode ajudar quem tenha um pouco de dificuldade com o Inglês.

Existe uma website que também explica um pouco mais sobre a arquitetura de micro-serviços e sugiro fortemente que leiam seu conteúdo.

Abaixo algumas das vantagens e desvantagens que geralmente são encontradas em uma aplicação desenvolvida em uma arquitetura de micro-serviços.

Vantagens

• Cada micro-serviço é relativamente pequeno
• Mais fácil do desenvolvedor entender
• As IDEs compilam e trabalham com projetos pequenos fazendo com que os desenvolvedores sejam mais produtivos.
• A aplicação inicia rápido, o que torna o desenvolvedor mais produtivo e o deploy mais rápido.
• Cada serviço pode ser implantado independente de outros serviços isso os torna mais fácil de atualizar e permite fazer isso com mais frequência.
• Fácil de escalar o desenvolvimento pois fica mais fácil de organizar os esforços entre múltiplos times de desenvolvimento. Cada time é dono e responsável por um ou mais serviços únicos e cada time pode desenvolver, implantar e escalar (criar mais instâncias dos serviços para atender a demanda de produção) seus serviços independente de todos os outros times.
• Melhora o isolamento de falhas, por exemplo, se um serviço tem um memory leak esse leak não afeta outros serviços. Em uma arquitetura monolítica um leak de memória geralmente derruba todo o sistema.
• Elimina qualquer comprometimento de longo prazo com uma tecnologia ou linguagem pois é mais fácil alterar as tecnologia envolvidas em um serviço já que ele é pequeno. Fica mais fácil também que cada time responsável pelo serviços possa usar a linguagem de programação que mais lhes convém e melhor se adapta ao serviço que está sendo construído. 

Desvantagens

• Desenvolvedores precisam lidar com uma complexidade adicional gerada pela construção de aplicações distribuídas.
• As IDEs são orientadas pela construção de aplicações monolíticas e somente agora estão suportando de uma forma decente o desenvolvimento de aplicações distribuídas.
• O teste é muito mais difícil, principalmente os testes de Unidade. Então para micro-serviços o ideal é sempre trabalhar com testes de Comportamento utilizando BDD (Behavior Driven Development).
• Os desenvolvedores precisam implementar a camada de comunicação entre serviços. Nesse quesito alguns frameworks como Netflix OSS podem ajudar nessa tarefa.
• O desenvolvimento de casos de uso que afetam múltiplos serviços requerem um cuidado adicional na coordenação do trabalho entre times diferentes.
• A implantação em produção tem uma complexidade operacional maior com a disponibilização e monitoramento dos serviços e acaba sendo obrigatório a utilização de ferramentas de monitoramento para garantir que os serviços estão todos em pleno funcionamento e apoiar no escalonamento horizontal de carga atendendo picos de utilização.
• Aumenta consideravelmente a quantidade de memória consumida para a aplicação como um todo, já que existem vários serviços rodando e várias JVMs (no caso de serem micro-serviços java) consumindo memória mínima para a subida do Java(JVM).

3. MICRO-SERVIÇOS EM UMA APLICAÇÃO PEQUENA

Essa é uma decisão difícil. Inclusive eu mesmo já cometi o erro de iniciar um projeto e simplesmente tomar uma decisão de construí-lo em micro-serviços. Existe um ponto muito importante a se pensar antes de tomar qualquer decisão, e a primeira delas é primeiro saber em qual ponto o seu software, ou projeto de construção de software está. Geralmente quando temos uma ideia de um software não sabemos exatamente se essa idéia será apreciada pelos nossos futuros usuários, se vai dar certo, se as pessoas adotarão, então, nesse cenário, precisamos conduzir o desenvolvimento utilizando um modelo MVP (Minimum Viable Product - Mínimo Produto Viável) pois precisamos colocar o software no ar o mais rápido possível para que possamos validar nossas ideias e tomar as decisões de negócio para se adaptar de forma rápida ao mercado que desejamos conquistar. Se nesse momento incluirmos uma arquitetura muito complicada para desenvolver dificilmente conseguiremos colocar o software em produção rapidamente para ser validado. De qualquer forma isso não significa que não devemos criar o projeto tentando separar a responsabilidade de cada serviço que está ali dentro, sem nesse primeiro momento se preocupar em separar os projetos entre unidades de código distintas. Podemos criar uma aplicação monolítica porém com os serviços bem desacoplados para que, caso nossa aplicação realmente caia nos braços dos usuários, possamos com um esforço relativamente pequeno iniciar o processo de separação dos serviços e ir crescendo a estrutura e arquitetura para atender a demanda de utilização. Precisamos pensar que algo que nasce pequeno de uma hora para a outra pode explodir e ganhar milhares ou milhões de usuários e nesse cenário não vejo a possibilidade de uma aplicação monolítica sobreviver por muito tempo no meu ponto de vista.

4. O QUE ESPERAR DESSA SÉRIE

Construirei aqui um artigo completo que disponibilizarei em vários episódios e esse que você está lendo se trata do primeiro episódio da série 'Micro-serviços - Uma proposta de arquitetura resiliente, escalável, moldável, monitorável & automatizada''

A cada episódio estaremos evoluindo uma arquitetura de micro-serviços que suporte uma operação grande em produção pensando desde o início o que se precisa para garantirmos estabilidade, escalabilidade e segurança. A ideia é a cada capítulo eu trazer um problema que precisamos endereçar e como fazer isso utilizando a linguagem Java com alguns frameworks de mercado mais utilizados hoje para construção de software via micro-serviços, e com o final dessa série você será capaz de, ao iniciar a construção de um software, saber como estruturá-lo para que seja mais fácil porta-lo para uma arquitetura mais robusta como essa que vamos explorar dentro dessa série.

Chega de blah, blah, blah e mãos a obra. Nó próximo episódio introduziremos o primeiro problema e construiremos nosso primeiro micro-serviço.