Spring Boot: Como desenvolver microservices seguros

Spring Boot: Como desenvolver microservices seguros

Veja neste artigo algumas das opções disponíveis para isso e como garantir a segurança de microsserviços através de autenticação.

Por que eu devo ler este artigo: Cenário: Este artigo apresenta uma maneira simplificada de adicionar autenticação em microserviços baseados no Spring Boot.

Os microserviços são aplicações autônomas que normalmente utilizam um servidor web embarcado e disponibilizam uma interface REST para interação com sistemas externos. Com esse novo estilo arquitetural, torna-se crucial a adição de componentes que realizem a segurança e só permitam o acesso de clientes (aplicações ou usuários) que tenham autorização para executar determinada ação.

Lembre-se que independentemente do tipo de aplicação, é de suma importância a proteção contra requisições indevidas e isso se torna ainda mais crítico quando se trata de microserviços baseados em REST, visto que toda forma de comunicação ocorre sobre o protocolo HTTP, podendo ser acessado por qualquer usuário na web. Com base nisso, este artigo busca explorar as opções que possibilitam construir microserviços mais 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.

Portanto, apesar de sua característica autônoma, cada microserviço precisa se adequar a um escopo de segurança, de forma que cada requisição realizada seja tratada adequadamente e só após a confirmação das credenciais válidas, que o acesso deve ser liberado.

Fonte: DevMedia
https://www.devmedia.com.br/
https://www.devmedia.com.br/spring-boot-como-desenvolver-microservices-seguros/34101

Introdução à arquitetura de microservices com Spring Boot

Introdução à arquitetura de microservices com Spring Boot

Aprenda neste artigo os principais conceitos e desenvolva um microsserviço para distribuição de pacotes de viagens a diferentes clientes de um portal.


Por que eu devo ler este artigo: Este artigo apresenta de forma prática um dos assuntos que vem ganhando mais destaque entre arquitetos e desenvolvedores de software: o padrão de arquitetura microsserviços (ou microservices). Para isso, exploraremos aqui os principais conceitos, vantagens e desvantagens, assim como um caso de uso. A partir do conteúdo exposto o leitor será capaz de dar os primeiros passos na construção de sistemas baseados nessa arquitetura na plataforma Java utilizando o Spring Boot.

Uma das funções mais importantes e desafiadoras de um arquiteto de software é a definição da arquitetura para o sistema a ser desenvolvido. Iniciada entre as primeiras fases do projeto, esta etapa é fundamental para o bom andamento do mesmo. Para se ter uma noção mais precisa, uma decisão incorreta pode ocasionar atrasos na entrega do sistema, comprometer a qualidade, a segurança ou até mesmo inviabilizar o desenvolvimento.

Dada a importância dessa fase para a fundação do sistema, inúmeros padrões de desenvolvimento, frameworks e modelos arquiteturais são elaborados para resolver problemas comuns utilizando as melhores práticas. Neste cenário, um dos padrões arquiteturas que mais tem se destacado é a arquitetura de microservices, justamente pelos benefícios adquiridos ao adotar esta solução. Antes de discutirmos mais detalhes sobre essa arquitetura, no entanto, precisamos entender outro padrão arquitetural muito utilizado, talvez o mais comum deles: a arquitetura monolítica.

Portanto, no decorrer do artigo iremos debater sobre os conceitos introdutórios dos padrões de arquitetura monolítica e de microservice e, de forma prática, iremos aplicar esses conceitos para solucionar um problema elaborado para o caso de uso do artigo, que fará uso do Spring Boot como base.

Aplicações Monolíticas

Sistemas construídos sobre o padrão arquitetural monolítico são compostos basicamente por módulos ou funcionalidades agrupadas que, juntas, compõem o software. Como exemplos de aplicações que fazem uso do modelo monolítico, podemos citar os sistemas ERP (Enterprise Resource Planning), como o SAP ou Protheus. Estes possuem, normalmente, módulos para controle do setor financeiro, contábil, compras, entre outros, agrupados numa única solução que acessa o banco de dados.

Na Figura 1 podemos verificar um exemplo de ERP construído com base numa arquitetura monolítica.

Sistema ERP

Figura 1. Exemplo de Arquitetura Monolítica.

Introduzida a mais tempo que o padrão de microservices, a arquitetura monolítica também é comumente utilizada no desenvolvimento de aplicações web. No entanto, assim como qualquer solução, ele provê vantagens e desvantagens.

Dentre as vantagens, podemos citar:

  • Implantar a aplicação é relativamente simples, uma vez que basta fazer o deploy de um único WAR ou EAR no servidor de aplicação;
  • Simples de monitorar e manter;
  • Ambiente de desenvolvimento mais simples, onde uma tecnologia core é utilizada em todo o projeto.

Dentre as desvantagens, podemos citar:

  • Uma mudança feita em uma pequena parte da aplicação exige que todo o sistema seja reconstruído e implantado;
  • Escalar a aplicação exige escalar todo o aplicativo, em vez de apenas partes que precisam de maior demanda;
  • Alta curva de aprendizado para novos desenvolvedores que entram no time de desenvolvimento, uma vez o desenvolvedor deve entender o contexto de todos os módulos do projeto;
  • Necessidade de reimplantar tudo para alterar um único componente. Sendo assim, o risco de falhas aumenta e consequentemente um ciclo maior de testes deve ser aplicado.

Microservices

Em suma, o estilo arquitetural de microservices consiste no desenvolvimento de uma aplicação como um conjunto de pequenos serviços, cada um executando em seu próprio processo. Os serviços podem ser construídos de forma modular, com base na capacidade de negócio da organização em questão.

Pelo fato dos serviços serem construídos de forma independente, a implantação e a escalabilidade podem ser tratadas de acordo com a demanda. Essa independência também permite que os serviços sejam escritos em diferentes linguagens de programação e diferentes tecnologias, visando atender a necessidades específicas da melhor maneira. Outro ponto importante é que cada serviço pode ser gerenciado por diferentes times de desenvolvimento, possibilitando a formação de equipes especializadas.

Para termos uma melhor noção de onde podemos aplicar este conceito, listamos a seguir algumas vantagens e desvantagens.

Dentre as vantagens, podemos citar:

  • Fácil entendimento e desenvolvimento do projeto;
  • Fácil e rápida implantação (build e deploy);
  • Redução do tempo de startup, pois os microservices são menores que aplicações monolíticas em termos de código;
  • Possibilidade de aplicar a melhor ferramenta para um determinado trabalho.

Dentre as desvantagens, podemos citar:

  • Dificuldade em implantar e operar sistemas distribuídos;
  • Como cada microservice geralmente tem sua própria base de dados, o gerenciamento de transação se torna mais difícil (múltiplas bases de dados);
  • Implantar uma alteração em um serviço utilizado por muitos sistemas demanda coordenação e cautela.

Organizando os microservices com a API Gateway

Depois de conhecermos os conceitos por traz dos microservices, uma das primeiras perguntas que nos vem à cabeça é: meus clientes ou consumidores (sistemas terceiros) precisam conhecer todos os microservices para se comunicar? Neste caso sim (ou teríamos que desenvolver um conjunto de microservices apenas para possibilitar a comunicação), e isso não é bom!

Como exemplo para melhorar o entendimento, vamos utilizar o caso do ERP citado anteriormente e decompor aquela arquitetura monolítica em serviços. Isso nos daria, por exemplo, um serviço específico para o módulo compras, outro para o financeiro, outro para o contábil e assim por diante.

Uma vez que os microservices estejam prontos para uso, imagine que nosso cliente seja uma aplicação web responsável apenas pela camada de apresentação do ERP, e que esta deva se comunicar com todos os módulos (serviços). Sendo assim, para evitar que essa aplicação conheça o endereço de cada um dos serviços, devemos incluir uma camada de abstração, pois seria muito complexo para o cliente se encarregar de manter estes endereços atualizados, por exemplo.

Para resolver este problema, um padrão foi criado: a API Gateway. Com o gateway os clientes terão um únic …


Fonte:
www.devmedia.com.br

https://www.devmedia.com.br/introducao-a-arquitetura-de-microservices-com-spring-boot/33703