[almighty] Major Architectural Question for the Build
Todd Mancini
tmancini at redhat.com
Wed Nov 2 14:36:11 UTC 2016
So let me give a PM perspective, which is generally non-technical (but,
given that this is a technical topic, it is semi-technical).
I see at least 4 extensibility points, in no particular order:
1. The "client". We have good separation of concerns and, therefore,
build our UX on top of a set of APIs. (And do not beat me up on API vs ABI
vs SPI vs. whatever -- use whatever term makes you the most comfortable.)
We have made an opinionated decision to focus on a 100% cloud-native UX.
However, given the availability of the API, someone could create a totally
different, purposeful client UX -- for example, maybe a tight, GUI
integration of Work Item Tracking in Eclipse, to make it easy to see work
to be done, associate commits against Tasks, etc.
2. The "Major Areas" of functionality. Per the wireframes, we are
working towards an opinionated bi-level UX for the top-level functionality.
Essentially, each major area of functionality lives on a tab in the UX,
with some name (e.g. Work, Code, Test, etc.), and offers up a short list of
choices which appear just below the tab. (e.g. Code/Codebases and
Code/Workspaces). Under that list is essentially a large panel, in which
that major area of functionality can do whatever it wants in terms of UX.
This gives is unified UX navigation but otherwise lets the extension do
what it wants (within whatever limitations are a result of the UX
framework/Patternfly).
In my mental model, these major areas of functionality are
plug-ins/extensions, resting on a common backplane. And the ones that
appear really should be a *run-time, per-user decision*. This enables
some interesting/important scenarios:
1. As a user, I may be part of a beta test for a new top-level piece
of functionality. So, when I log in, an extra tab "Foo" appears that most
others do not see.
2. We establish a marketplace, and individual users and/or orgs elect
to have new major areas of functionality enabled. These users
see new major
tab "Bar" when they log in.
1. That is not an attempt to make a statement about WHERE that
functionality executes (e.g. on our server), so do not assume
I've implied
anything about that.
3. Almighty becomes an even broader platform for substantially more
differentiated 'development' use cases via a UX drive by entitlement.
1. For example, maybe a user has the 'citizen developer'
entitlement, such that when then log into Almighty, they get a
significantly simplified UX -- maybe with only just a single tab --
enabling them to solve the finds of problems of interest to them (e.g.
integration solutions) -- all the while, behind the scenes, the full
Almighty infrastructure and project model is being
transparently used on
their behalf. They can then have a 'real developer' join
their project and,
when that 'real developer' signs in, they see the full
Almighty UX and can
augment the integration solution with code, etc.
3. The "Minor Areas" of functionality. There should be a standard way
for the Major Areas of functionality to express to the backplane their own
extensibility points. E.g, the Work tab containing the Planner might say to
the backplane 'hey, I've got a context menu exposed on work items" (e.g.,
when the user sees a work item, they can right-click and pop-up a menu for
that work item). This would permit a 'minor extension' -- e.g., someone
might write a plug-in which can graphically draw the full interconnected
graph of a work item linked to other work items. And this extension would
then say "hey, I'd like to add 'Visualize' as a menu choice to all of the
work item context menus, no matter which major functionality area has one."
4. Hooked Services. You standard web hooking stuff, but in this case
using Almighty as the event source. e.g., "any time a work item changes,
call this remote URL with the details of the change."
Okay, so where does the stuff run? Clearly, executing other people's stuff
on our server is, in general, a Very Bad Idea. Still, there are two viable
operating models: (1) the extension executes 'elsewhere' but has the
ability to draw its UX within Almighty. (2) the extension is essentially
100% browser-based (HTML5/JS/CSS3), rendered directly in the browser and
making use of APIs to get the data it needs. I've got a ton I could say on
how these 2 modes could actually work -- too much for an email, tho. [FWIW,
it's a proven model.]
Obviously, extensions we write and/or trust could execute on our servers. I
think the proper mental model is that all extensions are running
'elsewhere', but the server operator can choose to have that 'elsewhere' be
the same infrastructure.
Some pictures are probably going to help a lot...
On Wed, Nov 2, 2016 at 9:22 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:
> 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
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161102/4ed2f03c/attachment.htm>
More information about the almighty-public
mailing list