Spring Boot: Como desenvolver microservices seguros

Até poucos anos atrás, grande parte dos desenvolvedores Java desenvolviam aplicações corporativas organizadas como sistemas monolíticos, contendo um ou mais módulos, implantados como um único pacote (WAR ou EAR) em um servidor de aplicações (ex.: GlassFish, JBoss AS). Esse conceito ainda é amplamente adotado no mercado, mas uma alternativa promissora começa a ganhar espaço: a arquitetura baseada em microserviços.

Com a demanda pelo desenvolvimento de sistemas cada vez mais complexos e o consequente aumento no número de dependências e linhas de código, a rotina de um desenvolvedor que precisa trabalhar com aplicações monolíticas tornou-se cada vez mais difícil.

Além do grande número de módulos, componentes, pacotes e classes, que vão agregando funcionalidades que visam contemplar a cadeia completa do modelo de negócio em questão, o desenvolvedor precisa reimplantar a sua aplicação em um servidor de aplicações a cada modificação.

Para lidar com isso algumas estratégias foram desenvolvidas como, por exemplo, o plugin do JRebel, que realiza o hot-deploy (implantação instantânea, sem necessidade de reiniciar o serviço) da aplicação no servidor. No entanto, qualquer modificação mais complexa, como a criação de novos componentes de negócio, demanda um comando de reinicialização completo, o que pode levar alguns minutos.

Fora a queda de produtividade devido à demanda de implantação de um pacote no servidor a cada modificação, o desenvolvedor de aplicações monolíticas ainda precisa lidar com outros problemas clássicos de aplicações altamente acopladas, como a impossibilidade de manter módulos funcionando de maneira independente, a dificuldade da escalabilidade de um serviço específico (que demande mais processamento), o alto risco de inserção de efeitos colaterais após uma modificação e a dificuldade de integração com sistemas externos, visto que uma interface única de acesso normalmente é enorme e bastante suscetível a mudanças.

Como se torna difícil manter um padrão, ou acabam-se criando interfaces especializadas para determinados clientes, o que gera ainda mais acoplamento entre os sistemas, ou o cliente precisará estar constantemente atualizando a sua interface de comunicação com o servidor.

Então, como pensar em uma arquitetura viável para este cenário? Que tal pensarmos em aplicações com o escopo reduzido e focadas em um serviço específico, que possam ser distribuídas pela nuvem e não dependam da implantação em um servidor externo? Esse é o conceito-chave por trás dos microserviços.

Neste cenário, ao invés de um grande pacote EAR implantado em um servidor de aplicações, vamos ter um conjunto de aplicações empacotadas cada uma como um simples JAR, que não precisam ser implantados em nenhum servidor. Basta executar a aplicação via java –jar que ela estará pronta para ser acessada através de qualquer cliente HTTP.

De maneira mais prática, é como se desmembrássemos um sistema monolítico em vários sistemas menores, que executam de maneira independente.

Considerando como exemplo um sistema de loja on-line, poderíamos elencar vários microserviços, tais como: controle de logística, visualização de produtos, mala direta, emissão de notas fiscais, promoções, entre tantos outros; ou seja, são inúmeras as possibilidades.

Com esse desmembramento, torna-se possível atualizar versões de quaisquer serviços sem ter de parar toda a infraestrutura, organizar o armazenamento de cada microserviço adotando uma tecnologia mais adequada para aquele propósito (ex.: NoSQL, In-memoryDB) ou até mesmo, se for o caso, desenvolver cada um em uma linguagem de programação diferente. Enfim, essa nova solução nos dá a liberdade total para desenvolver cada parte do negócio e ainda força o desenvolvedor a pensar em sua aplicação com uma visão mais focada.

Dentro desse ambiente tão livre, surge um novo requisito, que até então não havia nas aplicações monolíticas: a necessidade de uma camada de segurança nos microserviços. Considerando o exemplo do sistema de loja on-line, não seria adequado que um usuário sem a devida autorização consiga alterar o preço de um produto."