Microservices após o hype - O que é? Qual a motivação? E eu realmente preciso disso? - Parte 01
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.