Next lesson playing in 5 seconds

  • Overview
  • Transcript

3.6 Distributed Processing With Nodes

Once you have created an OTP application, you have the foundation for microservices. Distributed architectures are quite easy to achieve in Elixir with Nodes. In this lesson, I'll show you how.

3.6 Distributed Processing With Nodes

Hi, and welcome back to Get Started With Elixir. In this lesson, I'm going to talk about nodes and how to create a distributed application with them. A node is an instance of the BEAM virtual machine. To start a node, you just need to run iex with the --sname option to create a name node. You can get your own node name with Node.self and connect to other nodes with with Node.connect. You can either connect local nodes together, or nodes across a network. For security purposes, remote nodes need to share a cookie that gets specified during the creation of the node. On local machines, the cookie is automatically shared. After connecting nodes you can use Node.spawn and Node.spawn_link to spawn processes on other Nodes. Then you can send messages to these processes. Before we look at an example, let's have a look at some features of nodes. Code is not sent between nodes, but the messages are copied between them. This also means that there is a performance penalty if you send a message with a lot of data to a remote node. Let's look at an example, a distributed PingPong service. It can all happen in a single module. First, let's create a PingPong function that retrieves messages from the mailbox. It can either be a ping message or a pong. Both also have to pit from the sending note. So let's output something to the console. Sleep for one second then send a pong or ping message back to where the message came from, parsing its own pid. Finally, we have to call PingPong again so the process won't be terminated. I'm also going to create a start method that takes a local and remote node to set everything up. First let's connect to the local node and use the module and function element. Then let's do the same with the remote node. I can then initialize the PingPong procedure by sending a message to the remote node passing the local one. Let's try it out. I have to start two separate consoles to show that off. One is named a, the second one is b. Then I can start the experiment by calling PingPong.start and parsing the local note with the name of the computer which you can see in the terminal and the remote node. It will output ping and pong in the console. The reason why it all shows here is the way processes are organized in Alexa. Each process has a group leader, and sends the output to this group leader. In fact, it is quite a challenge to get the pit from the remote nodes console to output in there. But I can show you another way that the code is executed on remote node. Let's kill this console and change the output to Ping Ping!, and Pong Pong!. When we restart the PingPong process, only one of the answers was doubled up. And this is how you distribute your processes on nodes. To recap, nodes are a native way to distribute your code. You can use them to scale or transition OTP apps to other servers using nodes. Network latency still applies for remote nodes.

Back to the top