Dados para cargas de trabalho SaaS no Azure

  • Artigo

Trate os dados como o ativo mais valioso da sua solução. Como fornecedor independente de software (ISV), você é responsável por gerenciar os dados de seus clientes. Sua estratégia de design de dados e escolha de armazenamento de dados podem afetar significativamente seus clientes.

Este artigo fornece orientação sobre como garantir a integridade e a confidencialidade dos dados para seus clientes e, ao mesmo tempo, atender aos requisitos de desempenho de negócios. Ele destaca as principais considerações para ajudá-lo a alcançar esses objetivos de forma eficaz.

Selecionar um arquivo de dados

O armazenamento de dados em uma solução de software como serviço (SaaS) afeta sua arquitetura, desempenho, confiabilidade e complexidade transacional. Compare os recursos dos serviços gerenciados do Azure com ofertas semelhantes que não sejam da Microsoft. Em algumas situações, você também pode considerar a execução de produtos de código aberto em máquinas virtuais.

Considerações de design

  • Diferencie entre suas operações transacionais e analíticas. Os armazenamentos de dados transacionais são projetados para dar suporte aos seus aplicativos, e os armazenamentos de dados analíticos são usados para relatórios e tarefas como aprendizado de máquina. Essas lojas são construídas com produtos especializados e têm necessidades exclusivas de desempenho, padrões de acesso, esquemas e casos de uso.

    Este guia se concentra em armazenamentos de dados transacionais.

  • Compreenda as suas necessidades de dados. Estime o volume, a frequência com que ele pode ser alterado e o tipo de dados que você precisa armazenar.

    Espere que os dados cresçam significativamente ao longo do tempo. Para soluções SaaS, o crescimento ocorre em múltiplas dimensões. Antecipe aumentos no volume e tipos de dados à medida que o número de clientes cresce. Certifique-se de planejar esse crescimento e investir em tecnologias que possam suportá-lo.

    Decida entre uma plataforma de dados relacional ou não relacional com base na natureza dos seus dados. Para muitas cargas de trabalho transacionais, um banco de dados relacional é uma boa opção para modelar entidades de aplicativo como tabelas discretas. Essa abordagem permite que as consultas operem no modelo de dados relacional. Como alternativa, se seus dados se ajustam naturalmente a um modelo de documento ou seguem uma estrutura gráfica, uma abordagem não relacional pode ser mais adequada.

    Para obter mais informações, consulte Plataformas de dados SQL versus NoSQL.

  • Minimize os tipos de armazenamentos de dados. Armazenar diferentes tipos de dados em vários armazenamentos de dados distintos pode ser benéfico para organizações maduras que têm experiência em várias plataformas de dados. No entanto, essa abordagem muitas vezes introduz complexidade desnecessária para startups e organizações menores. É mais eficaz concentrar-se em um ou em um pequeno número de armazenamentos de dados.

    Se você não tiver a justificativa comercial para usar vários armazenamentos de dados, concentre seus esforços em um ou em um pequeno número de armazenamentos de dados.

  • Use o que sabe e invista nele. Se sua equipe já tem experiência com um armazenamento de dados específico, geralmente é melhor usar esse armazenamento de dados em vez de investir no aprendizado de novas habilidades. Os armazenamentos de dados e as plataformas são complexos e as decisões de design podem ser difíceis de reverter.

    No entanto, tenha em mente o crescimento potencial. Se o armazenamento de dados atual não atender mais às suas necessidades, escolha um armazenamento de dados que possa melhorar o desempenho, a resiliência, a segurança e a eficiência operacional da solução. Também deve ajudar a sua equipa a aprofundar os seus conhecimentos.

Recomendações de design

Recomendação Benefício
Separe os armazenamentos de dados transacionais para operações diárias dos armazenamentos de dados analíticos e de relatórios. Misturar a intenção de seus armazenamentos de dados pode levar a uma complexidade desnecessária. A segmentação de dados aumenta a eficiência operacional e maximiza a utilização de cada armazenamento de dados.
Escolha entre uma estrutura de dados relacional ou não relacional com base em seus requisitos. Comece com um ou um pequeno número de armazenamentos de dados.

Priorize armazenamentos de dados gerenciados. As opções comuns incluem Azure Cosmos DB, Azure SQL, MySQL, MongoDB e PostgreSQL.		 Essa abordagem ajuda a minimizar a complexidade e garante que você use o produto certo para maximizar a eficiência. Os armazenamentos de dados gerenciados oferecem flexibilidade no gerenciamento de recursos e custos de forma elástica e dimensionada de acordo com suas necessidades. O uso de armazenamentos de dados gerenciados cria menos carga de gerenciamento do que a implantação de seu próprio armazenamento de dados em sua própria infraestrutura.
Invista na aprendizagem da tecnologia que escolheu. Equipe sua equipe para gerenciar os requisitos de alto escalabilidade e outras complexidades das soluções SaaS. Saiba mais sobre as ferramentas que você usa e seu ecossistema mais amplo para que você possa usar efetivamente sua plataforma de dados à medida que escala.
Adote a flexibilidade no seu design de dados. À medida que sua solução SaaS cresce ou seus requisitos mudam, você pode se adaptar adicionando ou alterando armazenamentos de dados. Essa flexibilidade permite que você comece com um armazenamento de dados e evolua ao longo do tempo para atender às suas necessidades.

Modelo de arrendamento e estratégia de base de dados

Um aspeto fundamental do design de dados é a decisão de hospedar recursos em nome de seus clientes ou hospedar recursos em seu ambiente. A maioria dos provedores de SaaS hospeda recursos para todos os clientes, o que oferece flexibilidade no gerenciamento de banco de dados. Se você hospedar recursos no ambiente do cliente, considere como você acessa e gerencia esses recursos.

Considerações de design

  • Planeje sua segmentação de banco de dados. Em soluções SaaS business-to-business (B2B), recomendamos que você crie bancos de dados dedicados para cada cliente. Essa abordagem melhora a segurança dos dados mantendo um isolamento rigoroso entre os clientes, o que reduz o risco de mistura de dados e suporta chaves de criptografia gerenciadas pelo cliente. Ele também ajuda você a atender aos requisitos de conformidade regulamentar para alguns clientes.

    Separar os dados do cliente em bancos de dados individuais pode melhorar o desempenho, minimizando problemas barulhentos de vizinhos. Alguns armazenamentos de dados gerenciados incluem controles de alocação de recursos para mitigar esses problemas, fornecer eficiência de custos e incorporar ferramentas para gerenciar vários bancos de dados em escala.

    Em alguns casos, é apropriado armazenar os dados de vários clientes em um único armazenamento de dados. Por exemplo, em soluções B2C (business-to-consumer), você pode salvar dados em um único armazenamento com particionamento lógico baseado na ID do cliente. Em soluções B2B que compartilham componentes, você pode usar um único armazenamento de dados para partes específicas, como um repositório de eventos, garantindo ao mesmo tempo a inclusão de IDs de clientes em cada evento.

  • Coloque armazenamentos de dados com componentes de aplicativos. Se você hospedar recursos em nome do cliente, implante na mesma região do Azure para evitar cobranças de largura de banda de saída e latência. Quando você hospeda aplicativos e armazenamentos de dados no ambiente de um cliente, implante-os juntos no mesmo ambiente para evitar complexidades entre ambientes.

  • Padronize o gerenciamento de armazenamento de dados tanto quanto for prático. A uniformidade é fundamental para gerenciar dados entre os clientes. À medida que o seu negócio cresce, as diferenças entre os clientes aumentam o risco e a complexidade. Essas diferenças também podem tornar as interrupções de produção mais prováveis e a solução de problemas mais difícil.

    Evite alterações pontuais na sua gestão para dar suporte a clientes individuais. Por exemplo, para dar suporte a metadados gerenciados pelo cliente, evite alterações de esquema, como adicionar colunas extras ao banco de dados. Em vez disso, crie funcionalidades para que os clientes adicionem seus próprios metadados. Da mesma forma, se você precisar fornecer diferentes níveis de desempenho de banco de dados para clientes diferentes, crie um único processo que possa ser usado para aplicar configurações diferentes a diferentes camadas de clientes.

Para obter mais informações sobre como seu modelo de locação afeta sua estratégia de dados, consulte.

Recomendações de design

Recomendação Benefício
Avalie se deseja compartilhar bancos de dados entre vários clientes ou fornecer uma plataforma de dados compartilhada.

Implante um único banco de dados para os dados de cada cliente, quando apropriado. Relaxe essa estratégia se o isolamento rigoroso não for um requisito, como em soluções B2C.		 Essa abordagem minimiza problemas de vizinhos barulhentos e pode dar suporte aos requisitos de conformidade para alguns clientes.
Implante aplicativos e seus bancos de dados na mesma região. Essa abordagem otimiza o custo de largura de banda e a latência incorridos pelo acesso ao banco de dados entre regiões.
Projete uma abordagem padronizada para armazenar dados ou metadados definidos pelo cliente. Evite alterar o esquema para clientes individuais ou fazer com que os ambientes dos clientes sejam diferentes. Essa abordagem ajuda a evitar a carga operacional de gerenciar inconsistências entre bancos de dados para cada cliente.
Planeje operações de manutenção de rotina no ambiente implantado pelo cliente.

Planeje como acessar o banco de dados para atualizações, alterações de esquema, manutenção e outras operações.		 Essa abordagem proativa minimiza os problemas da falta de manutenção e reduz o risco de tempo de inatividade e problemas de desempenho.

Planear a capacidade

O planejamento de capacidade refere-se ao gerenciamento da utilização de recursos, com foco em CPU, memória, armazenamento e operações de disco, como operações de entrada e saída por segundo (IOPS). Alguns armazenamentos de dados combinam esses recursos em uma métrica de consumo de recursos simples e sintética, como uma unidade de taxa de transferência de banco de dados (DTU) no SQL do Azure ou uma unidade de solicitação (RU) no Azure Cosmos DB. Os armazenamentos de dados gerenciados oferecem flexibilidade no gerenciamento de recursos, o que permite alterações ao longo do tempo. É crucial estabelecer um plano inicial e iterar à medida que as suas necessidades evoluem.

Considerações de design

  • Entenda seus requisitos de alocação de recursos. Diferentes clientes em soluções SaaS podem ter necessidades de recursos variadas. Clientes menores podem precisar de recursos mínimos, e clientes maiores podem precisar de mais. Clientes maiores costumam pagar mais, o que justifica maior alocação de recursos. Usando bancos de dados separados para cada cliente, você pode ajustar a alocação de recursos com base em seu tamanho e necessidades.

  • Entenda os diferentes modelos de capacidade que as plataformas de dados oferecem. As plataformas de dados baseadas na nuvem geralmente fornecem vários modelos de recursos. Por exemplo, alguns serviços do Azure, como o Azure Cosmos DB, fornecem modelos provisionados baseados em taxa de transferência e modelos sem servidor. O Banco de Dados SQL do Azure também fornece pools elásticos.

    A taxa de transferência provisionada requer alocação de recursos predeterminada, seja de um único banco de dados ou de um grupo de bancos de dados. Os pools elásticos permitem o compartilhamento de recursos entre vários bancos de dados. Piscinas elásticas são comumente usadas em soluções SaaS.

    Embora a taxa de transferência provisionada exija que você aloque recursos com antecedência, serviços como o Azure Cosmos DB fornecem taxa de transferência de dimensionamento automático. Você pode definir regras para adicionar ou remover recursos dinamicamente com base em gatilhos especificados.

    Os modelos de recursos sem servidor são dimensionados automaticamente com base na demanda. Esse recurso os torna um bom ponto de partida se você não puder prever seus requisitos de capacidade com antecedência. No entanto, eles podem suportar menos recursos e se tornar ineficientes em termos de custos à medida que você cresce. Os modelos sem servidor estão disponíveis no Banco de Dados SQL do Azure e no Azure Cosmos DB.

Recomendações de design

Recomendação Benefício
Modele seus requisitos de banco de dados para cada cliente. Determine se você deve ter muitos bancos de dados pequenos, menos bancos de dados grandes ou uma mistura dos dois.

Use um exercício de dimensionamento de camisetas para categorizar os clientes em baldes pequenos, médios e grandes.		 Essa abordagem fornece uma estimativa aproximada dos recursos necessários por cliente e ajuda a mapear os clientes para seu modelo de faturamento.
Segmente pools de recursos com base no tamanho dos bancos de dados de clientes que os usam.

Use a capacidade provisionada a seu favor. Por exemplo, você pode criar um pool elástico SQL compartilhado para clientes menores, um pool separado para clientes médios e recursos dedicados para clientes grandes.		 Ao segmentar pools de recursos com base no tamanho do banco de dados de seus clientes, você pode otimizar a alocação de recursos e a eficiência de custos.
Aproveite os recursos internos de dimensionamento que os serviços gerenciados oferecem. Você pode descarregar responsabilidades de dimensionamento para a plataforma. Recursos como pools elásticos e dimensionamento automático podem ajudar a otimizar o uso de recursos.
Analise regularmente os armazenamentos de dados sem servidor para garantir que eles continuem a atender às suas necessidades. Você pode garantir que o armazenamento de dados permaneça eficaz com suas necessidades em evolução. Otimize o desempenho e a eficiência de custos à medida que suas necessidades mudam.

Recuperação de elevada disponibilidade e após desastre

Os clientes de soluções SaaS geralmente têm altas expectativas de alta disponibilidade (HA) e recuperação de desastres (DR). Se seus clientes operam em setores regulamentados ou confiam em sua solução para operações diárias, seus requisitos podem ser ainda mais rigorosos.

HA e DR não são soluções únicas e dependem de vários fatores. Tenha uma compreensão clara das opções disponíveis que são aplicáveis aos requisitos de você e de seus clientes para tomar decisões informadas sobre a mitigação de diferentes riscos.

Compensação: confiabilidade, custo e desempenho: a resiliência para serviços de dados geralmente requer a distribuição de réplicas ou cópias de seus dados em uma área geográfica mais ampla para reduzir os riscos. No entanto, há compensações. Quanto maior a distância que os dados têm de percorrer, mais proteção você tem contra falhas localizadas. No entanto, copiar dados a longas distâncias aumenta a latência e, muitas vezes, custa mais. Muitos armazenamentos de dados gerenciados fornecem replicação automatizada de dados, mas podem impor limites aos tipos de replicação que você pode executar em diferentes distâncias para manter o desempenho.

Considerações de design

  • Quantificar a resiliência. Meça os requisitos de resiliência usando SLOs (Service Level Objetives, objetivos de nível de serviço), que incluem métricas como tempo de atividade, tempo de recuperação e ponto de recuperação. Essas métricas são impulsionadas tanto pelos requisitos do seu negócio quanto pelos dos seus clientes, que podem ter necessidades variadas. Se você armazenar grandes quantidades de dados em nome de seus clientes, sua solução de HA e DR pode precisar ser mais complexa para atender a requisitos rigorosos.

    Para obter mais informações sobre métricas de resiliência, consulte RE:04 Recomendações para definir metas de confiabilidade.

  • Use os recursos da plataforma. O Azure fornece recursos de resiliência em um datacenter, em uma região usando zonas de disponibilidade e em uma área geográfica mais ampla usando várias regiões. Combine estratégias como zonas de disponibilidade, backup entre regiões e implantações em várias regiões para alcançar o nível certo de resiliência para sua solução. Para requisitos de alta resiliência, considere uma arquitetura ativa-passiva de várias regiões com replicação assíncrona de dados entre regiões. Essa abordagem pode resultar em alguma perda de dados durante uma interrupção catastrófica.

    Compensação: projetos ativos e multirregionais com replicação são os mais resilientes, mas são complexos de criar e testar. Para a maioria das soluções ativas, você precisa projetar uma abordagem de resolução de conflitos que leve em conta os atrasos na sincronização de dados. A maioria das soluções não precisa desse grau de resiliência.

    Consulte RE :05 Recomendações para usar zonas e regiões de disponibilidade.

  • Use carimbos de implantação para isolar o raio de jateamento dos componentes. O padrão de carimbos de implantação é amplamente utilizado em soluções SaaS porque fornece benefícios para implantação, gerenciamento, desempenho e resiliência. Por exemplo, implantar um selo nos Estados Unidos e outro na Europa garante que os clientes em uma região fiquem isolados de interrupções na outra região e possam operar de forma independente.

Recomendações de design

Recomendação Benefício
Concentre-se nos requisitos de resiliência enquanto pensa nos requisitos gerais de dados para você e seus clientes. Ao fundamentar suas decisões de projeto nesses requisitos, você pode garantir que você faça as compensações apropriadas e evite engenharia insuficiente ou excessiva para suas necessidades.
Reflita diferentes níveis de resiliência no seu modelo de faturação.

Defina expectativas com os seus clientes. Zero perda de dados durante interrupções catastróficas ou 100% de tempo de atividade pode ser irrealista.		 Os modelos de faturação podem ajudar os seus clientes a compreender a resiliência garantida para a qual estão a aderir. Por exemplo, com um nível mais baixo, os clientes obtêm garantias mínimas. Em um nível mais alto, os clientes recebem mais resiliência porque você pode se dar ao luxo de replicar seus recursos em várias regiões.
Use as zonas de disponibilidade do Azure para soluções de produção. Sempre que possível, use armazenamentos de dados redundantes de zona. As zonas de disponibilidade oferecem resiliência contra interrupções do datacenter, sem aumentar significativamente o custo, a latência ou a complexidade da sua solução.
Mantenha backups de seus armazenamentos de dados em um formato globalmente redundante usando a replicação entre regiões, quando disponível. Os backups de dados entre regiões adicionam um nível extra de resiliência.
Use carimbos de implantação para criar instâncias separadas de sua solução em locais geograficamente distribuídos. Usando carimbos de implantação para criar instâncias separadas de sua solução em locais geograficamente distribuídos, você pode aumentar a resiliência e fornecer mais benefícios, como gerenciamento de operações mais fácil.
Avalie se você precisa de implantação em várias regiões e se precisa de um design ativo-ativo para atender aos requisitos.

Considere as compensações envolvidas. Os componentes sem estado são mais fáceis de replicar do que os componentes com monitoração de estado, como um armazenamento de dados.		 Distribuir sua solução ou carimbos entre regiões oferece níveis mais altos de resiliência ao replicar dados entre regiões.

Segurança e conformidade

Você é responsável por garantir a confidencialidade e integridade dos dados de seus clientes. Ao criar uma linha de base de segurança, considere seus requisitos e promessas de segurança. Planeje atender às necessidades de conformidade de seus clientes, incluindo retenção de dados.

Considerações de design

  • Rede: considere quem acessará seu armazenamento de dados. Normalmente, apenas seu aplicativo precisa de comunicação direta, portanto, configure-o para rede somente privada.

  • Identidade: considere como seus armazenamentos de dados serão acessados. Muitas soluções SaaS usam uma única identidade de aplicativo para todos os armazenamentos de dados, com a camada de aplicativo impondo isolamento e autorização. Para segurança em nível de linha ou autorização em nível de banco de dados, talvez seja necessário propagar a identidade do usuário para o armazenamento de dados, que é complexo em um ambiente multilocatário.

  • Retenção de dados: planeje suas políticas de retenção de dados com antecedência. A manutenção de mais dados aumenta os custos de armazenamento e a complexidade do gerenciamento. Por exemplo, grandes quantidades de dados em um banco de dados transacional podem complicar os processos de consulta e truncamento.

    Para retenção de dados a longo prazo, como para conformidade ou análises futuras, considere realocar dados para um armazenamento adequado para retenção de longo prazo.

Recomendações de design

Recomendação Benefício
Configure seus armazenamentos de dados para usar pontos de extremidade privados e desabilite pontos de extremidade públicos. Esta abordagem aumenta a segurança, restringindo o acesso à sua rede interna. Ao restringir o acesso, você pode reduzir o risco de acesso não autorizado e possíveis violações de dados.
Use identidades gerenciadas e ID do Microsoft Entra para autenticação. Evite o uso de chaves ou credenciais de banco de dados. As identidades gerenciadas eliminam a necessidade de chaves ou credenciais de banco de dados, o que reduz o risco de roubo de credenciais e simplifica o gerenciamento de acesso.
Ao trabalhar com armazenamentos de dados compartilhados, certifique-se de que o aplicativo escope todas as solicitações para um único locatário incluindo o identificador de locatário em WHERE cláusulas. Esse processo ajuda a reduzir o risco de vazamento de dados entre locatários ou falsificação de identidade.
Planeje sua estratégia de retenção de dados com base na conformidade e nas necessidades de negócios. Evite manter dados históricos desnecessários. Para retenção de longo prazo, mova os dados dos armazenamentos principais para o armazenamento de arquivamento. Ao evitar a retenção desnecessária, você mantém uma área de superfície menor.
Use os recursos de armazenamento de dados para dar suporte às suas necessidades do ciclo de vida dos dados.

No Azure Cosmos DB, defina o tempo de vida nos documentos. No Azure SQL, implemente uma estratégia de janela deslizante usando o particionamento de tabela para minimizar o impacto do processo de arquivamento no banco de dados.		 Essas abordagens garantem o gerenciamento eficiente do ciclo de vida dos dados, otimizam o armazenamento arquivando ou excluindo dados desatualizados e reduzem a intervenção manual quando possível.

Operações

As soluções SaaS geralmente incluem um grande número de bancos de dados ou outras lojas. É importante planear a manutenção de rotina da sua frota e explorar opções de automação para gerir estas tarefas de forma eficiente.

Considerações de design

  • Compreenda as capacidades da sua equipa. Se você não tiver grandes equipes de administradores de banco de dados que possam realizar análises detalhadas nos bancos de dados de clientes individuais, tenha um plano para executar operações em escala e use ferramentas de plataforma sempre que possível.

  • Planeie os seus procedimentos de manutenção regulares. Enumerar as operações de manutenção regulares necessárias e a sua frequência. As operações específicas variam de acordo com o tipo de armazenamento de dados que você usa. Por exemplo:

    • Monitore a quantidade total de dados e dados localizados em entidades específicas, como tabelas importantes.
    • Reconstruir índices.
    • Crie ou remova índices com base na alteração de padrões de consulta.
    • Reequilibre partições.

    Explore os recursos da plataforma que podem ajudá-lo a realizar manutenção regular e procurar proativamente novos problemas. Por exemplo, o Consultor do Banco de Dados SQL no Banco de Dados SQL do Azure monitora problemas.

  • Design para automação. As operações automatizadas são essenciais para que uma solução SaaS seja dimensionada de forma eficaz. Identifique tarefas regulares e ocasionais e crie playbooks ou scripts de automação para elas. Para tarefas que você não pode automatizar imediatamente, documente minuciosamente os processos para garantir consistência e clareza.

Recomendações de design

Recomendação Benefício
Procure a consistência entre os armazenamentos de dados dos clientes sempre que possível.

Se um cliente precisar de acomodações especiais, integre-as em um processo geral em vez de personalizar a configuração para esse cliente. Por exemplo, use o mesmo esquema para cada banco de dados e use os mesmos processos para implantar e gerenciar seus recursos.		 A consistência facilita a realização de alterações em escala e minimiza o risco de problemas acidentais durante implantações ou procedimentos de manutenção.
Implante recursos limitados com cuidado e busque oportunidades para simplificar as operações. Você pode evitar pequenas eficiências e ter melhor utilização de recursos e desempenho geral.
Crie automação para tarefas repetitivas. Opte por comprar ferramentas automatizadas em vez de criar uma solução personalizada.

Explore as opções que a plataforma e os fornecedores que não são da Microsoft fornecem.		 Ao investir em automação de qualidade, você pode usar repetidamente esses ativos e reduzir tarefas manuais que muitas vezes são propensas a erros. As ferramentas automatizadas são valiosas se você não for um especialista no armazenamento de dados que está usando ou se não tiver certeza sobre as tarefas de manutenção necessárias.
Implante a capacidade de administração de banco de dados da sua equipe com cuidado. Reserve administradores de banco de dados humanos para as atividades mais impactantes, como lidar com grandes clientes ou automação de edifícios que pode ser dimensionada para muitos clientes. Ao priorizar funções valiosas, você pode maximizar a eficiência.

Acesso do cliente aos dados

Alguns de seus clientes podem solicitar acesso direto aos seus dados para relatórios ou análises personalizados. Considere cuidadosamente como os clientes podem acessar os dados em sua solução e se devem conceder essas solicitações ou fornecer métodos alternativos para atender às suas necessidades.

Considerações de design

  • Justifique as razões para o acesso direto. Entenda por que os clientes precisam ter acesso a dados brutos obtendo informações sobre seus problemas de negócios. Colabore para encontrar uma solução que atenda às suas necessidades sem introduzir riscos à sua plataforma.

    Encontre maneiras alternativas de atender aos requisitos em vez de dar acesso direto. Se o acesso for necessário para fins de relatório, as abordagens da camada de aplicativo são preferíveis. Por exemplo, você pode criar relatórios para eles usando o Microsoft Power BI ou pode exportar um subconjunto de seus dados para um arquivo fornecido a eles. Você também pode criar APIs que eles podem usar para acessar seus dados.

  • Avalie as implicações de segurança e isolamento. Fornecer acesso direto a um armazenamento de dados representa riscos de segurança significativos. Evite expor recursos internos a terceiros, incluindo clientes. Em um ambiente SaaS que tem muitos clientes compartilhando uma solução, os riscos são ainda maiores porque o ambiente pode ser explorado para acessar os dados de outros clientes.

    Considere fornecer aos clientes acesso aos seus dados de forma segura e isolada que não afete seu sistema de produção e permita que você faça alterações internas no design do banco de dados sem interromper as consultas dos clientes.

  • Considere o efeito no desempenho. Permitir o acesso direto ao seu armazenamento de dados transacionais pode levar a problemas de desempenho para seu aplicativo principal. Por exemplo, um cliente pode executar uma consulta que consome muitos recursos e interrompe a funcionalidade do aplicativo.

Recomendações de design

Recomendação Benefício
Evite dar acesso direto aos seus armazenamentos de dados.

Se você precisar conceder acesso direto, forneça acesso a uma réplica somente leitura, se a plataforma de dados oferecer suporte a ela.		 As abordagens da camada de aplicativo oferecem controle sobre como os clientes usam seus dados. Se não for possível criar construções de camada de aplicativo, o acesso por meio de réplicas somente leitura reduz o esforço das consultas do cliente em suas operações.
Evite expor detalhes internos da implementação. Ao controlar o acesso às suas estruturas de dados, você impede que os clientes façam suposições sobre a funcionalidade do seu esquema de banco de dados. Essa flexibilidade permite que você evolua e otimize sua estrutura de banco de dados ao longo do tempo sem as restrições de ferramentas criadas pelo cliente ou suposições imprecisas.

Recursos adicionais

A multilocação é uma metodologia de negócios central para projetar cargas de trabalho SaaS. Estes artigos fornecem mais informações sobre considerações de design de dados:

Próximo passo

Saiba mais sobre a consideração do DevOps para cargas de trabalho SaaS, incluindo gerenciamento eficiente do ciclo de vida do cliente e práticas de implantação seguras.

Área de design: práticas de DevOps para cargas de trabalho SaaS no Azure