SaaS Factory (A série) — Entendendo a arquitetura do SaaS Factory (Parte 3/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: Os benefícios e adversidades de cada modelo e Software como Serviço entregue com Agilidade. No post de hoje, falaremos sobre Operações de Software como Serviço.

Operações de Software como Serviço

Os ambientes SaaS exigem uma pegada de operações robusta e responsiva. Ter uma visão precisa e proativa da integridade do seu sistema é essencial para maximizar a confiabilidade do seu ambiente SaaS. A arquitetura de SaaS viabiliza o aproveitamento de uma rica coleção de ferramentas para criar visualizações robustas e com reconhecimento de locatário da atividade e políticas do locatário para gerenciar a integridade do sistema.

Monitoramento em nível de locatário

É importante identificar estratégias e ferramentas específicas que podem ser combinadas para oferecer suporte ao conjunto exclusivo de desafios operacionais que os provedores de SaaS enfrentam. Neste sentido, a análise, o consumo e as métricas de aplicativo podem correlacionar a atividade do locatário com a integridade do sistema para identificar e solucionar problemas de forma proativa. Também deve-se explorar técnicas para monitorar e gerenciar diferentes modelos de isolamento de locatário SaaS, como silo, pool e assim por diante.

Modelo proativo de operações

O conexto multilocatário de SaaS requer que toda a operação seja observada e analisada de forma proativa. O estabelecimento de um guia de trabalho (framework) ajuda a estruturar este processo. Basicamente, o processo de monitoramento em SaaS considera três componentes:

• Métricas de Sistemas/Locatários: Deve-se definir os SLAs dos locatários, analisar o consumo dos locatários, estabelecer limiares (tier thresholds), processo de embarque (on-boarding) de locatário, e acompanhar métricas de atividades;
• Políticas: Com o estabelecimento das métricas, são definidas as políticas de ações a partir da análise destas. As políticas definem os diferentes fluxos estabelecidos a partir dos dados coletados do ambiente;
• Alertas, automações e notificações: As políticas previamente mencionadas, definirão o fluxo de como a partir de um dado gatilho, alertas e alarmes serão acionados, a partir destes gatilhos algumas ações são disparadas automaticamente e os clientes são devidamente notificados.

Este fluxo garante uma operação proativa e, principalmente, confiável.

Agregando dados técnicos e de aplicação

Ainda sobre monitoramento, uma importante prática é a adoção de métricas horizontais. Muito mais do que analisar os contextos sob uma perspectiva de componentes — bancos de dados, servidores, funções e etc — é compreender o ciclo de vida horizontal de um serviço. Por exemplo: para que uma aplicação web funcione, diferentes componentes precisam estar funcionais — serviços de frontend, servidores web, servidores de aplicação, servidores de banco de dados… Neste caso, se eventualmente houver falha ou perda de qualidade em um componente, possivelmente, haverá prejuízo para todo um serviço. Neste caso, é fundamental garantir que a camada de monitoramento analise não apenas o contexto de cada componente individualmente, mas sim, todo um serviço, fim a fim.

No próximo post, falaremos sobre Arquitetura de Software como Serviço.

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

Até lá =)