[erlang-questions] Dependencies, included applications and supervision

[Jay Nelson]

I am a strong advocate of using included_applications, but even a stronger advocate
of using “least constraint” architectural choices.

If you choose to implement your application in a manner compatible with the included
application rules (no initialization before root supervisor starts, only one root supervisor
called directly from application:start function), then it is possible for someone else to
include your application under their own supervisor hierarchy.

If you choose not to follow these rules, then you have chosen to not allow anyone else
to supervise your application from within theirs without access to your source and copy
and paste maintenance whenever you release a new version.

The latter is restricting the choice of future integration.

When you run “sibling applications” three things happen:

1) You must choose whether application death is ignored, or whether it will crash
the entire node — there is no in between.

2) You have to sprinkle ‘ensure_started’ calls throughout your code if there is a
dependency. And trust me, you can never be completely assured that it is started
at any given moment, ensure_started is yet another race condition.

3) You cannot guarantee start ordering and you may have unexpected race
conditions if you try to roll your own restart mechanism (every combination of
single or multiple application failure must be accounted for with every interleaving
of application restart).

As Max said, you can take a hammer to it and force all application deaths to crash
your node, and just ensure you always have multiple nodes, and a healthy load
balancer and guarantee that there are no hiccups with long restart times.

An application is really just a registry in an ets table with environment associated,
and some thin semantics about starting. It is a semantic container for a supervisor
hierarchy that provides a set of related functionality delivering a single service.
I like to integrate single services into a larger hierarchy with ordering and restart
semantics that I control. It is a more structured way to integrate erlang applications,
by removing one container and placing more than one root supervisor into a new
container.

I think a better future is to have sibling services and the ability to have services
degrade or go down, rather than a strict hierarchical supervision tree. But given
only a supervision hierarchy, there is no reason to write a library or an application
that precludes using the included_applications option. It should be the choice of
the integrator how to organize (and deal with the consequences) of their own
application server.

jay