Kuby-core: What kind of apps should we (not) deploy with Kuby?

Created on 8 Oct 2020  ·  5Comments  ·  Source: getkuby/kuby-core

Hi,

it would be nice to say somewhere (I did not see anywhere, correct me if I am wrong) what kind of app we should and should not deploy with Kuby.

I would imagine it might get expensive to deploy hobby app to EKS? Never used it but their website says: You pay $0.10 per hour for each Amazon EKS cluster that you create. which would be around 72 USD per month, right? Not sure if it's with servers and databases and stuff.

In this case something like Dokku or Heroku would be much cheaper.

Anyway, such a discussion should probably be not only about money, but overall technical overkills and so on.

All 5 comments

Hey @hovancik. You're absolutely right, there's not much in the documentation about the various cloud providers and how much they cost. I was thinking about adding a pricing matrix to the docs, but the deployment solution really has nothing to do with the cloud provider. Imagine, for example, asking the same question of Capistrano :)

Kuby is designed to deploy your app into any Kubernetes cluster, regardless of the cloud provider and how much it costs. You as the developer should be free to choose whichever cloud provider serves your needs the best. For example, I wouldn't choose EKS or Azure for a hobby or personal project - it's far to expensive. For EKS, the $72/mo you mentioned is literally only for the Kubernetes control plane, and doesn't include the cost of any compute resources, block storage, etc. Instead, I would reach for DigitalOcean or Linode, which are far more cost-effective (around $20/mo for a 4gb RAM, 2 CPU instance) and give you the control plane for free. If you're part of a business that wants to use some of the other numerous AWS or Azure services, then maybe EKS is the right solution for you. The point is that you get to choose. Kuby doesn't care - it's designed to work everywhere.

That said, would it help to see a pricing matrix in the documentation? I'm hesitant to add one because 1) the reasons listed above, 2) prices change frequently, and 3) I don't want to get into the business of recommending cloud providers or being perceived as favoring one over the other.

Thoughts?

Hi @camertron , yeah, pricing matrix is bad idea.

As I title says, what I am trying to ask is: What kind of apps should we (not) deploy with Kuby? In a sense: describe the tool in the term of job :)

I started with hobby vs professional ( =money) , because it's easy one, but I would like to hear more about what kind of apps you're aiming for. Is this overkill for simple server-rendered rails app with db? Or that's the perfect candidate? Or the more complicated app the better this tool will be for devs?

Maybe I am misunderstanding and this is meant for all kind of apps? You know, the kind of pages where they say use this tool if and don't use this tool if is what I look for when checking them :)

Ah ok I see what you mean. I would say Kuby is meant for all types of apps, but there are certainly some types that will benefit from it more than others. You're probably better off using a free Heroku dyno for a super small app that doesn't see a lot of traffic and that only manages a few hundred (or less) database rows. The thing is, it's not that Kuby is a bad choice for these types of apps, it's just that you're likely to spend less money and less brainpower getting Heroku set up. It's pretty hard to beat them on simplicity. Heroku starts to get expensive when you need more resources though, and I've found that, generally speaking, a managed Kubernetes cluster with a single node deployed with Kuby is more cost-effective than the equivalent Heroku setup. Yes, Kuby requires more brainpower to configure (again, it's pretty hard to beat git push heroku master), but the flexibility you get as a result is worth it IMHO.

Kuby also might not be the right choice for very large, highly customized apps that have deviated significantly from Rails conventions. I'm sure you could get Kuby to work for such apps, but it would likely mean customizing Kuby to a large degree. To do so, you'd probably have to have a deeper understanding of how Docker, Kubernetes, and Kuby work. I guess it boils down to how willing you are to invest time in learning the technologies.

Maybe the best way to say it is that Kuby was designed to serve the same audience as Rails itself, and should be thought of as residing at the same level as active record, active storage, etc. You might reasonably say an ORM is overkill for a very small app, and you might also reasonably say it gets in your way in a large, bespoke app. Active record is designed to abstract away the complexities of database communication, and Kuby is designed to do the same for deployment. Both come, as DHH is fond of saying, with batteries included.

Thanks! Some form of this should probably be on the web somewhere :)

Agreed, thanks for bringing this up @hovancik :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kingdonb picture kingdonb  ·  6Comments

traels picture traels  ·  13Comments

ghost picture ghost  ·  3Comments

millisami picture millisami  ·  3Comments

kalkin picture kalkin  ·  3Comments