How to Architect/Compose/Deploy and Secure Modern Erlang Applications

Questions:

  • How do you architect/compose/and deploy full stack erlang applications? This is a question I asked on the gleam discord forum.
  • What is the equivalent of the LAMP stack in Erlang?
  • What precautions do you take when exposing a Erlang node(s) to the internet?
  • Do you compose your application into Erlang nodes that run the webapps are exposed on the internet and other nodes run backend logic and are not exposed?
  • Do you find horizontal scaling to be more cost effective than vertical scaling?
  • If you are scaling horizontally, how do you spread the load across the nodes?
  • Do you depoly to bare metal, to VMs, or to auto-scaled resources like AWS Fargate?
  • How do you secure your erlang applications, and what do you use to test that they are secure?
  • What do you use for logging? For example, at work, we use fastapi + loguru → datadog
  • What is the sweet spot for ETS/DETS vs an external cache?

I have a handle on how to do this with traditional web stacks. Configure the LB to expose the web front ends to the internet, and expose whatever service APIs need the web front end needs to access. Keep all other resources such as databases, redis caches, control plane APIs, etc. in the private subnet (not exposed by the LB over the internet).

BTW - A lot of what I’m asking comes from reading Fred Hebert’s blog post: My favorite Erlang Container.

Related Links

1 Like

I know these are a lot of questions, all at once. But in a way, they are all the same question:

How do you typically use Erlang in internet facing applications?

And it’s clearly a loaded question as once something is internet facing, there’s a whole boatload of security concerns, which may or may not dictate a bunch of architectural concerns, which impacts how you compose things, and this impacts how you deploy the things.

Fixed link: How do you deploy Erlang applications in cloud?

For personal context: I’ve been wishing I could use Erlang at my various jobs for the past 15+ years, but have been more or less stuck with java, go, python, etc., and in the process, re-inventing erlang, but poorly (iirc either Armstrong or Virding was quoted as saying something like, “any reasonably complex software endeavor will re-invent 80% of erlang/otp, but poorly”). Anyway, with the advent of Gleam, I think I can make a stronger pitch that this is the way to go. But first, I need to understand some of these architectural concepts first. I really don’t want to be the guy that deploys a system that get’s pawned b/c I didn’t understand some core concepts and security constraints that everyone who’s steeped in this already knows.

That’d be Robert:

“Virding’s First Rule of Programming:
Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.”

(Robert Virding Quotes (Author of Concurrent Programming in Erlang))

2 Likes