It will be nice if we had an idea of the price before committing to using it. We've been down this road before and it left a bad taste when the pricing was announced.
On Tue, May 8, 2012 at 11:03 PM, Ugorji wrote:
> It will be nice if we had an idea of the price before committing to using
> it.
Surely the idea is you don't commit to using it until it graduates
from experimental.
The free quota is there to experiment (and help Google figure out how
much it costs them to run the service) - not to use it for real
(unless you very brave :)
I think features have been released before but we knew the price (TaskQueues, etc). The feature is out of trusted testers mode (after many many months). It's now in experimental but generally available mode, which tells me that the API's may change somewhat but the feature is here to stay.
If I sink in development time using it, and build my application to depend on it, and then the price is released and it's prohibitive to me, I've lost a fair amount of development time.
There are some features which you can just easily back out of (e.g. SSL, etc). But something like Search, Cloud SQL, etc are commitments, even if in experimental mode, because your application starts to depend on it once built.
On Tuesday, May 8, 2012 6:37:02 PM UTC-4, barryhunter wrote:
> On Tue, May 8, 2012 at 11:03 PM, Ugorji wrote: > > It will be nice if we had an idea of the price before committing to > using > > it.
> Surely the idea is you don't commit to using it until it graduates > from experimental.
> The free quota is there to experiment (and help Google figure out how > much it costs them to run the service) - not to use it for real > (unless you very brave :)
> I think features have been released before but we knew the price
> (TaskQueues, etc). The feature is out of trusted testers mode (after many
> many months). It's now in experimental but generally available mode, which
> tells me that the API's may change somewhat but the feature is here to
> stay.
> If I sink in development time using it, and build my application to depend
> on it, and then the price is released and it's prohibitive to me, I've lost
> a fair amount of development time.
> There are some features which you can just easily back out of (e.g. SSL,
> etc). But something like Search, Cloud SQL, etc are commitments, even if in
> experimental mode, because your application starts to depend on it once
> built.
> On Tuesday, May 8, 2012 6:37:02 PM UTC-4, barryhunter wrote:
> > On Tue, May 8, 2012 at 11:03 PM, Ugorji wrote:
> > > It will be nice if we had an idea of the price before committing to
> > using
> > > it.
> > Surely the idea is you don't commit to using it until it graduates
> > from experimental.
> > The free quota is there to experiment (and help Google figure out how
> > much it costs them to run the service) - not to use it for real
> > (unless you very brave :)
Would you be able to share an estimate on when the Search API will be available from the Go runtime? I understand that both are experimental, but is it actively being worked on or is still on the todo list?
> Would you be able to share an estimate on when the Search API will be
> available from the Go runtime? I understand that both are experimental, but
> is it actively being worked on or is still on the todo list?
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
On Tue, May 8, 2012 at 7:49 PM, Ugorji <ugo...@gmail.com> wrote:
> If I sink in development time using it, and build my application to depend
> on it, and then the price is released and it's prohibitive to me, I've lost
> a fair amount of development time.
I concur. It's not necessary to have a final price, but some sort of
guidance is needed before investing the days of engineering time
required to use it. For example, I have a FTS solution right now
using an indexed list property in the datastore. Will this be cheaper
or more expensive?
(GAE team: congrats!!! on search-- please add clustered/grouped results<http://wiki.apache.org/solr/FieldCollapsing>to your todo list-- it's very hard to emulate such a feature at the app layer)
Jeff: - this is pre-release, and if you personally can't bear that risk, then let others play beta-tester for you. - if Google waits for pricing before release then that delays the release, which nobody wants. - pricing can depend on usage patterns, which they only know once they see usage.
in general, if you're already live in production on GAE then there are few reasons to invest materially in a beta: - someone is demanding this. - you expect to depend on little details of this feature and therefore want to join the design - your karma with google and its community are running a little low, and this is an easy way to restock. <== why I'm posting this. - you have spare time and it's more fun than youtube cat videos.
fwiw, 95% of the time, I read the docs on new APIs, then go back to work, and this is no exception: - we're not in pain: my company uses SOLR/Lucene on IntoVPS and it works well. It was a big investment last year, but now it's a sunk cost. - we need clustered/grouped results, which isn't in the beta (and it's hard to emulate).
On Thursday, May 10, 2012 8:04:08 PM UTC-7, Jeff Schnitzer wrote:
> On Tue, May 8, 2012 at 7:49 PM, Ugorji wrote:
> > If I sink in development time using it, and build my application to > depend > > on it, and then the price is released and it's prohibitive to me, I've > lost > > a fair amount of development time.
> I concur. It's not necessary to have a final price, but some sort of > guidance is needed before investing the days of engineering time > required to use it. For example, I have a FTS solution right now > using an indexed list property in the datastore. Will this be cheaper > or more expensive?
On Fri, May 11, 2012 at 4:17 PM, Adam Sah <adam....@gmail.com> wrote:
> - this is pre-release, and if you personally can't bear that risk, then let
> others play beta-tester for you.
> - if Google waits for pricing before release then that delays the release,
> which nobody wants.
> - pricing can depend on usage patterns, which they only know once they see
> usage.
It isn't black and white. A little more transparency might entice
some of the more experienced users to try out the feature and provide
feedback. It doesn't require firm pricing, but it does require some
amount of trust that the feature will be priced attainably.
Unfortunately, there are several recent examples of Google announcing
prices that effectively take features offline: Backends, XMPP, and
Maps. I don't have high hopes that FTS will avoid the same fate.
Let me provide a bit more background on our thinking for pricing for the
Search API. We use the experimental phase for many APIs to test the API's
stability, get developer feedback and to fine-tune our pricing. It's
important to us that we only publish pricing when we are confident that it
won't change drastically in a short time frame, so that our developers will
have a better sense of what to expect going forward.
That being said, here's the general idea of what we're thinking
pricing-wise for the Search API. We are planning to charge for the Search
API based on three metrics: indexing, searches and storage. Indexing will
likely be charged per GB indexed (or re-indexed) and searches per query.
This will allow our developers to pay for what they use while still being
able to predict their usage (we expect that it's easier to estimate the
number of searches your app will make per day than how many front-end
instances you might need to run a search stack). As noted in our
docs<https://developers.google.com/appengine/docs/python/search/overview#Q...>,
we expect our free quotas to cover about 1000 searches per day on a 250MB
index once we graduate from experimental -- so that should give you an
indication of whether you will be able to keep your usage under the free
quota.
Thanks,
Christina
On Sat, May 12, 2012 at 11:48 PM, Jeff Schnitzer <j...@infohazard.org>wrote:
> On Fri, May 11, 2012 at 4:17 PM, Adam Sah <adam....@gmail.com> wrote:
> > - this is pre-release, and if you personally can't bear that risk, then
> let
> > others play beta-tester for you.
> > - if Google waits for pricing before release then that delays the
> release,
> > which nobody wants.
> > - pricing can depend on usage patterns, which they only know once they
> see
> > usage.
> It isn't black and white. A little more transparency might entice
> some of the more experienced users to try out the feature and provide
> feedback. It doesn't require firm pricing, but it does require some
> amount of trust that the feature will be priced attainably.
> Unfortunately, there are several recent examples of Google announcing
> prices that effectively take features offline: Backends, XMPP, and
> Maps. I don't have high hopes that FTS will avoid the same fate.
> Jeff
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
I guess what I'm most interested in is knowing how it will compare,
pricewise and performancewise, to using the datastore for FTS.
Obviously the datastore doesn't provide all the bells and whistles,
but it's pretty easy to store all the fragments of a set of words in
an indexed list property. For example, 'foo' would store 'f', 'fo',
'foo', and now I can do as-you-type queries. Would this be cheaper
(both for storage and for queries) with FTS?
I could imagine using this to index geocell queries too. Would this
be more or less expensive than a datastore-based solution?
On Tue, May 15, 2012 at 9:46 AM, Christina Ilvento <cilve...@google.com> wrote:
> Hi All,
> Let me provide a bit more background on our thinking for pricing for the
> Search API. We use the experimental phase for many APIs to test the API's
> stability, get developer feedback and to fine-tune our pricing. It's
> important to us that we only publish pricing when we are confident that it
> won't change drastically in a short time frame, so that our developers will
> have a better sense of what to expect going forward.
> That being said, here's the general idea of what we're thinking pricing-wise
> for the Search API. We are planning to charge for the Search API based on
> three metrics: indexing, searches and storage. Indexing will likely be
> charged per GB indexed (or re-indexed) and searches per query. This will
> allow our developers to pay for what they use while still being able to
> predict their usage (we expect that it's easier to estimate the number of
> searches your app will make per day than how many front-end instances you
> might need to run a search stack). As noted in our docs, we expect our free
> quotas to cover about 1000 searches per day on a 250MB index once we
> graduate from experimental -- so that should give you an indication of
> whether you will be able to keep your usage under the free quota.
> Thanks,
> Christina
> On Sat, May 12, 2012 at 11:48 PM, Jeff Schnitzer <j...@infohazard.org>
> wrote:
>> On Fri, May 11, 2012 at 4:17 PM, Adam Sah <adam....@gmail.com> wrote:
>> > - this is pre-release, and if you personally can't bear that risk, then
>> > let
>> > others play beta-tester for you.
>> > - if Google waits for pricing before release then that delays the
>> > release,
>> > which nobody wants.
>> > - pricing can depend on usage patterns, which they only know once they
>> > see
>> > usage.
>> It isn't black and white. A little more transparency might entice
>> some of the more experienced users to try out the feature and provide
>> feedback. It doesn't require firm pricing, but it does require some
>> amount of trust that the feature will be priced attainably.
>> Unfortunately, there are several recent examples of Google announcing
>> prices that effectively take features offline: Backends, XMPP, and
>> Maps. I don't have high hopes that FTS will avoid the same fate.
>> Jeff
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
