This module is way better https://github.com/hcloud-k8s/terraform-hcloud-kubernetes/tr...

I'm using it right now

I agree, this is probably the most complete solution out there. My intentions with this project are to provide various layers of abstraction, not only for Kubernetes provisioning, but also for the most common apps and tools that are usually extending the Kubernetes capabilities and also allow some low level configuration options.

Thanks for the feedback. I've stumbled upon it when it when the project was quite new, and it looked promising.

kube-hetzner seems to be a bit stuck, they have a big backlog for the next major release, but it might never happen.

The pricing is misleading. You say on the landing page that the free plan is €0 per month, but in reality you still have to pay for the control plane nodes. The cheapest control plane node is €3.29 per month; if you want high-availability - you need to double that.

So in reality you would pay €20 per month for the standard plan and also extra for control plane nodes.

Also, with this Terraform module I can setup a similar setup without paying any extra fee for your service: https://github.com/hcloud-k8s/terraform-hcloud-kubernetes/tr...

The Terraform module takes care of ingress, certificates, metrics etc

Anyway, congrats for shipping

> if you want high-availability - you need to double that.

Triple. 1 and 2 nodes will give failure allowance of zero.

Actually you want 3 nodes for high availability, two will do you nothing good

I can recommend Rancher. I’ve used Openshift, Kubernetes and Rancher - so far, Rancher has been the best experience.

http://rancher.com/

You can also test Rancher now easily 0 setup: https://try.rancher.com

We deploy all our containerized applications to Rancher (using Cattle for orchestration) via Jenkins jobs with a standardized Makefile for build, test, and deploy, making things consistent.

We look at running straight k8s, but it was like using a chainsaw to sharpen a pencil for our use case.

In addition their devs are extremely helpful and also have a hobby of getting things to run on ARM.

We're migrating to Rancher from a mix of Jenkins tasks and manual deploys on AWS machines (ie: a mess) and the product is great. I've evaluated both DCOS and k8s about 7-8 months ago and found a k8s a bit complex and moving really fast (we're a small ops team so we can't spend too much time browsing documentation and keeping up with the latest way of doing things). I didn't like DCOS for various reasons (it seemed less mature and the community was too small.)

Rancher is also a breeze to deploy, I could manually deploy it with one hand tied behind my back in 10mn on AWS.

I read something about using Rancher to deploy an Elixir cluster with Docker the other day. That jumped out at me because prior to reading that, the general feeling was that Docker + Erlang/Elixir cluster was a no go.

Rancher was the first thing I'd seen that claimed to be able to pull it off. I'll definitely give this more of a look.

I'll take a look at it, thanks for the suggestion!

There already are some companies in that space that are using big data and machine learning for credit scoring. A few that come to mind: http://hellosoda.com/ http://bigdatascoring.com/

In case of Hello Soda they are using social media data for credit scoring.

PS I'm not associated with any of these companies.

I’ve used Openstack at my current $dayjob and I’d say that Openstack is probably one of the buggiest solutions that I’ve ever used. Even simple things like stopping or resizing VM-s sometimes failed completely and the VM came unusable after that. Feature wise it’s also lacking. Seems that Openstack spends more time/money on marketing and generating hype than creating a good solution. I’d even say that Docker has a somewhat similar problems, they spend more on hype/marketing than creating a stable and usable solution. However, at least Docker is more usable right now than a year ago, the same can’t be said about Openstack.

I guess those expectations are part of the problem, a talk in the recent openstack conf higlighted this: OpenStack was initially created for what these days is called "cloud-native" workloads, every VM was considered ephemeral. companies and users then try to mould it into a cheaper VMWare and are frustrated how bad it is at this.

Resizing, stopping VMs, while admittedly being a rather trivial tasks, point to this usage of OpenStack. When I would mourn the loss of individual VMs on OpenStack (or public clouds for that matter), I would turn gray soon.