[brightball]

I tend to agree with you and it's one of the biggest reasons that I'm a fan of Elixir.

Here's the path that leads to K8s too early.

1. We think we need microservices

2. Look how much it will cost of we run ALL OF THESE microservices on Heroku

3. We should run it ourselves, let's use K8s

One of the big "Elixir" perks is that it bypasses this conversation and lets you run a collection of small applications under a single monolith within the same runtime...efficiently. So you can built smaller services...like a monolith...with separate dependency trees...without needing to run a cluster of multiple nodes...and still just deploy to Heroku (or Gigalixir).

Removes a lot of over-architectural hand-wringing so you can focus on getting your business problem out the door but will still allow you to separate things early enough that you don't have to worry about long term code-entanglement. And when you "need" to scale, clustering is already built in without needing to create API frontends for each application.

It solves a combination of so many short term and long term issues at the same time.

[lilactown]

100% agreed. A lot of the cloud computing products are simply re-implementations of what was created in the Erlang/BEAM platform, but more mainstream languages. IMO it's cheaper to invest in learning Erlang or Elixir than investing in AWS/K8s/etc.

Elixir and Erlang are basically a DSL for building distributed systems. It doesn't remove all of the complications of that task, but gives you excellent, battle tested, and non-proprietary tools to solve them.

[pjmlp]

And JEE :)

[_asummers]

> One of the big "Elixir" perks

This is also true of Erlang, for those not aware that Elixir runs on the Erlang Virtual Machine (BEAM).

You do get a lot of cool things with clustered nodes though (Node monitors are terrific) and tools like Observer and Wobserver have facilities for taking advantage of your network topology to give you more information.

[pencilhappen]

Not my tweet, but so so relevant:

https://twitter.com/littleidea/status/532927711472549888

[coffeecount]

http://rvirding.blogspot.co.uk/2008/01/virdings-first-rule-o...

[pjmlp]

Same applies to JEE application servers.

They are basically an OS, with containarized applications.

Thanks to them I stopped caring about the underlying OS.

[brightball]

Not going to lie, Java app servers basically had me predisposed to see the appeal of Elixir. When I was spending a lot of time with Ruby I got really into Torquebox (Ruby-ized JBoss) specifically for the clustering aspects, ability to spread workers and clustered cache with Infinispan.

Elixir has a lot in common, but it takes it to another level. You can call functions from those other applications on the server with nothing more than a Module.function(arguments). You can call a function on another node in the cluster by just sending the node + module, function and arguments.

Because of immutability and message passing, this just works everywhere. With Java, a similar implementation would have to guard against memory references and mutex locks that wouldn't behave the same way on different nodes.

[fokinsean]

Interesting, I didn't know that about Elixir. Do you ever have to break them up into smaller Elixir apps or can you stick with that pseudo-monolith for good?

[brightball]

You break them into smaller apps. It’s little more than code rearranging though.

You can still call the functions through the same Module.function() approach you’d use if they were in the same app.

The $30 PragDave Elixir for Programmers course actually drills in this approach the whole way through if you’re looking for a good resource.

[dceddia]

Seconded. It's a very good course for someone getting started with Elixir having already had a good amount of programming experience.

I originally bought it at $60, and even at that price point I would buy it again.