Beehive router architecture

 

Introduction

Beehive is an open-source application deployment implementation that uses technologies like squashfs, erlang and ruby. It aims to provide a simple, easy application deployment platform. This post will go over the router portion of Beehive.

Architecture

Beehive is implemented with two servers. One server is the backend server that sits on the nodes that are available to deploy applications. The other is the router server. Note, these are not exclusive of each other, but there must be a router server that the client connects to and the backend nodes must have knowledge of access to the router. Here are a few specifications for the router of Beehive.

With this in mind, let's get right to the implementation of the router server. We'll come back to the backend server after we flush out the router implementation.

Router server

For the router server, we'll use the following modules (leaving out the obvious application details, like supervisors, etc.):

This is responsible for keeping track of all the backends the router knows about. When a new backend comes online, it will register itself with the backend_registry on the router node.

app_registry_srv.erl

This is responsible for keeping track of the current apps or packed applications that the router knows about. At an n-interval, the backend server (on the remote host) checks the node for new applications. If there is a new application found, it calls register to this server.

router_srv.erl

This is the glue between the two above mentioned servers. And handles messages to connect a client to the backend server that matches up to the requested resource.

Backend registry process

When the backend starts up, it must either be given a router_node, or it assumes the router is located on the same machine at the localhost name.

Application registry

Each backend node has a backend process that pings the system to see if there is a new application present. If there is an application present that was not previously known about, the app registry server is notified and updated.

Lookup routing:

When a request comes in, the router_srv is notified of a new request and asks the app_registry_srv for the list of backends that support the subdomain carrying the application.

Future upgrades

Enhance the application lookup by routing to the fastest responding backend server. This could be done by registering the router's backend server as a "listener" on the backend's backend_srv.