Kafka Removing Zookeeper Dependency

Post by ashtonkem » Sun, May 17, 2020, 12:49 PM UTC

skyde wrote: post #53

lchengify wrote: post #42

I couldn't be more excited about this! Having finished a Kafka project about a year ago, we had so many Zookeeper production and test environment issues that it was the running joke to check Zookeeper first if anything went wrong. Honestly Zookeeper in theory is a great idea: Having a centralized service for maintaining config info saves a lot of heartache when dealing with an open source distributed systems project.…

i am curious to know why people expect a raft library to be more reliable if embedded inside the kafka controller versus running inside a service like Etcd. in the end broker will do RPC to a service (kafka controller/ etcd) and this service will use raft to replicate the state. It should be exactly the same. And if anything knowing which node are running the raft algorithm help you be more careful with rolling resta…

Post by Tsarbomb » Sun, May 17, 2020, 1:21 PM UTC

bsaul wrote: post #95

elric wrote: post #88

Earlier quoted context omitted.

Seriously? When was the last time you deployed something as a standalone, static binary? Hardly anything with any amount of complexity is shipped like that, especially not cross-platform. Just about everything requires some kind of runtime, some kind of dependencies or some kind of environment. I can go "dnf install firefox" just as easily as I can go "dnf install ant". Both of these come with a boatload of dependenc…

I'm not sure what you mean. Deploying static binaries was the main way to go before, and is now the standard approach with go. Pretty much every service developed in go is deployed as a standalone statically compiled binary, and i would assume it's the same for code developped in Rust.

Post by Tsarbomb » Sun, May 17, 2020, 1:26 PM UTC

morelisp wrote: post #85

weego wrote: post #74

Earlier quoted context omitted.

That's not really a good faith argument. That's the equivalent of saying that a major problem with NodeJS is you have to pick which version to install before you deploy. I deploy single package jvm files most days having not had to consider the deploy environment for a about 4 years.

> That's the equivalent of saying that a major problem with NodeJS is you have to pick which version to install before you deploy. Are you saying this isn't a major problem with Node? In my experience it's a problem with every language that requires a separate runtime. The JVM is the worst of two worlds because I have the build complexity of an AOT compiler to make my deployment artifact and the deployment complexity…

Post by touisteur » Sun, May 17, 2020, 1:46 PM UTC

Tsarbomb wrote: post #113

bsaul wrote: post #95

Earlier quoted context omitted.

I'm not sure what you mean. Deploying static binaries was the main way to go before, and is now the standard approach with go. Pretty much every service developed in go is deployed as a standalone statically compiled binary, and i would assume it's the same for code developped in Rust.

Except you need to make sure you built against the correct version of libc because you cannot statically link that. I remember when docker first came out and people were losing their minds about how they will be able to deploy their applications with all their dependencies in a single shippable bundle, kind of like an uber jar.

Post by gilbetron » Sun, May 17, 2020, 1:53 PM UTC

ashtonkem wrote: post #108

silisili wrote: post #59

Earlier quoted context omitted.

I don't understand Java apologists. I'm not saying Java is bad. Quite the opposite, it's one of the most optimized systems to date. But if you cannot admit Java apps are a pain to deploy, or, at least harder than deploying a static binary, I cannot take this argument seriously in good faith.

I’ve deployed Java apps for years, the idea that I must “admit” to Java being painful to deploy in order to be taken seriously is laughable. Like any other tool, Java has its pros and its cons, but you’re being hyperbolic.