Hacker News Reader

Comment by whalesalad | Hacker News Reader

You’re missing a lot! In the case of a simple request/response web app yes it doesn’t do a whole lot. Imagine you’re building a complex system with lots of different behavior patterns. Let’s say a backend that fans out to 100 different 3rd party APIs, like a shipping aggregator that needs to talk UPS, FedEx, USPS, Canada Post, Royal Mail, etc… and you want to be able to carefully control rate limits, batch sizes, etc.. to those endpoints. An actor system with supervision trees is a very good way to build a system like this.

Also... the rhetoric here on HN about Erlang/Elixir vs. Kube really needs to stop. People are misinformed. They are not mutually exclusive, you do not need to choose one or the other. We need to reconcile that because the discourse always goes to this weird war in the comments.

View on HN

Jose Valim has a post[0] on the Platformatic blog about how Elixir and Kubernetes can happily co-exist together, and that each solves problems at different levels.

[0] https://blog.plataformatec.com.br/2019/10/kubernetes-and-the...

That sounds very interesting and specific.

If it's not a random example and if you're at liberty to say, would you mind elaborating further how Elixir specifically excels in that particular use case, and what would an alternative approach, regardless how cumbersome, be?

I have been meaning to write a blog post - I am going to escalate the priority on that.

This really isn't an elaboration on the grandparent comment but if you are interested in general in learning how Elixir excels at data pipelines I'd suggest looking at this library:

https://hexdocs.pm/broadway/Broadway.html

your example is interesting. I assume the reason is that it's an in-between situation between stateful and stateless: aka shipping using 3rd party api is a transient state of a complex process that can be ultimately recreated from the orders stored in the DB, but better not for speed reason.

I wonder if there are other patterns like that.

Any kind of long held connection is state ;) So websocket, long http one, database connection, etc.

Being able to tightly define what part of your app is impacted if one of these fail and restore it before the rest of the app is impacted is a game changer.

OTP also deeply force you to think of how you start and how you stop these, taking dependencies into account. It helps in cleaning up stuff.

sure. By state i really meant working end-user business-level data. Those are the kinds that really set the type of guarantees you need for your system.

I guess i'll have to try OTP one time to understand why so many people rave about it. I only know one guy who had made real work with erlang / otp and he told me it was beautiful, but not quite as relevant anymore, because of k8s. But i guess i need to make my own opinion.

If the value you're looking for is just 0 downtime, then k8s solves that for you. As others have pointed out, the BEAM/Elixir/Erlang give you great process isolation and resilience to small failures, timeouts, weird transient issues, big short lived spikes traffic, and stuff like that.

With respect to user data, a supervised process can crash and the supervisor can restart with the last known good state of that data. It requires some thought on the part of the developer to achieve this, but it's really powerful.

You don't need k8s for 0 downtime, putting a monolith into an autoscaling group behind loadbalancer solves that ;)

> aka shipping using 3rd party api is a transient state of a complex process that can be ultimately recreated from the orders stored in the DB, but better not for speed reason.

Plus some 3rd party APIs are rather terrible and if you end up re-sending a request (because your server/container went down after the request got sent to the API, but before the response got back/was processed) then the 3rd party API could end up in an inconsistent state.

Reply on news.ycombinator.com