Proposal: remove command and Helm modes

[krancour]

The obvious benefit of dropping these two modes is that it frees us to focus efforts on CF mode, Steward's internal state machine, and most importantly the UX.

Benefits aside, I'll try to defend why we can afford to lose these modes:

1. Through our participation in SIG Service Catalog, it has become evident that the community (for now, and for better or worse) regards the CF service broker API as the lingua franca of the service catalog space. This promotes CF mode in relative importance and demotes the other two.
2. The SIG's collective thinking seems to be trending in the direction of decentralized service catalog controllers. Multiple controllers, even of varying implementations, could co-exist in a single cluster to adapt different kinds of brokers (based on CF broker API or something else) to the k8s-native workflow. This is mostly in-line with how we envisioned Steward being used-- deployed in a 1:1 ratio with backing brokers. Where this departs from our thinking is that the SIG seems to imagine different implementations of a controller, whereas Steward (as a controller) is a single implementation offering three "modes." If we wish or hope that Steward could eventually be donated as the default or reference implementation of a service catalog controller, then the modes not operating on the lingua franca should be separated (if still valuable) to become their own, alternative, standalone implementations.
3. Command mode was well-intentioned. It was to provide a lightweight, easy-to-implement spec for broker developers. Having personally implemented command mode and sample command mode brokers, I see why it cannot succeed at this.
   1. Currently, In command mode, responses to discreet operations like provision or bind are written to STDOUT. These must conform to a specification mutually understood by Steward. That message format remains defined, at this time, by the CF service broker API.
   2. Currently, two compelling reasons exist to depart from writing responses to STDOUT. The first is that doing so represent a vulnerability. Binding responses contain credentials and we should assume anything written to STDOUT is logged. Second, using STDOUT as a communication channel precludes brokers from writing anything but the properly formatted response to STDOUT. Currently, this makes it impossible for command mode brokers to write debug messages to STDOUT, which is a major implementation constraint. In reaction to both of these issues, #169 has proposed that command mode brokers begin using a webhook (which Steward would listen for) as a new, more secure channel for sending responses. However such a change pushes additional responsibility onto broker developers and introduces a test-time dependency on Steward (or a mocked out webhook endpoint). I would assert that by the time #169 were addressed, the complexity inherent in implementing a command mode broker will have risen to a level on par with that of implementing a CF mode broker.
   3. Given the previous two points, it would seem the notion of command mode brokers as an easier-to-implement alternative to CF mode brokers will have been obviated. And given that, it seems the rational choice for broker developers would be to implement the CF broker API spec, which is well-established, better defined, and already considered by the SIG to be lingua franca.
4. Helm mode is incapable of satisfying what I would (personally) submit is Steward's primary use case-- using a k8s-native workflow to provision and bind to off-cluster services.
   1. Keeping your data on cluster still feels risky. Many (if not most) operators prefer to keep data off-cluster. Helm cannot do that.
   2. If an operator remains intent on standing up services in-cluster for consumption by their app(s), they can use Helm charts to do so directly. Steward is not required to facilitate that.

[arschles]

I mentioned the following offline, but I'll repeat here as well.

Many in the sig-service-catalog have discussed providing a reference implementation of a CF broker API based broker that adheres to the design in https://github.com/kubernetes-incubator/service-catalog/pull/13. My opinion on this issue is that we should:

• Build a library that implements all the Kubernetes-specific design bits according to the aforementioned PR
• Build steward on top of that library, and make it the CF broker reference implementation

[arschles]

Now that we've split steward into steward-framework and steward-cf, helm and command modes are effectively removed. We can always add them back by building a steward-helm and/or steward-cmd project in the future. Closing.