Forget Microservices: Just Use Erlang.

A distributed system, without the distributed headaches.

Forget Microservices: Just Use Erlang.

Once upon a time, software engineers decided that monoliths were bad.

"Monoliths don’t scale," they said. "Microservices give you flexibility," they said. "Just break it up into small services!" they said.

And then they spent the next two years debugging network partitions, timeouts, and retries, while their monolithic colleagues… just kept shipping features.

But hey, at least their architecture diagrams look nice.

The Myth of the Monolith

A monolith, according to microservices evangelists, is a big, scary thing that will eventually crush your hopes, dreams, and deploy pipeline.

The solution? Take your nice, self-contained system and distribute it across twelve different languages, five different message queues, and an unmaintainable web of HTTP calls.

Of course, now every request has a 1% chance of failing mysteriously, but that’s resilience engineering, not a bug.

A distributed system, without the distributed headaches.

Here’s the thing: if you write your system in Erlang, you don’t actually have a monolith. Instead, you get lightweight processes instead of OS threads—essentially microservices without the YAML. You get message passing instead of API calls, allowing for asynchronous execution without the added risk of network failures. And you get supervision trees that replace the need for a dedicated chaos engineering team because your system automatically recovers from failures. In short, Erlang provides all the benefits of microservices without the latency, operational complexity, or existential angst.

In other words: You already built an Erlang system—you just made it 10x slower and called it “modern architecture.”

Congratulation: You have built an Erlang

Virding’s First Rule of Programming

There’s an old saying:

“Any sufficiently complicated concurrent program in another language contains an ad hoc, informally-specified, bug-ridden implementation of half of Erlang. -- Robert Virding”

Which of course is a paraphrasing of Greenspun's tenth rule.

And yet, here we are.

People reinvent Erlang every day, usually by:

• Wrapping HTTP in gRPC.
• Implementing retries with exponential backoff.
• Logging everything, because nobody actually knows how their system works anymore.

So, Should You Build a Monolith?

Yes. But in Erlang. Because then, it isn’t a monolith.

It’s a highly efficient, self-healing, distributed system—without the part where you spend your weekends fixing Kubernetes networking issues.

And if you still really want microservices?

Congratulations, you already have them.

They’re just called OTP Applications, and they don’t require four extra DevOps engineers to keep running.

Conclusion

Before you break your system into 100 microservices, ask yourself:

Do you need microservices, or do you just need Erlang?

Because if you don’t, you’re probably just reimplementing it—badly.

And deep down, you already knew that.