I’d also strongly recommend against kubernetes if performance matters, even if it does make networking easier. Containerizing BEAM results in a non-trivial performance hit.
zinclozenge
dazuma
Can you point me to some analysis on the performance issues of containerizing BEAM? (Benchmarks or reasons for performance reduction?) I’ve occasionally heard this claim and I’d like to understand where it’s coming from. Thanks!
7
tristan
Rebar3 Core Team
Was about to ask the same… I don’t know how it could have any BEAM specific performance hit, assuming properly configured.
If not properly configured and you end up with N active schedulers but limited cpu slices you are going to take a BEAM specific hit.
1
Overbryd
I would suggest making your application resilient against node downtimes.
Have you thought about integrating protocols that implement consensus to hold state in a distributed environment.
Then upgrading the app would just move the “leading” node once it is shut down.
Writes and consistent reads might be slightly degraded during rollout, but would eventually recover if implemented properly.
I would advise against container best practices. That said, why must it be containers in the first place?
After all, putting state to some place where it can be centrally managed is most probably the best option. Pick a database and roll with it, save yourself the headache.
In memory state is volatile, even on Erlang. Less so when taken care of, more so if run in dynamic hosting environments.
Just my 2c
1
alvises
because containers are great for isolation and environment consistency. In my not so distant past I was used to deploy in AWS using OpsWorks and Chef scripts.. a nightmare compared to Kubernetes.. But obviously I’m not saying “always containers”. My team and I, for example, tend to keep databases outside kubernetes. We had big issues with MongoDB replication inside k8s.
3
Overbryd
I understand. Chef and in particular AWS OpsWorks is really bad. I have been there too.
So I am also running some Elixir applications on Kubernetes, but I found that Kubernetes is practically replicating much of what Supervisors have to offer.
On the other hand, for any other language, service it is pretty darn powerful, and a bliss for maintenance and operations.
2
tristan
Rebar3 Core Team
I’ve never understood this comparison.
If this were the case then I don’t know why Erlang would come with heart when supervisors are already there.
0
Overbryd
Some long time later…
…and I am happily running many Elixir applications on container environments. I found they complement each other insanely well.
I talked about service discovery, finding consensus, and so on.
Well all that is solved in Kubernetes with a really powerful and elegant API.
I have grown to love it and work with it very well. Takes time to understand, but now I see (the light).
0
r8code
burmajam
There’s no library for deployment in k8s.You deploy your application as any other. What differs is the way you join nodes in a cluster. If that’s what you’ve meant, then libcluster is your friend.
0