Servidor de preço fixo ou faturação por utilização?

Se a sua aplicação corre sempre e o tráfego é bastante previsível, um servidor de preço fixo vai surpreendê-lo menos. Se o tráfego é muito baixo, ou dá saltos súbitos e grandes, as plataformas faturadas por utilização podem fazer mais sentido. É menos uma escolha técnica do que uma questão de saber que linha da sua fatura não para de crescer.

A comparação abaixo não usa preços, porque as tarifas por unidade diferem entre plataformas e mudam com frequência. Em vez disso, dá-lhe uma forma de fazer as contas com os seus próprios números.

Por que cobra cada modelo?

Cada linha é uma troca, e nenhum dos modelos ganha em todas.

Quando faz mais sentido a faturação por utilização?

• O projeto é novo e quase não tem tráfego. Se um plano gratuito o cobre, pagar por um servidor faz pouco sentido.
• Está a publicar uma demonstração de curta duração ou uma página de campanha. Não vale a pena montar um servidor para algo que fecha dentro de poucas semanas.
• O seu tráfego tem picos súbitos e acentuados. Um servidor pode não ter capacidade nesse momento, e uma plataforma absorve isso por si.
• Os seus visitantes estão espalhados pelo mundo e quer responder a cada um a partir de um ponto próximo.
• Nunca quer lidar com atualizações, cópias de segurança ou monitorização, e está disposto a pagar por isso.

Quando faz mais sentido um servidor de preço fixo?

• A sua aplicação faz trabalho constante em segundo plano: workers de filas, tarefas agendadas, ligações WebSocket.
• Quer a base de dados, a cache e a aplicação lado a lado. Quando partilham a mesma máquina, cada uma não traz a sua própria fatura.
• As suas funcionalidades de IA produzem respostas longas. Onde a faturação é por duração de função, cada resposta lenta soma ao custo.
• O seu orçamento tem de ser conhecido de antemão. A mensalidade fica acertada à partida, por isso o fim do mês não traz surpresas.
• Serve muitas imagens ou ficheiros, e o tráfego passou a ser a sua maior rubrica.

Como fazer as suas próprias contas?

Em vez de adivinhar, recolha os valores dos últimos três meses. Se ainda não está no ar, use o tráfego que espera e anote que é uma estimativa.

1. Anote o tráfego mensal em GB, o número de pedidos e a duração total das funções.
2. Anote os seus minutos de compilação. Cada push é uma compilação, por isso esta linha cresce depressa numa equipa que publica com frequência.
3. Acrescente extras como lugares de equipa, uma base de dados e uma cache.
4. Multiplique cada um pela tarifa por unidade da página de preços atual da plataforma. Isso dá-lhe a fatura de um mês normal.
5. Repita a conta como se o tráfego fosse dez vezes maior. Essa é a fatura do mês mau.
6. Compare os dois resultados com a mensalidade de um servidor que aguente a sua aplicação com folga.

Se o valor do mês mau não o preocupa e não tem interesse na manutenção, fique onde está. Se o mês normal já custa mais do que o servidor, ou se o mês mau prejudicasse o negócio, um servidor merece uma análise séria.

Qual é o custo de um preço fixo?

Quando o servidor é seu, algumas tarefas passam também a ser suas. Escolha isto sabendo quais são:

• Manter o sistema operativo e as aplicações atualizados fica consigo. Os painéis de publicação assumem parte desse trabalho, mas não todo.
• Nada cresce automaticamente quando a capacidade se esgota. O servidor fica lento, e cabe-lhe aumentá-lo.
• Um servidor é um único ponto de falha. Enquanto reinicia, a sua aplicação deixa por breves instantes de responder.
• Responde a partir de uma só localização. Os visitantes distantes veem mais latência, e uma rede de distribuição de conteúdos à frente pode ajudar, se isso lhe importar.

Pode usar os dois?

Sim, a escolha não tem de ser tudo ou nada. Uma configuração comum mantém a interface numa plataforma faturada por utilização e executa o backend, a base de dados e os workers de filas num servidor de preço fixo. A maior parte do tráfego vai para a interface, enquanto o trabalho constante que faz inchar uma fatura fica a custo fixo no servidor. O preço é vigiar dois sítios e proteger a ligação entre eles. Se tem uma única aplicação, esta configuração costuma ser mais complexidade do que vale a pena, por isso comece num só sítio.

O meio-termo: git push no seu próprio servidor

Muitas vezes, a maior diferença entre os dois modelos é a comodidade, e essa diferença está a diminuir. Os painéis de publicação de código aberto, como o Coolify, dão-lhe o mesmo fluxo de trabalho no seu próprio servidor: liga um repositório do GitHub, cada push é compilado e entra no ar, gere variáveis de ambiente e domínios numa interface web, e o painel pede o certificado. Mantém o acesso root, e pode gerir tudo a partir do painel se preferir.

Na Seturack, as opções Coolify e Next.js chegam com este painel instalado. Escolhe um tamanho com um controlo deslizante e aumenta mais tarde a partir do painel. Quando aumenta, o IP e os dados mantêm-se e só paga a diferença pelos dias restantes. As cópias de segurança diárias estão incluídas no preço e o tráfego é ilimitado. Os servidores ficam em Istambul. Pode comparar tamanhos na página de preços.

Pronto a usar na Seturack: Next.js, Coolify.