Transient Services

Until now, to run a distributed transient program it was necessary to distribute manually the same copy of the program, compiled for the architecture of the node, then connect each program to the cloud.

The distributed program follows a single monadic expression that execute the whole distributed program. This is great for composability, maintainability and readability. But it has two disadvantages:

• It is necessary to distribute the executable, execute and connect manually and
• The program must be almost identical in all nodes, or at least must have the same closure variables which are shared in the log (it can even be written in different languages, theoretically)

These two problems are eliminated with transient services. Services can be executed remotely on demand at runtime by a monitor. This means that if a program being executed need a service, the cloud will be asked for a suitable node that would install it from sources in a git repository if necessary, so the application will continue his execution.

A program can perform a remote call to a transient service, which is a completely different program so the second problem is solved.The interaction is with all the effects of the transient monad: I can stream in both directions. A transient service, for example a database, being called by a program, can send messages reactively to the calling program each time a record is updated. This is not possible with REST services if not with web callbacks (webhooks) that must be set at installation time. This generates a callback hell at the distributed level that precludes composability.

Analogously a REST service with webhooks can be transformerd as a transient service by inverting the callback using react.

So transient services permits to split an application in different distributed pieces without loosing power and composability.

Currently this is under development.