3 ms·

I'm not afraid of specialized tools. For example I've used RabbitMQ which I believe is written in Erlang. We run it in Kubernetes in both our CI environment an

I'm not afraid of specialized tools. For example I've used RabbitMQ which I believe is written in Erlang. We run it in Kubernetes in both our CI environment and locally so we can use the same configuration for both. It runs a dozen microservices and saves us a lot of devops time. In our CI environment it's nice for a developer to roll out a new copy of the services from a different branch for testing, and because of the autoscaler nodes are dynamically provisioned when needed, and then removed when the test environment is destroyed. That's pretty nice functionality you get basically out of the box. On EKS anyway. There are some occasional rough edges, but I think the decision to use k8s for this makes sense... At some point we'll migrate prod too. Kubernetes has a lineage as well... Based on the Borg project at Google. I guess I'm not seeing why these things are being compared. Aren't they solving different problems?

comma_at 8y ago
I think (s)he was talking about BEAM. Using RabbitMQ makes no difference if you're not programming in Erlang. If you look at the BEAM VM you will see isolated processes, supervisors, restart strategies etc. Wikipedia[1] lists Erlang's runtime system characteristics: "Distributed, Fault-tolerant, Soft real-time, Highly available, non-stop applications, Hot swapping, where code can be changed without stopping a system." Does that ring any bells? [1] https://en.wikipedia.org/wiki/Erlang_(programming_language) https://en.wikipedia.org/wiki/Erlang_(programming_language)
- cdoxsey 8y ago
  So you're suggesting we use BEAM instead of Kubernetes? So just rewrite all our code in Erlang, including off the shelf products we didn't write? Then use some other technology to deploy the software, configure the machine, come up with a way to do service discovery, attach block devices to nodes, and automatically provision new machines based on resource usage? It doesn't make sense yet it's seemingly repeated on every thread about Kubernetes. The Erlang community should celebrate technologies like Kubernetes, Mesos, or any other number of resource scheduling systems because they're finally the industry taking seriously the problems addressed by Erlang.
  - Thaxll 8y ago
    The biggest difference is BEAM is Erlang which imo is what's done wrong, Kubernetes is language neutral, it's a platform not a language runtime. Similar to what Envoy is when you do service mesh, you don't need to integrate libraries into your code to get service mesh features using Envoy as side car proxy. I have that conversation with Erlang users on every k8s topics, they seem to miss the point that decoupling features outside of the language / runtime is the way to go.

comma_at 8y ago

I think (s)he was talking about BEAM. Using RabbitMQ makes no difference if you're not programming in Erlang. If you look at the BEAM VM you will see isolated processes, supervisors, restart strategies etc. Wikipedia[1] lists Erlang's runtime system characteristics: "Distributed, Fault-tolerant, Soft real-time, Highly available, non-stop applications, Hot swapping, where code can be changed without stopping a system." Does that ring any bells? [1] https://en.wikipedia.org/wiki/Erlang_(programming_language) https://en.wikipedia.org/wiki/Erlang_(programming_language)

cdoxsey 8y ago
So you're suggesting we use BEAM instead of Kubernetes? So just rewrite all our code in Erlang, including off the shelf products we didn't write? Then use some other technology to deploy the software, configure the machine, come up with a way to do service discovery, attach block devices to nodes, and automatically provision new machines based on resource usage? It doesn't make sense yet it's seemingly repeated on every thread about Kubernetes. The Erlang community should celebrate technologies like Kubernetes, Mesos, or any other number of resource scheduling systems because they're finally the industry taking seriously the problems addressed by Erlang.
- Thaxll 8y ago
  The biggest difference is BEAM is Erlang which imo is what's done wrong, Kubernetes is language neutral, it's a platform not a language runtime. Similar to what Envoy is when you do service mesh, you don't need to integrate libraries into your code to get service mesh features using Envoy as side car proxy. I have that conversation with Erlang users on every k8s topics, they seem to miss the point that decoupling features outside of the language / runtime is the way to go.