Nesse post iremos responder algumas dúvidas de profissionais que pretendem desenvolver aplicações de grande porte e também precisam escalar sistemas sustentáveis, que durem muito e ainda gerem valor para as empresas.
1 — Devo utilizar API Gateway no Kubernetes?
Quem trabalha com Kubernetes sabe que existem duas formas padronizadas para receber as requisições externas, que são:
Criar um Load Balancer para gerar um IP externo que torna o serviço acessível a todos.
Utilizar o Ingress para rotear os domínios e endereços acessados para algum serviço específico.
Com base na URL o Ingress recebe e roteia as requisições para o serviço correto, muito semelhante à uma API Gateway no Kubernetes, embora não seja igualmente completo. Mas existem outras alternativas que podem suprir essas necessidades. Confira a seguir.
Service Mesh — Istio
A primeira opção é utilizar o Istio, que conta com um componente chamado Ingress Gateway. Esse recurso é mais potente que o Ingress padrão do Nginx no Kubernetes e ainda permite que você utilize Virtual Services e Destination Rules para diversas finalidades.
Você escolhe o tipo de algoritmo para o seu Load Balancer e também cria um “peso” para cada versão do serviço. É possível, por exemplo, definir que 90% do seu serviço ficará na versão 1 e 10% na versão 2.
Você consegue estipular uma quantidade de rate limit e adicionar recursos muito úteis em relação à fault injection e políticas de retry.
Por padrão o Istio também faz validações de JWT na autenticação, sem a necessidade de enviar para os serviços internos do Kubernetes.
Mas leve em consideração que o Istio é mais pesado e requer mais carga na sua rede para funcionar. E se você pretende utilizar apenas o Ingress Gateway, o Istio não é recomendado porque ele coloca mais coisas na sua aplicação. Mas se você quiser as demais vantagens, essa opção disponibiliza diversos recursos que uma API Gateway possui.
Service Mesh — Kong
Essa opção evita que você tenha instalado toda a malha de serviços para trabalhar com uma API Gateway no Kubernetes. E o Kong, nesse caso, é um sistema de API Gateway baseado no Nginx, contando com muitos plugins para te auxiliarem.
Entre os diversos recursos de Load Balancing, o Kong oferece processos de rate limit e serviços de plugins instaláveis com os recursos de uma API Gateway, viabilizando também a conversão de padrões quando recebemos uma mensagem.
E além de validar o JWT para fazer autenticações de frente e na borda do mesmo serviço, o Kong tem recursos de introspecção na parte do JSON.
Em suma, o Kong é recomendado se você quer uma API Gateway sólida, rápida e funcional para trabalhar de forma stateless no Kubernetes.
2 — O que são entidades na Clean Architecture?
Criar entidades é uma tarefa típica de quem trabalha com DDD, JPA ou modelo de persistência. Porém, o Uncle Bob (Robert Martin), criador da Clean Architecture, nomeou essas camadas de entidades de ‘Enterprise Business Rules’.
Elas são basicamente regras de negócio que devem ser protegidas e a relação entre as suas classes e funções definem o coração da aplicação.
Essas camadas de entidades são referentes às regras de negócio que existem entre uma classe e outra. E assim, na comunicação entre as classes, é executada uma função ou método de integração que mantém todas as regras do negócio, independente do contexto.
Isso é diferente das entidades criadas no DDD, que trabalha com mais camadas e esse conceito se baseia na existência de um ID para identificar o que está na nossa aplicação. E nesse caso a entidade é tratada como identidade, algo que atribui valores e funciona através de mudança de estado.
A comunicação entre as classes para os serviços no DDD é feita numa camada superior à camada de entidades, chamada de Domain Services. E numa correlação pode-se dizer que isso é relativamente semelhante à camada de entidade da Clean Architecture.
Nós criamos esses arquivos e classes para nos ajudarem no modelo de persistência e não há relação com as entidades que trabalhamos para fechar regras de negócio, ou mesmo qualquer entidade criada no Doctrine do PHP, no Hibernate ou no Entity Framework.
3 — Que sistema você utiliza para acompanhar a performance das suas aplicações?
Ferramentas para monitoramento de performance (APM – Application Performance Monitoring) nos ajudam a acompanhar o desempenho das nossas aplicações, desde erros a comportamentos suspeitos no banco de dados, tracing distribuído e diversas outras análises.
Aqui na Full Cycle nós utilizamos duas ferramentas. São elas:
Elastic APM
Essa ferramenta instala um agente na aplicação que capta os dados e os envia para o APM Server. E você também pode utilizar o dashboard do Kibana para acompanhar diversas informações relevantes em relação aos seus resultados.
New Relic
Com algumas vantagens em relação ao Elastic, o New Relic não exige que você tenha o Elasticsearch instalado. Basicamente você contrata e instala esse serviço sem se preocupar com infraestrutura e servidor; você escolhe o seu plano e utiliza os recursos disponíveis.
Essa ferramenta mostra as transações dos bancos de dados mais lentas e mais rápidas, verifica erros e abre casos para os problemas com base nas métricas que nós mesmos definimos. E ao fazer o reajuste o caso é fechado automaticamente.
Outro detalhe é que se você tem um sistema novo, com um tráfego de até 100 GB de ingestão de dados mensais, o New Relic é gratuito.
Outras ferramentas de APM:
Existem opções mais reconhecidas no mercado que também cumprem essas funções. E grande parte desses serviços possuem diferentes formas de acesso. Isso varia dependendo de como você negocia o preço, a responsabilidade que você quer ter sobre a aplicação e qual ferramenta você mais se identifica.
O Datadog, por exemplo, faz diversas correlações para captar informações e a injeção de dados recebidos é feita no Splunk.
4 — Qual a relação entre DDD e Clean Architecture?
DDD (Domain-Driven Design)
A princípio devemos entender que DDD não se limita a código, apenas, mas em integrar técnicas que consistem em dividir um problema para facilitar a sua modelagem.
Isso nos ajuda a criar uma linguagem que evita problemas de comunicação durante o projeto e ainda cria design patterns que orientam as nossas implementações. E em geral o DDD é mais abrangente nesses quesitos.
Clean Architecture
Já a Clean Architecture, por mais que leve ‘arquitetura’ no nome, é mais centrada no design da aplicação, estruturando as suas camadas para deixá-la mais desacoplada. Isso ajuda a protegermos as regras de negócio antes de tomarmos decisões mais específicas durante a solução.
Isso ajuda mais a desenhar a solução, do que necessariamente promover uma visão global de tudo, como no DDD. Mas é comum utilizarmos patterns, que normalmente são encontrados nos livros de Eric Evans e Vaughn Vernon sobre DDD, para trabalharmos com Clean Architecture.
Normalmente você cria classes de entidades, usa value objects (objetos de valor) e define agregados. Então na Clean Architecture você indiretamente acaba trabalhando com DDD.
Eventualmente é comum utilizarem o padrão de repositório do DDD na parte de gateway, de comunicação externa e com banco de dados. E de alguma forma essas abordagens podem convergir, embora a abrangência do DDD seja maior em relação à Clean Architecture.
Há situações em que o DDD nos ajuda a ter um ponto de partida para dividirmos sistemas em microsserviços, mas a Clean Architecture trabalha especificamente no mesmo sistema.
Portanto, apesar dos pontos de diferença, é muito comum utilizarmos conceitos e padrões de DDD na Clean Architecture para desenharmos as nossas aplicações.
Se você curtiu esse conteúdo e quer aprender mais sobre Clean Architecture e DDD, solicite contato clicando aqui e nós te ajudamos.
