Na QCon Londres 2025, o Embaixador da AWS Jon Topper fez uma palestra sobre os erros comuns que as empresas cometem ao construir soluções SaaS (Software como Serviço).
“Construir, implantar e operar software é difícil, e isso se aplica em dobro quando se trata de SaaS,” disse Topper, fundador da The Scale Factory (agora parte da Ten10). Um tema recorrente de sua palestra foi como as equipes podem, muitas vezes acidentalmente, complicar a vida de seus futuros eu. Ele destacou o quanto a sabedoria pode vir de comunidades e grupos de usuários, “eles nos permitem ouvir as lições das pessoas e entender seus erros antes de cometê-los nós mesmos.”
Topper começou sua palestra explicando como o software tradicional pode ser enviado em mídias ou como artefatos baixáveis discretos para os usuários instalarem como desejarem, mas as soluções SaaS vêm com a complexidade de serem fundamentalmente projetadas para hospedar múltiplos inquilinos. Ele apontou a escala do SaaS no espaço de software contemporâneo: metade do capital de risco investido em empresas em todo o mundo em 2024 foi para negócios SaaS, de acordo com a Dealroom.
Topper instou as pessoas a pensarem em arquitetar para multi-inquilinos desde o início. Ele explicou que muitos produtos SaaS evoluem de aplicações empresariais destinadas a um único inquilino e aventurou que não considerar a multi-inquilinos desde o início pode dificultar significativamente as opções de escalabilidade mais tarde. Ele também sugeriu calcular imediatamente os custos básicos por inquilino e garantir que esses se encaixem no preço que o mercado precisa.
Se você não está pensando sobre inquilinos no primeiro dia, você está caminhando para poder apenas construir o modelo silo.
Refletindo sobre o fato de que as equipes de desenvolvimento geralmente estão ocupadas inovando e iterando em novos recursos, geralmente cabe a elas provisionar ambientes para novos potenciais clientes, e isso pode estar frequentemente baixo em suas prioridades. Assim, Topper aconselha a automatizar o provisionamento de inquilinos desde cedo para evitar que a equipe de desenvolvimento se torne um gargalo para o lado comercial do negócio.
Voltando a como realmente construir aplicações SaaS na nuvem, Topper descreveu três principais modelos arquitetônicos: o modelo “pool”, onde tudo é compartilhado; o modelo “silo”, onde cada cliente tem infraestrutura única dedicada; e uma opção de modelo “bridge” no meio, onde alguns recursos são compartilhados, mas alguns são dedicados por cliente. Ele afirmou que os requisitos regulatórios em indústrias como saúde, ciências da vida e finanças podem às vezes levar as pessoas a optar pelo modelo silo, observando que o modelo silo tem custos básicos mais altos e é mais complicado, mas oferece o maior isolamento.
Ele conceitualizou a arquitetura SaaS como tendo dois componentes: o plano de aplicação (aplicação web, serviços, gateway de API, banco de dados) e o plano de controle (camada de orquestração, integração de inquilinos, automação de cobrança). Ele defendeu fortemente o uso do AWS Control Tower e Landing Zones para fornecer guardrails de segurança e consistência entre contas.
Topper alertou fortemente sobre os perigos das personalizações por cliente e permitir que os clientes determinem os horários de liberação. “Entregar recursos únicos ou diferentes versões para inquilinos matará as equipes de operações se você não tomar cuidado.” Ele defendeu uma forte filosofia de produto que inclui estar confortável com o “não estratégico” quando os clientes pedem recursos que não estão alinhados com o roadmap atual do produto.
Se você permitir que os clientes dictem quando ou onde as atualizações de software acontecem, então você está incorporando complexidade operacional e sacrificando seus finais de semana.
Ele também aconselhou contra implantar software nas contas da AWS de seus clientes, apesar dos pedidos dos clientes, explicando que “filosoficamente isso não é realmente SaaS – é apenas vender software,” e evitar tentar ser multi-nuvem; “como um negócio em estágio inicial, você não deve se preocupar em construir em mais de uma plataforma até ter saturado o mercado para pessoas que comprarão a versão AWS.”
Topper recomendou fazer um planejamento adequado de recuperação de desastres e segurança, citando a sabedoria do CTO da AWS, Werner Vogels, de que “tudo falha o tempo todo”. Ele sugeriu realizar exercícios de pré-morte para começar com isso. Sobre o tópico de dados, ele propôs construir um modelo de segurança baseado no desenvolvimento de uma compreensão de onde seus dados estão e quem tem responsabilidade por eles.
Resumo: Dez coisas que as pessoas erram ao construir aplicações SaaS:
Construir algo que os usuários não querem
Não construir conceitos de inquilinos nos componentes da aplicação
Não calcular os custos básicos por inquilino e testar isso com o mercado
Não automatizar o provisionamento de inquilinos
Entregar recursos únicos ou diferentes versões para inquilinos
Implantar seu software nas contas AWS de seus clientes
Construir sua solução para ser multi-nuvem ou agnóstica em nuvem
Implantar sua solução localmente para clientes
Não pensar suficientemente sobre backups e recuperação de desastres
Não classificar ativos de dados
Ouvir consultores em vez de entender sua base de clientes