Aplicação web sem servidor

Esta arquitetura de referência mostra um aplicativo Web sem servidor. O aplicativo serve conteúdo estático do Armazenamento de Blobs do Azure e implementa uma API usando o Azure Functions. A API lê 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

Transfira um ficheiro do Visio desta arquitetura.

O termo serverless tem dois significados distintos, mas relacionados:

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

Ambas as definições têm em comum a ideia de que os desenvolvedores e o pessoal de DevOps não precisam implantar, configurar ou gerenciar servidores. Essa arquitetura de referência se concentra em FaaS usando o Azure Functions, embora o fornecimento de conteúdo da Web do Armazenamento de Blobs do Azure possa ser um exemplo de BaaS. Algumas características importantes do FaaS são:

1. Os recursos de computação são alocados dinamicamente conforme a necessidade da plataforma.
2. Preços baseados no consumo: você é cobrado apenas pelos recursos de computação usados para executar seu código.
3. Os recursos de computação são dimensionados sob demanda com base no tráfego, sem que o desenvolvedor precise fazer qualquer configuração.

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

Componentes

A arquitetura é composta pelos seguintes componentes:

Armazenamento de Blob. O conteúdo estático da Web, como arquivos HTML, CSS e JavaScript, é armazenado no Armazenamento de Blobs do Azure e servido aos clientes usando a hospedagem estática de sites. Toda a interação dinâmica acontece por meio de chamadas de código JavaScript para as APIs de back-end. Não há nenhum código do lado do servidor para renderizar a página da Web. A hospedagem estática de sites suporta documentos de índice e páginas de erro 404 personalizadas.

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

Aplicativos de função. O Azure Functions é uma opção de computação sem servidor. Ele usa um modelo controlado por eventos, onde um pedaço 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 do Azure fornece um gateway de API que fica na frente da função HTTP. Você pode usar o Gerenciamento de API para publicar e gerenciar APIs usadas por aplicativos cliente. O uso de um gateway ajuda a dissociar o aplicativo front-end das APIs back-end. Por exemplo, o Gerenciamento de API pode reescrever URLs, transformar solicitações antes que elas cheguem ao 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 preocupações transversais, como:

• Aplicação de quotas de utilização e limites de taxas
• Validando tokens OAuth para autenticação
• Habilitando solicitações de origem cruzada (CORS)
• Armazenamento em cache de respostas
• Monitoramento e registro de solicitações

Se você não precisar de todas as funcionalidades fornecidas pelo Gerenciamento de API, outra opção é usar Proxies de Funções. Esse recurso do Azure Functions permite definir uma única superfície de API para vários aplicativos de função, criando rotas para funções 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íticas do Gerenciamento de API.

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

Microsoft Entra ID (Microsoft Entra ID ). Os usuários entram no aplicativo Web usando suas credenciais de ID do Microsoft Entra. O Microsoft Entra ID retorna um token de acesso para a API, que o aplicativo Web usa para autenticar 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á-los em um painel, você pode obter visibilidade sobre a integridade da solução. Ele também coletou logs de aplicativos.

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

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

Detalhes do cenário

Potenciais casos de utilização

Esta solução de entrega de drones é ideal para as indústrias aeronáutica, aeronáutica, aeroespacial e robótica.

Recomendações

Planos do aplicativo de função

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

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

Aqui estão alguns fatores a considerar ao escolher qual tipo de plano usar:

• Arranque a frio. Com o plano de consumo, uma função que não tenha sido invocada recentemente incorrerá em alguma latência adicional na próxima vez que for executada. Essa latência adicional é devido à alocação e preparação do ambiente de tempo de execução. Geralmente é da ordem dos segundos, mas depende de vários fatores, incluindo o número de dependências que precisam ser carregadas. Para obter mais informações, consulte Understanding Serverless Cold Start. O arranque a frio é geralmente mais uma preocupação para cargas de trabalho interativas (gatilhos HTTP) do que cargas de trabalho assíncronas orientadas por mensagem (gatilhos de fila ou hubs de eventos), porque a latência adicional é observada diretamente pelos usuários.
• Período de tempo limite. No plano de consumo, a execução de uma função expira após um período de tempo configurável (até um máximo de 10 minutos)
• Isolamento de rede virtual. O uso de um plano do Serviço de Aplicativo permite que as funções sejam executadas dentro de um Ambiente do Serviço de Aplicativo, que é um ambiente de hospedagem dedicado e isolado.
• Modelo de precificação. O plano de consumo é faturado pelo número de execuções e consumo de recursos (memória × tempo de execução). O plano do Serviço de Aplicativo é cobrado por hora com base na SKU da instância da VM. Muitas vezes, o plano de consumo pode ser mais barato do que um plano do Serviço de Aplicativo, porque você paga apenas pelos recursos de computação que usa. Isto é especialmente verdadeiro se o seu tráfego tiver picos e vales. No entanto, se um aplicativo tiver uma taxa de transferência constante de alto volume, um plano do Serviço de Aplicativo poderá custar menos do que o plano de consumo.
• Dimensionamento. Uma grande vantagem do modelo de consumo é que ele é dimensionado dinamicamente conforme necessário, com base no tráfego de entrada. Embora esse escalonamento ocorra rapidamente, ainda há um período de ramp-up. Para algumas cargas de trabalho, talvez você queira provisionar deliberadamente as VMs, para que possa lidar com picos de tráfego com tempo de ramp-up zero. Nesse caso, considere um plano do Serviço de Aplicativo.

Limites do aplicativo de função

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

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

Considere adotar uma abordagem de microsserviços, em que cada aplicativo de função representa um microsserviço, possivelmente consistindo em várias funções relacionadas. Numa arquitetura de microsserviços, os serviços devem ter um acoplamento flexível e uma elevada coesão funcional. Acoplamento flexível significa que você pode alterar um serviço sem exigir que outros serviços sejam atualizados ao mesmo tempo. Coeso significa que um serviço tem um único propósito bem definido. Para obter mais discussões sobre essas ideias, consulte Projetando microsserviços: análise de domínio.

Ligações de função

Use associações de funções quando possível. As associações fornecem uma maneira declarativa de conectar seu código aos dados e integrar-se 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 banco de dados.

Por exemplo, a GetStatus função na implementação de referência usa a associação de entrada do Azure Cosmos DB. Essa associação é configurada para pesquisar um documento no Azure Cosmos DB, usando 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.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

Usando associações, você não precisa escrever código que fala diretamente com o serviço, o que torna o código da função mais simples e também abstrai os detalhes da fonte de dados ou coletor. Em alguns casos, no entanto, você pode precisar de uma lógica mais complexa do que a vinculação fornece. Nesse caso, use os SDKs de cliente do Azure diretamente.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte 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 de função simultâneas, mas cada instância pode processar mais de uma solicitação de cada vez. Para um plano do 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 pode ser dimensionado automaticamente com base em um conjunto de regras de dimensionamento automático. Para obter informações, consulte Dimensionamento 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 necessária para OBTER um documento de 1KB. Para dimensionar um contêiner do Azure Cosmos DB para além de 10.000 RU, você deve especificar uma chave de partição ao criar o contêiner e incluir a chave de partição em cada documento criado. Para obter mais informações sobre chaves de partição, consulte Particionar e dimensionar no Azure Cosmos DB.

Gerenciamento de API. O Gerenciamento de API pode ser dimensionado e oferece suporte ao dimensionamento automático baseado em regras. O processo de dimensionamento leva pelo menos 20 minutos. Se o seu tráfego estiver estourado, você deve provisionar o tráfego de intermitência máximo esperado. No entanto, o dimensionamento automático é útil para lidar com variações horárias ou diárias no tráfego. Para obter mais informações, consulte Dimensionar automaticamente uma instância de Gerenciamento de API do Azure.

Recuperação após desastre

A implantação mostrada 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 nos vários serviços:

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

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

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

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

Autenticação

A GetStatus API na implementação de referência usa o Microsoft Entra ID para autenticar solicitações. O Microsoft Entra ID suporta o protocolo OpenID Connect, que é um protocolo de autenticação construído sobre o protocolo OAuth 2.

Nessa arquitetura, o aplicativo cliente é um aplicativo de página única (SPA) que é executado no navegador. Esse tipo de aplicativo cliente não pode manter um segredo do cliente ou um código de autorização oculto, portanto, o fluxo de concessão implícito é apropriado. (Ver Qual fluxo OAuth 2.0 devo usar?). Aqui está 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 utilizador inicia sessão.
4. O Microsoft Entra ID redireciona de volta para o aplicativo cliente, incluindo um token de acesso no fragmento de URL.
5. Quando o aplicativo Web chama a API, ele inclui o token de acesso no cabeçalho Autenticação. O ID do aplicativo é enviado como a declaração de audiência ('aud') no token de acesso.
6. A API de back-end valida o token de acesso.

Para configurar a autenticação:

• Registe uma aplicação no seu inquilino do Microsoft Entra. Isso gera um ID de aplicativo, que o cliente inclui com a URL de login.

• Habilite a autenticação do Microsoft Entra dentro do aplicativo Function. Para obter mais informações, veja Autenticação e autorização no Serviço de Aplicações do Azure.

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

Para obter mais detalhes, consulte o Leiame do GitHub.

É recomendável criar registros de aplicativo 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 oferece a flexibilidade de definir várias APIs e clientes e controlar as permissões para cada um.

Dentro de uma API, use escopos para dar aos aplicativos controle refinado sobre quais permissões eles solicitam de um usuário. Por exemplo, uma API pode ter Read e Write escopos, e um aplicativo cliente específico pode pedir ao usuário para autorizar Read apenas permissões.

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 o uso de autorização baseada em declarações, onde as informações sobre o usuário são transmitidas pelo provedor de identidade (neste caso, Microsoft Entra ID) e usadas para tomar decisões de autorização. Por exemplo, quando você registra um aplicativo no Microsoft Entra ID, você pode definir um conjunto de funções de aplicativo. Quando um usuário entra no aplicativo, a ID do Microsoft Entra inclui uma roles declaração para cada função que o usuário recebeu, incluindo funções herdadas por meio da associação ao grupo.

O token de ID que o Microsoft Entra ID retorna ao cliente contém algumas das declarações do usuário. No aplicativo de função, 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 a partir de dados de vinculação. Para outras declarações, use o 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 Trabalhando 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, é uma solicitação de origem cruzada. A segurança do browser impede que uma página Web realize pedidos de AJAX para outro domínio. Essa restrição é chamada de política de 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 de Compartilhamento de Recursos entre Origens (CORS) ao 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, por padrão, o navegador não envia credenciais com uma solicitação de origem cruzada.

Impor HTTPS

Para máxima segurança, exija HTTPS em todo o pipeline de solicitação:

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

• Alojamento estático de websites. Ative a opção "Transferência segura necessária" na conta de armazenamento. Quando essa opção está habilitada, a conta de armazenamento só permite solicitações de conexões HTTPS seguras.

• Gerenciamento de API. Configure as APIs para usar apenas o protocolo HTTPS. Você pode configurar isso no portal do Azure ou por meio de um modelo do Gerenciador de Recursos:

  {
      "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" ]
      },
      ...
  }
  

• Funções do Azure. Habilite a configuração "Somente HTTPS".

Bloquear a aplicação de funções

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

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

• O gateway de gerenciamento de API tem um endereço IP estático. Restrinja a Função do Azure 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. (Este recurso está disponível apenas para serviços de camada Standard.)

Proteger segredos da aplicação

Não armazene segredos do aplicativo, como credenciais de banco de dados, em seu código ou arquivos de configuração. Em vez disso, use as configurações do aplicativo, que são armazenadas criptografadas no Azure. Para obter mais informações, consulte Segurança no Serviço de Aplicativo do Azure e Azure Functions.

Como alternativa, você pode armazenar segredos do aplicativo no Cofre da Chave. Isso permite centralizar o armazenamento de segredos, controlar sua distribuição e monitorar como e quando os segredos estão sendo acessados. Para obter mais informações, consulte Configurar um aplicativo Web do Azure para ler um segredo do Cofre da Chave. No entanto, observe que os gatilhos e ligações do Functions carregam suas definições de configuração das configurações do aplicativo. Não há uma maneira interna de configurar os gatilhos e ligações para usar segredos do Cofre da Chave.

DevOps

Implantação front-end

O front-end dessa arquitetura de referência é um aplicativo de página única, com JavaScript acessando as APIs back-end sem servidor e conteúdo estático fornecendo uma experiência de usuário rápida. Seguem-se algumas considerações importantes para tal aplicação:

• Implante o aplicativo uniformemente para usuários em uma ampla área geográfica com uma CDN pronta para uso global, 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 com a 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 criar e implantar automaticamente todas as alterações de origem. A fonte 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 as Ações do GitHub para Azure, consulte Implantar aplicativos no Azure.
• Comprima os arquivos do seu site para reduzir o consumo de largura de banda na CDN e melhorar o desempenho. A CDN do Azure permite a compactação instantânea nos servidores de borda. Como alternativa, o pipeline de implantação nessa arquitetura de referência compacta os arquivos antes de implantá-los no armazenamento de Blob. Isso reduz os requisitos 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 recebam o conteúdo mais recente. Uma limpeza de cache é necessária se os processos de compilação e implantação não forem atômicos, por exemplo, se substituírem arquivos antigos por arquivos recém-criados na mesma pasta de origem.
• Uma estratégia de cache diferente, como versionamento usando diretórios, pode não exigir uma limpeza pela CDN. O pipeline de compilação neste aplicativo front-end cria um novo diretório para cada versão recém-criada. Esta versão é carregada como uma unidade atômica para o armazenamento de Blob. A CDN do Azure aponta para essa nova versão somente após uma implantação concluída.
• Aumente o TTL do cache armazenando em cache arquivos de recursos por um período mais longo, abrangendo meses. Para garantir que os arquivos armazenados em cache sejam atualizados quando forem alterados, imprima a impressão digital dos nomes dos arquivos quando eles forem reconstruídos. Este aplicativo front-end imprime impressões digitais de todos os arquivos, exceto arquivos voltados para o público, como index.html. Como o index.html é atualizado com frequência, ele reflete os nomes de arquivos alterados causando uma atualização de cache. Consulte Gerir a expiração de conteúdo Web na CDN do Azure para obter mais informações.

Implantação de back-end

Para implantar o aplicativo de função, recomendamos o uso de arquivos de pacote ("Executar a partir do pacote"). Usando essa abordagem, você carrega um arquivo zip para um contêiner de Armazenamento de Blob e o tempo de execução do Functions monta o arquivo zip como um sistema de arquivos somente leitura. Esta é uma operação atômica, que reduz a chance de que uma implantação com falha deixe o aplicativo em um estado inconsistente. Também pode melhorar os tempos de arranque a frio, especialmente para aplicações Node.js, porque todos os ficheiros são trocados de uma só vez.

Controlo de versões de API

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

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

• As revisões permitem que os administradores de API façam alterações contínuas em uma API e implantem essas alterações, juntamente com um log de alterações para informar os 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 com a versão original, em um aplicativo de função separado. Isso permite migrar clientes existentes para a nova API sem interromper os aplicativos cliente. Eventualmente, você pode depreciar a versão anterior. O Gerenciamento de API suporta vários esquemas de controle de versão: caminho de URL, cabeçalho HTTP ou cadeia de caracteres de consulta. Para obter mais informações sobre o controle de versão da API em geral, consulte Controle de versão de uma API da Web RESTful.

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

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

Utilize a calculadora de preços do Azure para prever 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 Aplicações.

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

Nessa arquitetura, uma função é invocada quando um cliente faz uma solicitação HTTP. Como uma taxa de transferência constante de alto volume não é esperada neste 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 cobra a taxa de transferência provisionada e o armazenamento consumido por hora. A taxa de transferência provisionada é expressa em Unidades de Solicitação por segundo (RU/s), que podem ser usadas para operações típicas de banco de dados, como inserções e leituras. O preço é baseado na capacidade em RU/s que você reserva.

O armazenamento é cobrado por cada GB usado para os dados armazenados e o í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 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 Entrega de Conteúdos

A taxa de cobrança pode variar dependendo da região de faturamento com base no local do servidor de origem que entrega o conteúdo ao usuário final. A localização física do cliente não é a região de cobrança. Qualquer solicitação HTTP ou HTTPS que atinge a CDN é um evento faturável, que inclui todos os tipos de resposta: sucesso, falha ou outros. Respostas diferentes podem gerar quantidades de tráfego diferentes.

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

Para reduzir os custos, considere aumentar o TTL de cache armazenando em cache arquivos de recursos por um período mais longo e definindo o TTL mais longo possível em seu conteúdo.

Para obter mais informações, consulte a seção Custo no Microsoft Azure Well-Architected Framework.

Implementar este cenário

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

Próximos passos

Documentação do produto:

• O que é o Armazenamento de Blobs do Azure?
• Rede de Entrega de Conteúdos (CDN) do Azure
• Introdução às Funções do Azure
• Sobre a Gestão de API
• Bem-vindo ao Azure Cosmos DB
• Microsoft Entra ID
• Descrição geral do Azure Monitor
• O que é o Azure Pipelines?

Aprenda módulos:

• Escolha a melhor tecnologia sem servidor do Azure para o seu cenário de negócios
• Criar lógica sem servidor com o Azure Functions

Recursos relacionados

Para saber mais sobre a implementação de referência, leia Code walkthrough: Serverless application with Azure Functions.

Orientações relacionadas:

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