How should the Plugin SDK (and Meltano!) represent services vs standard commands

[aaronsteers]

Internally and in the community, a lot of thought is going into 'services' as can now be supported informally within Utility plugins but in the future may be formally declared and instantiates.

Informal Plugin Support in Meltano

A plugin can have a command that means something like up or start, and a user can be instructed to run the up command to launch the service and the down command to brind down the service.

Formal Plugin Support in Meltano

A more formal contract for services in Meltano and Meltano plugins/extensions would be to have a formal contract for how services perform basic functions, especially: start, stop, restart, and status.

If Meltano knows how a plugin can be invoked as a service, then we can better support applications such as postgres, superset, ssh-tunnel, etc. - and we can even define tasks or jobs as 'requiring' one or more services. (E.g. a tap which requires an SSH tunnel to reach the endpoint, or a 'test job' that requires a postgres service as backend.)

Currently Out of Scope: Many Services Per Plugin

Initially we only imagined one service per plugin (e.g. Superset, ssh-tunnel or postgres) but @pandemicsyn rightly calls out that some plugins could require separate service invocations for . While this doesn't necessarily need to be supported in first iterations, it's healthy for us to consider as we are doing design work on the interfaces and contracts for plugins and their service relationship(s).

To avoid unnecessarily complicating this issue, let's keep this out of scope for now and have a separate discussion thread to talk about how a given plugin might support multiple services.