DEV Community: Pierre Le Gall

Elixir can make you avoid the microservices architecture

Pierre Le Gall — Wed, 14 Dec 2022 17:54:02 +0000

While many companies are still thinking about a migration to a microservice architecture, many didn't hear about Erlang/Elixir yet. It seems surprising because Erlang solved a lot of scalability headache before the microservice concept was named; even before the first releases of Java and Python!

The purpose of a microservices architecture

To be as brief as possible, microservices architecture help in these cases:

scalability issues: monolithic apps can be hard to scale
splitting a service into functional parts: teams could have a much adapted code source organization for their project
language agnostic solution: you can choose the more suitable tool to solve a specific problem

Despite this nice characteristics, this is an expensive architecture (in time, context switching and team skills needed). If we think costs will just double, we are often far from the truth.

Common advice is to start small and simple, so microservices is rarely the best option at the birth of a project.

The case of Elixir

Elixir is welcomed in a microservices architecture, like every other languages. But that is not the point here: monolithic architectures with Elixir will be compared to microservices architectures.

Scalability

One of the killer feature of Elixir is the use of the BEAM (a.k.a. the Erlang VM) under the hood. The BEAM allows you to write an app as a monolith following the actor model patterns. Consequently, it runs it "as microservices" on the host machine; i.e. each operation runs in a single lightweight process without sharing memory. Data is shared between processes with message passing. So, all CPU cores are used without making a change to your code base (I really recommend this talk by late Joe Armstrong on this topic). Moreover, multiple BEAMs on different machines could work together as a cluster with a bit of configuration.

This is often the main argument in favor of a microservices architecture. However, Elixir (in fact, the BEAM) solved the issue about scalability a long time ago. The reason why it shines so much on this topic is because it has been design for concurrency from start.

Note Akka, the Java & friends framework, is working with the actor model and have as main inspiration Erlang to mimic some features of the BEAM on top of the JVM.

Functional split

Breaking a monolith into functional parts is doable thanks to the concept of apps in Erlang/Elixir. It enables us to add an app as a dependency of another app. Because all apps run on the BEAM, you take advantage of it: processes still communicates through the classic Erlang message passing mechanism.

Managing multiple Git repositories and their dependencies can be hard. In that case, Umbrella comes to the rescue to manage your different parts of your project in a single repository.

Language agnostic?

In the case of Elixir, there is fantastic tools helping you to stay in a monolithic approach. I think about Rustler to add safe machine code written in Rust to your project, or even Nx for AI purposes (like Numpy in the Python ecosystem) which can make use of the GPU for intensive scientific computations.

Nevertheless, microservices is still the architecture of choice to fully enable the "good tool for the right job" spirit.

In short

Erlang/Elixir can avoid you many complexities of a microservices architecture, because it's written as a monolith (with actor model patterns), but runs concurrently at the fine grain of processes. If you start a project, choosing it allows you to build a monolith without the need to rebuild everything as microservices in the future. If you feel the need of a functional split of the source code, the concept of "apps" comes to the rescue. But if Elixir does not seem to feet your requirements, feel free to think about a microservices architecture, but start simple as possible (probably with a monolith finally).

I will finish with a real world example of a company using Erlang/Elixir for their little messaging service called WhatsApp, which only needs 50 engineers for its 900M users. To name some others: Discord, Pinterest, Riot Games.

Stay curious, but pragmatic.

Git: amending commits and forcing with lease a push

Pierre Le Gall — Thu, 16 Jan 2020 10:03:44 +0000

I often have a discussion about git commit --amend and git push --force versus git push --force-with-lease with new colleagues.

First things first: it is ok to rewrite commits on your working branches, even already pushed commits. It allows you to remove useless commits and inconsistencies, resulting in a cleaner history.

Rewriting commits seems tricky as a beginner. However, if you want to rewrite the last one, git commit --amend allows you to do it easily. Not only the commit message is alterable, but the content of the commit too (you just have to add or remove some changes before your git commit --amend). This is definitely my main way for editing a commit. More advanced history rewrites may be done with git rebase which is a broad topic I will not discuss in this post.

After changing an already committed work, you will then be forbidden to push it the regular way. The reason is it would result to an inconsistent synchronization between your local machine and the remote. So you have to force your git push. But as you maybe already heard, git push --force is a truly bad habit. This is because, if something changed on the remote, it will not be taken into account. Put it another way, if someone else pushed a commit and you didn't pull it before, the commit will be lost (or more precisely, it will be hard to recover).

Maybe you think git push --force is unavoidable after rewriting your commits history? Spoiler alert: it's not true. The alternative is to use git push --force-with-lease. The --force-with-lease option works somehow like a --force, but will check if you are well synchronized with the remote before pushing. If you are not up-to-date locally, the command fails and warns you. In other words, you are forcing, but safely. This good practice may avoid many “where is that damn commit?!” situations in your team.

I sometimes heard: “I do not git push --force-with-lease but I always git pull before every git push --force”. Unfortunately, this is not enough yet because another push could be done by someone else between the two commands. Rare, but not impossible.

The Git CLI gets nicer these days, e.g. adding in version 2.23 the switch and restore sub-commands to do some stuff checkout is already capable of. Thanks to this update, we have now more suitable verbs to do the job. However, the CLI change I would be the most happy to see is a -f short option bound to the --force-with-lease option of git push. In this case, brutal force short option could use -F instead. Sadly, it would be a breaking change. Nevertheless, I am still passively hoping.