The automatic scaling is in fact the point. k8s provisions the servers, orchestrates the loads and does a lot more things that only connecting nodes. BEAM can't do that, you have to physically provision a node, connect it, assign some storage, ensure that is in enough availability zones so that your app is resilient to failures. With just a Erlang cluster, if a node dies, it dies forever. You have to restart it with tools/scripts outside the beam. If you want to share storage between nodes, you can't do that with beam. What I want to say is, as impressive as the BEAM is, it is quite limited in what it can do to keep your cluster healthy and elastic.
Of course that's not a requirement for every application, but when you have that requirement, k8s solves the problem and BEAM doesn't.
Ok! I imagine you can form a cluster of containers (not sure how they communicate) but if I read you, it doesn't make any sense. Just have a dockerized app at let k8 do the piping and scaling. Now, if your application is modest, I believe you have a cheap and robust implementation using a small cluster, knowing that you have to keep an eye on you nodes. BEAM looks more like Docker Swarm, isn't it?
Yes, you're right.
For small clusters and if you don't really need the added complexity of k8s and are willing to do the monitoring/provisioning of nodes, a simple Erlang cluster of your Elixir application is a perfectly valid solution. I think for some internal application in a company that has on premises servers, that's is a solution that works very well.
k8s is not a solution for everyone, and certainly not for small apps, or apps with very few users or that don't need high availability.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The automatic scaling is in fact the point. k8s provisions the servers, orchestrates the loads and does a lot more things that only connecting nodes. BEAM can't do that, you have to physically provision a node, connect it, assign some storage, ensure that is in enough availability zones so that your app is resilient to failures. With just a Erlang cluster, if a node dies, it dies forever. You have to restart it with tools/scripts outside the beam. If you want to share storage between nodes, you can't do that with beam. What I want to say is, as impressive as the BEAM is, it is quite limited in what it can do to keep your cluster healthy and elastic.
Of course that's not a requirement for every application, but when you have that requirement, k8s solves the problem and BEAM doesn't.
Ok! I imagine you can form a cluster of containers (not sure how they communicate) but if I read you, it doesn't make any sense. Just have a dockerized app at let k8 do the piping and scaling. Now, if your application is modest, I believe you have a cheap and robust implementation using a small cluster, knowing that you have to keep an eye on you nodes. BEAM looks more like Docker Swarm, isn't it?
Yes, you're right.
For small clusters and if you don't really need the added complexity of k8s and are willing to do the monitoring/provisioning of nodes, a simple Erlang cluster of your Elixir application is a perfectly valid solution. I think for some internal application in a company that has on premises servers, that's is a solution that works very well.
k8s is not a solution for everyone, and certainly not for small apps, or apps with very few users or that don't need high availability.