SaaS Factory (A série) — Entendendo a arquitetura do SaaS Factory (Parte 4/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.

No post anterior, falamos sobre Operações de Software como Serviço. No post de hoje, falaremos sobre Arquitetura de Software como Serviço.

Arquitetura de Software como Serviço

Se você está mergulhando no SaaS, é importante compreender a visão geral dos princípios de arquitetura e práticas recomendadas de SaaS. Um dos princípios fundamentais do SaaS, é a agilidade que normalmente estão por trás da mudança de uma organização para um modelo de entrega de Software como Serviço, a visão operacional do SaaS e os elementos arquiteturais centrais dos ambientes SaaS.

Para apoiar nesta questão, a AWS desenvolveu o SaaS Enablement Framework (SEF) . Essa estrutura serve como uma agregação ponta a ponta dos padrões e práticas comuns que são freqüentemente usados ​​para construir e entregar soluções SaaS na pilha de serviços da AWS. A estrutura aborda os temas comuns associados à adoção de uma abordagem mais ágil para entregar soluções em uma assinatura, mentalidade pague conforme o uso. É importante observar que a estrutura não é um conjunto formal de ferramentas ou tecnologias. O objetivo é fornecer às organizações SaaS uma visão mais clara dos modelos comuns e sistemas de valores que devem ser considerados ao fornecer soluções SaaS na AWS.

Componentes centrais do SaaS

Considerações de locação e negócios apresentam uma camada de melhores soluções específicas de SaaS e práticas que afetam a maioria das dimensões da pilha de serviços. Para um contexto de SaaS, componentes específicos precisam ser abordados individualmente, com a proposta de estratégias individuais para cada caso.

Os componentes centrais do SaaS são:

• Embarque (on-boarding) de locatário;
• Aplicação;
• Identidade;
• Isolamento de locatário;
• Particionamento de Dados;
• Perfile e análises;
• Gestão e monitoramento;
• Métricas e faturamento.

Embarque (on-boarding) de locatários

As soluções SaaS geralmente oferecem suporte a uma variedade de mecanismos diferentes para acessar o ambiente SaaS. Este processo também abrange os elementos básicos de integração de novos usuários, gerenciamento de suas contas e provisionamento da área de cobrança.

Neste estágio, considero que está moldando e estruturando uma discussão mais profunda dos vários modelos que podem ser aproveitados para atender às metas de agilidade de SaaS de seu negócio. É importante observar que a estrutura representa uma gama de possibilidades de SaaS. Evita intencionalmente sugerir que existe um modelo preferido.

A realidade do SaaS é que não existe um modelo que se adapte a todos os ambientes. A chave, então, é simplesmente montar a paleta de opções, pesar as compensações e selecionar o modelo (ou híbrido de modelos) que melhor se adapta às necessidades atuais e de longo prazo de seu mercado e dinâmica de negócios.

Componente de Aplicação, Identidade

Certamente, o protagonista na ofertade Software como Serviço, é o próprio software. SaaS está muito mais focado em endereçar o “como” o produto é entregue aos clientes finais, do que sobre “por quê” o tal software existe ou mesmo “o quê” ele é.

Em contextos de SaaS, habitualmente o componente de aplicação precisa prever pelo menos três temas: Identidade, Isolamento de Locatários e Particionamento de Dados. No que se refere a identidade, a criação de perfil envolve a coleta e correlação de dados que podem informar a forma técnica e de negócios de sua oferta de SaaS. A estrutura descreve os diferentes tipos de dados que podem ser coletados para construir uma visão robusta da atividade em seu sistema. Este perfil geralmente inclui a agregação de dados de atividade do usuário e consumo de recursos.

Componente de Aplicação, Isolamento de locatários

Como vimos anteriormente, 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.

Componente de Aplicação, Forçando o isolamento de locatários

Como definiu Tod Golding (Arquiteto de Soluções de Parceiros da AWS), o desenvolvimento de um perfil de locatário envolve a compreensão dos sistemas de valores e forças de domínio que influenciarão a disposição do cliente em adotar sua solução SaaS. Sua capacidade de entender e categorizar as necessidades do cliente pode ajudar a determinar como e onde você pode precisar oferecer suporte a variações de inquilino em seu design e arquitetura subjacentes.

Quando abordamos o isolamento de locatários, é importante identificar todo o ciclo de vida de utilização destes, desde a alocação de recursos — como buckets S3, tabelas DynamoDB, entre outros como também todo o seu ciclo de vida de utilização do software, isolando-o horizontalmente — ante a cada componente do software.

Ainda assim, haverão casos em que certos componentes serão compartilhados integralmente, não sendo possível, porém, identificar a porção de uso de cada locatário naquele recurso — como uma fila SQS, conforme exibido acima. Neste sentido, há se considerar métodos externos para identificação do uso e consumo de um locatário daquele recurso compartilhado. No exemplo acima, poderia-se contabilizar o volume de dados trafegados por um único locatário em uma dada janela de tempo, por exemplo.

Componente de Aplicação, Particionamento de dados

Conforme você projeta, desenvolve e constrói soluções de software como serviço (SaaS) na Amazon Web Services (AWS), você deve pensar sobre como deseja particionar os dados que pertencem a cada um de seus clientes, que são comumente referidos como locatários em um ambiente SaaS.

Existem vários fatores (vizinho barulhento e isolamento de dados, por exemplo) que influenciam como você escolhe armazenar os dados do locatário. Você pode escolher armazenar seus dados em construções de armazenamento separadas usando um modelo de “silo” ou pode escolher agrupar seus dados em um modelo de “pool”.

Antes de nos aprofundarmos em estratégias específicas, vamos começar falando sobre como os dados são geralmente particionados em um modelo agrupado. A ideia básica do modelo agrupado é que os dados de todos os locatários sejam armazenados em uma única estrutura — que pode ser isolada em nível de locatário, por base de dados ou mesmo por identificador do locatário dentro do modelo de dados, fazendo com que estes sejam identificados por meio de um identificador de locatário, como TenantID.

Existem muitas abordagens para armazenar dados em ambientes multilocatários. Os arquitetos SaaS devem identificar a combinação de estratégias de particionamento de dados que alinharão as necessidades de escala, isolamento, desempenho e conformidade de seu ambiente SaaS. O particionamento de dados é influenciado pelo modelo multilocatário que você está adotando e pelas diferentes abordagens de fragmentação disponíveis para cada um dos serviços de armazenamento da AWS.

Com este post, chegamos ao fim da primeira parte da nossa série sobre como entender a arquitetura do SaaS Factory. Continuem acompanhando o blog para os próximos capítulos da série.

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

Até o próximo post! =)