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

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.	Quarta Cafeteria.
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.

Fluxo de Trabalho

O administrador do cliente SaaS navega até o site hospedado no aplicativo Onboarding &admin.
O administrador do cliente SaaS entra usando o fluxo de trabalho de entrada do usuário .
O administrador do cliente SaaS conclui o fluxo de integração.
O administrador do cliente SaaS navega até a área de administrador do locatário no aplicativo Onboarding &admin e adiciona um Usuário do Cliente SaaS ao locatário recém-criado.
O usuário do cliente SaaS navega até o aplicativo de aplicativo SaaS e usa o aplicativo SaaS.

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

O usuário final navega até um aplicativo front-end e seleciona um botão Logon .
O aplicativo Front-end redireciona o usuário final para uma página de entrada hospedada pelo provedor de identidade.
O Usuário Final insere informações da conta e envia o formulário de entrada para o provedor de identidade.
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.
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.
O provedor de identidade adiciona as permissões e funções como declarações personalizadas ao token de ID, que é um JWT (token Web JSON).
O provedor de identidade retorna um token de ID para o usuário final e inicia um redirecionamento para o aplicativo front-end.
O usuário final é redirecionado para o ponto de extremidade de entrada no aplicativo front-end e apresenta o token de ID.
O aplicativo Front-end valida o token de ID apresentado.
O aplicativo 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 o protocolo OpenID Connect.

Como integrar um novo locatário

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

O administrador do cliente SaaS navega até o aplicativo Onboarding &admin e conclui um formulário de inscrição.
O aplicativo Onboarding &admin emite uma solicitação POST à API de dados do locatário para criar um novo locatário.
A API de dados do locatário cria um novo locatário no armazenamento de dados do locatário.
A API de dados do locatário emite uma solicitação POST à API de dados de permissão para conceder permissões de administrador do cliente SaaS ao locatário recém-criado.
A API de dados de permissão cria um novo registro de permissão no armazenamento de dados de permissão.
A API de dados de permissão retorna com êxito.
A API de dados do locatário retorna com êxito.
O aplicativo Onboarding &admin 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.
O provedor de notificação por email envia o email.
O provedor de notificação por email retorna com êxito.
O aplicativo Onboarding &admin emite uma solicitação ao provedor de identidade para atualizar o token de ID do administrador do cliente SaaS para que ele inclua uma declaração JWT para o locatário recém-criado.
O provedor de identidadeemite 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.
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.
O provedor de identidade adiciona as permissões e funções como declarações personalizadas ao token de ID.
O provedor de identidade retorna o token de ID para o Aplicativo de Integração &admin.
O aplicativo Onboarding &admin retorna uma mensagem de sucesso e um novo token de 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:

O administrador do cliente SaaS solicita para ver uma lista de locatários da área de administrador de locatários no aplicativo Onboarding &admin.
O aplicativo Onboarding &admin 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.
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.
A API de dados de permissão retorna uma lista de permissões de locatário.
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.
O aplicativo Onboarding &admin retorna a lista de dados de locatário para o administrador do cliente SaaS.
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.
O aplicativo Onboarding &admin 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.
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.
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.
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.
O provedor de identidade retorna a ID do objeto do usuário do cliente SaaS.
A API de dados de permissão adiciona um registro de permissão no armazenamento de dados de permissão para o usuário cliente SaaS no locatário especificado usando sua ID de objeto.
A API de dados de permissão retorna com êxito.
A API de dados do locatário retorna com êxito.
O aplicativo Onboarding &admin 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 Banco de Dados SQL do Azure é um serviço gerenciado de banco de dados relacional de uso geral que dá suporte a dados relacionais, dados espaciais, JSON e XML.
Os Aplicativos Lógicos do Azure permitem criar rapidamente integrações avançadas usando uma ferramenta simples de GUI (interface gráfica do usuário).

Alternativas

A eficácia de qualquer escolha alternativa depende muito do modelo de locação que você pretende dar suporte ao seu aplicativo SaaS. 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 a ID do Microsoft Entra.
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, consulte Well-Architected Framework.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte a lista de verificação de revisão de design para 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 JWTs (tokens de ID do usuário).

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte a lista de verificação de revisão de design para Otimização de Custos.

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 obter mais informações, consulte a visão geral do plano 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, consulte o preço 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 modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da carga de trabalho de dimensionar para atender às demandas do usuário com eficiência. Para obter mais informações, consulte a lista de verificação de revisão de design para 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 (plataforma como um serviço (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:

Landon Pierce | Engenheiro do Cliente

Outros colaboradores:

Chris Ayers | Engenheiro sênior de clientes
John Downs | Engenheiro sênior de clientes
LaBrina Loving | Gerente de Engenharia de SVC principal
Gary Moore | Programador/Gravador
Nick Pinheiro | Consultor Sênior
William Salazar | Engenheiro sênior de clientes
Ali Sanjabi | Engenheiro sênior de clientes
Arsen Vladimirskiy | Engenheiro de cliente principal
Jason Young | Gerente de Engenharia de SVC principal

Próximas etapas

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

Arquitetar soluções multilocatários no Azure – Descreve as práticas recomendadas.
Considerações do ISV para zonas de destino do Azure
Estrutura Bem Projetada do Microsoft Azure
Aplicativo SaaS WingTips Tickets – Fornece detalhes sobre as compensações entre vários modelos de locação dentro da camada de banco de dados.