O blog da AWS

Portabilidade de tenants: mova tenants entre tiers em uma aplicação SaaS

Por Aman Lal, arquiteto de nuvem na AWS e Varun Saxena, arquiteto de nuvem na AWS.

No atual cenário acelerado de software como serviço (SaaS), a portabilidade de tenants é um recurso essencial para os provedores SaaS que buscam se manter competitivos. Ao permitir a movimentação perfeita entre os tiers, a portabilidade de tenants permite que as empresas se adaptem às necessidades de seus clientes. No entanto, a orquestração manual de solicitações de portabilidade pode ser um gargalo significativo, dificultando a escalabilidade e exigindo recursos substanciais. À medida que os volumes de tenants e as solicitações de portabilidade aumentam, essa abordagem se torna cada vez mais insustentável, tornando essencial implementar uma solução mais eficiente.

Esta postagem investiga a importância da portabilidade de tenants e descreve as etapas essenciais para sua implementação, com foco na integração perfeita com a arquitetura de referência serverless SaaS. O diagrama a seguir ilustra o processo de mudança de tier, destacando as funções dos tenants e administradores, bem como o impacto nos serviços novos e existentes na arquitetura. As seções subsequentes fornecerão uma explicação detalhada da sequência de eventos mostrada neste diagrama.

Figura 1. Incorporando a portabilidade de tenants em uma arquitetura de referência SaaS serverless

Figura 1. Incorporando a portabilidade de tenants em uma arquitetura de referência SaaS serverless

Por que precisamos da portabilidade dos tenants?

  • Flexibilidade: os upgrades ou downgrades de tier iniciados pelo tenant ajudam a se alinhar à evolução da demanda, das preferências, do orçamento e das estratégias de negócios dos clientes. Essas mudanças de tier geralmente alteram o contrato de serviço entre o tenant e o provedor SaaS.
  • Qualidade do serviço: geralmente iniciados pelo administrador do SaaS em resposta a uma violação de segurança ou quando o tenant está atingindo os limites do serviço, esses incidentes podem exigir a migração do tenant para manter os acordos de nível de serviço (SLAs).

Fluxo de portabilidade de alto nível

A portabilidade do tenant geralmente é obtida por meio de um processo bem orquestrado que garante transições de tier perfeitas. Esse processo compreende as seguintes etapas:

Figura 2. Fluxo de portabilidade de tenants de alto nível

Figura 2. Fluxo de portabilidade de tenants de alto nível

  1. Portabilizar repositórios de identidade: avalie a necessidade de migrar o repositório de identidade do tenant para o tier de destino. Em cenários em que o repositório de identidades existente é incompatível com o tier de destino, você precisará provisionar um novo repositório de identidades e usuários administrativos.
  2. Atualizar a configuração do tenant: os aplicativos SaaS armazenam detalhes da configuração do tenant, como o identificador e o tier do tenant, que são necessários para a operação.
  3. Gerenciamento de recursos: inicie pipelines de implantação para provisionar recursos no tier de destino e atualize as tabelas de mapeamento de tenants da infraestrutura.
  4. Migração de dados: migre os dados do tenant do tier antigo para a infraestrutura do tier de destino recém-provisionado.
  5. Transição: redirecione o tráfego dos tenants para a nova infraestrutura, permitindo a utilização sem tempo de inatividade dos recursos atualizados.

Passo a passo de consideração

Agora vamos nos aprofundar em cada etapa do fluxo de trabalho de portabilidade, destacando as principais considerações para uma implementação bem-sucedida.

1. Portabilidade dos repositórios de identidade

A principal consideração para portar a identidade é migrar as identidades do usuário e, ao mesmo tempo, manter uma experiência consistente do usuário final, sem exigir redefinições de senha ou alterações nos IDs do usuário.

Crie um novo repositório de identidades e um client de aplicativo associado que o front-end possa usar; depois disso, precisaremos de um mecanismo para migrar usuários. Na arquitetura de referência usando o Amazon Cognito, um silo se refere a cada tenant com seu próprio user pool, enquanto um pool se refere a vários tenants compartilhando um user pool por meio de grupos de usuários.

Para garantir um processo de migração tranquilo, é importante se comunicar com os usuários e oferecer a eles opções para evitar redefinições de senha. Uma abordagem é notificar os usuários a fazerem login antes do prazo para evitar redefinições de senha. Empregue a migração just-in-time, permitindo a retenção de senhas durante o login para uma experiência ininterrupta do usuário com as senhas existentes.

No entanto, isso exige esperar que todos os usuários migrem, o que pode levar a uma janela de migração prolongada. Como medida complementar, após o prazo, os usuários restantes podem ser migrados usando a importação em massa, que impõe redefinições de senha. Isso garante uma migração consistente dentro de um prazo definido, embora incomode alguns usuários.

2. Atualizar a configuração do tenant

Os provedores de SaaS dependem de armazenamentos de metadados para manter todas as configurações relacionadas ao tenant. As atualizações dos metadados do tenant devem ser concluídas com cuidado durante o processo de portabilidade. Quando você atualiza a configuração do tenant para o novo tier, dois aspectos principais devem ser considerados:

  • Mantenha as IDs dos tenants durante todo o processo de transferência para garantir uma integração perfeita do registro, das métricas e da alocação de custos do tenant após a migração, fornecendo um registro contínuo dos eventos.
  • Estabeleça novas chaves de API e um mecanismo de limitação adaptado ao novo tier para acomodar maiores limites de uso para os tenants.

Para lidar com isso, um novo serviço de portabilidade de tenants pode ser introduzido na arquitetura de referência SaaS. Esse serviço atribui um plano de uso diferente do AWS API Gateway ao tenant com base na alteração de tier solicitada e orquestra chamadas para outros serviços downstream. Posteriormente, o serviço de gerenciamento de tenants existente precisará de uma extensão para lidar com as atualizações de metadados do tenant (tier, user-pool-id, app-client-id) com base na solicitação de portabilidade recebida.

3. Gerenciamento de recursos

A portabilidade bem-sucedida depende de dois aspectos cruciais durante o provisionamento da infraestrutura:

  • Garanta que as construções de isolamento de tenants sejam respeitadas no processo de portabilidade por meio de mecanismos para impedir o acesso entre tenants. Tanto o controle de acesso baseado em função (RBAC) quanto o controle de acesso baseado em atributos (ABAC) podem ser usados para garantir isso. O isolamento ABAC geralmente é mais fácil de gerenciar durante a portabilidade se o identificador do tenant for preservado, como na etapa anterior.
  • Garanta que a instrumentação e a coleta de métricas estejam configuradas corretamente no novo tier. Recrie filtros métricos idênticos para garantir a visibilidade do monitoramento das operações de SaaS.

Para lidar com o provisionamento e o desprovisionamento da infraestrutura na arquitetura de referência, estenda o serviço de provisionamento de tenants:

  • Atualize a tabela de mapeamento da stack do tenant para registrar os detalhes da stack do tenant migrada.
  • Inicie pipelines de provisionamento ou destruição de infraestrutura conforme necessário (por exemplo, para executar pipelines de destruição após a migração de dados e as etapas de transferência do usuário).

Por fim, garanta que os novos recursos estejam de acordo com os padrões de conformidade exigidos aplicando configurações de segurança relevantes e implantando uma versão compatível da aplicação.

Ao abordar esses aspectos, os provedores de SaaS podem garantir uma transição perfeita, mantendo o isolamento dos tenants e a continuidade operacional.

4. Migração de dados

A estratégia de migração de dados é fortemente influenciada por decisões arquiteturais, como o mecanismo de armazenamento e a abordagem de isolamento. Minimizar o tempo de inatividade do usuário durante a migração exige um foco na aceleração do processo de migração, na manutenção da disponibilidade do serviço e na configuração de um canal de replicação para atualizações incrementais. Além disso, é crucial abordar as alterações de esquema feitas pelos tenants em um modelo de silo para garantir a integridade dos dados e evitar a perda de dados ao fazer a transição para um modelo de pool.

Estendendo a arquitetura de referência, um novo serviço de portabilidade de dados pode ser introduzido para permitir a migração de dados do Amazon DynamoDB entre diferentes tiers. A migração de partições do DynamoDB pode ser realizada por meio de várias abordagens, incluindo AWS Glue, scripts personalizados ou duplicação de tabelas do DynamoDB e exclusão em massa de partições. Recomendamos uma abordagem híbrida para obter uma migração sem tempo de inatividade. Essa solução se aplica somente quando o esquema do DynamoDB permanece consistente em todos os tiers. Se o esquema tiver sido alterado, é necessária uma solução personalizada para a migração de dados.

5. Transição

A fase de transição envolve o redirecionamento dos usuários para a nova infraestrutura, a desativação da replicação contínua de dados e a garantia de que os requisitos de conformidade sejam atendidos. Isso inclui a execução de testes ou a obtenção de auditorias/certificações, especialmente ao migrar para silos de alta criticidade. Depois de uma transição bem-sucedida, atividades de limpeza são necessárias, incluindo a remoção da infraestrutura temporária e a exclusão de dados históricos do tenant do tier anterior. No entanto, antes de excluir dados, certifique-se de que as trilhas de auditoria sejam preservadas e estejam em conformidade com os requisitos regulatórios e que a exclusão de dados esteja alinhada às políticas organizacionais.

Conclusão

Em conclusão, a portabilidade é um recurso vital para o SaaS multitenant. Ele permite que os tenants movam dados e configurações entre tiers sem esforço e pode ser incorporado à arquitetura de referência conforme descrito acima. As principais considerações incluem manter identidades consistentes, manter a conformidade, reduzir o tempo de inatividade e automatizar o processo.

Autores

Aman Alal Aman Lal é arquiteto de nuvem na AWS, especializado em desenvolvimento de SaaS, tecnologias de contêineres e engenharia de plataformas. Com paixão pela inovação, ele se destaca na criação de soluções criativas para atender às diversas necessidades dos clientes comerciais da AWS. Aman é defensor das práticas de engenharia da Amazon, orientando os clientes a criar produtos escaláveis e otimizar sua infraestrutura de nuvem para gerar valor comercial.
Varun Saxena Varun Saxena é arquiteto de nuvem na AWS com mais de 16 anos de experiência como engenheiro e construtor de software. Ele é especialista em projetar e criar aplicações nativas da nuvem que utilizam SaaS e tecnologias de ponta, incluindo IA, para impulsionar a transformação digital e o sucesso comercial das empresas da Fortune em todo o mundo. Dedicado a fornecer soluções mais rápidas e econômicas, Varun está comprometido em ajudar seus clientes a alcançar os resultados desejados, aproveitando a tecnologia para resolver problemas comerciais complexos e aumentar sua eficiência e lucratividade gerais. Ele é um firme defensor de construir a coisa certa e construir essas coisas da maneira certa.

 

 


Este conteúdo foi traduzido para Português do blog original em inglês (link aqui).

Tradutor: Cesar Augusto Kuehl, arquiteto de soluções – AWS Brasil

Revisor: Gustavo Barbosa, arquiteto de soluções – AWS Brasil