Deploying other kinds of apps

[camertron]

This discussion pertains to the article on the Evil Martians blog entitled "Kubing Rails: stressless Kubernetes deployments with Kuby". It is part of a series of discussions pertaining to the article that will hopefully help improve Kuby and its ecosystem.

From the article:

Kuby was designed to deploy Rails apps: the core gem (kuby-core) contains all the necessary Rails-gluing code (Rake tasks, middlewares), and the rails_app plugin is included by default (and there is no API to remove it 🤷🏻‍♂️). This is a relatively common situation and totally normal for a young project. Still, the community should step in and show interest in using Kuby to deploy, for example, Hanami apps. Or, maybe, we can make Kuby a universal infrastructure as code solution? I believe we can.

Kuby was designed to deploy Rails apps and was initially meant to be tightly integrated with Rails. I believe, thanks to Evil Martians, that we have a good path forward to separating Kuby from Rails, as it turns out the integration doesn't have to be that deep after all. So I think deploying other Ruby-based apps like those built with Hanami, Sinatra, etc, is possible/desirable. However I'm not sure I want Kuby to be a universal infrastructure-as-code tool. How would that look, and what would Kuby do?

/cc @palkan

[palkan]

However I'm not sure I want Kuby to be a universal infrastructure-as-code tool. How would that look, and what would Kuby do?

Yeah, that's a good question; we can re-phrase it as "Where does the application responsibility ends and infrastructure begins?". What should be handled by Rails engineers and what by SRE?

Or, maybe, Kuby could become and alternative to Pulumi and similar tools? I believe, the killer feature of Kuby is Ruby and its expressiveness; so, it worth exploring this general direction as well; probably, after Kuby will become Rails-agnostic first.

[camertron]

I like your re-phrasing, that makes sense. I could see leaving Kuby as a Rails-only (or maybe Ruby-only) solution that consumes the more general-purpose libraries like kube-dsl, etc. Those general-purpose libs could then form the basis of a more language-agnostic offering like Pulumi which leverages Ruby instead of Python or Javascript.

I believe the killer feature of Kuby is Ruby and its expressiveness

That's an interesting take, I hadn't considered Ruby being the killer feature. It's written in Ruby because Kuby was designed to integrate seamlessly with Rails. However I have read of some demand for Ruby support in Pulumi, so maybe the community would rally around a Pulumi-like tool that lets you write Ruby. I have to admit that I'm not very familiar with all that Pulumi does, but it seems like a good place for some investigation/research.