Introdução

Nota 1: Aqui está a demonstração interativa hospedada: demo.saasconstruct.com

Nota 2: Minha fatura mensal para cada configuração de SaaS é de 3 a 5$ por mês, e é principalmente custos de CI/CD.

Nota 3: o modelo está aqui: saasconstruct.com.

Já fiz vários AI PoCs e MVPs na AWS, e são sempre coisas semelhantes:

• Hospede o front-end em algum lugar
• Faça uma chamada para o back-end
• O back-end obtém/atualiza dados do armazenamento/banco de dados binário
• O back-end faz alguma lógica de IA ou chama outro serviço e envia de volta o resultado
• Existem duas contas AWS isoladas: dev e prod
• CI/CD para implantações
• Infraestrutura como código para declaração de recursos em nuvem

Então, pensei em criar uma solução simples para inicializar essas coisas na AWS. E escreva uma postagem no blog sobre isso.

Decidi adicionar alguns recursos, como pagamentos Stripe (e pagamentos LemonSqueezy se você não quiser se preocupar com imposto sobre vendas/IVA) e gerenciamento de pagamentos, autenticação, alarmes de trânsito e outros. Também pensei que precisava ser configurável, como substituir API Gateway e AWS Lambda por ELB e ECS para tarefas mais longas.

Front-end

Eu escolhi a estrutura comumente declarada mais fácil para começar. É Vue e, até onde eu entendi, o segundo framework mais popular que existe. Eu escolhi porque não só é o mais fácil, mas também porque tenho alguma experiência com ele.

O site é um aplicativo SPA padrão com Vite como ferramenta de construção. Para estilização, eu uso Bootstrap porque também é muito fácil de trabalhar e também porque não causa muita dor ao migrar de uma versão do framework frontend para outra.

Hospedagem de front-end

Existem duas opções:

• S3 e CloudFront (CDN)
• AWS Amplify Hosting, que é um wrapper do S3 e do CloudFront, fácil de trabalhar, mas menos configurável. Por exemplo, você não pode fazer nada com a distribuição do CloudFront, pois ela não é visível. Você também não pode bloquear geograficamente seu aplicativo, exceto fazendo isso com redirecionamentos.

Eu optei pelo Amplify Hosting como foco principal da AWS em soluções de hospedagem front-end e porque é fácil de configurar, anexar um domínio, etc.

Como é uma base pré-paga, configurei um alarme de trânsito: se houver mais do que um certo número de acessos a cada 10 segundos, recebo uma notificação.

Back-end

O back-end é o API Gateway, que faz a limitação de taxa, e o AWS Lambda (Python), que faz o negócio e a lógica geral:

• Verificando se o usuário está autenticado
• Processamento de pagamentos e gerenciamento de assinaturas (portal do cliente)
• Envio de e-mails
• etc.

Também tenho outra função AWS Lambda que cria um usuário no banco de dados após se inscrever no Cognito.

Existem utilitários compartilhados onde coloco algumas funcionalidades compartilhadas, por exemplo, envio de e-mail. Além disso, a funcionalidade de registro, por exemplo, um e-mail é enviado para mim se houver um erro de pagamento.

Autenticação

A autenticação é uma dor, eu sei, e não queria usar um serviço de terceiros. Então fiquei com o AWS Cognito. É muito barato.

Você pode dizer, basta usar AWS Amplify Auth (que é um wrapper do AWS Cognito), mas tive alguns problemas com ele. Até escrevi um post no Reddit:

Minha lista de problemas com o Amplify para autenticação

E há outro post com uma lista ainda maior de algum usuário frustrado (embora seja um post antigo).

aqui

Além disso, se você usar apenas o Amplify, ficará preso a todo o ecossistema, sem chance de mudar alguma coisa. Por exemplo, se você deseja ter acesso à distribuição do CloudFront (por exemplo, quando deseja bloquear geograficamente determinadas regiões), azar, você não pode ver isso com o Amplify Hosting. Eu também tive outros problemas: um dos exemplos foi a criação de CDK a partir de recursos do Amplify, o que foi um problema para mim.

Então, o que fiz foi uma abordagem híbrida (que é um tanto popular de acordo com o Reddit): a biblioteca AWS Amplify JS permite que você importe recursos de nuvem que você mesmo cria, como grupos de usuários, então eu os criei com CDK e depois usei a biblioteca Amplify JS para autenticação.

Nesse caso, posso sempre alterar o que quiser, trocar recursos da nuvem (por exemplo, poderia passar do Amplify Hosting para o CloudFront S3 se precisar de acesso à distribuição do CloudFront).

E-mails

AWS SES. É o principal serviço de e-mail da AWS. Ele envia tudo, incluindo e-mails de autenticação Cognito, solicitações do formulário de contato, etc. A única coisa que você precisa entender é que em sua conta dev AWS, você precisará primeiro criar identidades verificadas para poder enviar (eu automatizei via IaC) e na conta AWS de produção, você precisará solicitar acesso de produção (que leva apenas alguns cliques).

Usando o AWS SES, notificações por e-mail são enviadas nos seguintes cenários:

• Quando ocorrem erros de pagamento.
• Em caso de picos no tráfego da web.
• Se a implementação do CI/CD falhar.
• Para outras situações, como e-mails de autenticação e consultas do formulário de contato, etc.

Armazenar

DynamoDB como um banco de dados. Fácil, rápido e gerenciado. Sim, tive que pensar em padrões de acesso, mas geralmente é bom trabalhar e também não me custa nada enquanto valido/construo. Como pretendo trabalhar em vários produtos e quero mantê-los isolados, não posso colocar RDS/DocumentDB em contas de desenvolvimento e produção por projeto (custa muito caro).

Pagamentos

Adicionei dois sistemas de pagamento, e é possível escolher qual usar porque funcionam de forma semelhante:

• Stripe é popular e fácil de integrar, puro e simples. Quando um usuário compra um produto, eu uso o checkout do Stripe e, para gerenciar assinaturas, uso o portal do cliente Stripe.
• LemonSqueezy é muito semelhante ao Stripe, mas também é um Merchant of Record, o que significa que ele lida com impostos sobre vendas/IVA para você. Possui também checkout para compra de assinatura e portal do cliente para gerenciamento.

Existem endpoints que escrevi para os webhooks Stripe/LemonSqueezy, que lidam com toda a lógica.

Infraestrutura como código

Portanto, há muitas coisas para escolher:

• Algo como Terraform ou OpenTofu (alternativa totalmente de código aberto baseada em Terraform)
• Pulumi
• CDK
• Formação em nuvem

Eu escolhi AWS CDK, e aqui estão meus motivos:

• É fácil de trabalhar
• É popular e maduro o suficiente
• É muito melhor que AWS CloudFormation, na minha opinião
• É uma biblioteca AWS e eu uso AWS
• Posso escrever em Python, TypeScript ou outras linguagens. Como uso Python no backend e TypeScript no frontend, é uma boa escolha.

A razão pela qual não escolhi o Terraform é que o CDK é mais fácil; permite criar recursos de forma simples, pelo menos na minha opinião. Gosto de OOP e tento construir minha infraestrutura em nuvem de acordo. Um grande benefício é que CI/CD está incluído (pipelines CDK), então não preciso inventar isso.

CI/CD

Escolhi pipelines CDK porque é, novamente, fácil. Basta conectar o pipeline ao repositório GitHub e pronto. Git push para o branch de desenvolvimento -> será implementado na conta de desenvolvimento. Git push para o principal (ou pull request) -> implementação de produção.

Alarmes e limites de taxa

Configurei o Rate Limiting para evitar spam através do gateway da API. Configurei dois alarmes do CloudWatch:

• Para me alertar quando o site hospedado estiver recebendo spam com solicitações.
• Para me alertar quando o API Gateway estiver recebendo spam com solicitações.

Também configurei alarmes de cobrança para me informar se estou prestes a gastar muito.

Registro

CloudWatch registra os eventos, você pode vê-los no Console AWS e diretamente no IDE por meio de extensões.

IA

A escolha foi entre usar OpenAI (com modelos GPT) ou AWS Bedrock (com modelos Claude). Essa decisão foi desafiadora porque, embora o AWS Bedrock com Claude se integre facilmente à AWS, o OpenAI é mais comumente usado. Ambas as empresas oferecem modelos de IA de primeira linha. Por enquanto, optei por ficar com o AWS Bedrock. Isso pode mudar no futuro, mas por enquanto, aprecio a simplicidade. Para o banco de dados vetorial, eu uso o Pinecone, que possui índices sem servidor.

Um exemplo de aplicativo de IA que construí aqui é um sistema RAG, que é essencialmente um chatbot que pode responder perguntas com base em seus dados. Você armazena as informações em um banco de dados vetorial, e na consulta, você faz uma busca por similaridade, e depois é só usar o LLM para dar uma resposta com base no resultado dessa busca. Atualmente utilizo modelos simples para evitar custos, mas mudar para modelos diferentes é tão simples quanto alterar uma linha de código.

Linguagens de programação

Inicialmente fui um desenvolvedor Java, mas depois me tornei um desenvolvedor Python porque desenvolvi serviços de aprendizado de máquina e aprendizado profundo. A maioria das bibliotecas nesse espaço são desenvolvidas em Python ou apresentam um wrapper Python. Além disso, Python integra-se perfeitamente com AWS, seja em AWS Lambda (por exemplo, usando a biblioteca AWS Lambda Powertools) ou em CDK. Então, no final das contas, tanto o backend quanto a infraestrutura de nuvem (via CDK) são implementados em Python.

Minha linguagem secundária é TypeScript devido à sua popularidade com frameworks frontend. Embora eu trabalhasse com JavaScript, achei a ausência de tipos confusa à medida que a base de código crescia. A digitação estática do TypeScript fornece a clareza e segurança necessárias durante o desenvolvimento, especialmente em grandes projetos.

Faturas da AWS

Como não tenho uma carga de tráfego alta, meus custos com AWS são muito baixos, normalmente $3-5 por mês, principalmente devido às despesas de CI/CD.

A configuração inclui um CDN (fornecido pela Amplify Hosting) e uma pequena camada de cache no AWS Lambda. Além disso, alguns serviços se enquadram no Nível gratuito da AWS, o que reduz ainda mais meus custos.

À medida que o produto é dimensionado e ganha mais usuários, talvez seja necessário otimizar recursos mudando para o DynamoDB provisionado e implementando o DAX (Acelerador DynamoDB). No entanto, por enquanto, esta configuração funciona perfeitamente.

Conclusão

Esta solução atende minhas necessidades atuais de forma eficiente.

Incluí toda essa pilha de tecnologia como um boilerplate (que desenvolvo e atualizo ativamente) em meu modelo AWS no SaaSConstruct.

Continuarei explorando recursos adicionais que podem ser incorporados a esta configuração para aprimorar suas capacidades...