Is Elixir good for microservices?

[pierrelegall]

I recommend you this article by Martin Fowler about microservices.

In the case of Elixir, you can write a monolith app but in it will run “as microservices” on the host machine, which is one of it’s killer feature.

However, microservices could be interesting with Elixir if you want to slice your service into functional pieces (e.g. for a team organization purpose).

[Skysoft13]

tnx so much appreciated

[quda]

How one can define microservices?
It has different meanings, depending on the project’s context.

[tj0]

I think this question was covered when microservices was more hyped up.

Here are some relevant discussions from a few years ago:

Is it fair to call an umbrella project a microservice chassis?

Don’t you mean umbrella project - as in the OTP app being the equivalent of a microservice? I’d say by default it is not - however there is nothing stopping you from moving functionality under the umbrella to end up with the equivalent of a microservices chassis. But I think ultimately one has to be careful with just chasing the microservices buzzword. I maintain that in Erlang/Elixir you should be able to get many of the benefits of microservices without having to invest in the usual opera…

Robert Virding’s quote in there is quite hilarious because Erlang has been doing microservices forever by its design.

Elixir in an environment of polyglot microservices; feasible or not?

My question: considering an application consisting of a set of polyglot [micro ~ substitute your definition]-services, would Elixir, and in extension Erlang, fit into such an environment? Disclaimer: I am new to Elixir. I’ve started learning and experimenting only a few weeks ago, and do not mean to offend with an unthoughtful question, I just didn’t come across satisfying answers to this problem yet. There have been several questions to this avail, and from the discussion arou…

Anyway, on another note, something no one hasn’t mentioned yet - microservices are very useful when you have cross-organizational boundaries and have 300 people trying to commit to trunk. They are somewhat useful when you have to scale a hotspot. And for everything else…meh.

One group I was working with in 2015 divided a system into 14 separate microservices for a team of 8-9. When I went to visit, I asked them, “Why are you storing the same data over these 5 boundaries? It’s all the same data, why not the same service.” They answered, “That’s what we said, but our architect told us we need to microservices!”

So whatever you’re building, don’t do that and blame the language(s).

[dub2]

hi smita, can you expand a bit on both of these?

[dimitarvp]

These libraries are not exclusive to microservices at all. They can and are used just fine in monoliths as well.

[dub2]

Ah right. Just curious how she would have set it up and what are the benefits and so on with that approach.

[dimitarvp]

There are almost no benefits to microservices unless you’re a huge corp. And that’s the core of the problem, people look at what Google / Facebook etc. do and wrongly believe that it fits their project.

Keep it all in a single repo, I am pretty sure you’re not working on the next YouTube or Netflix or Twitter.

[LuizzAugusto]

That’s surprising, I think micro services were agnostic about database. In my imagination I think it’s more about creating mini apis for every module that you don’t want to rewrite in every language to server and make it run on cloud.

[c4710n]

I wanna share a good old blog post about this problem:

Elixir in times of microservices « Plataformatec Blog

In short:

• Abstractions: Elixir has proper abstractions for handling code complexity as the codebase grows, such as OTP applications, etc. You can think every application as a so-called microservice.
• Communication: Communication between applications is easy - just function call and message sending between processes .You have no need to handle the general RPC things, like gRPC, or something.
• Observation: With :observer, you can inspect all application easily. Besides showing information and graphs about your live node, you can kill random processes, see their memory usage, state and more.

With all of these, you can build so-called “microservices” without pushing complexity into the network and interfaces and devops. (just like @gregvaughn said).

Yup, Elixir is good for microservices.

As Elixir programmers, we build “microservices” everyday. Just that we don’t call them “microservices”, but rather “applications”.

[Skysoft13]

I think, choosing the best programming language for your microservices architecture depends on a variety of factors such as your team’s skills and preferences, the requirements of your application, and the scalability and performance needs.

That being said, Elixir is a popular language for building microservices due to its scalability, fault tolerance, and low latency. Elixir’s underlying Erlang virtual machine (VM) is also known for its ability to handle high concurrency, making it a good choice for microservices that require a large number of concurrent connections. Elixir also has a growing ecosystem of libraries and tools specifically designed for building microservices.

Python is another popular language for microservices, thanks to its ease of use, flexibility, and vast library of third-party packages. Python’s strong community support and mature ecosystem make it a good choice for building a wide range of microservices, including web applications, machine learning services, and data processing pipelines.

Go is a newer language that has gained popularity in recent years for building microservices. It is known for its simplicity, performance, and concurrency features, which make it well-suited for building highly scalable and resilient microservices.

Ultimately, the choice of programming language for your microservices architecture will depend on a variety of factors such as your team’s skills and experience, the requirements of your application, and the specific features and trade-offs that each language offers. Consider trying out different languages and frameworks to determine which one best fits your needs

[pierrelegall]

There is still big misunderstandings on this topic.

Yes, Elixir is a choice to consider for a microservice as all other languages if you follow the “right tool for the right job” principle.

However, Elixir (as a BEAM-based language) can completely replace a microservices infrastructure being wrote as a monolith (or not), and run as microservices without going out of the BEAM (or a BEAM cluster). It is the purpose of Concurrent Programming Languages (CPL) as described by Joe Armstrong here and then here. The BEAM is today the only available technology to build things this way.

[dimitarvp]

Yeah, the problem in these discussions is everyone’s definitions of various terms are slightly (or severely) different.

While the BEAM is great for microservices-in-a-single-VM, it’s quite terrible at “a microservice is a single isolated program that must be able to cold-start in less than 50ms”.

So I agree, right tool for the job. For my definition of microservices (that I just mentioned) I see no other choice except Rust, Golang, OCaml and other languages that generate very fast binaries.

Though for at least 80% of everything I have in mind I’d still go with Elixir because the BEAM is that good; however, you can’t have good security isolation if you have several programs living in the same VM. And that is very important in a number of business scenarios where there is regulation and security licensing and compliance.