> the barrier to rolling my own is lower for me than introducing a Java dependency.
Really? I never had problems using some JVM base image and deploying via a Docker image, which is what I would be doing anyway.
Really? I never had problems using some JVM base image and deploying via a Docker image, which is what I would be doing anyway.
> If it provided some massive major advantage over the large number of other options, I'd consider it
People reject using technologies because of the impact of having to support them all the time when the benefit does not justify needing to support one more technology. I don't have an issue with using JVM based services if I can have someone else manage them for me, but when I have to deal with the operational issues myself, or within my team, then how comfortable we are with managing a specific technology vs. the advantages it brings over competing alternatives absolutely is part of the consideration, and it'd be irresponsible for it not to be.
In this case the benefit seems marginal at best, and I'm not deploying a JVM based service for marginal benefits given how much hassle they've brought me over the years.
Nothing is outright rejected because it runs on the JVM, but it is a detracting quality, adding complexity. If Kafka is clearly the best solution available for your problem, you'll suck it up and the use JVM, but if there is another approach that will also serve your needs without a JVM dependence then the choice is easy.