12 ms·

They make some cogent points about Zookeeper, but is javaphobia really a valid concern here? Yes, you have to install a JVM, and Oracle doesn't make that as fri

They make some cogent points about Zookeeper, but is javaphobia really a valid concern here? Yes, you have to install a JVM, and Oracle doesn't make that as friendly as it could be. But in my experience ZK doesn't bring along "a ton of dependencies". Likewise, I'm skeptical that the performance of Java v. Go in this case makes a huge difference: you're only spinning the JVM once, at startup. Maybe I'm too technically conservative, but it seems like the advantages of Zookeeper's maturity and support base outweigh the ickiness of Java and the whizbang factor of Go. Complaining about the politics of the ASF doesn't really factor in; they're still much more likely to be around in 10 months

johnbellone 13y ago
Even though Zookeeper is "mature" it is definitely a beast to fine tune and wade through. Zookeeper definitely does not bring along a ton of dependencies. If you're deploying it as documented it should be running on its own dedicated machines. I don't see why dependencies are a problem there especially with Chef/Puppet nowadays.
- alanctgardner2 13y ago
  Exactly. A "devops" company shouldn't really be complaining about dependencies anyways, they're a fact of life. I admit my experience with ZK has been 50% administering it with Cloudera Manager, which basically abstracts away all the nastiness. I'm curious about specific issues people have had though; I've used ZK with Hadoop and Kafka without any major issues.
  - sandfox 13y ago
    Why shouldn't a 'devops' company complain about dependency? It's their domain completely. Treating anything as a "fact of life" is not going to make the problem go away... And what about anyone out there trying to use them who isn't a 'devops' thingy. A painful dependency graph is going to be something that influences their decision on what tool they choose.
    - hunvreus 13y ago
      Pretty much what I thought. The leaner the better. Moreover, in our specific case, we did not want to introduce dependencies on hosts that are managed by our customers so as to not run into conflicts with their own stack.
  - brown9-2 13y ago
    Especially when the standard way to deploy it is likely to unarchive a tar and use the JARs needed directly from the project's lib folder rather than a system-wide/package-manager installed JAR.
- sandfox 13y ago
  Just because you have tools ease dealing with dependencies, it does not mean that those dependencies and the cost of dealing with them has gone away. Easier to not have the problem instead of solving it...
  - johnbellone 13y ago
    What exactly are there problems with? I am behind a strict corporate network and all I needed to do was download the Zookeeper JAR and write a couple of deployment scripts. Even though the environment variables for the startup scripts are lacking they cover nearly everything you can want. Zookeeper has legitimate issues and from experience most of which stems from the documentation being so verbose that it takes a lot of fine tuning to get right. But if you put it on its own hardware, or at the very least, the write-ahead log on its own partition, you should be good go.
hunvreus 13y ago
As we said, we don't hate Java. We were however constrained in what we could install on the host machines since we administrate these on behalf of others. Even lightweight dependencies were a no-go for us. With regards to Apache, we have "mixed feelings". We're aligned with a lot of what they stand for and are definitely very thankful for what they enabled in the OSS community, but are not enthused with the way they handle the projects that join them.
- alanctgardner2 13y ago
  I get the mixed Apache feelings, but I still don't quite get the dependencies complaint. It seems like your clients have heterogeneous environments (multiple Linux distros, at least). Do you distribute a statically linked binary, or do they compile it on their box? It seems like in this case Go code is actually way more complex to set up.
  - hunvreus 13y ago
    We actually deal with a limited number of distros for now (mostly Ubuntu and RHE) and we distribute statically linked binaries (meaning no dependency at all).
nivertech 13y ago
It's not javaphobia. I think the point is that Go produces a statically-linked native executable, while VM-based languages like Java adding many dependencies and also reduce memory which left for the application itself (assuming z-nodes running on the same nodes as application).
- Xorlev 13y ago
  You can run a high performance Java process with a small heap, I would call this a non-issue. I have many heavily-used services with 32-64mb of heap space. Certainly, Go will end up using less memory but in the day and age of small servers with 1.5GB of RAM, it's really a non-issue.
  - mattzito 13y ago
    Right, but bear in mind that their customers will see that ram usage as "wasted" RAM. I have a product with an agent that runs around 80MB of RAM usage on giant servers, servers with 500+GB of RAM, and my customers still complain sometimes.
lucian1900 13y ago
Even if you only look at amount of RAM used, with Zookeeper it'll never be lower than 35M and most likely be much higher than 50M. With etcd, you can get away with significantly less than that. The dependencies and JVM boot time are also annoying if you don't already use Java, though.
- nemothekid 13y ago
  Are you guys already using etcd in production? I've been using it for a project lately, and I thought it would have low memory usage but it doesn't. I'm making about ~80 writes/second with only ~125 keys and all 3 of my etcd nodes sit at 200M+ resident memory.
  - unoti 13y ago
    Is 80 writes per second super huge traffic, beyond the realm of what this is designed to handle? I would expect for etcd to be used for things like which machines are responsible for doing what in a cluster, and for the values to change relatively infrequently during events such as adding a new machine to the cluster. Perhaps for a system running 80 requests per second, using etcd to locate a Redis server would be better. Would the memory use be more reasonable then, if it weren't replicating such a huge volume of log transactions?
    - nemothekid 13y ago
      The readme claims that etcd's can perform up top 1000 w/s, and I don't think 80/s is particularly alot. At the end of the day there are only ~125 keys (most of which aren't the 80, expire really quickly), and I'm only writing integers (maybe 8 bytes in length converted to strings). However, I dont know if this is caused my use case or if its just a normal day for etcd. I haven't been able to confirm with anyone else what their memory patterns look like. While running my etcd cluster of the last couple of days my log file has grown 3x to 92M (expected), but my memory usage hasn't grown that much. It now sits at 295M, so I'm unconvinced it has anything to actually to do with the way I'm using it. I opened an issue here, https://github.com/coreos/etcd/issues/162 https://github.com/coreos/etcd/issues/162, and it seems the maintainer confirmed it.

johnbellone 13y ago

Even though Zookeeper is "mature" it is definitely a beast to fine tune and wade through. Zookeeper definitely does not bring along a ton of dependencies. If you're deploying it as documented it should be running on its own dedicated machines. I don't see why dependencies are a problem there especially with Chef/Puppet nowadays.

alanctgardner2 13y ago
Exactly. A "devops" company shouldn't really be complaining about dependencies anyways, they're a fact of life. I admit my experience with ZK has been 50% administering it with Cloudera Manager, which basically abstracts away all the nastiness. I'm curious about specific issues people have had though; I've used ZK with Hadoop and Kafka without any major issues.
- sandfox 13y ago
  Why shouldn't a 'devops' company complain about dependency? It's their domain completely. Treating anything as a "fact of life" is not going to make the problem go away... And what about anyone out there trying to use them who isn't a 'devops' thingy. A painful dependency graph is going to be something that influences their decision on what tool they choose.
  - hunvreus 13y ago
    Pretty much what I thought. The leaner the better. Moreover, in our specific case, we did not want to introduce dependencies on hosts that are managed by our customers so as to not run into conflicts with their own stack.
- brown9-2 13y ago
  Especially when the standard way to deploy it is likely to unarchive a tar and use the JARs needed directly from the project's lib folder rather than a system-wide/package-manager installed JAR.
sandfox 13y ago
Just because you have tools ease dealing with dependencies, it does not mean that those dependencies and the cost of dealing with them has gone away. Easier to not have the problem instead of solving it...
- johnbellone 13y ago
  What exactly are there problems with? I am behind a strict corporate network and all I needed to do was download the Zookeeper JAR and write a couple of deployment scripts. Even though the environment variables for the startup scripts are lacking they cover nearly everything you can want. Zookeeper has legitimate issues and from experience most of which stems from the documentation being so verbose that it takes a lot of fine tuning to get right. But if you put it on its own hardware, or at the very least, the write-ahead log on its own partition, you should be good go.

hunvreus 13y ago

As we said, we don't hate Java. We were however constrained in what we could install on the host machines since we administrate these on behalf of others. Even lightweight dependencies were a no-go for us. With regards to Apache, we have "mixed feelings". We're aligned with a lot of what they stand for and are definitely very thankful for what they enabled in the OSS community, but are not enthused with the way they handle the projects that join them.

alanctgardner2 13y ago
I get the mixed Apache feelings, but I still don't quite get the dependencies complaint. It seems like your clients have heterogeneous environments (multiple Linux distros, at least). Do you distribute a statically linked binary, or do they compile it on their box? It seems like in this case Go code is actually way more complex to set up.
- hunvreus 13y ago
  We actually deal with a limited number of distros for now (mostly Ubuntu and RHE) and we distribute statically linked binaries (meaning no dependency at all).

nivertech 13y ago

It's not javaphobia. I think the point is that Go produces a statically-linked native executable, while VM-based languages like Java adding many dependencies and also reduce memory which left for the application itself (assuming z-nodes running on the same nodes as application).

Xorlev 13y ago
You can run a high performance Java process with a small heap, I would call this a non-issue. I have many heavily-used services with 32-64mb of heap space. Certainly, Go will end up using less memory but in the day and age of small servers with 1.5GB of RAM, it's really a non-issue.
- mattzito 13y ago
  Right, but bear in mind that their customers will see that ram usage as "wasted" RAM. I have a product with an agent that runs around 80MB of RAM usage on giant servers, servers with 500+GB of RAM, and my customers still complain sometimes.

lucian1900 13y ago

Even if you only look at amount of RAM used, with Zookeeper it'll never be lower than 35M and most likely be much higher than 50M. With etcd, you can get away with significantly less than that. The dependencies and JVM boot time are also annoying if you don't already use Java, though.

nemothekid 13y ago
Are you guys already using etcd in production? I've been using it for a project lately, and I thought it would have low memory usage but it doesn't. I'm making about ~80 writes/second with only ~125 keys and all 3 of my etcd nodes sit at 200M+ resident memory.
- unoti 13y ago
  Is 80 writes per second super huge traffic, beyond the realm of what this is designed to handle? I would expect for etcd to be used for things like which machines are responsible for doing what in a cluster, and for the values to change relatively infrequently during events such as adding a new machine to the cluster. Perhaps for a system running 80 requests per second, using etcd to locate a Redis server would be better. Would the memory use be more reasonable then, if it weren't replicating such a huge volume of log transactions?
  - nemothekid 13y ago
    The readme claims that etcd's can perform up top 1000 w/s, and I don't think 80/s is particularly alot. At the end of the day there are only ~125 keys (most of which aren't the 80, expire really quickly), and I'm only writing integers (maybe 8 bytes in length converted to strings). However, I dont know if this is caused my use case or if its just a normal day for etcd. I haven't been able to confirm with anyone else what their memory patterns look like. While running my etcd cluster of the last couple of days my log file has grown 3x to 92M (expected), but my memory usage hasn't grown that much. It now sits at 295M, so I'm unconvinced it has anything to actually to do with the way I'm using it. I opened an issue here, https://github.com/coreos/etcd/issues/162 https://github.com/coreos/etcd/issues/162, and it seems the maintainer confirmed it.