1. 35
  1.  

  2. 2

    While not in the same league, one may think of Kubernetes (also written in Go, BTW) as an alternative to the BEAM capable of orchestrating macro-scale processes (pods, services).

    I have noticed this too. Can anyone from elixir confirm this ? I wanted to learn elixir just to avoid kubernetes but erlang concepts are just weird. There are people who tried to port more BEAM style solutions to go on github.

    I am still not sure how different elixir is to deploying with lets say ansible + supervisord + python (with workers) on multiple servers, through an nginx proxy. Isn’t the real challenge of scaling database sharding, which is already solved by nosql ?

    1. 8

      While not in the same league, one may think of Kubernetes (also written in Go, BTW) as an alternative to the BEAM capable of orchestrating macro-scale processes (pods, services).

      I have noticed this too. Can anyone from elixir confirm this ? I wanted to learn elixir just to avoid kubernetes but erlang concepts are just weird. There are people who tried to port more BEAM style solutions to go on github.

      Think of Erlang as its own OS and you’re not far off. It’s not weird, per se, it just doesn’t resemble the other OSes you’ve used before. Also, it’s not like k8s isn’t a little weird too :)

      I am still not sure how different elixir is to deploying with lets say ansible + supervisord + python on multiple servers, through an nginx proxy. Isn’t the real challenge of scaling database sharding, which is already solved by nosql ?

      Deploying Elixir is a non-issue. Throw it in a Docker container and do what you want with it, if you like. There is no single “real challenge of scaling”, but Elixir is there not to be the challenge.

      1. 6

        So. I worked with a system that used to be ansible + uwsgi + python and I rebuilt it in elixir. It was a vm orchestrator (think bespoke ec2 for a special class of machine + customer). Maintaining the system with python was awful since it doesn’t really have a sane way to handle tracking state concurrently, especially when you are multidatacenter. Python forces you to think synchronously. When your objects go out of sync with reality you wind up in trouble (we had zombie vms all the time). Elixir by contrast makes you distrust any local data as soon as it’s obtained and guides you to smart strategies to handle conflict (crash the process and start over with a fresh pull of data).

        However I had to leave when I was knocked down the org chart and the cto that was put between me and the ceo could not understand this.

        1. 1

          When your objects go out of sync ?

          How can this happen ? Can’t we use database/redis as the source of state ?

          1. 3

            Yeah that’s the problem. The CTO wanted to treat the database as authoritative, when the source of truth was things IRL. It’s the object oriented mindset. And then I got blamed when stuff was not in sync, and the cto refused to create something that triggered a celery job to periodically poll my component to update the database.

            And I couldn’t have my component write to the database, because it was in a different data center (not that that would have been a good idea, due to separation of concerns).

            1. 1

              That sucks. I can see how elixir can make you think carefully about such state. That’s something I got out of a bit of clojure.

          2. 1

            Where was your authoritative data though? I can’t imagine that elixir somehow does away with a need for some source of truth.

            1. 1

              The authoritative information about the state of the vms lives at the edge, on the host machines. The authoritative information about customer intent lives in the database. So already there is something dangerous because information is not centralized. And it gets complicated. Suppose a customer does sudo shutdown from inside the vm instead of terminating from the dashboard (to be fair this was a huge problem for end users in the early ec2 days too). You have to think hard about reconciling these differences (and tolerating other corner cases, like netsplits or network disruptions, or orchestrator software redeploys, that might for reasons look like vm shutdown depending on how you are checking).

              Elixir doesn’t do away with that need but it just surfaces these concerns early because it doesn’t try to hide them behind artificial abstractions like objects. As an elixir dev you get into the habit of distrusting (in the sense of is it stale?) any data that comes your way. Along with that mentality it provides a very convenient way of dealing with inconsistency or confusion: log it, crash your process, and have it restarted with a fresh pull of data, so you also don’t have to think about reconciling any data dependencies, because they will be populated in the way that you expect from the fresh pull.

          3. 5
            1. 2

              The section on partial failures is enlightening. Having faced something like it in python, I can totally see how it works … but itsn’t the crash and fail model similar to apache + php in that case ?

              1. 5

                The key difference is the Erlang OTP model is often modelled in long running processes usually as gen_servers. Those processes are supervised and those processes are grouped such that failures are isolated. This structure makes it easy to reason about and isolate partial failures in your application.

                You can certainly provide the same isolation in PHP, but it not part of the core PHP platform.

                1. 1

                  It is similar to many things:

                  • system supervisor restarting your application
                  • ASG restarting your VM
                  • CGI when retrying request

                  The main difference between BEAM platform and others, is that BEAM makes it layered and basis for most of its work. So restarting is very quick, that in many cases you shouldn’t even notice that. Additional thing there is that the failure is highly isolated - it causes only single process to fail - no other parts of your system are affected at all (for example failure in one HTTP request do not cause any troubles in other, concurrent, requests in the same system).

              2. 3

                BEAM provides you with fault tolerance at the scale of a server rack, whilst K8S provides region failover. They do not operate at the same scale and this is by design. Now if you want, you can base an a big infrastructure on BEAM clusters, but you’ll be doing most of the hard work.

              3. 2

                Good article though I kind of wish it showed some examples. I really like the idea behind OTP, and using this to orchestrate Go (or other services) makes a lot of sense. I will do some research to understand a bit more how Elixir handles this.