Please define “microservices”. Do you mean them as a physical deployment model? If so, I think that is a pox on the software industry, pushing complexity into the network and interfaces and devops. If you mean it as a logical model, then, yes, each BEAM process is a microservice. It is isolated from its peers from crashes due to supervision trees. They communicate via memory-copied messages (however binary vs. json).

I am hugely in favor of logical microservices in an Elixir release, but I have issues with the more conventional meaning of the term.

That’s the wrong question to ask. Much better question is: “Why have microservices?”

The classic microservices are basically self-contained apps that still have to work together and each has a separate database. That’s a nightmare to maintain because what can be a simple function call is now a networked exchange of messages – needlessly complex (and 1000x times slower, too)! Even something like 2 separate microservices is going to be a huge drain of your time and energy.

Advice: do NOT fall for hyped up videos or “tutorials”, do NOT listen to some 22 year olds that barely have one production project behind them but are now excited because they themselves saw some hyped up video.

IT work (programming included) is about ruthlessly managing and reducing complexity. Do NOT introduce complexity in your paid work. Oh, and don’t mix languages unless you are forced to. Stick to one language.

If you are so hyped up about something, try it on your own time and on a hobby project. If you do that in your paid work I promise you that you’ll dearly regret it and will curse your life.

I’ll echo what @gregvaughn and @dimitarvp have said. However, if it was decreed from above that you have to use a microservice approach, then the answer is yes, Elixir can do microservices, and monolithic, and everything in between.

I’ve never seen anyone voluntarily build a bunch of microservices in their personal hobby project. If I were a masochist, there are easier ways to torture myself.

Why not? Because the upside it has is largely overrated for most projects but it brings tons of complexity. The kind of costs you only should be willing to pay if your app is so complex/large that is is a problem.

Real microservices don’t share a database. Figure how you do joins, how you ensure all services have the same definition of a ‘user’, how you version interfaces, etc etc.

Ohhh…and stay away from NoSQL. As cool as they make it sound; it super fun for prototyping but once apps grow it soon becomes a burden only to become valuable again once you have enormous amounts of data (but then your schema is probably less fluid so that’s okey)

Why you want microservices in the first place?