Is App Engine suddenly becoming more expensive???

[Ugorji Nwoke]

Did App Engine suddenly start costing a minimum of $45 per month?

http://googleappengine.blogspot.com/2011/05/year-ahead-for-google-app-engine.html

Summary: pay-as-you-go is 8 cents per hour an instance is running, or 5 cents per hour if you pre-reserve. This translates to $58 per month for pay-as-you-go or $36 per month for pre-reserved. Add the $9/app/month fee for any serious apps with billing enabled (required for using blobstore, etc), and it translates to $45 (if pre-reserved) or $67 (pay-as-you-go). And this is for an app with only one instance always running.

Compared to what we've been used to, this seems like a major increase in price. Maybe someone can shed some light on this - I hope it's not as bad as it looks to me.

(P.S. Pricing for High Replication Datastore is a welcome change - thanks Google. You've also made it easier to pick HRD, as there'd no pricing advantage for M/S anymore).

[Ugorji Nwoke]

Correction:

I missed something. We still get 24 Instance Hours per day for the free quota. So it's really just a minimum of $9 per month. Phew.

[JH]

Instance hours seem very expensive still, Always on would require you
to commit to 3 * 24 * 30 instance hours a month...

[Brandon Wirtz]

I’m not worried about the minimum price so much as I am the 8 cents per instance hour.  Rackspace cloud gives you a significantly more powerful instance for 11 cents an hour, and most of my CPU hours were billed by the API not by the Instance.  So I’m not sure how my model just changed.

 

 

All of my apps that were running at $40 a month are at least 3 instances 24x7 and most are well above that…   From what I can tell, I’m going from $1.40 a day.  To 60*24*.05 = $72 a day. Plus 98 cents for bandwidth.  So $73 a day.  That’s a change from $45 a month to $2,100 a month. 

 

If this is the case, I’m out.  We had expected things to go up 25-50% not 500%

 

 

 

--
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-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Gregory D'alesandre]

Thanks for raising this point.  While we are going to start charging for instances rather than CPU, there are a few factors to keep in mind:

- We are going to be putting work into improving our scheduler so that we will do a better job of taking advantage of instances, your average qps is currently

- If you are using Java, we just launched the ability to make your instances multi-threaded allowing you to use fewer instances to handle the same traffic

- You are getting 24 instance hours pre day for free

We do expect your bill will go up somewhat but we don't expect it to jump from $45 to $2100 per month.  We are going to be showing new bills once the changes to the scheduler are complete but before we leave preview and the new pricing takes effect.  From the graph above, I could imagine from the graph you gave that you'll likely have somewhere around 4 or 5 instances per day under the new scheduler.  That would be between $3.50/day - $5/day (assumed pre-reserved IH pricing) instead of $1.40/day, that is also before multi-threading or any changes you might make to optimize your usage.

Its tricky to compare instances from Infrastructure providers to Platform providers as the Platform actually handle a lot of management you'd have to do on your own (including load-balancing) if you are just buying infrastructure.

I apologize in advance if I am not responsive on this thread today as I'm at I/O and connectivity is, well, flakey :(

Thanks again for the questions and we are excited about leaving preview but know that pricing changes are always tough, and we look forward to working with you through this transition.

Greg D'Alesandre

Senior Product Manager, Google App Engine

[Ugorji Nwoke]

Hi Greg,

Thanks much for the response. I understand responses will be slow this week.

For once, it now seems that Java has an advantage, as Python (and GO) users do not have the option of using multi-threaded to reduce the number of instances. So although Python (and GO) will *potentially use less resources and a lower footprint, will they now get charged more due to a limitation in the app engine runtime?

I've been developing with Java, but am pretty excited about GO's inclusion. This seems to be a bottleneck.

[Calvin]

Looks like this billing change is going make using my XMPP Logger much more expensive. XMPP went from 46,000,000 free messages per day to 1,000.

[Brandon Wirtz]

I’m going to hold you to that… I know where you work, and I’m not beyond sitting in front of the door every day with a sign that says “Gregory D'alesandre promised to only increase my price 2.5x not 70x”   and people will say “really? He’d be happy with knowing his cost went up 2.5x? That man is a loon”

 

Only likely not being from Canada or Michigan they wouldn’t use the word loon.

[Andrei]

Could somebody compare pricing to AWS if I am running Tomcat or Jetty?

On May 10, 12:29 pm, Ugorji <ugo...@gmail.com> wrote:
> Did App Engine suddenly start costing a minimum of $45 per month?
>

> http://googleappengine.blogspot.com/2011/05/year-ahead-for-google-app...

[Gregory D'alesandre]

Well, technically I said I could imagine it :)  We can't commit to what precisely your price will be until the scheduler changes are complete, and once that is done, we'll show you comparative bills.  Looking at the graph above it looks like even if nothing changed you would be around $8/day which is around 4x, I'm not sure where 70x came from.  Good to know that you are willing to sit in front of my door with a sign :)  And if they call you a loon, feel free to point them to me.

Greg D'Alesandre

Senior Product Manager, Google App Engine

[Gregory D'alesandre]

For the time being that is indeed true.  We are working on ways to bring concurrency to Python but don't have anything we can announce just yet.  Go is currently single-threaded, but this too is something that could change over time.

Greg

[Ross Karchner]

It'd be nice if the monthly fees were a "down payment" on your actual usage-- so instead of paying $9 (or $500) on top of usage, your monthly fee covers your first $X of usage.

Ross M Karchner

[Kenneth]

So is Guido finally getting rid of the GIL :-)

[Sylvain]

For very small app $9/month is a big jump.

Example : for one of my apps, I pay $1/month and with the new price
$10/month
= +900%

GAE was : "pay for what you use", it is no more the case...

On May 10, 7:29 pm, Ugorji <ugo...@gmail.com> wrote:
> Did App Engine suddenly start costing a minimum of $45 per month?
>

> http://googleappengine.blogspot.com/2011/05/year-ahead-for-google-app...

[JH]

The $9 is nothing compared to the Instance Hour $$ you will pay

[Brandon Wirtz]

I don't mind $9 to help reduce the number of spam farms using GAE to mine
api calls and send email... $9 = cost of a dream host account I figure
even as a sandbox $9 is cheap.

-----Original Message-----
From: google-a...@googlegroups.com
[mailto:google-a...@googlegroups.com] On Behalf Of Sylvain
Sent: Tuesday, May 10, 2011 3:25 PM
To: Google App Engine
Subject: [google-appengine] Re: Is App Engine suddenly becoming more
expensive???

--

[Dan F]

I agree, $9/month is reasonable for a real app.

The big open question is the less predictable costs, e.g., the new scheduler and API changes.

[Stephen]

On Tue, May 10, 2011 at 11:37 PM, Brandon Wirtz <dra...@digerat.com> wrote:
>
> I don't mind $9 to help reduce the number of spam farms using GAE to mine
> api calls and send email...

This could be fixed by restoring the 2000 email quota for emails sent
to admins of the app, and bumping up the price of the first X emails
sent to non-admins, with a bulk discount for further usage.

> $9 = cost of a dream host account...

Dreamhost gives you storage, bandwidth, memory etc for $9. On App
Engine $9 will buy you the opportunity to be further charged for
actual usage. It's a regressive tax on startup projects, which
considering the effort made to offer a completely free tier, is self
defeating.

[Ugorji Nwoke]

Even though $9/month is pretty insignificant to many of us because

1. It is a fixed cost

2. It is small

We still should not gloss over it. Like Stephen said, this is really just a tax for the privilege of using blob-store and other billing-enabled services.

Having said that, I reckon that this is Google's attempt to streamline their business package (which they are doing away with) by saying that anyone that needs higher level services will pay a per-app or per-account cost.  In that light, it becomes more palatable (as it simplifies the offering), and I for one am okay with that. 

I think the bigger concern is the per-instance cost. This is especially troubling for 

1. folks that depend on the always-on features in java. 

2. folks in Python or the new GO runtime that don't as yet have concurrent request support. More instances will be spun dynamically with a consequential cost to them which is expected to be significant).

Hopefully, the new scheduler will iron out a lot of these unknowns so we're back to being happy app-engine users. Right now, it seems we're the only ones in the whole Google Ecosystem that's unhappy with some of the recent announcements. 

Actually, scratch that - I'm very happy for 2 things:

- GO language runtime support (the geek in me is just thrilled)

- Moving away from Preview status (I was always concerned about the life of GAE beyond the promised 3 years support post EOL. This removes my fears).

[Jay Young]

On Tuesday, May 10, 2011 5:00:35 PM UTC-4, Greg D wrote:

Go is currently single-threaded, but this too is something that could change over time.

Greg

I'm really confused by this.  Do you mean the language's concurrency primitives (go routines, channels, etc) will still result in multi-threading, but we won't be able to explicitly spin up new threads and processes, or can we not use those concurrency primitives at all?

I don't mean to jump on you prematurely, but saying you're running Go in a single-threaded environment just made my head explode.

[Stephen]

On Wed, May 11, 2011 at 12:12 AM, Ugorji <ugo...@gmail.com> wrote:
>
> Hopefully, the new scheduler will iron out a lot of these unknowns so we're
> back to being happy app-engine users.

In the future if Google's scheduler is not optimal, you will be
charged for it. What is the incentive to get it right? How will you
know it is right?

Here's another perverse incentive: under the current scheme memory
usage is used as an input to the scheduler as well as latency and
start-up time. Apps which use less memory can have more instances at
the same resource cost to Google. My incentive is to optimise memory
usage. Under the upcoming scheme you are charged per-instance, so
there is zero incentive to optimise memory usage.

[Ugorji Nwoke]

Hi Stephen,

I am totally with you on it. I actually alluded to this earlier, when I said:

For once, it now seems that Java has an advantage, as Python (and GO) users do not have the option of using multi-threaded to reduce the number of instances. So although Python (and GO) will *potentially use less resources and a lower footprint, will they now get charged more due to a limitation in the app engine runtime?

In building my app, I spent a lot of time optimizing resource usage, et al. With this model, all that seems to be for naught. 

Somewhere in the docs today, there's a note to the effect that "apps on the java runtime will be charged more for using using more resources". 

I don't understand how this will be ironed out, which is why I termed this all unknowns. From what Greg says, it sounds like there's still some stuff to be ironed out on Google's end, and we'd only really know how things shake out once we see how the new scheduler works. 

I'm holding my breath ...

P.S. Google has been pretty fair and upfront with app engine - I haven't had a reason to distrust them yet. I'm hoping that their promotion of AppEngine from Preview will still maintain this fairness. 

[Ugorji Nwoke]

eeIt's actually stated in the blog:

http://blog.golang.org/2011/05/go-and-google-app-engine.html

Also, although goroutines and channels are present, when a Go app runs on App Engine only one thread is run in a given instance. That is, all goroutines run in a single operating system thread, so there is no CPU parallelism available for a given client request. We expect this restriction will be lifted at some point.

So you can still use go routines, channels, etc - but we're back to like the days of green threads in java where the runtime multiplexes them on a single thread (which is fine). However, we don't get concurrent web requests on the same instance (which is not fine). Consequently, right now, Java Runtime seems to have a pretty significant advantage over the others (even over GO which has concurrency as some of its major advantages). And with instance pricing, it seems like it directly affects cost.

[Albert]

I just checked the new proposed pricing here...
http://www.google.com/enterprise/appengine/appengine_pricing.html

I'm confused why all the items below "Channel API" in the API Pricing
models have check marks instead of a price per unit. What does that
mean?

And when they say, "Frontend Instances", does that include instances
handling task queues and crons?

Thanks!


Albert

On May 11, 8:24 am, Ugorji <ugo...@gmail.com> wrote:
> eeIt's actually stated in the blog:http://blog.golang.org/2011/05/go-and-google-app-engine.html
>
> Also, although goroutines and channels are present, when a Go app runs on

> App Engine only one thread is run in a given instance. That is, *all

> goroutines run in a single operating system thread, so there is no CPU

> parallelism* available for a given client request. We expect this

[Ugorji Nwoke]

I think FrontEnd instances refer to your instances (ie JVM, or Python, etc). Task Queues and cron are still run by default on your instances (so your instances handle all web traffic, and taskqueues and cron are implemented as internally-generated web traffic to your application). 

Regarding the cost per operation for the other API's (like task queue, etc), I'm not sure. Wishful thinking :-> maybe it means that we wouldn't be charged for those APIs anymore, and will just be charged for data storage (blobstore and datastore), bandwidth usage and datastore operations (put/get/query). 

A Googler will be better able to answer that part.

[JH]

The more I think about it, I wonder:

Are instance hours billed for actual time used by an instance, or
simply an instance alive...
So if I have 3 instances fired up via Always on, am I constantly
charged 3 * .05 per hour, or am I only billed by the actual time
instances were serving requests?

[Kaan Soral]

I've been working on my project for 6 months, I've sacrificed
everything for the project and I feel like I may have done a big
mistake depending on GAE. And I am sure I spent 5 months out of 6
months on GAE specific things.

Let's say I have an application that depends on ad income. And assume
every request is 1 second and Task Scheduler is perfect!
So I pay $0.05 to an instance every hour, which has 3600 seconds
inside it. So lets average that number to 3600 requests and lets say
there are 1800 page views. (Assuming things are done with Ajax).

So the cost for 1000 page views are: $0.05/1800*1000=0.027$.

Assuming everything works perfect, and not counting background tasks,
although mine are huge, I need to get at least 0.027$ ecpm.

For example for Turkish traffic sometimes ecpms can drop below 0.1$'s,
and I am sure there are countries out there with significantly lower
ecpms and our cost traffics were optimal.

To sum up, It seems if I use GAE, I will always have the risk that the
costs will be higher than the income ...

I have applications on Dedicated Servers, usually a server is nearly
idle, the load is 0.5 out of 8, sometimes 2-3, and I am sure I don't
utilize them to %20 maybe, but still my cost ratio is %10 ! If I could
utilize a server to a maxomum level that could be %2 !

And on the best case it seems this rate will be %25 on gae assuming
everything is perfect ....

This pricing and advertising under the page:
http://www.google.com/enterprise/appengine/appengine_pricing.html made
me think gae only wants client like Best Buy etc, big companies who
have much higher income rates from web products ...

Other than these cost problems, I am using Python and I am very
worried since Go came out, which seems to be run multi-threaded in
future, Java is also multi-threaded, and as Python users we will only
have 1 instance / 1 request.

So is Python GAE feasible at this point? it doesn't seem that way?

On May 11, 3:40 am, Albert <albertpa...@gmail.com> wrote:
> I just checked the new proposed pricing here...http://www.google.com/enterprise/appengine/appengine_pricing.html

[JH]

This pricing definately seems slanted towards the Best Buys and the
Webfilings....

Those with high traffic apps are probably happy to only pay for
instance hours, when their hours are filled with thousands of requests
that were being billed for cpu previously.

However, if you want to keep an instance running, which you need to do
on GAE, a low traffic app is now paying when the app is even idle to
keep the instance alive, when before we were not paying since at idle
times you use no cpu...

[Brandon Donnelson]

I liked the pay as you go formula better too. I think it would have been a better choice to lower the thresholds on the quota limits before paying, or a better sales job in the price changes.

Brandon Donnelson

http://gwt-examples.googlecode.com

[Sylvain]

I've many "small" app for personal uses or friends where I only need
more storage : 2 GB.

For this app where the free version is not enough but for little use,
$9 is important.

Before : it costed about $100€ for 10 apps / year.
Now : 100 (storage) + $9 * 12 (month) * 10 (app) = $1180.

If you have 1 "real" app, it's ok.
For many small app, $9 is very important.

Maybe if $9 was per account not per app it would ok else, AppEngine is
not the good solution.
There are so many cheaper solution.

[Gregory D'alesandre]

On Tue, May 10, 2011 at 4:12 PM, Ugorji <ugo...@gmail.com> wrote:

Even though $9/month is pretty insignificant to many of us because

1. It is a fixed cost

2. It is small

We still should not gloss over it. Like Stephen said, this is really just a tax for the privilege of using blob-store and other billing-enabled services.

As an aside, under the new model, blobstore is actually included with free apps (up to 5G!).  We want developers to be able to use most aspects of the platform in order to try it out and use it, blobstore is indeed one of those.

 

Having said that, I reckon that this is Google's attempt to streamline their business package (which they are doing away with) by saying that anyone that needs higher level services will pay a per-app or per-account cost.  In that light, it becomes more palatable (as it simplifies the offering), and I for one am okay with that. 

I think the bigger concern is the per-instance cost. This is especially troubling for 

1. folks that depend on the always-on features in java. 

I mentioned this in another thread, but just to be clear this is actually one part of the model that we are still working on.  The feedback from the groups has been very important in this regard.

 

2. folks in Python or the new GO runtime that don't as yet have concurrent request support. More instances will be spun dynamically with a consequential cost to them which is expected to be significant).

This is indeed true currently but it is an area we are looking into as well.

 

Hopefully, the new scheduler will iron out a lot of these unknowns so we're back to being happy app-engine users. Right now, it seems we're the only ones in the whole Google Ecosystem that's unhappy with some of the recent announcements. 

Actually, scratch that - I'm very happy for 2 things:

- GO language runtime support (the geek in me is just thrilled)

- Moving away from Preview status (I was always concerned about the life of GAE beyond the promised 3 years support post EOL. This removes my fears).

Glad to hear you there are aspects you are happy about and sorry to hear that there are aspects you aren't :(  I'm glad you touched on the moving away from preview status.  This and the changes to pricing are intrinsically linked.  We want to build a product that is around for a long, long time.  Google wants that as well, but in order for that to happen it needs to be a viable business.  The new pricing model is indeed higher but will now be on par with the alternatives, in exchange we will be offering a higher and higher level of service as well.

Thanks again for your thoughts on this announcement,

Greg 

[Gregory D'alesandre]

On Tue, May 10, 2011 at 5:16 PM, Ugorji <ugo...@gmail.com> wrote:

Hi Stephen,

I am totally with you on it. I actually alluded to this earlier, when I said:

For once, it now seems that Java has an advantage, as Python (and GO) users do not have the option of using multi-threaded to reduce the number of instances. So although Python (and GO) will *potentially use less resources and a lower footprint, will they now get charged more due to a limitation in the app engine runtime?

In building my app, I spent a lot of time optimizing resource usage, et al. With this model, all that seems to be for naught. 

Somewhere in the docs today, there's a note to the effect that "apps on the java runtime will be charged more for using using more resources". 

Hmm, I'm not sure where that line was, but we are not planning on having any special charges for the java runtime in particular.  All runtimes will be charged based on instance usage.

 

I don't understand how this will be ironed out, which is why I termed this all unknowns. From what Greg says, it sounds like there's still some stuff to be ironed out on Google's end, and we'd only really know how things shake out once we see how the new scheduler works. 

I'm holding my breath ...

P.S. Google has been pretty fair and upfront with app engine - I haven't had a reason to distrust them yet. I'm hoping that their promotion of AppEngine from Preview will still maintain this fairness. 

Thanks Ugorji, we are certainly not trying to be unfair although we are trying to price App Engine based on the value it provides and the feedback from this group and all of our customers is very useful.

Greg D'Alesandre

Senior Product Manager, Google App Engine

 

[Gregory D'alesandre]

On Tue, May 10, 2011 at 5:40 PM, Albert <alber...@gmail.com> wrote:

I just checked the new proposed pricing here...
http://www.google.com/enterprise/appengine/appengine_pricing.html

I'm confused why all the items below "Channel API" in the API Pricing
models have check marks instead of a price per unit. What does that
mean?

That means we do not charge for those APIs, they come free with the platform :)  The one exception is the prospective search API which is still experimental, once it it no longer experimental we will likely charge for it.

And when they say, "Frontend Instances", does that include instances
handling task queues and crons?

Yes.

Greg

 

Thanks!


Albert

On May 11, 8:24 am, Ugorji <ugo...@gmail.com> wrote:
> eeIt's actually stated in the blog:http://blog.golang.org/2011/05/go-and-google-app-engine.html
>
> Also, although goroutines and channels are present, when a Go app runs on
> App Engine only one thread is run in a given instance. That is, *all
> goroutines run in a single operating system thread, so there is no CPU
> parallelism* available for a given client request. We expect this
> restriction will be lifted at some point.
>
> So you can still use go routines, channels, etc - but we're back to like the
> days of green threads in java where the runtime multiplexes them on a single
> thread (which is fine). However, we don't get concurrent web requests on the
> same instance (which is not fine). Consequently, right now, Java Runtime
> seems to have a pretty significant advantage over the others (even over GO
> which has concurrency as some of its major advantages). And with instance
> pricing, it seems like it directly affects cost.

[Gregory D'alesandre]

That's what I get for reading messages sequentially.  I just responded to this but I should've said Ugorji was correct on all counts, including the wishful thinking :)

Greg

[Albert]

Hi Greg!


Thanks for the clarifications on the check marks on the pricing of
some of the API's.


Albert

[Paul]

Well, always-on is pretty important for low-traffic apps. They usually
do not use free quota and quite often they are not even close. Having
to pay for always-on + app fee + instance hours would be huge
difference. And all of that just to make smooth start for new
requests...


BTW, good to see Google App being expanded. It's great to have service
like that - it really takes away most of that stuff that is not actual
development :)