[almighty] Major Architectural Question for the Build

[Michael Kleinhenz]

Hi all,

preliminary notice: I can live with any of the solutions, I see
advantages and problems with both.

Maybe I have done too much sales on such stuff, but I think the
"Consumer Model" will be a major roadblock in actually convincing
people to support us. This model will require lots of effort, changes
to their live system and/or deployment and operations(!) to support
integrating with us. In my experience especially the last one,
operations, is a real blocker for 3rd parties. Just my 0.02€ on real
world adoption of products in the corporate world..

I think our way of approaching that question is way to technical and
not enough sales. (I am feeling dirty that I have said that :-)

But anyway, again: if we decide for the consumer style model, thats
fine for me, I just want to say that there might be another, non-tech,
view on that.

-- Michael


On Tue, Nov 1, 2016 at 6:30 PM, Andrew Lee Rubinger <alr at redhat.com> wrote:
> Gave some time to think this through. :)  Appreciate the thoughts Michael,
> because I think your email here has redirected our line of thinking into
> something better than originally designed.
>
> To me, the most important issues this thread has vetted are:
>
> 1) Encouraging extension of Almighty through new providers
> 2) Security
>
> Now, I had been initially conceiving something akin to what Michael is
> calling the "Deployment" model; an interface that providers implement.  On
> further reflection I've come to find the REST-based approach outlined as the
> "Consumer" model accomplishes all of our goals and better handles the two
> points above.
>
> For 1), we let users register their own service, running *somewhere*, to be
> written in whatever language and execution environment they decide.  This
> imposes on providers writers the burden of deploying their thing instead of
> deploying it into Almighty, but, as 2) shows, this is a good thing.
>
> The security constraints of 2) really say that we will absolutely not run
> untrusted code in our online service offering.  Initially I'd thought that
> anyone who wants to write their own providers could be on their own to host
> an Almighty instance as well, but by making the provider model a firewall
> where untrusted code runs externally to Almighty, we could be opening
> ourselves off to safe extensibility or community-driven extensions in the
> future.  While this is not a requirement for our first launch, it's
> definitely the kind of thing Todd envisions for us going forward.
>
> TL;DR for me now: a REST-based extension SPI model, and registration
> mechanism with Almighty core which sets that up.  Will look forward to
> seeing those designs.
>
> S,
> ALR
>
> On Mon, Oct 31, 2016 at 10:57 AM, Tomas Nozicka <tnozicka at redhat.com> wrote:
>>
>> Hi Pete,
>>
>> (see inline)
>>
>> On Thu, 2016-10-27 at 13:15 -0400, Pete Muir wrote:
>> > This reminded me of the VS Code/LSP architecture. In this
>> > architecture there are a number of proceses running:
>> >
>> > 1) The VS Code tool
>> > 2) A server which can control and talk to any LSP implementation via
>> > a socket or REST or other transport protocol
>> > 3) The LSP implementation(s) written in the language of choice,
>> > talking a JSON protocol
>> I like the separation and implementation language independence.
>>
>> >
>> > This is closest to the the Consumer model that Michael describes, but
>> > I think we could also look at also being able to run the plugin (and
>> > the thing it connects to) on our servers, but using transports other
>> > than HTTP (e.g. sockets).
>> I am not opposing the idea, but would you mind laying out some story
>> why it would be useful?
>>
>> From my point of view vendors can run such service on OpenShift Online
>> or any other server (or cloud).
>>
>> Even we were (are) planing to run OSBP on different server using
>> HTTPS.
>>
>> I don't see the use case for supporting sockets (or similar mechanisms)
>> especially when Almighty will be running in the cloud; if such
>> mechanism could even work there.
>>
>> >
>> > I don't think allowing people to write scripts that execute inside
>> > our processes is a good idea.
>> +1
>>
>>
>> Regards,
>> Tomas
>
>
>
>
> --
> Red Hat Developer Group Architecture
> @ALRubinger



-- 
Michael Kleinhenz
Principal Software Engineer

Red Hat Deutschland GmbH
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany

RED HAT | TRIED. TESTED. TRUSTED.
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht München,
HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill