4 ms·

Ask HN: Flynn.io/Hyper.sh/Nanobox.io vs. Kubernetes

18 points by sdomino 10y ago

What benefits/drawbacks might one of these "pre-packaged" container orchestration tools like Flynn.io, Hyper.sh, or Nanobox.io have verses just rolling your own with something like Kubernetes? Edit: I didn't make it as clear as I should have initially that I actually work with Nanobox.io. I'm legitimately trying to gain an understanding of why developers might find something like Nanobox (or a similar tool) appealing over something like Kubernetes. Apologies for any misdirection initially.

rubiquity 10y ago
Disclaimer: the OP appears to work for one of the companies/tools listed, Nanobox.io.
- sdomino 10y ago
  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.
nodesocket 10y ago
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/ https://cloudnext.withgoogle.com/
- mrmrcoleman 10y ago
  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?
danhunsaker 10y ago
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.
IanCal 10y ago
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.
- sdomino 10y ago
  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.
charlieegan3 10y ago
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.
- sdomino 10y ago
  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?
  - charlieegan3 10y ago
    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 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.
ianwalter 10y ago
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.
mrmrcoleman 10y ago
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.
- ianwalter 10y ago
  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.
  - mrmrcoleman 10y ago
    Thanks for the clarification. I'll check out Nanobox.

18 points by sdomino 10y ago

rubiquity 10y ago

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

sdomino 10y ago
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.

nodesocket 10y ago

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/ https://cloudnext.withgoogle.com/

mrmrcoleman 10y ago
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?

danhunsaker 10y ago

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.

IanCal 10y ago

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.

sdomino 10y ago
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.

charlieegan3 10y ago

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.

sdomino 10y ago
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?
- charlieegan3 10y ago
  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 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.

ianwalter 10y ago

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.

mrmrcoleman 10y ago

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.

ianwalter 10y ago
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.
- mrmrcoleman 10y ago
  Thanks for the clarification. I'll check out Nanobox.