[almighty] Major Architectural Question for the Build

Wed Nov 2 13:22:23 UTC 2016

On 2 Nov 2016, at 14:15, Michael Kleinhenz wrote:

> 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'm really confused how something that requires no changes on their 
external systems
is a problem for adoption ?

I'm missing something in this argument ;)

> 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.

/max
>
> -- 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
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public

/max
http://about.me/maxandersen