Hacker News Reader

Comment by amgreg | Hacker News Reader

> Some teams are happy to use Elixir to write web applications, to fit it into their pre-existing microservice deployment model. I urge developers to reach for those bigger thoughts that fault tolerant lighweight processes enable. You can consider each process a logical microservice, but you don’t need the friction of deploying it separately, and serializing to/from json, and containers, and orchestration, and distributed logging, et.al. You can deploy an entire system of millions of interacting logical microservices in a single BEAM release.

This resonates with me instinctually, but I’d love to learn more. What disadvantages would there be in jettisoning real microservices in favor of Erlang’s “logical microservices”?

View on HN

Release independence? If one team has a regression and needs to roll back their week's release, everyone gets rolled back too.

From my experience with microservices, this is kind of a utopia that never happens. What actually would happen is that everyone else's service is dependent on the new feature that the problematic service delivered, so they're all going to be rolled back anyway.

Maybe in very large, mature companies this happy land of backwards compatible, fully independent microservices, deployed totally independently, is possible. But in startups tearing forward at full speed with limited crew it's a pipe dream. The better solution is for proper source control management, so problematic changes that are actually independent can be reverted effectively, leaving everything else alone.

It's certainly true that microservices can be set up in such a way that they're really a distributed monolith. But you don't have to be a large, mature company to apply microservice best practices. A foundational best practice of microservice development is that each service has a staging environment that uses the prod endpoint for every service it depends on, and this is where you run acceptance tests prior to release. This way the staging behavior before release aligns with the prod behavior after release.

The week N release for microservice A won't have a dependency on a new feature in the week N release for microservice B, because the staging environment for microservice A (at release N) calls into the prod environment of microservice B (at release N-1), so the release-blocking tests wouldn't have passed.

It is a common and critical antipattern to have a single staging environment across multiple services, where each service calls the staging environment of each other service. This is a disaster waiting to happen for just the reason you describe.

I think the author's use of the microservices is unfortunate and confusing.

With the BEAM, it is easy to create fully independent process trees. The architecture enables it. In fact, you can pull in dependencies and add them as "OTP applications" (which is in essence a fully independent process tree, doing its thing.)

The BEAM lends itself very well to structuring parts of your application as independently supervised process trees.

This is similar to microservices, where each microservice represents a fully independent process tree, with which you can only communicate via well-defined interfaces.

As I said, the author's comparison to Microservices is very unfortunate.

What's the practical difference between a "real" microservice and an independent process tree potentially running on a different machine? Erlang/Elixir really doesn't have any trouble being distributed across multiple nodes, you just get a lot more latency on your messages.

You're correct, there's barely any difference, from a structural point of view.

I was mainly taking issue with the author's comparison of processes with microservices:

> You can consider each process a logical microservice

But as you said, the process trees can be considered (micro)services, but I wouldn't say that each process represents a microservice. It's just not accurate in my opinion.

OP here. You make a valid point. I was speaking in generalities in a short high-level blog post. I liked microservices better the first time when it was called SOA (service oriented architecture) in which there was an emphasis on the logical encapsulation of services. How they were to be deployed was a separate concern.

I was really trying to emphasize the logical separation vs. deployment separation and not the "micro" nature. Thanks for picking up on that.

Reply on news.ycombinator.com