[almighty] Major Architectural Question for the Build
Tomas Nozicka
tnozicka at redhat.com
Wed Nov 2 17:04:51 UTC 2016
On St, 2016-11-02 at 17:33 +0100, Michael Kleinhenz wrote:
> I understand the point, in the REST API model, a 3rd party could write
> a proxy and host it elsewhere, but is that a realistic scenario?
Even we are going this way for OSBP (OpenShift Build Provider) so it
makes it quite realistic. (We won't modify OpenShift, but instead we'll
write the proxy.)
>
> This boils down to three scenarios:
>
> 1. the build provider's vendor would host it themselves, then this
> would be prone to the described problem "must operate our integration,
> which costs ongoing money".
Very *little* money; they can most probably fit into some free offering
with Online. Even Almighty will probably provide user with some free
resources, so they can host it there.
This is a stateless service which just translates API calls; resource
usage will be really funny.
> 2. we host it, then there is no real difference between the REST API
> case and the Plugin case.
There is a *huge* difference between running something in a sandbox and
hosting microservice in a multi-tenant cloud.
Ease of implementation, the ability to choose implementation language,
being testable and easily updatable are another ones.
> 3. a 4th party hosts it, at which point I would say that is a very
> fragile construct, both technically and from a policy standpoint (the
> secret key is going thu not 2 parties, but 3!).
Say they run it on AWS, GCE or GKE - I wouldn't say it's an issue.
>
> So either way, I see the "proxy" model only asa theoretical model, not
> a real one.
I guess we shall agree to differ on this point.
>
> And I don't like it either, but tech considerations are if ever, only
> 50% of the consideration when providing external integration points.
> The best designed system does not make sense if customers don't adopt
> this stuff because of business reasons.
Well, the only disadvantage in REST API is the need to deploy it. From
a business point: shorter time to market, testability, updateability,
ability to get usage metrics from such service and other advantages
should easily overcome it.
>
>
> On Wed, Nov 2, 2016 at 3:54 PM, Tomas Nozicka <tnozicka at redhat.com> wrote:
> >
> > Both models require NO changes to vendor's existing systems!
> >
> > Max, I am a bit confused by that argument as well. Maybe Michael would
> > like to elaborate on that?
> >
> > Let's summarize:
> >
> > = Plugin model (Deployment API) =
> > The plugin will be "a proxy" translating Almighty Build SPI -> Target
> > build environment API calls.)
> >
> > + doesn't need any hosting
> > + no changes to vendor's existing system
> > - runs inside Almighty process in sandbox - major *security risk*
> > - forces user to learn subset of Lua (or any scripting language we
> > *force* them to use) with special functions - *steep learning curve*;
> > - additional complexity for Almighty to implement sandboxing
> >
> >
> >
> > = REST API (Consumer API)
> > The REST service will be "a proxy" translating Almighty Build SPI ->
> > Target build environment API calls. Also a vendor can *choose* to build
> > such API into their build system providing a native support for
> > Almighty without need for such proxy. Again *choose*.)
> >
> > + *vendor chooses implementation language* he likes (uses) an writes
> > simple REST (stateless) service (like a proxy translating Almighty
> > Build SPI -> Target build environment API calls)
> > + no changes to vendor's existing system
> > + scales independently
> > + one provider can be used by multiple Almighty instances
> > + *testable*
> > + *secure*
> > - needs hosting (but that's dead simple e.g. with OpenShift Online
> > especially for stateless service)
> >
> >
> > I don't really see any advantage in writing a plugin than the fact that
> > you don't need to deploy it. But that's really simple in the age of
> > OpenShift, Kubernetes and CaaS...
> >
> > Otherwise there are only advantages if we choose the REST approach.
> >
> > Regards,
> > Tomas
> >
> >
> >
> > On St, 2016-11-02 at 14:36 +0100, Michael Kleinhenz wrote:
> > >
> > > Ah, sorry, missed the words. I meant the "Deployment Model", not the
> > > "Consumer Model", sorry. I meant the one I would recommend :-)
> > > Everything else applies :-)
> > >
> > > On Wed, Nov 2, 2016 at 2:22 PM, 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
> > >
> > >
> > >
>
>
>
More information about the almighty-public
mailing list