Em 2015, houve um grande barulho sobre o tópico de microservices. Não havia uma conferência sequer que não falasse no assunto e não houve uma semana sem um novo mágico framework que fosse capaz de entregar mil funcionalidades com um clique.

Resultado: houve muito foco em ferramentas e histórias bonitas, e não em questões realmente relevantes.

Logo, nos pareceu relevante revisar os aspectos arquiteturais relacionados a microservices, uma vez que o estilo arquitetural adotado para um sistema influencia diretamente no ciclo de vida do projeto e na organização da empresa.

Vocabulário

Antes de entrarmos nos detalhes, é importante deixar claro alguns conceitos:

• Serviço, como utilizado neste artigo, está relacionado a um serviço com valor para negócio. É a composição de diversos serviços (REST, SOAP, …) que, como um todo, fornecem uma funcionalidade que tem valor ao negócio.
• Projeto, como utilizado neste artigo, corresponde a um projeto de TI e todo o seu ciclo de vida, e não somente a projeto como uma fase antes de entrar em modo sustentação (também chamado modo manutenção em alguns casos)

1) Porque microservices: questões referentes a grandes projetos

A arquitetura de microservices foi criada para resolver alguns dos problemas vividos em grandes projetos.

Com o tempo, os projetos crescem naturalmente, seja adicionando novas funcionalidades ou estendendo outras. Raramente, alguma funcionalidade é retirada, causando o surgimento de alguns problemas, tais como:

Complexidade

Quando a quantidade de código cresce, o código torna-se mais complexo. Mesmo com uma arquitetura sólida, a interdependência entre os elementos estruturais do sistema cresce com o tempo.

A complexidade traz duas desvantagens:

Escalabilidade e Confiabilidade

Conforme o tempo passa, quando novas funcionalidades tornam-se mais complexas, os diferentes blocos da arquitetura passam a ter um maior número de interações. Não importa o quanto se organize o código em camadas ou componentes, sempre haverá alguma funcionalidade ou patch específico que tornará a arquitetura um pouco mais obscura.

Depois de algum tempo, torna-se impossível ter uma visão global do modelo do projeto.

Mesmo com um conjunto sólido de testes, a multiplicação de efeitos colaterais a cada mudança inserida no sistema torna-o instável, fazendo com que seja mais difícil inserir novas funcionalidade e realizar refactorings.

Escalabilidade horizontal

Melhorar a escalabilidade de um sistema pode requerer modificações estruturais no projeto. Quanto maior o projeto, tais modificações tornam-se mais custosas e arriscadas. Corre-se o risco de, ao final, ter-se um sistema praticamente impossível de evoluir ou inserir novas funcionalidades.

Inovação

Inovação tecnológica

Como uma forma de capitalizar os investimentos e facilitar a gestão das pessoas, é comum ter projetos estruturados de maneira consistente dentro de uma empresa: mesmo modo de trabalho, mesma linguagem de programação, mesmas ferramentas.

Cada projeto é direcionado a seguir escolhas transversais, podendo divergir dessas escolhas por necessidades específicas, porém justificando-se sempre.

Para grandes projetos, encontra-se o mesmo dilema. Como forma de evitar a fragmentação, cada mudança técnica deve ser propagada para todo o projeto.

Com o passar do tempo, as mudanças tornam-se cada vez mais custosas e complexas, culminando com uma dificuldade enorme para se introduzir novas ferramentas ou tecnologias devido a uma necessidade específica.

Inovação de negócio

Como forma de atender as necessidades de negócio, deve-se ser capaz de ter um espaço para inovação dentro de um projeto.

Apesar de algumas inovações serem realizadas em novos projetos, a maior parte é feita dentro de projetos existentes.

Assim, quanto maior o projeto, mais crítico é para a empresa inovar. Tende-se a experimentar menos novos produtos, funcionalidades e inovações. Pouco a pouco, a tendência é tornar o produto estável e não mais experimentar inovações.

2) A ideia de microservices

Os problemas descritos acima são conhecidos e práticas existentes nos métodos ágeis ou relacionadas ao software craftsmanship podem limitar a gravidade do impacto sobre projetos.

Infelizmente, essas práticas exigem muito rigor, ainda mais considerando a troca de pessoas em um time e a evolução do projeto.

Comumente, esse rigor é implementado na forma de controles manuais ou documentação extensiva, resultando em projetos insustentáveis que se arrastam por anos antes de decidir trocá-los.

Para tratar essa questão, a proposta de microservices é simples e ainda assim radical: para evitar problemas com grandes projetos, você precisa somente ter pequenos times por projetos.

Para isso, é necessário limitar os projetos a poucas pessoas, para ter feature teams com no máximo sete pessoas com diferentes perfis técnicos. Deve-se quebrar os times existentes em times menores sempre que necessário.

Não trata-se apenas de quebrar times grandes em times menores. A questão é quebrar projetos grandes em projetos pequenos e independentes. Cada projeto podendo ter sua organização, agenda, base de código, base de dados. A integração entre os projetos é feita através de serviços.

Ao contrário de grandes projetos, a arquitetura baseada em microservices possui pequenos projetos independentes, com times dedicados, seu próprio código-fonte e base de dados.

A divisão é orientada a unidades de negócio, agrupando serviços e bases de dados que possuem forte ligação e separando-os quando são suficientemente independentes.

Um time independente responsável por uma unidade de negócio irá ser responsável também pelo deploy completo das aplicações relacionadas a tal unidade de negócio.

Caso você não entenda o porque de isso se chamar "microservices", sem problemas, é um buzzword para deixar o conceito mais atrativo.

Da mesma maneira que a palavra monolítico é usada, de certa forma, para dar um tom negativo para soluções.

Esta arquitetura é resultado de uma convergência de evoluções tecnológicas recentes:

• SOA demonstrou os benefícios da abordagem orientada a serviços;
• Métodos ágeis e o Lean Startup proveram novos modelos de organização e processos;
• A industrialização do deployment e tecnologias de virtualização permitem uma redução de custo e automação de atividade de deploy;
• Banco de dados NoSQL permitiram maior flexibilidade na gestão dos dados.

Neste artigo estamos discutindo a arquitetura baseada em microservices. Nesta parte 01 foi apresentados os problemas encontrados em grandes projetos sob a perspectiva da complexidade e da inovação. Também foi apresentado o conceito de microservices e como microservices trata as dificuldades encontradas em grandes projetos.

Na parte 02, iremos tratar as vantagens e as limitações da arquitetura baseada em microservices.