Padrões para implantação de SaaS em ambientes remotos

Por Sunil Ramachandra, arquiteto de soluções sênior na AWS; Farooq Ashraf, arquiteto de soluções sênior na AWS e Peter Yang, arquiteto de soluções de parceiros sênior na AWS.

Em um ambiente de software como serviço (SaaS), o objetivo dos fornecedores de SaaS é oferecer seu software verdadeiramente como um serviço, ocultando todos os detalhes da implementação de seus tenants. Nesse modelo, toda a aplicação está sendo executada na infraestrutura do provedor SaaS.

No entanto, existem modelos em que determinados fatores, comerciais ou técnicos, exigem que os fornecedores hospedem parte da aplicação na infraestrutura do tenant. Esse modelo, em que há uma propriedade compartilhada da infraestrutura de aplicações entre o provedor e o tenant, foi nomeada como “SaaS Anywhere”.

O SaaS significa alcançar inovação e crescimento por meio de operações eficientes. A aplicação SaaS deve ser gerenciada, operada e escalada por meio de uma única experiência de gerenciamento que aumente essa eficiência operacional.

Com um modelo de implantação de SaaS Anywhere, no entanto, os provedores SaaS enfrentam o desafio de encontrar maneiras novas e criativas de controlar os recursos remotos sem comprometer esses valores fundamentais do SaaS. Com isso em mente, o provedor SaaS precisa considerar cuidadosamente quais recursos precisam ser executados em um ambiente remoto ao pensar em adotar uma estratégia de SaaS Anywhere.

Neste post, falaremos sobre três padrões de SaaS Anywhere que identificamos. Analisaremos alguns dos principais fatores e considerações de negócios associados a cada um dos padrões. Por fim, discutiremos alguns desafios a serem considerados ao operar e gerenciar uma solução com um modelo de implantação de SaaS Anywhere.

Control Plane e Application Plane

Antes de entrarmos nos padrões, é importante falarmos primeiro sobre as duas partes fundamentais de uma solução SaaS, o ambiente de gerenciamento (controle plane) e o plano de aplicação (application plane). O control plane é um conjunto de serviços compartilhados que o provedor SaaS usa para gerenciar, operar e analisar uma solução SaaS multitenant. O application plane é a parte da aplicação com a qual os usuários finais irão interagir. É aqui que residem as funcionalidades da aplicação de sua solução SaaS.

Com o SaaS Anywhere, analisaremos os padrões de como os recursos dos application planes podem ser implantados e operados em ambientes remotos. É importante observar que, embora o application plane possa ser arquitetado para ser executado total ou parcialmente em um ambiente remoto, o control plane na conta do provedor SaaS ainda deve ser o conjunto de serviços compartilhados que gerencia todas as instâncias do application plane.

Considerações comuns

Cada padrão de implantação do SaaS Anywhere vem com seu próprio conjunto de compensações e considerações. Vamos abordá-los à medida que abordamos cada padrão, mas há algumas considerações que são comuns aos padrões. Isso inclui:

• A disponibilidade e a confiabilidade se tornam uma responsabilidade compartilhada entre o provedor SaaS e o tenant. O provedor SaaS tem um controle claro sobre os recursos em execução em seu ambiente e pode gerenciar a disponibilidade e a confiabilidade desses recursos. No entanto, os tenants também podem assumir algum nível de controle sobre os recursos executados em seu ambiente. Isso significa que o tenant pode assumir alguma responsabilidade pelo tempo de atividade e resiliência desses recursos.
• A integração perfeita é essencial para uma solução SaaS e isso não muda com o SaaS Anywhere. No entanto, fica mais complicado devido à introdução de uma dependência externa no ambiente remoto e às permissões necessárias para concluir o processo de integração. Os provedores SaaS precisam considerar como/onde seu código de automação de integração provisionará e configurará quaisquer recursos remotos. Isso pode incluir provisionamento de armazenamento/computação, configuração de rede, configuração de funções do AWS Identity and Access Management (IAM) e assim por diante. O objetivo aqui é garantir que os recursos apropriados possam ser provisionados nessas configurações remotas.
• A observabilidade entre contas será fundamental com uma implantação do SaaS Anywhere. Com serviços executados em ambientes remotos, é importante que o provedor SaaS estabeleça um método para publicar dados de observabilidade de ambientes remotos de volta ao control plane, onde os dados possam ser monitorados, agregados e analisados.

Agora que abordamos algumas das considerações comuns entre os três padrões, vamos examinar mais de perto cada padrão.

Armazenamento de dados distribuído

Nesse modelo de entrega, os planos de controle e aplicação são implantados na (s) conta (s) do provedor SaaS e alguns ou todos os dados da aplicação são implantados na conta do cliente. O diagrama abaixo (Figura 1) fornece um exemplo desse padrão.

Figura 1 – Armazenamento de dados distribuído

Esse modelo pode ser considerado quando é proibitivo transferir os dados do cliente. Um cenário é quando os clientes dos provedores SaaS estão em um setor altamente regulamentado, onde os dados precisam ficar com o cliente. Outro cenário é quando a quantidade de dados é muito grande e não é ideal ser movida entre ambientes.

Idealmente, uma solução SaaS tem um conjunto de microsserviços e cada microsserviço deve ter seu armazenamento de dados correspondente em vez de um armazenamento de dados para toda a aplicação. Isso significa que os provedores SaaS devem ter a flexibilidade de configurar o armazenamento remoto para microsserviços específicos, em vez de configurar a aplicação inteira.

Com o modelo de armazenamento de dados distribuído, seu tenant agora pode controlar esses recursos de armazenamento remoto. Tarefas administrativas, como backup do banco de dados, desempenho do banco de dados e segurança do banco de dados, podem se tornar responsabilidade do tenant.

Um exemplo pertinente desse modelo é o de serviços em nuvem como o Amazon Security Lake, AWS HealthLake e o AWS HealthOmics, em que um repositório central de conjuntos de dados altamente controlados pertence e é controlado pelos clientes. Nesse cenário, os dados poderiam ser armazenados na conta do tenant e acessados por meio da aplicação em execução na conta do provedor SaaS.

No exemplo de arquitetura abaixo (Figura 2), o provedor SaaS hospeda o control plane e o application plane em sua própria conta da AWS. Alguns ou todos os dados do tenant estão na conta da AWS do tenant. Para permitir que o provedor SaaS acesse o banco de dados Amazon DynamoDB do cliente, por exemplo, uma role cross-account do IAM é usada. Isso permite que o provedor SaaS assuma uma role na conta do cliente, concedendo permissão para se conectar e realizar operações no Amazon DynamoDB.

Ao separar as contas, o cliente mantém a propriedade e o controle de seus dados, ao mesmo tempo em que permite que o provedor SaaS tenha acesso para realizar ações de serviço. A role cross-account define as permissões apropriadas para o provedor SaaS realizar suas tarefas sem acesso excessivo ao ambiente do cliente.

Figura 2 — Exemplo de arquitetura para o modelo de armazenamento de dados distribuído.

Application plane distribuído

No modelo de application plane distribuído, o control plane e parte do application plane são implantados na conta do provedor SaaS, enquanto alguns dos serviços do application plane são implantados na conta do cliente. O diagrama abaixo ilustra esse modelo.

Figura 3 — Application plane distribuído.

O modelo de application plane distribuído pode ser considerado quando os clientes têm grandes quantidades de dados que precisam ser transferidos. O provedor SaaS pode implantar serviços de aplicações remotos no ambiente do cliente final para interagir com recursos remotos e se comunicar com serviços de aplicações executados na conta do provedor SaaS.

Isso permite que o provedor SaaS implante seletivamente determinados serviços remotamente, mantendo o restante do application plane em sua própria conta. Isso permite mover os serviços que fazem sentido migrar.

Nesse modelo, o cliente agora também é responsável pelos recursos necessários para suportar a computação e o armazenamento desses serviços remotos. Com partes do application plane agora implantadas em diferentes ambientes, o cliente também precisará garantir que esses serviços remotos sejam protegidos, resilientes e acessíveis aos provedores SaaS. O restante da aplicação ainda é executado na conta de nuvem do provedor SaaS. Isso permite otimizar o desempenho e o custo ao colocar apenas os serviços mínimos no ambiente do cliente.

Na arquitetura de exemplo (Figura 4), o control plane e parte do application plane estão em execução na conta da AWS do provedor SaaS. No ambiente do cliente, há serviços de aplicações remotos implantados pelo provedor SaaS que podem processar dados e executar ações com recursos remotos. Por exemplo, um serviço remoto pode executar tarefas relacionadas ao produto no ambiente em que está implantado e, eventualmente, enviar metadados de volta ao ambiente do provedor SaaS.

Figura 4 — Exemplo de arquitetura para application plane distribuído.

Application plane remoto

No modelo de application plane remoto, o control plane é implantado na conta do provedor SaaS e todo o application plane é implantado na conta do tenant. A figura abaixo (Figura 5) fornece um exemplo desse padrão.

Figura 5 — Application plane remota.

O modelo de application plane remoto pode ser uma opção quando os requisitos de tenant, domínio e/ou segurança criam a necessidade de hospedar recursos de aplicações remotamente. Como todos os recursos da sua aplicação são implantados na conta do tenant, o tenant também terá a responsabilidade de proteger esses recursos. Mesmo nesse cenário, o provedor SaaS ainda usuaria um control plane centralizado para gerenciar esses applications planes de tenants remotos.

Na arquitetura de exemplo mostrada abaixo (Figura 6), o application plane está em execução na conta do cliente e se conecta ao control plane executado na conta do provedor SaaS. Especificamente, o cluster Amazon Elastic Kubernetes Service (Amazon EKS) implantado na conta do cliente se comunica com o control plane na conta do provedor SaaS. Os microsserviços no cluster EKS têm acesso aos conjuntos de dados que residem na conta do cliente.

Ao ter o control plane na conta do provedor e o application plane na conta do cliente, essa arquitetura separa a camada de gerenciamento da camada de aplicação em todas as contas. Isso permite que o provedor gerencie as plataformas enquanto mantém os recursos do tenant isolados no ambiente do cliente.

Figura 6 — Exemplo de arquitetura para application plane remota.

Conclusão

Nesta postagem, abordamos algumas considerações comuns associadas aos recursos de implantação em um ambiente remoto, como o impacto na integração de novos tenants e a responsabilidade compartilhada pelo gerenciamento desses recursos remotos. Também descrevemos três modelos de implantação diferentes, juntamente com uma arquitetura de amostra para cada modelo.

Se você estiver projetando uma solução SaaS com serviços executados em um ambiente remoto, considere cuidadosamente o objetivo de negócio que deseja alcançar e determine se o SaaS Anywhere é a abordagem certa para a solução. Se o SaaS Anywhere for necessário, você deve identificar qual modelo é o mais apropriado e minimizar o espaço remoto para atingir sua meta sem comprometer a agilidade e a velocidade da inovação da solução SaaS.

Sobre o AWS SaaS Factory

O AWS SaaS Factory ajuda organizações em qualquer estágio da jornada de SaaS. Seja para criar novos produtos, migrar aplicativos existentes ou otimizar soluções de SaaS na AWS, podemos ajudar. Visite o AWS SaaS Factory Insights Hub para descobrir mais conteúdo técnico e comercial e melhores práticas.

Os criadores de SaaS são incentivados a entrar em contato com seu representante de conta para obter informações sobre modelos de engajamento e trabalhar com a equipe do AWS SaaS Factory.

Explore os recursos atuais para qualquer estágio de sua jornada de SaaS, desde o design e a construção até o lançamento e a otimização.

—

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