4 ms·
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 dep
by hosh 10mo ago
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).
- rdtsc 10mo agoYup, 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.
- hosh 10mo agoYeah, 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.
- Nextgrid 10mo 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.
- rdtsc 10mo 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.
- venturecruelty 10mo agoErlang 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.)
- rapnie 10mo agoYou 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/ https://gleam.run/
- venturecruelty 10mo agoThis looks delightful! Thanks for the recommendation!
- awesome_dude 10mo agoThis 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...
- com 10mo agoWell the canonical example is WhatsApp, but there are loads of other success stories if you care to look. Small teams, big results is a characteristic that I’m very interested in, in our post-ZIRP reality.