Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ClusterHQ is shutting down

clusterhq.com

Post reply on HN
Print view View original

181–190 of 230 posts

Re: ClusterHQ is shutting down

#181

Post by dang »

gtirloni wrote: post #142
tlb wrote: post #88

Earlier quoted context omitted.

Many -- probably most -- ultimately very successful companies had near-death experiences. They aren't usually written about. Apple's near-death in 1997 is well documented. Tesla's is described in Ashlee Vance's biography of Musk. http://foundersatwork.com/ has firsthand stories about some others. They would have become full-death experiences if the CEO had said, "Hey everybody, we're near death, just FYI". So in the…

Maybe you have been seeing things through SV pink colored glasses for too long. Companies everywhere are shutting down daily with proper warnings to customers, employees and users. It's not uncommon for companies to give several months (or even a year) of warning that they are winding down operations, won't be accepting new users, will honor contracts, etc. And they are doing the right thing. Every time there's a pos…

Please don't be uncivil when commenting here. The middle parts are fine (though weakened by a straw man you call "the general feeling"), but the personal swipe at the beginning is not.

tlb's argument is an interesting one, and so would yours be had you focused on its substance and dropped the snark and the elbowing—which was even worse in your original comment upthread. Indignation gets upvotes, but it also reduces signal/noise ratio and primes others for fight mode. Those things are bad for HN threads.

Re: ClusterHQ is shutting down

#182

Post by user5994461 »

rickycook wrote: post #171
otterley wrote: post #152

Earlier quoted context omitted.

Storage is definitely one of those businesses where "fast, good, cheap: pick any two" has always applied, and still does.

and as an industry, we are tending towards fast, cheap, and you can write code to work around not having "good"

It's not so much about the code as having a usage that can accommodate being run on "not good".

Banks and hospitals don't.

Re: ClusterHQ is shutting down

#183

Post by nodesocket »

dang wrote: post #179
nodesocket wrote: post #176

Earlier quoted context omitted.

This is a ridiculous comment. Have you ever tried running a company? I'm certain the founders of these companies put their blood sweat and tears into their work, but unfortunately things didn't go as planned. They are probably deeply saddened and crushed about having to fire employees and made very hard decisions. Life doesn't revolve around you and your technology inconveniences.

Please don't post uncivil comments to Hacker News. There's a good point in the middle of your post, but it's ruined by the name-calling of the first bit and the personal nastiness of the final bit, which break the site guidelines. https://news.ycombinator.com/newsguidelines.html

Sorry dang not my intention.

> name-calling of the first bit

When did I name call though?

Re: ClusterHQ is shutting down

#184

Post by user5994461 »

kureikain wrote: post #79
tw04 wrote: post #60

Earlier quoted context omitted.

>NFS? No way. Not performant. Really? https://www.spec.org/sfs2008/results/res2011q4/sfs2008-20111... And those are nothing compared to modern systems.

I have lots of issue to get NFS works on some particular db as well. Such as RethinkDB and InfluxDB...

Last I checked, databases came with numerous warning in the docs "don't run me on a network drive".

Is there any reason why you are trying this at all?

Re: ClusterHQ is shutting down

#185

Post by blorgle »

chrissnell wrote: post #15

We've been running Kubernetes (500+ containers) in production for over a year now. I believe (and hope) that 2017 will be the year that persistent data storage will be solved. We are ready to move our data out of OpenStack and have our data services (Elasticsearch, Cassandra, MySQL, MongoDB) join the rest of our apps on Kube-orchestrated infrastructure. But, we're not there yet. The options just aren't good enough. L…

This doesn't really make much sense to me.

If your systems support software level replication (Elasticsearch, Cassandra, MySQL, MongoDB all do) then why do you need persistent storage? You just need container scheduling anti-affinity and enough replicas.

You only need persistent storage for systems which don't support that replication. Ceph can certainly be deployed as performant for DB workloads.

You say "Cinder has the stench of OpenStack" but Cinder is just a Python based webapp which povides an API to arbitrary storage backends (Ceph RBD, iSCSI, NetApp ONTAP, whatever). How can it be "better now"? It doesn't provide storage on its own. If your ops team was using the default "proof of concept" LVM backend then I could see how you might get a bad impression but that just means your ops team doesn't know much about OpenStack.

Am I missing something obvious?

Re: ClusterHQ is shutting down

#186

Post by user5994461 »

BinaryIdiot wrote: post #8

How many people were employed at ClusterHQ? Honestly I never even heard of the company but I had heard of some of the open source projects. Maybe I'm just out of the loop. Also any information as to lessons learned, etc? Basically why it failed? Looking at the marketing material I didn't see anything really remarkable about it (nothing that stood out as a "oh this is why I would give them money") so I'm curious. > I’…

> Also any information as to lessons learned, etc? Basically why it failed? Looking at the marketing material I didn't see anything really remarkable about it (nothing that stood out as a "oh this is why I would give them money") so I'm curious.

My personal take on this from what I've red in the post (which is kinda harsh).

[First, containerization (read: Docker) is in its infancy. It's only 3 years old. Let's assume it's immature and not well understood.]

It seems from the post that ClusterHQ is about doing stateful containers + The company was born in 2014. Stateless containers are still a challenging and new topic as of now. Stateful containers are purely theoretical as of right now.

They had => No product. No market. No business model. Tech is not ready. Usages ain't defined. It couldn't go well.

They don't seem to have products or sale something? Were they an open source company by any chance? (I couldn't tell, never heard of them, site is shutting down so too late).

Re: ClusterHQ is shutting down

#187

Post by dang »

nodesocket wrote: post #183
dang wrote: post #179

Earlier quoted context omitted.

Please don't post uncivil comments to Hacker News. There's a good point in the middle of your post, but it's ruined by the name-calling of the first bit and the personal nastiness of the final bit, which break the site guidelines. https://news.ycombinator.com/newsguidelines.html

Sorry dang not my intention. > name-calling of the first bit When did I name call though?

'This is a ridiculous' is name-calling in the sense described at https://news.ycombinator.com/newsguidelines.html:

When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

Re: ClusterHQ is shutting down

#188

Post by brazzledazzle »

luka-birsa wrote: post #92
chrissnell wrote: post #15

We've been running Kubernetes (500+ containers) in production for over a year now. I believe (and hope) that 2017 will be the year that persistent data storage will be solved. We are ready to move our data out of OpenStack and have our data services (Elasticsearch, Cassandra, MySQL, MongoDB) join the rest of our apps on Kube-orchestrated infrastructure. But, we're not there yet. The options just aren't good enough. L…

Same here. Running ~100 app servers in K8S and the rest (databases & legacy apps) as regular GCE instances with PD drives. But long term going K8S-only is instrumental for us to prevent vendor lock-in. I really hope that storage for K8S happens this year in a form that is simpler than Gluster/Ceph/etc and preferably integrated. Right now we're using NFS and it's ok for the simple applications but I right now I wouldn…

Correct me if I'm wrong, but if you have the storage solved for the rest why not just use that same storage mechanism? If you're using local storage on your legacy applications and are essentially bound to the one node why couldn't you tag one node and use hostpath in kubernetes?

Since these applications are fundamentally not designed for something like kubernetes what everyone seems to be asking for is Kubernetes to provide network storage that has the good things from NFS but faster. I could be way off base here but asking for a simple and performant solution to this problem from projects like kubernetes just doesn't seem reasonable. Network storage, particularly the type that provides traditional filesystem semantics, is a hard space all on its own.

To put it another way, it sounds like people are asking kubernetes to take single node applications dependent on traditional filesystems and provide a magical performant network storage layer to make those failover seamlessly between kubernetes nodes with no (or tunable?) data loss. For those asking for this how would _you_ go about creating such a system? Just thinking through that a little should make it clear that what you're asking for isn't just a solution to a very difficult problem, it's a solution that is, I think, worth quite a lot of money to the person/group that solves it elegantly.

I would genuinely love to be proven wrong here so by all means destroy my argument with extreme prejudice.

Re: ClusterHQ is shutting down

#189

Post by brazzledazzle »

user5994461 wrote: post #184
kureikain wrote: post #79

Earlier quoted context omitted.

I have lots of issue to get NFS works on some particular db as well. Such as RethinkDB and InfluxDB...

Last I checked, databases came with numerous warning in the docs "don't run me on a network drive". Is there any reason why you are trying this at all?

I think that's a good rule of thumb but you can certainly do it if you know what you're doing (which includes having the right hardware).

Re: ClusterHQ is shutting down

#190

Post by benley »

user5994461 wrote: post #177
chrissnell wrote: post #15

We've been running Kubernetes (500+ containers) in production for over a year now. I believe (and hope) that 2017 will be the year that persistent data storage will be solved. We are ready to move our data out of OpenStack and have our data services (Elasticsearch, Cassandra, MySQL, MongoDB) join the rest of our apps on Kube-orchestrated infrastructure. But, we're not there yet. The options just aren't good enough. L…

I don't want to break your hopes but stateful containers will only ever run on GCE and AWS. The entire existence of stateful containers depends on having network storage at hands. The only good network storages are GCE and AWS volumes, which are proprietary trade-secret technologies only available there. If you want to play it old-school. You can run virtual machines with VmWare on bare metal servers with SAN disks (…

If virtual machines with live migration is what you're after, vmware is not your only option. You can get largely the same effect without involving any iscsi/FC/SAN tech with another open source project, which happens to originate from the same place as Kubernetes: http://www.ganeti.org/

Ganeti has been battle-tested for about a decade too, supports an assortment of storage backends, including some clustered ones like Ceph, can do live migration between hypervisor nodes, and it's a nicely maintained Python app with some Haskell parts in it.

ganeti came out of my team at google in the mid 2000s, fwiw. I did not work on it, but I've certainly used it. It's pretty nice.

Post reply on HN