3 ms·

We've been building this way ever since we moved to Elixir which makes distributing state across your application easy. Memory on application servers is severel

by thdxr 7y ago

We've been building this way ever since we moved to Elixir which makes distributing state across your application easy. Memory on application servers is severely underutilized

lifeisstillgood 7y ago
Can you explain more?
- liveoneggs 7y ago
  probably just using ETS out of the box
- the_duke 7y ago
  Erlang/OTP provides a system of stateful processes that communicate via message passing, with a focus on resiliency and fault tolerance. These processes can seamlessly interoperate while running on multiple machines. This makes building stateful application servers a pretty natural fit.
- wmeddie 7y ago
  Systems like Erlang/OTP, Akka, Orbit and Orleans/Service Fabric are built on an actor model where domain objects of the system (e.g. Users, Accounts, Invoices, etc.) exist within the cluster and have a an address so they are like having a bunch of mini servers. These servers typically keep their state in memory so they can respond to query messages quickly. Plus the application can unload idle (or no longer necessary) actors and restore their state when they are needed again. It's very similar to the Linked in-memory key-value idea mentioned in the paper.
  - cuddlecake 7y ago
    I think it is an anti-pattern to design a system where each domain object is a process. Sometimes data is just data and should be managed as such. I think what makes actor models so nice is the explicit ownership of state. It is not possible to declare "var x = 1" in one file, and access x in another file. You always have to retrieve state explicitly, otherwise it won't be accessible within the scope of your function.
- sb8244 7y ago
  We do this for several key elements of a high throughput service. It keeps the critical path local only. The flow is to dual write to our rdms and a local process. The process either stores in ETS or an process state map. It also broadcasts out the event to the cluster. When a node in the cluster gets a message, it executes on it. Process startup is restored from the DB which is still authority. Generally this is really easy to do in Elixir. Maybe 50 lines of code for the system described (minus DB code), much of it definition lines.
bastawhiz 7y ago
> Memory on application servers is severely underutilized That's highly dependent on your choice of language and how you're running your app.
atonse 7y ago
Came here to add this. At least based on this paper, I feel better about where things are headed with my choice of using elixir/erlang/OTP as the primary stack for our web services, for exactly this reason. While we don't have the scale yet to need to cluster out and handle these kinds of issues, I've told my cofounder, that thanks to Elixir, I'm not terribly worried about the costs when does happen (not as worried as I would be if we were using something like ruby)

by thdxr 7y ago

We've been building this way ever since we moved to Elixir which makes distributing state across your application easy. Memory on application servers is severely underutilized

lifeisstillgood 7y ago

Can you explain more?

liveoneggs 7y ago
probably just using ETS out of the box
the_duke 7y ago
Erlang/OTP provides a system of stateful processes that communicate via message passing, with a focus on resiliency and fault tolerance. These processes can seamlessly interoperate while running on multiple machines. This makes building stateful application servers a pretty natural fit.
wmeddie 7y ago
Systems like Erlang/OTP, Akka, Orbit and Orleans/Service Fabric are built on an actor model where domain objects of the system (e.g. Users, Accounts, Invoices, etc.) exist within the cluster and have a an address so they are like having a bunch of mini servers. These servers typically keep their state in memory so they can respond to query messages quickly. Plus the application can unload idle (or no longer necessary) actors and restore their state when they are needed again. It's very similar to the Linked in-memory key-value idea mentioned in the paper.
- cuddlecake 7y ago
  I think it is an anti-pattern to design a system where each domain object is a process. Sometimes data is just data and should be managed as such. I think what makes actor models so nice is the explicit ownership of state. It is not possible to declare "var x = 1" in one file, and access x in another file. You always have to retrieve state explicitly, otherwise it won't be accessible within the scope of your function.
sb8244 7y ago
We do this for several key elements of a high throughput service. It keeps the critical path local only. The flow is to dual write to our rdms and a local process. The process either stores in ETS or an process state map. It also broadcasts out the event to the cluster. When a node in the cluster gets a message, it executes on it. Process startup is restored from the DB which is still authority. Generally this is really easy to do in Elixir. Maybe 50 lines of code for the system described (minus DB code), much of it definition lines.

bastawhiz 7y ago

> Memory on application servers is severely underutilized That's highly dependent on your choice of language and how you're running your app.

atonse 7y ago

Came here to add this. At least based on this paper, I feel better about where things are headed with my choice of using elixir/erlang/OTP as the primary stack for our web services, for exactly this reason. While we don't have the scale yet to need to cluster out and handle these kinds of issues, I've told my cofounder, that thanks to Elixir, I'm not terribly worried about the costs when does happen (not as worried as I would be if we were using something like ruby)