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.
While others has spoken finely about why you really consider carefully about microservices approach (recently popular opinion has moved toward modular monolith, even among microservices proponent like Sam Newman), i want to focus if you decide to do microservices approach, how do you decide between elixir/python/golang?
Each of the language has it’s strong point and weak point, you would need to consider which of the language suit your problem domain + context the best.
IMO,
Elixir has it’s strong suit on correctness + robustness + general productivity, example problem domain it shine is communication (WhatsApp), blockchain/web3 tech, and rapid application development
GoLang has it’s strong suit on low level/binary manipulation + fast performance + tooling support, example problem domain it shine is CLI tools, binary level work (video/streaming encoding), gRPC based microservice.
Python has it’s strong suit in it’s large amount of library (especially data based library) + general productivity, example problem domain it shine is machine learning, and rapid application development
Context is things like company culture and developer general skill. for example some company is invest heavily on JVM, so usually when they introduce new language, it’s a language which are supported on JVM (like clojure/scala/kotlin).
tnx so much for ur answer, I have an example, you have a mobile app like tiktok, it has message service and video streaming service, I mean if you were create microservice about it, how you will decide, like write chat service by elixir, and video streaming service by python, or write all services by elixir?
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).
I think this question was covered when microservices was more hyped up.
Here are some relevant discussions from a few years ago:
Robert Virding’s quote in there is quite hilarious because Erlang has been doing microservices forever by its design.
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).
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.
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.
I wanna share a good old blog post about this problem:
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”.
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
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.
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.
