SaaS Factory (A série) — Entendendo a arquitetura do SaaS Factory (Parte 1/4)

O objetivo deste post é fornecer uma introdução às terminologias, estratégias e padrões básicos que são aplicados ao criar produtos SaaS na AWS. Este material apresenta um modelo mental que pode ser usado ​para mergulhar mais profundamente no conteúdo técnico de SaaS.

Primeiramente, precisamos definir o que é software como serviço. SaaS refere-se a como licenciar e entregar software de forma centralizada, gerenciada e hospedada por um provedor, disponibilizando o software aos clientes em um modelo de subscrição ou pagamento pelo uso.

Quando falamos sobre Software como Serviço, habitualmente focamos muito nos aspectos de tecnologia. Como toda solução de software, há um foco natural em entender e implementar as nuances técnicas para atender aos requisitos de produto. Entretanto, a prática de implementação e migração de softwares como serviço na AWS nos mostram que há diversas práticas e abordagens que precisam ser tratadas para garantir que um modelo de SaaS está sendo implementado da melhor forma possível.

A prática mostra que habitualmente temos quatro grandes pilares:

• Tecnologia: como são separados e particionamos os dados, como a infraestrutura é arquitetada e provisionada, com um novo locatário é integrado ao ambiente;
• Modelo Operacional: como é gerenciada a saúde do ambiente geral, como um locatário impacta em outro, como são abordados os aspectos de confiabilidade geral e individual de cada locatário;
• Modelo de Entrega: como o software é entregue ao cliente, quais são os mecanismos de sign-up e integração (on boarding) no ambiente, como o tenant é alocado e provisionado para o cliente;
• Estratégia de Negócio: como o produto é entregue e como são construídas as estratégias de produto, quais são os tiers oferecidos, qual o modelo de custo e de venda, como são bilhetados os custos de uso.

A estrutura geral de Software como Serviço

A estrutura geral de software como serviço começa pela identificação do locatário (tenant). O locatário é a menor unidade consumidora de um produto de SaaS. É o cliente, propriamente dito. A partir da identificação deste, a primeira etapa da jornada de SaaS passa pelo processo de integração inicial (on boarding). É fundamental que o processo de assinatura seja o menos custoso e menos “doloroso” possível. Ou seja, não pode haver nenhuma barreira que dificulte o processo de entrada de um novo cliente.

O segundo ponto na estrutura geral de SaaS refere-se ao nível de isolamento deste locatário na infraestrutura. Por exemplo: haverá segregação de ambiente para aquele cliente em específico? Os recursos computacionais utilizados por ele são individuais ou compartilhados? Pode haver, de alguma forma, interseção entre um locatário e outro?

Para que este gerenciamento em nível de infraestrutura do locatário possa ser realizado, é fundamental que haja um painel de controle operacional por locatário. Deve-se prever um subconjunto de recursos ou funcionalidades que permitam, de forma rápida, identificar o contexto geral do software como serviço, porém, individualmente por locatário.

E para que essa gestão seja possível, é fundamental que sejam produzidos dados e informações sobre todo o ambiente de SaaS, cada locatário, cada componente de infraestrutura, bem como de utilização e operação geral do software.

O modelo mental do Multi Tenancy

O termo “multilocação de software” (multi tenancy) refere-se a uma arquitetura de software na qual uma única instância do software é executada em um servidor (ou recurso computacional) e atende a vários locatários (tenants).

Os sistemas projetados dessa maneira costumam ser chamados de compartilhados (em contraste com dedicado ou isolado). Um locatário é um grupo de usuários que compartilham um acesso comum com privilégios específicos para a instância do software. Com uma arquitetura multilocatária, uma aplicação de software é projetada para fornecer a cada locatário um compartilhamento dedicado da instância — incluindo seus dados, configuração, gerenciamento de usuário, funcionalidade individual do locatário e propriedades não funcionais. A multilocação contrasta com arquiteturas de várias instâncias, em que instâncias de software separadas operam em nome de diferentes locatários.

O que vemos na prática em Multi Tenancy

Ainda que no contexto geral de SaaS tenhamos observado que uma abordagem de contextos compartilhados de infraestrutura seja naturalmente vislumbrado, o que vemos na prática é diferentes abordagens de alocação e arquitetura para SaaS.

• Modelo Silo: refere-se a uma arquitetura em que os locatários recebem recursos dedicados. Imagine, por exemplo, um ambiente SaaS em que cada locatário de seu sistema possui uma pilha de infraestrutura totalmente independente. Ou talvez cada locatário do seu sistema tenha um banco de dados separado para cada locatário. Quando alguns ou todos os recursos de um locatário são implantados dessa forma dedicada, nos referimos a isso como um modelo de silo. É importante observar que, embora o silo tenha recursos dedicados, um ambiente de silo ainda depende de uma identidade compartilhada, integração, e experiência operacional em que todos os locatários são gerenciados e implantados por meio de uma construção compartilhada. Isso diferencia o SaaS de um modelo de serviço gerenciado em que os clientes podem executar versões separadas de seu produto com experiências separadas de integração, gerenciamento e operação;
• Modelo Pool: refere-se a um cenário em que os locatários compartilham recursos. Essa é a noção mais clássica de multilocação, em que os inquilinos contam com uma infraestrutura escalonável e compartilhada para obter economias de escala, capacidade de gerenciamento, agilidade e assim por diante. Esses recursos compartilhados podem ser aplicados a alguns ou todos os elementos de sua arquitetura SaaS, incluindo computação, armazenamento, mensagens, etc;
• Modelo Bridge: refere-se arealidade de que os negócios de SaaS nem sempre são exclusivamente silo ou pool. Em vez disso, muitos sistemas têm um modo misto, em que parte do sistema é implementada em um modelo de silo e outra parte em um modelo em pool. Por exemplo, alguns microsserviços em sua arquitetura podem ser implementados com silo e outros podem usar pool. O perfil regulatório dos dados de um serviço e seus atributos de vizinho ruidoso podem direcionar um microsserviço para um modelo de silo. Enquanto isso, a agilidade, os padrões de acesso.

No próximo post, falaremos sobre os benefícios e adversidades de cada modelo e Software como Serviço entregue com Agilidade.

SaaS Factory (A série) — Como construir soluções de Software como Serviço na AWS

Até o próximo post! =)