Quais configurações de servidor vocês usam em seus projetos? Devem confiar na Amazon Web Services para tudo? EC2, S3, RDS e Cloudfront? Ou é melhor usar serviços separados, como a Amazon apenas para S3, enquanto a Digital Ocean para Discourse e talvez a Fastly como CDN?
Gostaria de saber como vocês gerenciam este fórum, mas também outras comunidades existentes, para entender o que deve ser feito.
Obrigado a todos desde já!
Realmente depende do seu objetivo e dos seus requisitos.
Executar tudo em um $5 droplet é ótimo e suficiente para a maioria das comunidades de hobby. Existem sites Discourse muito grandes rodando em uma única máquina, apenas escalando verticalmente conforme necessário.
Sites corporativos e empresariais podem optar por uma configuração mais complexa usando serviços de nuvem pública para atingir um SLA rigoroso, ou terceirizar a hospedagem para um provedor profissional como Discourse pricing | Discourse - Civilized Discussion
Estou usando um droplet de US$ 20 para o meu site, Cloudflare na frente disso e armazenamento S3 no back-end. Meu site tem cerca de 400 mil posts no total com cerca de 10 mil sessões/dia em média, de acordo com o Google Analytics.
Sou novo nesta comunidade, mas já tive experiências em desenvolvimento web no passado. No entanto, sou uma pessoa que adora fazer as coisas bem e gerenciar tudo da melhor maneira possível. Penso muito grande! E acho que a ideia de gerenciar o banco de dados e os uploads separadamente é muito boa. Mas estou tendo dificuldades em decidir se devo gerenciar tudo com a AWS usando seus produtos ou não. Por exemplo, o Vendor Lock-In. Obviamente, se usar o EC2 com uma distribuição Linux padrão como o Ubuntu e o RDS para o banco de dados PostgreSQL, não há problema, mas com o S3 ou talvez usando outros padrões e recursos de fornecedores como o Lambda, isso pode ser um problema quando você quiser migrar para qualquer outro servidor de hospedagem.
Existem outros provedores s3 compatíveis: Usando Armazenamento de Objetos para Uploads (S3 e Clones).
Pelo que você disse, eu recomendaria que você começasse com uma única EC2 para resolver as coisas. Se mais tarde você quiser migrar para RDS (e elasticache) e S3, você poderá fazer isso de acordo com suas necessidades e orçamento.
Última pergunta. Para usar o S3, você precisa de uma CDN, certo? Mas a mesma cdn usada para o site ou outra cdn deve ser configurada especificamente para os dados que são carregados no S3?
O posterior. O CDN do site e o CDN do S3 têm “Origens” diferentes.
Então, por exemplo, Fastly para o fórum e Amazon Cloudfront para o S3. Estou certo?
Eu usaria o Cloudfront ou o Fastly para ambos. Usar vários fornecedores para o mesmo produto em uma única instância parece desnecessariamente complicado.
Quando dizemos “outro CDN”, queremos dizer outra “distribuição de CDN” ou “instância de CDN”. Não literalmente outra empresa de CDN.
Ah, ok, obrigado pela explicação.
Não dependo da Amazon para nada.
Eu nunca usaria uma solução que não é considerada um padrão e, portanto, não pode ser migrada facilmente para outro lugar.
Um servidor virtual tradicional faz um ótimo trabalho. Posso facilmente mudar de provedor no futuro, se quiser.
Quais alternativas para EC2, S3, RDS e Elasticache você recomendaria? Quero dizer soluções padrão, para evitar, como você diz, o problema de Vendor Lock-In.
Por exemplo, Linode? Digital Ocean?
Gerenciei aplicativos web em todos os três (AWS, Linode e Digital Ocean). Prefiro Linode e DO. Achei-os baratos, sólidos como rocha e, o mais importante, mais simples de gerenciar. Eu era a única pessoa de tecnologia em uma pequena empresa, então esses foram fatores realmente importantes para mim.
Não é realmente difícil mover o Discourse para uma plataforma diferente, mesmo que você esteja usando todas essas ferramentas da AWS, você pode fazer um backup e restaurá-lo em qualquer instalação do Discourse.
DO e Linode (juntamente com centenas de provedores de serviços de nuvem concorrentes com preços semelhantes) são muito mais econômicos (cerca de 10% do custo, na minha experiência) do que AWS ou MS Azure para serviços equivalentes, e muito menos propensos a exigir que você construa coisas usando suas APIs e interfaces proprietárias, o que inibe a migração para outro provedor de hospedagem genérico. Eu recomendo fortemente permanecer neutro em relação ao fornecedor e ficar longe de AWS e MS Azure.