Dapr: crie aplicativos mais rapidamente com APIs padronizadas

Criar aplicativos e prepará-los para produção é uma tarefa enorme. Dê uma olhada no aplicativo Twelve-Factor que lista muitos aspectos essenciais envolvidos na criação e execução de produtos SaaS. As equipes de desenvolvimento devem ser capazes de compreender e implementar todos esses fatores técnicos em tempo hábil. Espera-se que as equipes forneçam funcionalidades rapidamente, enquanto os custos operacionais precisam ser minimizados.

Ferramentas e estruturas que reduzem os limites da criação e execução de aplicativos prontos para produção são essenciais, pois permitem que os desenvolvedores gastem mais tempo na implementação de recursos de negócios, em vez de fazer a barba. A estrutura de tempo de execução Dapr é popular para construir aplicativos distribuídos baseados em arquiteturas de microsserviços.

Este artigo destaca como a produtividade do desenvolvedor aumenta e como uma arquitetura ágil pode ser alcançada usando Dapr, independentemente da arquitetura de software escolhida.

Aumentando a produtividade do desenvolvedor

O Dapr ajuda os desenvolvedores a serem eficientes, fornecendo APIs fáceis de entender, também conhecidas como blocos de construção, para começar a desenvolver aplicativos rapidamente. Muitas organizações usam Dapr para construir microsserviços sobre Kubernetes. Mas e se você não quiser ou precisar de uma arquitetura de microsserviços? E se você quiser construir monólitos, monólitos modulares ou aplicativos de arquitetura de N camadas? Os blocos de construção Dapr podem beneficiar todos os tipos de aplicativos de back-end.

APIs de blocos de construção padrão

Alguns blocos de construção do Dapr, como invocação serviço a serviço, pub/sub e bloqueio distribuído, são essenciais para sistemas distribuídos. A maioria dos blocos de construção, entretanto, são relevantes para qualquer tipo de arquitetura de software:

• Gestão estadual (armazenamento de chave/valor): pares de chave/valor de leitura/gravação para criar serviços com estado.
• Segredos de gestão: acesse com segurança os segredos do seu aplicativo.
• Ligações: interface com sistemas externos.
• Configuração: gerenciar a configuração do aplicativo e fazer com que seu aplicativo se inscreva nas alterações.
• Fluxo de trabalho: permite processos de negócios com estado e de longa duração.
• Atores: unidade independente que contém estado e comportamento.
• Criptografia: execute operações criptográficas sem expor chaves ao seu aplicativo.

O diagrama abaixo ilustra como um aplicativo de N camadas ou um monólito modular pode se beneficiar do uso de blocos de construção Dapr na camada lógica.

A camada lógica dessas arquiteturas geralmente contém uma camada lógica de negócios e uma camada de acesso a dados. Blocos de construção como Fluxo de Trabalho e Atores destinam-se ao desenvolvimento de lógica de negócios, portanto, são uma ótima opção aqui. O bloco de construção Configuração é útil quando usado como uma solução leve de sinalização de recursos. Os blocos de construção Gerenciamento de estado, Ligações e Segredos são particularmente úteis na camada de acesso a dados quando recursos externos são acessados.

Todas as APIs de blocos de construção são intencionalmente básicas para manter a curva de aprendizado o mais plana possível. Por exemplo, se você usar a API de gerenciamento de estado para dados de chave/valor, estes são os métodos que você usaria:

Criar/inserir par chave/valor

POST <http://localhost>:<daprPort>/v1.0/state/<storename>
Content-Type: application/json

(
	{ "key" : "<key1>", "value" : "<value1>" },
	{ "key" : "<key2>", "value" : "<value2>" }
)

* refere-se ao nome do componente do armazenamento de estado*

Obtenha um valor por chave

GET<http://localhost>:<daprPort>/v1.0/state/<storename>/<key>

Obtenha vários valores por chaves

POST <http://localhost>:<daprPort>/v1.0/state/<storename>/bulk
Content-Type: application/json

{
	"keys": ( "<key1>", "<key2>" )
}

Excluir um par chave/valor

DELETE <http://localhost>:<daprPort>/v1.0/state/<storename>/<key>

Ao oferecer essas APIs padrão que podem ser usadas via HTTP, gRPC ou um dos SDKs do cliente Dapr, os desenvolvedores podem usar sua linguagem favorita e permanecer no ambiente de desenvolvimento integrado (IDE) de sua escolha.

Preocupações transversais

Portanto, além das APIs de blocos de construção padrão, como exatamente o Dapr pode ajudar a acelerar ainda mais o tempo de desenvolvimento? Todas as aplicações precisam considerar preocupações transversais, como:

• Observabilidade
• Resiliência
• Segurança

Se nenhuma estrutura for usada para implementar essas preocupações, elas precisarão ser implementadas repetidamente em cada aplicação, o que não seria o melhor uso do tempo de desenvolvimento. Algumas equipes implementam sua própria solução para gerenciar essas preocupações, com a desvantagem de possuir e manter uma base de código maior. Com o Dapr, todas as preocupações transversais acima vêm imediatamente e são gerenciadas com arquivos de configuração declarativos.

Observabilidade

Dapr possui observabilidade integrada; isso inclui rastreamento, métricas e registro.

• Rastreamento: captura o fluxo de uma solicitação através de um sistema.
• Métricas: descreve uma medição pontual de uma propriedade do sistema que pode ser facilmente agregada.
• Exploração madeireira: captura eventos discretos em um formato mais rico para fornecer contexto.

O Dapr pode se conectar a qualquer ferramenta de observabilidade que suporte os protocolos OpenTelemetry (OTEL) e Zipkin, como DataDog, New Relic, Grafana e Jaeger. O rastreamento é configurado como parte de um arquivo YAML de configuração:

spec:
  tracing:
    samplingRate: "1"
    otel: 
      endpointAddress: "https://..."
			isSecure: true
      protocol: grpc

Os sidecars do Dapr expõem um endpoint de métricas do Prometheus que pode ser usado para obter insights sobre como o próprio Dapr está se comportando. Os tipos de métricas coletados incluem: plano de controle, aplicativo, componente e políticas de resiliência. Veja a lista completa com todas as métricas individuais no GitHub.

Resiliência

Tornar os aplicativos resilientes é um trabalho árduo. A resiliência geralmente é aplicada através da implementação de padrões de arquitetura bem conhecidos, como nova tentativa, disjuntor e tempo limite.

• O padrão de nova tentativa é usado quando uma chamada para um serviço falha e a chamada é repetida várias vezes.
• O padrão do disjuntor é usado para evitar falhas em cascata quando uma chamada para um serviço falha.
• O padrão de tempo limite é usado para aguardar uma resposta de um serviço que pode demorar para responder.

Normalmente, é preferível combinar esses padrões para obter uma boa resiliência geral do sistema.

Existem algumas bibliotecas que podem ajudar, como Polly (.NET) ou Resilience4j (Java), mas normalmente estão disponíveis para apenas uma linguagem de programação ou tempo de execução e devem ser incorporadas ao seu aplicativo. Com o Dapr, a resiliência é configurada usando arquivos de especificações de resiliência que contêm políticas e alvos aos quais as políticas se aplicam. Os arquivos de especificação de resiliência têm a seguinte estrutura:

apiVersion: dapr.io/v1alpha1
kind: Resiliency
metadata:
  name: myresiliency
scopes:
  # optionally scope the policy to specific apps
spec:
  policies:
    timeouts:
      # timeout policy definitions

    retries:
      # retry policy definitions

    circuitBreakers:
      # circuit breaker policy definitions

  targets:
    apps:
      # apps and their applied policies here

    actors:
      # actor types and their applied policies here

    components:
      # components and their applied policies here

Se for necessária uma política de repetição constante que tentará novamente 10 vezes com um intervalo de 5 segundos, isso poderá ser configurado da seguinte forma:

retries:
  pubsubRetry:
    policy: constant
    duration: 5s
    maxRetries: 10

As políticas são aplicadas a alvos, que podem ser aplicações, atores ou componentes. Este exemplo configura o pubsubRetry política de saída para um componente nomeado messageBrokerA:

targets:
  components:
    messageBrokerA: # any component name -- happens to be another pubsub broker here
      outbound:
        retry: pubsubRetry

Veja um exemplo completo de especificação de resiliência na documentação do Dapr. A aplicação da resiliência Dapr é independente do idioma e não se limita aos aplicativos Dapr; eles também podem ser aplicados ao chamar endpoints externos (não Dapr).

Segurança

O Dapr fornece segurança ponta a ponta usando criptografia mTLS e políticas de segurança onde o acesso às APIs do Dapr, aplicativos e componentes do Dapr são explicitamente configurados.

Neste exemplo de configuração, o acesso à API HTTP de gerenciamento de estado é permitido:

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: myappconfig
  namespace: default
spec:
  api:
    allowed:
      - name: state
        version: v1.0
        protocol: http

O acesso aos componentes pode ter como escopo aplicativos Dapr específicos. Neste exemplo de arquivo de componente, o statestore componente pode ser acessado por app1 e app2:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
  namespace: production
spec:
  type: state.redis
  version: v1
  metadata:
  - name: redisHost
    value: redis-master:6379
scopes:
- app1
- app2

Se a solução estiver expondo APIs da Web, a autorização de endpoint poderá ser implementada usando o middleware Dapr OAuth para usar o fluxo de concessão de código de autorização ou o fluxo de concessão de credenciais do cliente. Além disso, o uso de tokens de autenticação pode ser necessário para acessar a API Dapr por meio de um proxy reverso.

Arquitetura Ágil

Quando um novo projeto de software é iniciado em uma organização ágil, geralmente é feita uma combinação de design arquitetônico emergente e intencional. Essa combinação é conhecida como pista arquitetônica. Essa pista contrasta com o big design up front (BDUF), que é comumente feito ao fazer gerenciamento de projetos em estilo cascata. O BDUF leva muito tempo para ser concluído, não deixa espaço para alterações e, portanto, costuma ser um fator limitante posteriormente no projeto.

Deve haver um design de arquitetura intencional suficiente para iniciar o desenvolvimento e fornecer recursos utilizáveis ​​a cada sprint. O restante do projeto arquitetônico surge enquanto a equipe constrói e toma outras decisões. Ajuda adiar algumas decisões o máximo possível para permitir mais tempo para explorar opções durante o desenvolvimento.

Uma das decisões arquitetônicas intencionais poderia ser a utilização de um framework como o Dapr que permita adiar outras decisões arquiteturais que surgirão posteriormente. Freqüentemente, a equipe de desenvolvimento não controla certas decisões.

Por exemplo, o departamento de compras ainda está em negociação com vários fornecedores de nuvem, por isso ainda não há decisão sobre qual deles usar. A equipe de desenvolvimento ainda pode prosseguir com o Dapr, pois os aplicativos Dapr podem ser executados em qualquer nuvem que ofereça Kubernetes ou VMs.

Ou o aplicativo requer gerenciamento de estado para armazenamento de chave/valor, mas a decisão do armazenamento exato está sob revisão pela equipe de segurança. A equipe de desenvolvimento pode continuar com o desenvolvimento de aplicativos usando a API de gerenciamento de estado Dapr, já que é um bloco de construção padrão, e sua implementação pode ser facilmente alternada entre uma solução hospedada localmente e um provedor de nuvem, que está sob revisão, selecionando um estado diferente componente de loja.

O diagrama abaixo ilustra a flexibilidade na hospedagem de aplicativos e fornece um exemplo de vários componentes que podem ser usados ​​por meio da API padrão para gerenciamento de estado.

Flexibilidade com Componentes

Como os aplicativos Dapr usam uma API padrão para acessar recursos como gerenciamento de estado, mensagens pub/sub, ligações, armazenamentos de configuração, armazenamentos de segredos, etc., essas APIs e sua implementação subjacente são desacopladas por componentes Dapr. Dapr tem mais de 115 componentes integrados nas 11 APIs de blocos de construção. Componentes do mesmo tipo são intercambiáveis ​​sem alterar o código do aplicativo. Um arquivo de componente que contém o nome do componente, o tipo e os metadados sobre como conectar-se ao recurso subjacente é a única alteração necessária.

Este exemplo mostra um arquivo de componente onde o Redis é usado como armazenamento de estado:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <storename> 
spec:
  type: state.redis
  version: v1
  metadata:
  - name: redisHost
    value: <host>
  - name: redisPassword
    value: <password>

A única coisa que o aplicativo requer para usar esse componente é o valor metadata.name ( neste exemplo):

GET <http://localhost>:<daprPort>/v1.0/state/<storename>/<key>

No nível do componente, há flexibilidade no que diz respeito aos recursos usados ​​pelas APIs de blocos de construção, para que os desenvolvedores não fiquem presos ao denominador mais baixo em todos os recursos. Por exemplo, embora a API de gerenciamento de estado não tenha métodos para configurar o tempo de vida (TTL) para os pares chave/valor, no nível do componente (configuração declarativa), isso pode ser especificado para recursos que suportam isso nativamente:

- name: ttlInSeconds
  value: <int> # Optional

Caso os componentes integrados não sejam suficientes, o Dapr permite a criação de componentes conectáveis ​​para gerenciamento de estado, mensagens pub/sub e ligações. Isso permite que as equipes de desenvolvimento usem APIs de blocos de construção bem conhecidas, ao mesmo tempo que fornece flexibilidade máxima nos recursos de que necessitam.

Fechando

Muitos aplicativos precisam de alguma forma de gerenciamento de estado, acesso a configurações e segredos e integração com sistemas externos. Como o Dapr oferece blocos de construção para esses recursos, as equipes de desenvolvimento se beneficiam significativamente com o uso do Dapr, mesmo que inicialmente não envolva microsserviços. A API padrão para os blocos de construção tem uma curva de aprendizado modesta e, combinada com a implementação de preocupações transversais de observabilidade, segurança e resiliência, o Dapr ajuda os desenvolvedores a criar aplicativos prontos para produção com mais rapidez. A dissociação das APIs com os componentes permite adiar decisões arquitetônicas, o que garante que a arquitetura da aplicação seja flexível e portável.

Quer saber mais sobre o Dapr? Dê uma olhada no repositório learn-dapr no GitHub e junte-se ao Dapr Discord, com mais de 6.000 membros, para pedir ajuda e compartilhar seu conhecimento.

A postagem Dapr: crie aplicativos mais rapidamente com APIs padronizadas apareceu pela primeira vez em The New Stack.