Recentemente, embarcamos em uma jornada de seis meses para construir um serviço de banco de dados vetorial em nuvem na Zilliz. Na parte 1 desta série, mergulhei em nossos objetivos de design e forneci uma visão geral de nossa arquitetura final.
Aqui quero destacar alguns dos nossos principais insights e lições aprendidas ao longo do caminho. Meu objetivo é oferecer informações valiosas que podem ajudá-lo enquanto você navega no processo de construção de sua própria solução de Software como Serviço (SaaS).
Mesmo com sistemas nativos da nuvem como Milvus, a transição para SaaS na nuvem apresenta desafios significativos. Ele vai além de uma simples implantação no Amazon Web Services (AWS), no Elastic Compute Cloud (EC2) e no Elastic Block Store (EBS). Os usuários de bancos de dados de código aberto devem ter um conhecimento profundo das complexidades do produto para obter escalabilidade horizontal, recuperação de falhas e otimização de desempenho por meio de ajustes meticulosos de botões. O verdadeiro desafio dos serviços em nuvem reside na simplificação das operações, mantendo ao mesmo tempo alta confiabilidade e elasticidade. Lidar com restrições específicas do ambiente de nuvem, como limites de taxa do Amazon Simple Storage Service (S3) e limitações na frequência de chamadas OpenAPI, é crucial para capitalizar totalmente o potencial de elasticidade e escalabilidade da computação em nuvem.
Embora adicionar continuamente novos recursos nos estágios iniciais do produto possa parecer a coisa certa a fazer para atrair clientes, priorize abordar os verdadeiros pontos fracos dos usuários. Manter um prazo de entrega de aproximadamente seis meses para recursos de produtos de código aberto em relação à versão SaaS é um bom compromisso. Esse prazo ajuda a garantir que esses recursos sejam submetidos a testes e melhorias completos antes de serem implementados para prestação de serviços.
Nenhum produto é perfeito. Veja S3, por exemplo. Apesar de sua interface elegante e extenso refinamento, os desenvolvedores podem maximizar seu valor apenas em determinadas situações. Ao contrário da liberdade que os produtos de código aberto têm, os produtos SaaS exigem salvaguardas e restrições mais rigorosas. Essas restrições são parte integrante do produto e servem como orientação e educação para os usuários. Limitações razoáveis podem orientar os usuários para um uso mais inteligente do produto, aumentando o valor geral e a experiência do usuário.
Considerando a adoção de serviços independentes da nuvem, como S3, EC2 e Kubernetes, os serviços gerenciados (que estão amplamente disponíveis nas principais plataformas de nuvem) podem oferecer benefícios substanciais em termos de redução de custos e simplificação das complexidades da adoção multicloud. Alternativamente, optar por serviços SaaS que suportam inerentemente o uso de multicloud pode agilizar o processo. Apesar das possíveis variações na implementação entre diferentes provedores de serviços de nuvem, o estabelecimento precoce de uma camada de adaptação multicloud pode efetivamente minimizar esforços de desenvolvimento redundantes e aumentar a eficiência geral.
Na nuvem pública, recursos aparentemente acessíveis podem resultar inesperadamente em custos elevados. Por exemplo, antes de realizar uma análise de faturas, não prevíamos que os custos de largura de banda de rede pudessem constituir uma parcela significativa das despesas gerais. Para otimizar custos e maximizar o desempenho, é essencial compreender completamente o desempenho de diferentes tipos de instância e serviços. Por exemplo, cada disco de nuvem AWS gp3 oferece 3.000 operações de entrada/saída por segundo (IOPS); agrupar vários discos em uma única máquina e configurar o RAID pode aumentar substancialmente o rendimento do disco, evitando assim contas pesadas para IOPS adicionais.
A crescente adoção de agentes de inteligência artificial (IA) significa que o papel da OpenAPI e da documentação relacionada é cada vez mais importante. Os serviços de nuvem tradicionais dependem de consoles web e interfaces gráficas para fornecer funcionalidade, mas a futura interação e integração dos serviços de nuvem dependerá cada vez mais do OpenAPI. A automação de serviços, a facilidade de uso dos agentes e a observabilidade tornaram-se critérios de avaliação essenciais para futuros serviços em nuvem.
Espero que compartilhar nossas experiências ajude os desenvolvedores que estão iniciando sua própria jornada de construção de um SaaS. Olhando para trás, tenho orgulho de que nossa equipe tenha feito muito e também tenha tido a oportunidade de aprender ao longo do caminho, o que o tornou ainda mais gratificante.
Se você quiser conversar sobre sua experiência ou saber mais, conecte-se comigo no GitHub ou LinkedIn. Se esse tipo de trabalho parece interessante para você, confira nossa página de carreiras e junte-se a nós! Teremos muitos mais projetos como esse pela frente!
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
