Kuby-core: Que tipo de aplicativos devemos (não) implantar com o Kuby?

Oi @hovancik. Você está absolutamente certo, não há muito na documentação sobre os vários provedores de nuvem e quanto eles custam. Eu estava pensando em adicionar uma matriz de preços aos documentos, mas a solução de implantação realmente não tem nada a ver com o provedor de nuvem. Imagine, por exemplo, fazer a mesma pergunta de Capistrano :)

O Kuby foi projetado para implantar seu aplicativo em qualquer cluster Kubernetes, independentemente do provedor de nuvem e de quanto custa. Você, como desenvolvedor, deve ser livre para escolher o provedor de nuvem que melhor atende às suas necessidades. Por exemplo, eu não escolheria o EKS ou o Azure para um hobby ou projeto pessoal - é muito caro. Para o EKS, os US$ 72/mês que você mencionou são literalmente apenas para o plano de controle do Kubernetes e não incluem o custo de nenhum recurso de computação, armazenamento em bloco etc. Em vez disso, eu usaria DigitalOcean ou Linode, que são muito mais caros -eficaz (cerca de US $ 20/mês para uma instância de 4 GB de RAM, 2 CPU) e oferece o plano de controle gratuitamente. Se você faz parte de uma empresa que deseja usar alguns dos outros inúmeros serviços da AWS ou do Azure, talvez o EKS seja a solução certa para você. O ponto é que você pode escolher. Kuby não se importa - ele foi projetado para funcionar em qualquer lugar.

Dito isso, ajudaria ver uma matriz de preços na documentação? Estou hesitante em adicionar um porque 1) os motivos listados acima, 2) os preços mudam com frequência e 3) não quero entrar no negócio de recomendar provedores de nuvem ou ser percebido como favorecendo um em detrimento do outro.

Pensamentos?

Oi @camertron , sim, a matriz de preços é uma má ideia.

Como o título diz, o que estou tentando perguntar é: que tipo de aplicativos devemos (não) implantar com o Kuby? Em certo sentido: descreva a ferramenta no termo de trabalho :)

Comecei com hobby vs professional ( =money) , porque é fácil, mas gostaria de saber mais sobre o tipo de aplicativo que você deseja. Isso é um exagero para o aplicativo Rails renderizado pelo servidor simples com db? Ou esse é o candidato perfeito? Ou quanto mais complicado for o aplicativo, melhor será essa ferramenta para os desenvolvedores?

Talvez eu esteja entendendo mal e isso é para todos os tipos de aplicativos? Você sabe, o tipo de página em que eles dizem use this tool if e don't use this tool if é o que eu procuro ao verificá-los :)

Ah ok entendi o que você quis dizer. Eu diria que o Kuby é destinado a todos os tipos de aplicativos, mas certamente existem alguns tipos que se beneficiarão mais do que outros. Provavelmente é melhor usar um dinamômetro Heroku gratuito para um aplicativo super pequeno que não vê muito tráfego e que gerencia apenas algumas centenas (ou menos) linhas de banco de dados. O problema é que não é que o Kuby seja uma má escolha para esses tipos de aplicativos, é apenas que você provavelmente gastará menos dinheiro e menos inteligência para configurar o Heroku. É muito difícil vencê-los na simplicidade. O Heroku começa a ficar caro quando você precisa de mais recursos, e descobri que, em geral, um cluster Kubernetes gerenciado com um único nó implantado com Kuby é mais econômico do que a configuração Heroku equivalente. Sim, Kuby requer mais inteligência para configurar (novamente, é muito difícil de bater git push heroku master ), mas a flexibilidade que você obtém como resultado vale a pena IMHO.

Kuby também pode não ser a escolha certa para aplicativos muito grandes e altamente personalizados que se desviaram significativamente das convenções do Rails. Tenho certeza de que você poderia fazer com que o Kuby funcionasse para esses aplicativos, mas isso provavelmente significaria personalizar o Kuby em grande medida. Para fazer isso, você provavelmente precisaria ter uma compreensão mais profunda de como o Docker, o Kubernetes e o Kuby funcionam. Acho que tudo se resume ao quanto você está disposto a investir tempo no aprendizado das tecnologias.

Talvez a melhor maneira de dizer isso seja que o Kuby foi projetado para atender ao mesmo público que o próprio Rails, e deve ser pensado como residente no mesmo nível do registro ativo, armazenamento ativo, etc. Você pode razoavelmente dizer que um ORM é um exagero para um aplicativo muito pequeno, e você também pode razoavelmente dizer que isso atrapalha em um aplicativo grande e sob medida. O registro ativo foi projetado para abstrair as complexidades da comunicação do banco de dados, e o Kuby foi projetado para fazer o mesmo na implantação. Ambos vêm, como o DHH gosta de dizer, com baterias incluídas.

Obrigado! Alguma forma disso provavelmente deve estar na web em algum lugar :)

Concordo, obrigado por trazer isso à tona @hovancik :)