Aplicativo Web sem servidor

Esta arquitetura de referência mostra um aplicativo Web sem servidor. O aplicativo fornece conteúdo estático do Armazenamento de Blobs do Azure e implementa uma API usando o Azure Functions. A API faz a leitura dos dados do Azure Cosmos DB e retorna os resultados para o aplicativo Web.

Duas implementações de referência para essa arquitetura estão disponíveis no GitHub: Drone Delivery App (ARM & Azure Pipelines) e To Do App (Bicep & GitHub Actions).

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

O termo "sem servidor" tem dois significados diferentes, porém relacionados:

• Back-end como serviço (BaaS). Os serviços de nuvem de back-end, como bancos de dados e armazenamento, fornecem APIs que permitem aos aplicativos cliente se conectarem diretamente a esses serviços.
• Funções como serviço (FaaS). Nesse modelo, uma "função" é um trecho de código implantado na nuvem e executado dentro de um ambiente de hospedagem que abstrai completamente os servidores que executam o código.

As duas definições têm em comum a ideia de que os desenvolvedores e a equipe de DevOps não precisam implantar, configurar ou gerenciar servidores. Esta arquitetura de referência foca no FaaS usando o Azure Functions, embora o fornecimento de conteúdo da Web do Armazenamento de Blobs do Azure seja um exemplo de BaaS. Veja algumas características importantes do FaaS:

1. Os recursos de computação são alocados dinamicamente conforme exigido pela plataforma.
2. Preço com base no consumo: você recebe uma cobrança apenas pelos recursos de computação usados para execução do seu código.
3. Os recursos de computação aumentam sob demanda com base no tráfego, sem que o desenvolvedor precise realizar qualquer configuração.

As funções são executadas quando um gatilho externo ocorre, como uma solicitação HTTP ou uma mensagem que chega a uma fila. Isso faz com que um estilo de arquitetura orientada a eventos seja natural para arquiteturas sem servidor. Para coordenar o trabalho entre os componentes da arquitetura, considere o uso de agentes de mensagens ou padrões de pub/sub. Para obter ajuda com a escolha entre as tecnologias de mensagens no Azure, consulte Escolher entre os serviços do Azure que entregam mensagens.

Componentes

Essa arquitetura consiste nos seguintes componentes:

Armazenamento de Blobs. O conteúdo Web estático, como arquivos HTML, CSS e JavaScript, é armazenado no Armazenamento de Blobs do Azure e fornecido aos clientes usando a hospedagem de site estático. Toda a interação dinâmica ocorre através das chamadas do código JavaScript para as APIs de back-end. Não há código do lado do servidor para renderizar a página da Web. A hospedagem do site estático oferece suporte à indexação de documentos e páginas de erro 404 personalizadas.

CDN. Use a CDN (Rede de Distribuição de Conteúdo do Azure) para armazenar em cache o conteúdo para latência mais baixa e distribuição mais rápida do conteúdo, além de fornecer um ponto de extremidade HTTPS.

Aplicativos de Funções. O Azure Functions é uma opção de computação sem servidor. Ele usa um modelo controlado por eventos, em que um trecho de código (uma "função") é invocado por um gatilho. Nessa arquitetura, a função é invocada quando um cliente faz uma solicitação HTTP. A solicitação é sempre roteada por meio de um gateway de API, descrito abaixo.

Gerenciamento de API. O Gerenciamento de API fornece um gateway de API localizado à frente da função HTTP. Use o Gerenciamento de API para publicar e gerenciar APIs usadas por aplicativos cliente. O uso de um gateway ajuda a desacoplar o aplicativo de front-end das APIs de back-end. Por exemplo, o Gerenciamento de API pode reescrever URLs, transformar solicitações antes que elas atinjam o back-end, definir cabeçalhos de solicitação ou resposta e assim por diante.

O Gerenciamento de API também pode ser usado para implementar características transversais, como:

• Imposição do uso de cotas e limites de taxa
• Validação de tokens OAuth para autenticação
• Habilitação de CORS (solicitações entre origens)
• Armazenamento de respostas em cache
• Monitoramento e registro em log de solicitações

Se você não precisar de toda a funcionalidade fornecida pelo Gerenciamento de API, outra opção será usar Proxies do Functions. Esse recurso do Azure Functions permite a definição de uma única superfície de API para vários aplicativos de funções por meio da criação de rotas para funções de back-end. Os proxies de função também podem executar transformações limitadas na solicitação e resposta HTTP. No entanto, eles não fornecem os mesmos recursos avançados baseados em política do Gerenciamento de API.

Azure Cosmos DB. O Cosmos DB é um serviço de banco de dados multimodelo. Nesse cenário, o aplicativo de função busca a documentação no Azure Cosmos DB em resposta a solicitações HTTP GET do cliente.

Microsoft Entra ID (Microsoft Entra ID). Os usuários se conectam ao aplicativo da Web usando suas credenciais do Microsoft Entra ID. O Microsoft Entra ID retorna um token de acesso para a API, que o aplicativo Web utiliza para autenticar as solicitações de API (consulte Autenticação).

Azure Monitor. O Azure Monitor coleta métricas de desempenho sobre os serviços do Azure implantados na solução. Ao visualizá-las em um painel, você obtém informações sobre a integridade da solução. O Monitor também coletou logs de aplicativo.

Azure Pipelines. O Azure Pipelines é um serviço de CI (integração contínua) e CD (entrega contínua) que compila, testa e implanta o aplicativo.

GitHub Actions. O Workflow é um processo automatizado (CI/CD) que você configura no repositório do GitHub. Você pode criar, testar, empacotar, lançar ou implantar qualquer projeto no GitHub com um fluxo de trabalho.

Detalhes do cenário

Possíveis casos de uso

Essa solução de entrega por Drone é ideal para os setores de aeronaves, aviação, aeroespacial e robótica.

Recomendações

Planos do Aplicativo de funções

O Azure Functions dá suporte a dois modelos de hospedagem. O plano de consumo aloca automaticamente a potência de computação quando o código estiver em execução. Com o plano de Serviço de Aplicativo, um conjunto de VMs é alocado para seu código. O plano de Serviço de Aplicativo define o número de VMs e o tamanho da VM.

Observe que o plano de Serviço de Aplicativo não é estritamente sem servidor, de acordo com a definição fornecida acima. O modelo de programação é o mesmo, porém, o mesmo código de função pode ser executado em um plano de consumo e em um Plano do Serviço de Aplicativo.

Veja alguns fatores a serem considerados ao escolher qual tipo de plano usar:

• Inicialização a frio. Com o plano de consumo, uma função que não foi invocada recentemente incorre em alguma latência adicional na próxima vez que for executada. A latência adicional ocorre devido à alocação e à preparação do ambiente de runtime. Normalmente, demora segundos, mas depende de vários fatores, incluindo o número de dependências que precisam ser carregadas. Para saber mais, confira Noções básicas sobre a inicialização a frio sem servidor. Normalmente, a inicialização a frio é uma preocupação para cargas de trabalho interativas (gatilhos HTTP) do que para cargas de trabalho assíncronas orientadas a mensagem (gatilhos de fila ou hubs de evento), pois a latência adicional é observada diretamente pelos usuários.
• Tempo limite. Em um plano de consumo, o tempo de execução de uma função expira após um período configurável (até 10 minutos, no máximo)
• Isolamento da rede virtual. O uso de um plano de Serviço de Aplicativo permite a execução das funções dentro de um Ambiente de Serviço de Aplicativo, que é um ambiente de hospedagem dedicado e isolado.
• Modelo de preços. O plano de consumo é cobrado pelo número de execuções e pelo consumo de recursos (memória × tempo de execução). O plano de Serviço de Aplicativo é cobrado por hora com base no SKU da instância da VM. Geralmente, o plano de consumo é mais barato que um plano de Serviço de Aplicativo, pois você paga apenas pelos recursos de computação que usar. Principalmente se o tráfego apresentar picos e ciclos. No entanto, se um aplicativo apresentar uma taxa de transferência de alto volume constante, um plano de Serviço de Aplicativo poderá custar menos do que o plano de consumo.
• Dimensionamento. Uma grande vantagem do modelo de consumo é que ele se ajusta dinamicamente conforme o necessário, com base no tráfego de entrada. Embora esse dimensionamento ocorra rapidamente, ainda há um período de crescimento. Para algumas cargas de trabalho, convém sobreprovisionar deliberadamente as VMs, para que você possa lidar com picos de tráfego com um tempo de crescimento nulo. Nesse caso, considere um plano de Serviço de Aplicativo.

Limites do Aplicativo de funções

Um aplicativo de funções hospeda a execução de uma ou mais funções. Use um aplicativo de funções para agrupar várias funções como uma unidade lógica. Dentro de um aplicativo de funções, as funções compartilham as mesmas configurações de aplicativo, plano de hospedagem e ciclo de vida de implantação. Cada aplicativo de funções tem seu próprio nome de host.

Use os aplicativos de função para agrupar funções que compartilham o mesmo ciclo de vida e configurações. Funções que não compartilham o mesmo ciclo de vida devem ser hospedadas em aplicativos de funções diferentes.

Analise o uso de uma abordagem de microsserviços, em que cada aplicativo de funções representa um microsserviço, possivelmente composto por várias funções relacionadas. Em uma arquitetura de microsserviços, os serviços devem ter um acoplamento flexível e alta coesão funcional. O acoplamento flexível significa que você pode alterar um serviço sem a necessidade de atualizar simultaneamente outros serviços. Coesão significa que um serviço tem uma finalidade única e bem definida. Para saber mais sobre essas ideias, confira Criação de microsserviços: análise de domínio.

Associações de função

Use as associações do Functions quando possível. As associações fornecem uma maneira declarativa de conectar seu código aos dados e integrá-los a outros serviços do Azure. Uma associação de entrada preenche um parâmetro de entrada de uma fonte de dados externa. Uma associação de saída envia o valor de retorno da função para um coletor de dados, como uma fila ou um banco de dados.

Por exemplo, a função GetStatus na implementação de referência usa a associação de entrada do Azure Cosmos DB. Essa associação é configurada para procurar um documento no Azure Cosmos DB, utilizando os parâmetros de consulta que são retirados da cadeia de caracteres de consulta na solicitação HTTP. Se o documento for encontrado, ele será passado para a função como um parâmetro.

[FunctionName("GetStatusFunction")]
public static Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
    [CosmosDB(
        databaseName: "%COSMOSDB_DATABASE_NAME%",
        collectionName: "%COSMOSDB_DATABASE_COL%",
        ConnectionStringSetting = "COSMOSDB_CONNECTION_STRING",
        Id = "{Query.deviceId}",
        PartitionKey = "{Query.deviceId}")] dynamic deviceStatus,
    ILogger log)
{
    ...
}

Ao usar associações, você não precisa escrever um código para se comunicar diretamente com o serviço, o que simplifica o código de função e também abstrai os detalhes da fonte de dados ou do coletor. Porém, em alguns casos, talvez você precise de uma lógica mais complexa do que a fornecida pela associação. Nesse caso, use os SDKs do cliente do Azure diretamente.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Escalabilidade

Funções. Para o plano de consumo, o gatilho HTTP é dimensionado com base no tráfego. Há um limite para o número de instâncias simultâneas de função, mas cada instância pode processar mais de uma solicitação por vez. No caso de um plano de Serviço de Aplicativo, o gatilho HTTP é dimensionado de acordo com o número de instâncias de VM, que pode ser um valor fixo ou dimensionado automaticamente com base em um conjunto de regras de dimensionamento automático. Para saber mais, confira Escala e hospedagem do Azure Functions.

Azure Cosmos DB. A capacidade de taxa de transferência do Azure Cosmos DB é medida em Unidades de Solicitação (RU). Uma taxa de transferência de 1-RU corresponde à taxa de transferência exigida para obter (GET) um documento de 1 KB. Para escalar um contêiner do Azure Cosmos DB além de 10.000 RU, você deve especificar uma chave de partição quando você criar o contêiner e incluir a chave de partição em cada documento criado. Para saber mais sobre chaves de particionamento, confira Particionar e dimensionar no Azure Cosmos DB.

Gerenciamento de API. O Gerenciamento de API permite escalar horizontalmente e dá suporte ao dimensionamento automático baseado em regra. O processo de dimensionamento demora pelo menos 20 minutos. Se o tráfego for intermitente, provisione para o tráfego intermitente máximo esperado. No entanto, o dimensionamento automático é útil para lidar com variações por hora ou dia no tráfego. Para saber mais, confira Escalar automaticamente uma instância do Gerenciamento de API do Azure.

Recuperação de desastre

A implantação exibida aqui reside em uma única região do Azure. Para uma abordagem mais resiliente à recuperação de desastres, aproveite os recursos de distribuição geográfica de vários serviços:

• O Gerenciamento de API oferece suporte à implantação multirregião, que pode ser usada para distribuir uma única instância de Gerenciamento de API por qualquer quantidade de regiões do Azure. Para obter mais informações, consulte Como implantar uma instância do serviço de Gerenciamento de API do Azure em várias regiões do Azure.

• Use o Gerenciador de Tráfego para rotear as solicitações HTTP para a região primária. Se o Aplicativo de Funções nessa região ficar indisponível, o Gerenciador de Tráfego realizará o failover para a região secundária.

• O Azure Cosmos DB dá suporte a várias regiões de gravação, o que permite gravar em qualquer região que você adicionar à sua conta do Azure Cosmos DB. Se você não habilitar várias gravações, ainda poderá fazer o failover da região de gravação primária. Os SDKs do cliente do Azure Cosmos DB e as associações do Azure Function lidam automaticamente com o failover, portanto você não precisa atualizar nenhuma configuração do aplicativo.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Autenticação

A API GetStatus na implementação de referência utiliza o Microsoft Entra ID para autenticar as solicitações. O Microsoft Entra ID dá suporte ao protocolo OpenID Connect, que é um protocolo de autenticação criado com base no protocolo OAuth 2.

Nessa arquitetura, o aplicativo cliente é um aplicativo de página única (SPA) executado no navegador. Esse tipo de aplicativo cliente não consegue ocultar o segredo de um cliente ou um código de autorização, por isso o fluxo de concessão implícita é apropriado. (Confira Qual fluxo de OAuth 2.0 devo usar?). Veja o fluxo geral:

1. O usuário clica no link "Entrar" no aplicativo Web.
2. O navegador é redirecionado para a página de entrada do Microsoft Entra.
3. O usuário entra.
4. O Microsoft Entra ID redireciona de volta para o aplicativo cliente, incluindo um token de acesso a aplicativos no fragmento da URL.
5. Quando o aplicativo Web chama a API, ele inclui o token de acesso no cabeçalho de Autenticação. A ID do aplicativo é enviada como a declaração "aud" (público) no token de acesso.
6. A API de back-end valida o token de acesso.

Para configurar a autenticação:

• Registrar um aplicativo no seu locatário do Microsoft Entra. Isso gera uma ID de aplicativo, que é incluída pelo cliente com a URL de logon.

• Habilita a autenticação do Microsoft Entra dentro do Aplicativo de Funções. Para saber mais, confira Autenticação e autorização no Serviço de Aplicativo do Azure.

• Adicione validate-jwt policy ao Gerenciamento de API para pré-autorizar a solicitação validando o token de acesso.

Para saber mais, confira o Leiame do GitHub.

Recomenda-se criar registros de aplicativos separados no Microsoft Entra ID para o aplicativo cliente e a API de back-end. Conceda permissão ao aplicativo cliente para chamar a API. Essa abordagem lhe dá a flexibilidade para definir várias APIs e clientes e controlar as permissões de cada um.

Na API, use escopos para fornecer aos aplicativos um controle refinado sobre quais permissões eles solicitam de um usuário. Por exemplo, uma API pode ter os escopos Read e Write, e um aplicativo cliente específico pode solicitar que o usuário autorize apenas as permissões Read.

Autorização

Em muitos aplicativos, a API de back-end deve verificar se um usuário tem permissão para executar uma determinada ação. Recomenda-se usar a autorização baseada em declarações, em que as informações sobre o usuário são transmitidas pelo provedor de identidade (neste caso, o Microsoft Entra ID) e utilizadas para tomar decisões sobre autorização. Por exemplo, ao registrar um aplicativo no Microsoft Entra ID, você pode definir um conjunto de funções do aplicativo. Quando um usuário entra no aplicativo, o Microsoft Entra ID inclui uma declaração roles para cada função concedida ao usuário, incluindo as funções herdadas por meio da associação a um grupo.

O token de ID que o Microsoft Entra ID retorna para o cliente contém algumas das declarações do usuário. No aplicativo de funções, essas declarações estão disponíveis no cabeçalho X-MS-CLIENT-PRINCIPAL da solicitação. No entanto, é mais simples ler essas informações de dados de associação. Para outras declarações, use Microsoft Graph para consultar o Microsoft Entra ID. (O usuário deve consentir com essa ação ao entrar.)

Para obter mais informações, consulte Trabalhar com identidades de cliente.

CORS

Nessa arquitetura de referência, o aplicativo Web e a API não compartilham a mesma origem. Isso significa que, quando o aplicativo chama a API, essa solicitação ocorre entre origens. A segurança do navegador impede que uma página da Web envie solicitações do AJAX para outro domínio. Essa restrição se chama política da mesma origem e impede que um site mal-intencionado leia dados confidenciais de outro site. Para habilitar uma solicitação entre origens, adicione uma política CORS (Compartilhamento de recursos entre origens) para o gateway de Gerenciamento de API:

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

Neste exemplo, o atributo allow-credentials é true. Isso autoriza o navegador a enviar credenciais (incluindo cookies) com a solicitação. Caso contrário, o navegador envia, por padrão, as credenciais com uma solicitação entre origens.

Impor HTTPS

Para obter o máximo de segurança, exija HTTPS em todo o pipeline de solicitações:

• CDN. A CDN do Azure oferece suporte a HTTPS em um subdomínio *.azureedge.net por padrão. Para habilitar HTTPS na CDN para nomes de domínio personalizados, confira Tutorial: Configurar o HTTPS em um domínio personalizado de CDN do Azure.

• Hospedagem de sites estáticos. Habilite a opção "Transferência segura obrigatória" na conta de armazenamento. Quando essa opção estiver habilitada, a conta de armazenamento permitirá apenas solicitações de conexões HTTPS seguras.

• Gerenciamento de API. Configure as APIs para usar somente o protocolo HTTPS. Configure isso no portal do Azure ou usando o modelo do Resource Manager:

  {
      "apiVersion": "2018-01-01",
      "type": "apis",
      "name": "dronedeliveryapi",
      "dependsOn": [
          "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
      ],
      "properties": {
          "displayName": "Drone Delivery API",
          "description": "Drone Delivery API",
          "path": "api",
          "protocols": [ "HTTPS" ]
      },
      ...
  }
  

• Azure Functions. Habilite a configuração "Somente HTTPS".

Bloquear o aplicativo de funções

Todas as chamadas para a função devem passar pelo gateway de API. Você pode fazer isso da seguinte maneira:

• Configure o aplicativo de funções para exigir uma chave de função. O gateway de Gerenciamento de API inclui a tecla de função quando ela chamar o aplicativo de funções. Isso impede que os clientes chamem a função diretamente, ignorando o gateway.

• O gateway do Gerenciamento de API tem um endereço IP estático. Restrinja o Azure Functions para permitir apenas chamadas desse endereço IP estático. Para obter mais informações, consulte Restrições de IP estático do Serviço de Aplicativo do Azure. (Esse recurso está disponível apenas para serviços do tipo Standard.)

Proteger segredos do aplicativo

Não armazene segredos do aplicativo, como credenciais de banco de dados, nos arquivos de configuração ou código. Em vez disso, use as Configurações do Aplicativo, que estão armazenadas criptografadas no Azure. Para saber mais, confira Segurança no Serviço de Aplicativo do Azure e no Azure Functions.

Como alternativa, armazene segredos do aplicativo no Key Vault. Isso permite que você centralize o armazenamento de segredos, controle sua distribuição e monitore como e quando os segredos são acessados. Para saber mais, confira Configurar um aplicativo Web do Azure para ler um segredo do Key Vault. No entanto, observe que os gatilhos e associações do Functions carregam suas definições de configuração das configurações do aplicativo. Não há modos internos para configurar os gatilhos e associações para usar segredos do Key Vault.

DevOps

Implantação de front-end

O front-end dessa arquitetura de referência é um aplicativo de página única, com JavaScript que acessa as APIs de back-end sem servidor e conteúdo estático que fornece uma experiência rápida do usuário. Veja a seguir algumas considerações importantes para esse aplicativo:

• Implante o aplicativo uniformemente para usuários em uma ampla área geográfica com uma CDN pronta para o mundo, com o conteúdo estático hospedado na nuvem. Isso evita a necessidade de um servidor Web dedicado. Leia Integrar uma conta de Armazenamento do Azure à CDN do Azure para começar. Proteja seu aplicativo com HTTPS. Leia as Práticas recomendadas para usar redes de distribuição de conteúdo para obter recomendações adicionais.
• Use um serviço de CI/CD rápido e confiável, como o Azure Pipelines ou o GitHub Actions, para compilar e implantar automaticamente cada alteração de origem. A origem deve residir em um sistema de controle de versão online. Para obter mais detalhes sobre o Azure Pipelines, leia Criar seu primeiro pipeline. Para saber mais sobre o GitHub Actions para o Azure, consulte Implantar aplicativos no Azure.
• Compacte os arquivos do site para reduzir o consumo de largura de banda na CDN e melhorar o desempenho. A CDN do Azure permite a compactação em tempo real nos servidores de borda. Como alternativa, o pipeline de implantação nesta arquitetura de referência compacta os arquivos antes de implantá-los no armazenamento de Blobs. Isso reduz o requisito de armazenamento e oferece mais liberdade para escolher as ferramentas de compactação, independentemente de quaisquer limitações de CDN.
• A CDN deve ser capaz de limpar seu cache para garantir que todos os usuários sejam atendidos com o conteúdo mais recente. Uma limpeza de cache será necessária se os processos de compilação e implantação não forem atômicos, por exemplo, se eles substituírem arquivos antigos por recém-criados na mesma pasta de origem.
• Uma estratégia de cache diferente, como o controle de versão usando diretórios, pode não exigir uma limpeza da CDN. O pipeline de build neste aplicativo de front-end cria um novo diretório para cada versão recém-criada. Essa versão é carregada como uma unidade atômica no armazenamento de Blobs. A CDN do Azure aponta para essa nova versão somente após uma implantação concluída.
• Aumente a TTL de cache armazenando arquivos de recurso em cache por uma duração maior, com abrangência de meses. Para garantir que os arquivos armazenados em cache sejam atualizados quando forem alterados, faça a impressão digital dos nomes de arquivo quando eles forem reconstruídos. Esse aplicativo front-end faz impressões digitais de todos os arquivos, exceto para arquivos públicos, como index.html. Como o index.html é atualizado com frequência, ele reflete os nomes de arquivo alterados que causam uma atualização de cache. Consulte o Gerenciamento de expiração de conteúdo da Web na CDN do Azure para obter mais informações.

Implantação de back-end

Para implantar o aplicativo de funções, é recomendável usar arquivos de pacote (“Execução a partir do pacote”). Usando essa abordagem, você carrega um arquivo zip em um contêiner de Armazenamento de Blobs e o runtime das Funções monta o arquivo zip como um sistema de arquivos somente leitura. Essa é uma operação atômica, o que reduz a chance de uma implantação com falhas deixar o aplicativo em um estado inconsistente. Também é possível melhorar os tempos de inicialização a frio, especialmente para aplicativos Node.js, já que todos os arquivos são trocados ao mesmo tempo.

Controle de versão de API

Uma API é um contrato entre um serviço e os clientes. Nessa arquitetura, o contrato de API é definido na camada de Gerenciamento de API. O Gerenciamento de API oferece suporte a dois conceitos de controle de versão distintos, mas complementares:

• As versões permitem que os consumidores escolham uma versão de API com base nas necessidades, como v1 vs. v2.

• Revisões permitem que os administradores de API façam alterações sem interrupções em uma API e implantem essas alterações, juntamente com um log de alterações para informar aos consumidores da API sobre as alterações.

Se você fizer uma alteração significativa em uma API, publique uma nova versão no Gerenciamento de API. Implante a nova versão lado a lado da versão original em um Aplicativo de funções separado. Isso permite que você migre clientes existentes para a nova API sem invalidar os aplicativos cliente. Por fim, substitua a versão anterior. O Gerenciamento de API dá suporte a vários esquemas de controle de versão: caminho de URL, cabeçalho HTTP ou a cadeia de consulta. Para obter mais informações sobre o controle de versão de API, confira Controle de versão de uma API da Web RESTful.

Para atualizações que não são alterações da falha na API, implante a nova versão em um slot de preparo no mesmo Aplicativo de funções. Verifique se a implantação foi bem-sucedida e, em seguida, troque a versão de preparo pela versão de produção. Publique uma revisão no Gerenciamento de API.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Use a Calculadora de Preços do Azure para estimar os custos. Considere esses pontos para otimizar o custo dessa arquitetura.

Funções do Azure

O Azure Functions dá suporte a dois modelos de hospedagem.

• Plano de consumo.

  O poder de computação é alocado automaticamente quando o código está em execução.

• Plano do Serviço de Aplicativo.

  Um conjunto de VMs é alocado para seu código. Esse plano define o número de VMs e o tamanho da VM.

Nessa arquitetura, uma função é chamada quando um cliente faz uma solicitação HTTP. Como uma taxa de transferência constante de alto volume não é esperada nesse caso de uso, o plano de consumo é recomendado porque você paga apenas pelos recursos de computação usados.

Azure Cosmos DB

O Azure Cosmos DB é cobrado de acordo com a taxa de transferência provisionada e o armazenamento consumido por hora. A taxa de transferência provisionada é expressa em RU/s (Unidades de Solicitação por segundo), que podem ser usadas para operações típicas de banco de dados, como inserções, leituras. O preço é baseado na capacidade em RU/s que você reserva.

O armazenamento é cobrado para cada GB usado para seus dados armazenados e índice.

Consulte Modelo de preços do Azure Cosmos DB para obter mais informações.

Nessa arquitetura, o aplicativo de função busca documentos do Azure Cosmos DB em resposta a as solicitações HTTP GET do cliente. O Azure Cosmos DB é econômico nesse caso porque as operações de leitura são significativamente mais baratas do que as operações de gravação expressas em RU/s.

Rede de Distribuição de Conteúdo

A taxa de cobrança pode ser diferente dependendo da região de cobrança com base no local do servidor de origem que fornece o conteúdo para o usuário final. O local físico do cliente não é considerado a região de cobrança. Qualquer solicitação de HTTP ou HTTPS que atinge a CDN é um evento faturável, o que inclui todos os tipos de resposta: êxito, falha ou outro. Diferentes respostas podem gerar quantidades diferentes de tráfego.

Nessa arquitetura de referência, a implantação reside em uma única região do Azure.

Para reduzir os custos, considere aumentar a TTL de cache armazenando arquivos de recurso em cache por uma duração mais longa e definir o TTL mais longo possível em seu conteúdo.

Para obter mais informações, confira a seção de custo em Microsoft Azure Well-Architected Framework.

Implantar este cenário

Para implantar a implementação de referência para essa arquitetura, consulte o leiame do GitHub.

Próximas etapas

Documentação do produto:

• O que é o Armazenamento de Blobs do Azure?
• CDN (Rede de Distribuição de Conteúdo) do Azure
• Introdução ao Azure Functions
• Sobre o Gerenciamento de API
• Bem-vindo(a) ao Azure Cosmos DB
• Microsoft Entra ID
• Visão geral do Azure Monitor
• O que é o Azure Pipelines?

Módulos do Learn:

• Escolher a melhor tecnologia sem servidor do Azure para seu cenário empresarial
• Criar uma lógica sem servidor com o Azure Functions

Recursos relacionados

Para saber mais sobre a implementação de referência, leia o passo a passo do código: aplicativo sem servidor com Azure Functions.

Diretrizes relacionadas:

• Práticas recomendadas para o uso de CDNs
• Padrão de hospedagem de conteúdo estático