Live data from Hacker News

An Open Source, Self-Hosted Heroku

bitmatica.com

121–123 of 123 posts

Re: An Open Source, Self-Hosted Heroku

#121
post #120

Earlier quoted context omitted.

> Is there a reason projects like Flynn have not tackled it? Or is it just a question of time? Like most useful production software, coming up with industrial-grade implementations is harder than it looks. The tricky part is picking the right basic metric. CPU load is often a bit misleading.

maybe machine learning is useful here?

Probably overkill when the metrics are so easy to gather.

I think old-school SPC techniques will take us a lot of the way.

And even before that, asking people what they already watch is good too.

Re: An Open Source, Self-Hosted Heroku

#122

This is a great overview of the kubernetes/self-hosted PaaS landscape, but is also clearly a bit of marketing for Flynn. Flynn looks awesome, but also as/more awesome at a glance from my research and test runs is https://github.com/convox/rack which I got closer to working more quickly than Flynn, though it helped that Convox builds on top of docker-compose.yml files, which we were already using for development. For…

From looking at your KY tool, it sounds like the pain point you're having is that there's a lot of boilerplate repetition around loading configmaps and secrets into your containers, is that correct? If that's not far off the mark, have you looked at using an object-oriented k8s client? I've been playing with a pattern where I create classes which know how to render themselves into k8s API objects, and that gives the…

Sorry I didn't see this sooner! The repetition is definitely something that bothered me in the early working versions of our app on kubernetes, and also the general lack of reproducibility and manual fiddling that might be required to make changes or create new services, and the difficulty of having the configuration live in the code so it can change on a per branch basis, and have that branch built correctly by CI when it goes to QA/staging.

ky is definitely still just in the "maybe useful/maybe practical" territory, but now that the basic concept of compiling from a Procfile seems to work, I suspect adding some configuration and more environment aware and extensible/overrideable templating could make it pretty practical, but I also had/have my eye on Helm. There may be some practical/logistical complications in using Helm, and I think if we went that way we'd probably go full hog and use Deis Workflow (https://deis.com/workflow/), which also deserved mention in this thread's discussion, but the k8s clients like the python one you point to or the ruby one (https://github.com/abonas/kubeclient) may be worth bringing into the mix depending on how this all works out... Thanks for the links and for having a look!

Re: An Open Source, Self-Hosted Heroku

#123

Earlier quoted context omitted.

From looking at your KY tool, it sounds like the pain point you're having is that there's a lot of boilerplate repetition around loading configmaps and secrets into your containers, is that correct? If that's not far off the mark, have you looked at using an object-oriented k8s client? I've been playing with a pattern where I create classes which know how to render themselves into k8s API objects, and that gives the…

Sorry I didn't see this sooner! The repetition is definitely something that bothered me in the early working versions of our app on kubernetes, and also the general lack of reproducibility and manual fiddling that might be required to make changes or create new services, and the difficulty of having the configuration live in the code so it can change on a per branch basis, and have that branch built correctly by CI w…

Cool, thanks for the explanation. Interesting times living on the frontier here, lots of best practices (and the tools to support them) yet to be written. Definitely interested to follow your experiences, keep sharing :)
Post reply on HN