Mars, i totally understand and agree we should make developer successful. but Would like to understand your problem more before jump into conclusion
first, a complete PIO setup has following: 1. PIO framework layer 2. PIO administration (e.g. PIO app) 3. PIO event server 4. one or more PIO engines the storage and setup config applied to 1 globally and the rest 2, 3, 4 would run on top of 1. my understanding is that the Buildpack would take engine code and then build, release and deploy it which can then serve query. when heroku user use buildpack, - Where is the event server in the picture? - How user setup the storage config for 1? - if i use build pack to deploy another engine, does it share 1 and 2 above? On Wed, Jul 12, 2017 at 3:21 PM, Mars Hall <m...@heroku.com> wrote: > The key motivation behind this idea/request is to: > > Simplify baseline PredictionIO deployment, both conceptually & > technically. > > My vision with this thread is to: > > Enable single-process, single network-listener PredictionIO app > deployment > (i.e. Queries & Events APIs in the same process.) > > > Attempting to address some previous questions & statements… > > > From Pat Ferrel on Tue, 11 Jul 2017 10:53:48 -0700 (PDT): > > how much of your problem is workflow vs installation vs bundling of > APIs? Can you explain it more? > > I am focused on deploying PredictionIO on Heroku via this buildpack: > https://github.com/heroku/predictionio-buildpack > > Heroku is an app-centric platform, where each app gets a single routable > network port. By default apps get a URL like: > https://tdx-classi.herokuapp.com (an example PIO Classification engine) > > Deploying a separate Eventserver app that must be configured to share > storage config & backends leads to all kinds of complexity, especially when > unsuspectingly a developer might want to deploy a new engine with a > different storage config but not realize that Eventserver is not simply > shareable. Despite a lot of docs & discussion suggesting its share-ability, > there is precious little documentation that presents how the multi-backend > Storage really works in PIO. (I didn't understand it until I read a bunch > of Storage source code.) > > > From Kenneth Chan on Tue, 11 Jul 2017 12:49:58 -0700 (PDT): > > For example, one can modify the classification to train a classifier on > the same set of data used by recommendation. > …and later on Wed, 12 Jul 2017 13:44:01 -0700: > > My concern of embedding event server in engine is > > - what problem are we solving by providing an illusion that events are > only limited for one engine? > > This is a great ideal target, but the reality is that it takes some > significant design & engineering to reach that level of data share-ability. > I'm not suggesting that we do anything to undercut the possibilities of > such a distributed architecture. I suggest that we streamline PIO for > everyone that is not at that level of distributed architecture. Make PIO > not *require* it. > > The best example I have is that you can run Spark in local mode, without > worrying about any aspect of its ideal distributed purpose. (In fact > PredictionIO is built on this feature of Spark!) I don't know the history > there, but would imagine Spark was not always so friendly for small or > embedded tasks like this. > > > A huge part of my reality is seeing how many newcomers fumble around and > get frustrated. I'm looking at PredictionIO from a very Heroku-style > perspective of "how do we help [new] developers be successful", which is > probably going to seem like I want to take away capabilities. I just want > to make the onramp more graceful! > > *Mars > > ( <> .. <> )
