Editar

Aplicativo Web inicial para desenvolvimento de SaaS

Serviço de aplicativo do Azure
ID externo do Microsoft Entra
Banco de Dados SQL do Azure
Aplicativos Lógicos do Azure
Azure Resource Manager

Software como Serviço (SaaS) é um tópico complexo com muitos pontos a serem considerados. Fornecedores de software independentes (ISVs) que criam soluções SaaS no Azure precisam resolver problemas e tomar decisões como:

  • Qual modelo de locação devo usar?
  • Como configurar uma solução de identidade para uso em uma arquitetura multilocatário?
  • Como posso lidar com a integração de novos clientes?

Essa arquitetura tem como objetivo responder a algumas dessas perguntas e fornecer um ponto de partida para o mundo do SaaS. Essa arquitetura é adaptável para se ajustar a uma ampla variedade de cenários.

Possíveis casos de uso

Veja a seguir alguns casos de uso de exemplo nos quais você pode usar essa arquitetura:

  • Modernizar um aplicativo existente para dar suporte à multilocação completa como parte de uma mudança para um modelo de negócios baseado em SaaS.
  • Desenvolver uma oferta de SaaS completamente nova.
  • Migrar uma oferta de SaaS de outro serviço de nuvem para o Azure.

Arquitetura

Diagrama de arquitetura que mostra o plano de controle, a estrutura de identidade e o aplicativo SaaS do usuário final.

Baixe um arquivo do PowerPoint dessa arquitetura.

Terminologia

A tabela a seguir descreve os termos que aparecem nesse artigo.

Termo Descrição Exemplo
Fornecedor de SaaS ou ISV A entidade que possui o aplicativo SaaS e o código e vende o produto SaaS. Contoso Inc, vendendo seu aplicativo SaaS: Contoso Tickets.
Locatário Uma instância comprada do aplicativo SaaS do Fornecedor SaaS. Fourth Coffee Shop.
Administrador de clientes SaaS Pessoas que compram ou administram um locatário de aplicativo. Joe, dono da Fourth Coffee Shop.
Usuário do cliente SaaS As pessoas que usam um locatário de aplicativo sem administrá-lo e geralmente pertencem à mesma empresa ou grupo que o administrador do cliente SaaS. Jill, gerente de eventos da Fourth Coffee Shop, e Susan, cliente da Fourth Coffee Shop.
Usuário final Um administrador do cliente SaaS, um usuário cliente SaaS ou qualquer outro tipo de usuário que seja introduzido. Esse é um termo genérico para descrever os usuários que entram no aplicativo. Joe, Jill e Susan são todos usuários finais (da perspectiva do ISV).
Aplicativo de front-end Qualquer aplicativo de front-end O aplicativo de administração & de integração e o aplicativo SaaS são aplicativos de front-end.

Workflow

  1. O administrador do cliente SaaS navega até o site hospedado no aplicativo de Administração & de integração.

  2. O administrador do cliente SaaS entra usando o fluxo de trabalho de entrada do usuário.

  3. O administrador do cliente SaaS conclui o fluxo de integração.

  4. O administrador do cliente SaaS navega até a área de administrador de locatários no aplicativo de administração &de integração e adiciona um Usuário do Cliente SaaS ao locatário recém-criado.

  5. O usuário do cliente SaaS navega até o aplicativo de aplicativo SaaS e usa o aplicativo SaaS.

Entrada do usuário

O fluxo de trabalho de entrada do usuário consiste nas seguintes etapas:

Diagrama de sequência que mostra o processo de entrada de um usuário.

  1. O usuário final navega até um aplicativo de front-end e seleciona um botão de Entrada.

  2. O aplicativo de front-end redireciona o usuário final para uma página de entrada hospedada pelo provedor de identidade.

  3. O Usuário Final insere informações da conta e envia o formulário de entrada para o Provedor de identidade.

  4. O provedor de identidadeemite uma solicitação POST com o endereço de email e a ID do objeto do usuário final para recuperar suas permissões e funções.

  5. A API de dados de permissão pesquisa as informações do usuário final no armazenamento de dados de permissão e retorna uma lista de permissões e funções atribuídas a esse usuário final.

  6. O provedor de identidade adiciona as permissões e funções como declarações personalizadas ao token da ID, que é um token Web JSON (JWT).

  7. O Provedor de identidade retorna um token da ID para o usuário final e inicia um redirecionamento para o aplicativo de front-end.

  8. O Usuário final é redirecionado para o ponto de extremidade de entrada no aplicativo de front-end e apresenta o token da ID.

  9. O aplicativo de front-end valida o token da ID apresentado.

  10. O aplicativo de front-end retorna uma página de entrada bem-sucedida e o usuário final agora está conectado.

Para obter mais informações sobre como esse fluxo de entrada funciona, consulte Protocolo OpenID Connect.

Como integrar um novo locatário

O fluxo de trabalho de integração de locatário consiste nas seguintes etapas:

Diagrama de sequência que mostra o processo de integração do locatário.

  1. O administrador do cliente SaaS navega até o aplicativo de administração & de integração e conclui um formulário de inscrição.

  2. O aplicativo de administração &de integração emite uma solicitação POST à API de dados do locatário para criar um novo locatário.

  3. A API de dados do locatário cria um novo locatário no armazenamento de dados do locatário.

  4. A API de dados do locatário emite uma solicitação POST à API de dados de permissão para conceder as permissões de administrador do cliente SaaS ao locatário recém-criado.

  5. A API de dados de permissão cria um novo registro de permissão no armazenamento de dados de permissão.

  6. A API de dados de permissão retorna com êxito.

  7. A API de dados do locatário retorna com êxito.

  8. O aplicativo de administração &de integração emite uma solicitação POST ao provedor de notificação por email para enviar uma mensagem de email "criada pelo locatário" para o Administrador do cliente SaaS.

  9. O provedor de notificação por email envia o email.

  10. O provedor de notificação por email retorna com êxito.

  11. O aplicativo de administração &de integração emite uma solicitação ao Provedor de identidade para atualizar o token da ID do administrador do cliente SaaS para que ele inclua uma declaração JWT para o locatário recém-criado.

  12. O Provedor de identidade emite uma solicitação POST com o endereço de email do administrador do cliente SaaS e a ID do objeto para recuperar suas permissões e funções.

  13. A API de dados de permissão pesquisa as informações do administrador do cliente SaaS no armazenamento de dados de permissão e retorna uma lista de permissões e funções atribuídas ao administrador do cliente SaaS.

  14. O Provedor de identidade adiciona as permissões e funções como declarações personalizadas ao token da ID.

  15. O Provedor de identidade retorna o token da ID para o Aplicativo de Administração &de Integração.

  16. O aplicativo de administração &de integração retorna uma mensagem de sucesso e um novo token da ID para o Administrador do Cliente SaaS.

Como adicionar um usuário a um locatário

A adição de um usuário a um fluxo de trabalho de locatário consiste nas seguintes etapas:

Diagrama de sequência que mostra a adição de um novo usuário a um locatário.

  1. O administrador do cliente SaaS solicita ver uma lista de locatários da área de administrador de locatários no aplicativo de administração & da integração.

  2. O aplicativo de administração& da integração emite uma solicitação GET para a API de dados do locatário para obter uma lista de locatários para o administrador do cliente SaaS.

  3. A API de dados de locatário emite uma solicitação GET para a API de dados de permissão para obter uma lista de locatários que o administrador do cliente SaaS tem acesso para exibir.

  4. A API de dados de permissão retorna uma lista de permissões de locatário.

  5. A API de dados do locatário pesquisa as informações do locatário no armazenamento de dados do locatário e retorna uma lista de dados de locatário com base na lista de permissões de locatário recebidas.

  6. O aplicativo de administração &de integração retorna a lista de dados de locatário para o administrador do cliente SaaS.

  7. O administrador do cliente SaaS seleciona um locatário na lista para adicionar um usuário do cliente SaaS e insere o endereço de email para o usuário do cliente SaaS.

  8. O aplicativo de administração &de integração emite uma solicitação POST à API de dados do locatário para adicionar uma permissão para o usuário do cliente SaaS no locatário especificado.

  9. A API de dados do locatário verifica se o administrador do cliente SaaS tem uma declaração JWT válida para o locatário especificado e tem a permissão de gravação do usuário.

  10. A API de dados do locatário emite uma solicitação POST à API de dados de permissão para adicionar uma permissão para o usuário do cliente SaaS no locatário especificado.

  11. A API de dados de permissão emite uma solicitação GET ao Provedor de identidade para procurar o usuário do cliente SaaS pelo endereço de email fornecido.

  12. O Provedor de identidade retorna a ID do objeto do usuário do cliente SaaS.

  13. A API de dados de permissão adiciona um registro de permissão no armazenamento de dados de permissão para o usuário do cliente SaaS no locatário especificado usando sua ID de objeto.

  14. A API de dados de permissão retorna com êxito.

  15. A API de dados do locatário retorna com êxito.

  16. O aplicativo de administração &de integração retorna com êxito.

Componentes

Essa arquitetura usa os seguintes serviços do Azure:

  • O Serviço de Aplicativo permite que você crie e hospede aplicativos Web e aplicativos de API na linguagem de programação escolhida sem a necessidade de gerenciar a infraestrutura.

  • O Azure Active Directory B2C habilita facilmente o gerenciamento de identidade e acesso para aplicativos de usuário final.

  • O Bando de Dados SQL do Azure é um serviço gerenciado de banco de dados relacional de propósito geral que suporta dados relacionais, dados espaciais, JSON e XML.

  • Os Aplicativos Lógicos do Azure permitem criar rapidamente integrações avançadas usando uma ferramenta de GUI simples.

Alternativas

A eficácia de qualquer escolha alternativa depende muito do modelo de locação com o qual você pretende que o aplicativo SaaS seja compatível. Veja a seguir alguns exemplos de abordagens alternativas que você pode seguir ao implementar esta solução:

  • A solução atual usa o Azure Active Directory B2C como provedor de identidade. Em vez disso, você pode usar outros provedores de identidade, como o Microsoft Entra ID.

  • Para requisitos mais rigorosos de segurança e conformidade, você pode optar por implementar a rede privada para comunicação entre serviços.

  • Em vez de usar chamadas REST entre serviços, você pode implementar um estilo de arquitetura controlado por eventos para mensagens entre serviços.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework​, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

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.

Essa solução depende da identidade como seu paradigma de segurança. A autenticação e a autorização para aplicativos Web e APIs são regidas pela plataforma de identidade da Microsoft, que é responsável por emitir e verificar tokens de ID do usuário (JWTs).

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.

Os componentes nessa solução têm algum custo associado à operação, mas o custo é modesto para a maioria dos aplicativos Web e soluções SaaS. Além disso, você pode controlar o custo gerenciando as seguintes configurações de recurso:

  • Você pode dimensionar o plano do Serviço de Aplicativo que executa o aplicativo para ajustar a taxa de transferência necessária. Além disso, você poderá executar cada aplicativo em um plano separado se precisar de uma taxa de transferência mais alta, mas incorrerá em um custo mais alto como resultado. Para saber mais, confira Visão geral do planos do Serviço de Aplicativo do Azure.

  • O Azure AD B2C fornece duas SKUs: Premium P1 e Premium P2. Ambos as SKUs incluem um subsídio gratuito para o número de MAUs (usuários ativos mensais), mas você precisa avaliar quais recursos cada SKU fornece para determinar quais são necessários para seu caso de uso. Para obter mais informações, confira Preços da ID Externa do Microsoft Entra.

  • O SQL do Azure tem vários modelos de compra para atender a uma ampla variedade de casos de uso, incluindo a capacidade de dimensionamento automático. Você precisa avaliar o uso em seus próprios bancos de dados para garantir que você os dimensione corretamente. Para obter mais informações, consulte Comparar os modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.

Essa arquitetura deve ser capaz de ser dimensionada para atender facilmente à maioria das cargas de trabalho de médio a grande porte. Como a arquitetura usa principalmente os serviços de plataforma (PaaS) do Azure, você tem muitas opções para ajustar a escala da solução com base em seus requisitos e carga.

Implantar este cenário

Se você quiser implantar esse cenário, consulte o Kit de Desenvolvimento SaaS do Azure no GitHub. É uma implementação de referência implantável desta arquitetura.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Outros colaboradores:

Próximas etapas

Aqui estão alguns recursos recomendados adicionais para a criação de um aplicativo SaaS no Azure: