Hacker News new | ask | show | jobs
by weatherlight 1029 days ago
Well, in big orgs, that adopt Elixir/Erlang, along with other technologies with poor concurrency stories, those other ecosystems still need Kubernetes, Kafka, Redis and GRPC, to get by. elixir isn't going to make ruby or python apps magically concurrent. So that make sense.

However, in orgs that are primarily Elixir shops, I don't see a lot of Kafka or gRPC. (Redis is just useful, its more than just a queue and K8s and Elixir/Erlang compliment each other, btw.)

1 comments

>those other ecosystems still need Kubernetes, Kafka, Redis and GRPC, to get by

And what makes Elixir not need Kafka, Redis or GRPC?

Instead of Redis, you could use ETS for caching. But once you have 2+ instances of your app, you will need to have a centralized caching mechanism, otherwise, each instance will have its own ETS with its own memory, not sharing anything. Unless you decide to use Distributed Erlang and connect all the nodes of your application, which comes with a lot of trouble. Much easier to just use Redis.

And lets say you have multiple teams, each team has its own service(built with Elixir), and you need to have some async communication between those services. What native Elixir solution would you use instead of Kafka?

Same for GRPC. What's the alternative? Connecting all the nodes and using Erlang message-passing?

I think Elixir/Erlang + Redis pub-sub + PostgreSQL is the sane minimal subset for distributed and scalable systems.

Just say no to Kafka.

Where kafka comes in though is no-code db following. These are super handy when you want to be informed of changes to a table, but don't know which "micro-service" is changing the data. KafkaConnect is very handy.

Though I will concede, it's a bit of a bazooka for a mosquito, sort of thing.

After using NATS I don't think I'll ever want to use redis pubsub again.
ETS is quite faster than using Redis though.
single node though, so you have to add distribution in some manner. For some situations, whether its the "right" way or not, redis ends up being an easier way to go.

ETA: As another couple of comments pointed out, ETS also dies with the node so you've got to handle that also when rolling it.

ETS is cool, but its not a panacea.

Nebulex has different adapters although I've only use it on a local node which uses ETS and with transient data so I can't comment on them too much.

https://github.com/cabol/nebulex

> Connecting all the nodes and using Erlang message-passing? Most of the time, yes.