Comment by hosh

Comment by hosh 3 days ago

14 replies

View on Hacker News

It is not so black and white.

The BEAM ecosystem (Erlang, Elixir, Gleam, etc) can do distributed microservices within a monolith.

A single monolith can be deployed in different ways to handle different scalability requirements. For example, a distinct set of pods responding to endpoints for reports, another set for just websocket connections, and the remaining ones for the rest of the endpoints. Those can be independently scaled but released on the same cadence.

There was a long form article I once read that reasoned through this. Given M number of code sources, there are N number of deployables. It is the delivery system’s job to transform M -> N. M is based on how the engineering team(s) work on code, whether that is a monorepo, multiple repos, shared libraries, etc. N is what makes sense operationally . By making it the delivery system’s job to transform M -> N, then you can decouple M and N. I don’t remember the title of that article anymore. (Maybe someone on the internet remembers).

Nextgrid 3 days ago

> The BEAM ecosystem (Erlang, Elixir, Gleam, etc) can do distributed microservices within a monolith.

This ain't new. Any language supporting loading modules can give you the organization benefit of microservices (if you consider it a benefit that is - very few orgs actually benefit from the separation) while operating like a monolith. Java could do it 20+ years ago, just upload your .WAR files to an application server.

Reply View 11 replies
  • rdtsc 3 days ago

    > Java could do it 20+ years ago, just upload your .WAR files to an application server.

    Erlang could do it almost 40 years ago.

    It can be used to upgrade applications at runtime without stopping the service. That works well in Erlang, it’s designed from the ground up for it. I know of a few places that used that feature.

    Reply View 8 replies
    • venturecruelty 3 days ago

      Erlang seems like a joy to use. I feel a slight pang of regret that I haven't (yet) gotten to use it in my career. (I don't quite have the time or energy to play with it during my off hours, but it is on my list for someday.)

      Reply View 7 replies
      • rapnie 3 days ago

        You might give Gleam [0] a try, which is advertised as "language you can learn in a day". It is type-safe, supports the BEAM and you can easily invoke Erlang and Elixir. Compiles to Erlang or Javascript.

        [0] https://gleam.run/

        Reply View 1 reply
      • awesome_dude 3 days ago

        This is kind of why I've never bothered to look at it - everyone /says/ it's a wonderful thing, but... nobody uses it in production, or hobbies (apart from the diehard fans)

        It might see the light of day at some point in the future, but if the past is anything to go by...

        Reply View 4 replies
  • hosh 2 days ago

    What BEAM offers isn’t modularity, but concurrency. Every genserver is operating concurrently, all within the runtime. Up until actor models came to Java, and more recent Java with lightweight threads, Java was incapable of this. Java is still missing things that BEAM and OTP provides.

    Besides: Erlang predates Java.

    Reply View 0 replies
  • to11mtm 3 days ago

    I mean sure but one could also argue that VB6 can do the same analogue of Java so long as ASP is involved... And yes I've seen it done; you have a basic interface similar to an actor, but really more like a 'Take a key-value in for input, do processing on it, return a key-value to go to the next stage' and then the other necessary glue to handle that. The way the glue worked, it was minimal ceremony to get a new module in.

    NGL It was clever enough that every few years I think about trying to redo the concept in another language....

    Reply View 0 replies
rdtsc 3 days ago

Yup, good point on the BEAM. The joke we used when microservices were hot was that the BEAM is already ahead with nano-services: a gen_server is a nice lightweight, isolated process. You can define a callback API wrapper for it and deploy millions of them on a cluster.

Reply View 1 reply
  • hosh 2 days ago

    Yeah, the isolation provides a fault tolerance not seen in wide use until Kubernetes.

    Although it would be neat to implement some of the benefits of a service mesh for BEAM — for example, consistently applying network retry/circuit breaker policies, or dynamically scalable genservers.

    Reply View 0 replies