Hacker News Reader

Comment by kevmo314 | Hacker News Reader

> Some teams were suffering from servicitis. Even worse than that, it generated a lot of friction while developing. One could not just look into a project in their IDE, but it required to have multiple projects open simultaneously to make sense of all that mess.

This is real: I've worked in projects where purely transformational code was offloaded into a "service". Refactoring it into a library reduced lines of code, computational cost, and code complexity dramatically.

But wouldn't it be cool if there were a framework where the developer didn't have to demarcate where services started and ended? In principle, any pure asynchronous function could be abstracted out to a service. It would be neat if the compiler did that for me and deployment of the application was more like "deploy the cluster" instead of deploying each individual service.

View on HN

Lol, that sounds like Java in 2011... put an annotation on a function and it's a service :) SOAP and all that.

Maybe they had something right! It did cause problems when users put something on a tight loop that was actually a remote call but not easy to see.

Anyho... what's old is new!

The one I was thinking of was SCA. Define the interface and implement the backend, either as a service or library, and the SCA layer in between would handle how to call it.

Also Java in 1996; remember RMI?

I used RMI but put a queue in front of it.

One at a time, please wait your turn...

Next up, leftpad.io, leftpad as a service.

Haha someone actually made this: http://left-pad.io/

This is comedy gold:

> `left-pad.io` is 100% REST-compliant as defined by some guy on Hacker News with maximal opinions and minimal evidence.

> But wouldn't it be cool if there were a framework where the developer didn't have to demarcate where services started and ended?

Erlang/Elixir, for JVM Akka, for .NET Akka.NET.

No, it's a bit of a myth that those techs just magically scale everything. They don't make that problem go away at all. You still need to find homes for the services to run on. It does make it a single function call to potentially start up a new service on a remote node, but if you need to be careful about resource use you're hardly any better off than you are with anything else. In a way that can end up being too easy to just add work to systems rather willy-nilly, the ceremony in kubernetes or any other more explicit system can be a good thing.

The question wasn't "how to magically scale everything".

The question was why not eliminate the difference between in-process async call and a service, and that's basically what Erlang and actors do.

That is what lots of actor frameworks are trying, first specify a DAG of tranformations and then instantiate that graph on a physical network of computers such that the async boundaries can be scaled independently. It's cumbersome, like writing the same program squared just to get scaling for "free".

Personally I think the Persistency-as-a-library and Consistency-as-a-library architecture is a saner alternative.

servicitis sounds like the absence of an experienced system architect, or the absence of any kind of system architecture as such.

Erlang?

Reply on news.ycombinator.com