You should be more upfront about your links to companies you talk about. This community is pretty fine with self promotion, but it really needs to be honest.

Thanks for calling that out. I do work with Nanobox, but am legitimately trying to gain an understanding of how our platform (and things like it) might appeal to people who are more familiar with things like Kubernetes than I am.

I could have done a better job of making that clear in the description, and I apologize.

Disclaimer: the OP appears to work for one of the companies/tools listed, Nanobox.io.

I do work with Nanobox, and I apologize for not making that more clear initially, but am legitimately trying to gain an understanding of how our platform (and things like it) might appeal to people who are more familiar with things like Kubernetes than I am.

I am attending Google Cloud NEXT[1] right now, and there are a lot of breakout sessions on kubernetes and Container Engine. Google Cloud and Container Engine (GKE) makes creating a kube cluster super painless. It honestly just works and only takes a few minutes to spin up a kube cluster. GKE also has baked in awesomeness that is not available in the open source version such as automatic master and node version upgrades and automatic repair.

I'd recommend just using GKE instead of trying to run kubernetes on your own or using a lesser platform such as Flynn or Hyper. Google Cloud also has their own container registry which is nice since it is tightly integrated with GKE.

[1] - https://cloudnext.withgoogle.com/

Hey, I'm with Hyper. Also at Google Next.

GKE is obviously backed by a company that isn't going away anytime soon.

Other than that, I'd be curious to understand your use of the word "lesser" in this context. Have you tried Hyper?

Typically the pre-packaged tools don't give you enough control. They are an abstraction with no lower level to fall back on when you want to do something outside of whatever use case they are trying to solve. Kubernetes is sort of the opposite case. Personally, I think Docker Swarm is the best option at this point. The API is simple in comparison to Kubernetes and works well. One thing that I've found that Kubernetes and Docker Swarm are missing that some pre-packaged options have is a load balancer / reverse proxy, but Traefik has grown into a very nice solution. I think pre-packaged solutions to can still add a lot of value by doing things like autoscaling, simplifying blue-green deployments, etc, but I personally find some of the limitations frustrating.

I didn't really have Flynn and Hyper.sh down as really being comparable. I'm not sure how Nanobox fits into the picture.

I've been pretty impressed with Hyper.sh's ease of use and pricing. I didn't find Flynn a good match for my use case.

I've also found GCE to be pretty good to work with.

What is your use case that made Hyper.sh a better choice for you over Flynn.io?

Also, if you had to categorize some of these technologies how would you do that, and what are some of the other ones that are similar to those mentioned here that aren't listed?

In my mind Flynn has more of an application focus - something comparable to Heroku with git deploys etc.

I wanted to run a regular (every 10mins) task. I created a container that had the hyper cli installed that spawned a task container that exited on completion. This worked really well for what I was doing. They're thinking of adding this as a hyper sh feature: https://trello.com/c/JfyGyBKS/45-serverless-cron

I didn't consider using Flynn. Just didn't really have Flynn down as being for this kind of thing. Of course another difference is that Hyper.sh is a service; Flynn is a project that I need to self host.

Primarily, the orchestration tools will do a lot of the work for you, but they'll also make a lot of the decisions on how things will work. "Rolling your own" gives more control at the cost of more complexity.

Hello, I'm working with Hyper. There are valid comments here about how much control you might want over your container stack. If you need total control, you should run your own k8s cluster or have someone else run it for you, like GKE.

Most of our users choose us because they don't want that level of control and maintenance.

I'm aware of Flynn but not sure how it works and I'm hearing of Nanobox for the first time.

I imagine however that they will be experiencing the same thing as us, lots of people running event driven workloads.

I've used both Nanobox and Hyper and they seem to be set up for two different use cases with some overlap. Nanobox seems to be focused on the deployment of your custom application while Hyper is focused on letting you deploy whatever container to the cloud quickly and easily.

Thanks for the clarification. I'll check out Nanobox.