Google App Engine leaves preview, new pricing

http://www.google.com/enterprise/cloud/appengine/pricing.html

by endlessvoid94 • 15 years ago

201 129 15 years ago

thurn• 15 years ago

The trouble with App Engine is that I'm now locked in to their API. They can raise prices and I have no real recourse unless I want to rewrite a lot of code.

georgemcbay2• 15 years ago

I was an early advocate of GAE but this is now my fear as well. When the new pricing was announced, the amount that they raised the service by seemed quite fair, but just the fact that it went up spooked me into being afraid of the fact that they could readjust the price at any time.

While I suspect they won't make it a habit of raising the price from here on out, the more I thought about it the more I've come to the conclusion that it makes sense to go with providers that use more standardized software stacks (despite how great not having to sysadmin is and the easy deployment from Eclipse to GAE), because that way I can take advantage of future competition of providers. If I go with GAE the costs to switchover become greater and greater the longer I'm there... so while they may never jack the price UP on me, they'll have little incentive to bring the price down due to increased competition.

wavephorm2• 15 years ago

Google has altered the pricing agreement. Pray they don't alter it any further...

psm5• 15 years ago

we encourage you to look at appscale for app mobility. we're not interested in artificial lock-in from APIs. we're not that kind of a company. we're confident we can make the overall service superior. please note that we haven't changed the prices since we launched pricing, and GAE was in preview. that's an element to the notion of "preview". we're now taking it out of preview into a fully supported Google product. and part of that was to reprice so we have a sustainable business. after we announced the new pricing in May at I/O, we've actually seen our growth rate increase, since customers appreciate that we're committing to GAE.

tomjen3• 15 years ago

You can have the best of both worlds, Java has standardized their web format to the point where you simply upload a zip archive (if you don't want to work with Java, almost all frameworks for jvm languages, including lift, are compatible with the framework).

biot• 15 years ago

I'm not up to speed on how compatible and recent it is, but AppScale bills itself as "Open Source Platform for Google App Engine Apps": http://code.google.com/p/appscale/

wescpy2• 15 years ago

in addition to AppScale also look at the TyphoonAE project... these are open versions of the App Engine backend that claim to be fully-compatible to the SDK/client-side.

also to fight vendor lock-in, Python developers can create Django apps then run them on App Engine using django-nonrel or on any traditional hosted stack supporting Django; or move between then w/minor (settings.py) changes; don't forget data migration as well.

reinhardt• 15 years ago

Not much familiar with GAE but how hard would it be to build an abstraction layer and have it deployed on, say, AWS or Rackspace, using HBase or Cassandra as backend?

krosaen5• 15 years ago

http://code.google.com/p/appscale/

nlake443• 15 years ago

The datastore API is probably the most involved for porting to. You would have to do both indexes and composite indexes for scalable queries, and implement your own transaction system. You can learn about how we do it for AppScale in our publications. Also check out the articles on the App Engine documentation, as well as the Google I/O videos for details on how they do it for Megastore/BigTable.

StavrosK11• 15 years ago

I have written multiple projects for GAE in Django and even ported one to it. The changes are seriously minimal. In the ported project, I had to change two lines of a lookup query that was a JOIN.

If you're concerned, use Django-nonrel, it's been amazing so far. Otherwise, appscale sounds like a good alternative.

herdcall• 15 years ago

If you're writing in Java, use standard API like JPA instead of native (that's what we're using with our site). I've tested some sample code on Amazon Beanstalk, and the code (with JPA) WORKED WITHOUT A SINGLE ALTERATION. It's not 100% obviously, e.g. if you use native types like Key, but the point is you CAN write your code to be compatible with any Java platform.

ayanb• 15 years ago

The difference in features between the free and the paid ($9/app) plans are

1)Usage based pricing, 2) Infinitely scalable and 3) an SLA

ConceitedCode• 15 years ago

App Engine seems like a great platform, but unfortunately it's a pain in the ass to switch away if you decide you want to. Unless I'm building a small/quick app I do not want to be 'locked in' to App Engine.

wescpy2• 15 years ago

It's easier to switch away and not be locked-in if you develop your app using Python/Django (see my comment above).

kkowalczyk• 15 years ago

I'm seeing going from $0 to around $1 per day (can be as low as $0.25), all of it for CPU hours. This can be seen in billing history.

That's obviously not something to be happy about but then again an argument can be made that the introductory free quota that Google gave was very generous.

This might give Go a push - as I understand it Go is the most efficient of the supported languages which should translate into less CPU hours => less money. On the other hand, other than template parsing/substitution, my code doesn't do any CPU intensive tasks. On the other hand, the CPU hrs might count the overall overhead of the platform, which for statically linked Go will be the smallest (both Python and Java have sizable runtimes that need to be initialized at startup - according to http://www.youtube.com/watch?v=HQtLRqqB-Kk, Java runtime is especially bad in that regard (this is towards the end of the talk in the q&a part).

StavrosK11• 15 years ago

You should also note that CPU hours turn into instance hours in the new pricing, but it's a straight conversion. With multithreading, the instances you use will go down, perhaps significantly. I believe they will about match your CPU hours, so you might see comparable pricing (if the price per instance hour is the same as the old CPU hour, anyway).

ww5205• 15 years ago

I don't think it's a matter of Python/Java being slow and GO is faster. It actually doesn't matter which language you pick. If your GO app is IO/network bound, you will be charged for the idle CPU hours in the new billing scheme.

antrix2• 15 years ago

Go isn't going to help at least in the near term. Concurrent request handling is not supported on Go. Nor do they have it on their roadmap, AFAIK.

anabanana2• 15 years ago

I have an online store that I custom developed in Python hosted in App Engine.

I'm paying around $15 a month. With the new prices I would have to pay $450 a month.

Time to migrate :(

Any recommendations for a python hosting?

amirhhz• 15 years ago

You'll still have to do a lot of re-writing but https://www.dotcloud.com/ might be your best bet.

omfg• 15 years ago

Might want to try out Heroku's Cedar Stack. It's been great so far.

walkon• 15 years ago

Heroku currently supports Python, or is that something that is in the works? I can't find much on this...

jshen2• 15 years ago

I don't think it would be much cheaper.

xal• 15 years ago

I'll give you a Shopify account for $15 a month if you want it.

jorde• 15 years ago

ep.io is gaining ground with Django developers but it also runs other WSGI apps. I don't have personal experience with their pricing but the stack and services is starting to look pretty good at the moment. Heroku Cedar Stack and DotCloud might be other options.

andypants3• 15 years ago

What the...

The cost of my app is going from $9 per month to $200 per month. This is ridiculous...

peteysd• 15 years ago

Wow - According to their projections based on current usage, I'm seeing a 100x increase in my daily cost. I guess I will be migrating off of App Engine. I'm feeling pretty burned at this point.

psm5• 15 years ago

some apps get high multiples because they're using resources that weren't counted before, or were counted differently; that's why we enabled side-by-side billing now (before we switch on billing). if you email me your appid (psm@google.com) we can help. you should also review the FAQ and the tuning tips web page that we put together.

dfabulich• 15 years ago

Could you define how high a "high multiple" is? 30x is too high, right? Is 3x too high?

jbaker• 15 years ago

There has been a lot of confusion and complaining about the price increases, and this is understandable given the way it has come about. This is one of those oh so obvious things, but you just have to look at it and evaluate. Besides scalability, app engine can be a great platform from a rapid app development standpoint. It has other nice aspects in addition to the scalability.

And don't forget to look into what may be able to be done to minimize some of the quota impact. Good design changes may be able to have a noticeable positive effect there.

Have a look at AppScale if you are looking at moving off the platform. That may be a way to get 80% of the way there with less monumental changes.

angkec2• 15 years ago

"And don't forget to look into what may be able to be done to minimize some of the quota impact. Good design changes may be able to have a noticeable positive effect there."

You mean concurrency? That won't be available until November. And if it fails to save the bill, you'll be screwed big time.

krosaen5• 15 years ago

A key point seems to be:

""" The new pricing model charges are based on the number of instances you have running. This is largely dictated by the App Engine Scheduler, but for Python we will not be supporting concurrent requests until Python 2.7 is live. Because of this, and to allow all developers to adjust to concurrent requests, we have reduced the price of all Frontend Instance Hours by 50% until November 20th. """

Our app (python runtime) is going from about $9 a month to projected $270 a month, almost entirely due to frontend instance hours. I have to think that once python 2.7 is live and concurrent users != concurrent frontends, this will get waaay more reasonable.

krosaen5• 15 years ago

Oh shit, and the $270 a month is with the 50% discount:

"""The Frontend Instance costs reflect a 50% price reduction active until November 20th, 2011. Learn more about the price reduction and ways to reduce your costs permanently."""

So come winter, I'm looking at > $500 a month... here's hoping concurrent requests on the python runtime will make a huge difference, otherwise, sheesh.

psm5• 15 years ago

you have time before the billing switches on to tune/adjust your application. check out the FAQ and tuning tips page. the prices are going up, but they are also changing, in that we're measuring things differently. most apps that are initially seeing a large multiplier are because of the latter effect, not the former. this is why we built and launched the side-by-side billing. (i'm on the GAE team)

Shamiq• 15 years ago

At what point will you consider moving to a different provider?

davepeck2• 15 years ago

One of my clients, whose app sees a decent amount of traffic, is going to go from $510/month to $2070/month _if_ the 50% frontend discount is applied. After the discount lifts, it looks closer to $3300/month.

Which, in my opinion, is insane.

It's not clear to me, yet, what impact the new 2.7 concurrency features will have.

StavrosK11• 15 years ago

I am assuming (big, unfounded, no-data assumption here) that, with multithreading, instance-hours will roughly match CPU hours for most applications. Most apps take care to minimize actual request CPU usage, so most is in the API.

With the new changes, API time doesn't count, so all you're left with is pure CPU time. Since a single instance can service one request while waiting for another's API to return, you're pretty much limited by the CPU time you use.

I hope to be proved right, anyway.

sergeys5• 15 years ago

You're also limited by the number of threads the GAE team will decide you can use per instance.

yahelc• 15 years ago

Without performance tuning, this will take my SharedCount API (http://sharedcount.com) from ~$0.50/month to $750 per month, post discount. Unless I can tune it significantly, I'll almost certainly have to shut the API down.

bane2• 15 years ago

Have you thought about slapping some advertising on that? It's a useful service and I can see it pulling in lots of users.

Fizzer• 15 years ago

If Google had said from the beginning that their pricing was discounted for the preview, I would not have had a problem with this. But given that they didn't communicate this and that the cost of switching platforms is high, this feels more like a bait and switch tactic.

My cost is only increasing about 4x, but others in this thread are seeing 20-100x increases. Changes like this impact more than GAE -- this will make me hesitant to use any platform that I can't easily migrate away from.

cyberfart• 15 years ago

About the huge cost increase people mention in the comments: New cost unit is IH (Instance Hour) and GAE python scheduler has a habit of revving up new instances aggressively. To lower costs one needs to lower Max Idle Instances and -maybe depending on the situation- increase Min Pending Latency, thus lowering the Instance count (and the cost).

With the price increase and very harsh cut down on API free-quotas (plus the absence of long expected SSL on custom domains) GAE no longer seems a good option for me :/

psm5• 15 years ago

we've cut the free quotas from super-generous to just generous. we're still the only large service offer generic platform free quota with no time limit.

as for delay in SSL on custom domains, we're guilty as charged; we're not happy it's taking so long and we're working hard on it.

angkec2• 15 years ago

from super-generous to just generous can still be called "bait and switch".

Greedy_Fools• 15 years ago

Generic platform? Who do you think is buying that?

lukeinth• 15 years ago

Costs for our app have just gone from $120 per month to $1200. Its a service we provide to users for free, we cant afford that level of hosting. That is a 10x price increase.

How many biz can get away with that sort of hike? This and how Google treats Android developers (shutting down forum, not responding to issues) is making me question why I bother building anything for your platforms.

I was on app engine from the start, I've sat though your DevFests, arranged hackathons, and told countless people they should use your platform. I've invested many hours learning your API. But this is it, its over, no more.

Anything but a tiny free app is going to cost the earth, if you want to scale use AWS or Heroku. If you are an outside developer trusting Google it will cost you.

PanosJee2• 15 years ago

We (at bugsense) have about 500k requests per day and some of the are very intensive. Currently we pay $5.40 daily and it will go up to $22. So per month with the old pricing we ll be at $162, with the new pricing we ll up to $660. It's x4 increase and that makes it bit cheaper than EC2 for the same amount of data. If we subtract the administration cost it makes it cheaper. The old, cheap days are gone :( But still it compares well in comparison to other popular cloud solutions.

anabanana2• 15 years ago

$22 daily after November? Without the 50% discount?

PanosJee2• 15 years ago

Yes without but there is a lot of space for improvement with better leverage of taskqueues and async datastore operations. We hope to reduce by 50% some some of the requests so that we spin out less instances. We also fine tuned a bit, check out our results: http://news.ycombinator.com/item?id=2951217

StavrosK11• 15 years ago

Is this taking multithreading into account at all?

Also, congrats on bugsense, I highly recommend it!

jay_kyburz• 15 years ago

The most disappointing thing for me was that the little bit of banner advertising I have on the games is no longer going to cover the cost of the hosting. It was nice a thought that the games could sit there forever and people could enjoy them for free.

sylvinus• 15 years ago

AWS: "We'll continue to cut our prices forever"

GAE: "Almost all applications will be billed more under the new pricing"

Pick one...

andypants3• 15 years ago

Well, they have said that this is the first and only price change to happen. They won't be increasing the price anymore after this.

danssig• 15 years ago

Never is a long time, no?

chc• 15 years ago

Eh, if price is the largest factor in your decision, I would probably recommend Dreamhost over either of them. The real trouble is that GAE doesn't seem to offer a whole lot more than AWS.

StavrosK11• 15 years ago

Well, except practically infinite, automatic scaling and zero administration.

bojanbabic• 15 years ago

I've ported part of app build on top of gae to amazon and face huge difference in billing structure. I've been paying whole gae $4/month, while aws charged 10x. After these changes ... I have no alternatives left ...

chrisboesing• 15 years ago

Just a quick note: App Engine hasn't left preview.

This[1] blog post from today says at the end: "[...]and we hope you find these tools useful as we get closer to our goal of leaving preview!"

They just rolled out the new pricing.

[1] http://googleappengine.blogspot.com/2011/08/50-credit-for-ne...

bigwally• 15 years ago

The email I received was titled "Google App Engine Leaving Preview". And it states "We plan to roll this out in the second half of September...."

The scariest part of looking at my billing history is "Frontend Instance Hour costs reflect a 50% price reduction active until November 20th, 2011"

mark_l_watson• 15 years ago

I just read all of the comments and one thing that no one mentioned explicitly:

You can still use a free instance that is 6.5 hours a day, 1 gig of datastore, 1 gig each of incoming and outgoing bandwidth, etc. Low volume sites should easily be able to stay in the free zone.

Free instances had better have a low loading request time (e.g., for Java apps, use Objectify instead of JPA, etc.).

Assuming I understand the new billing correctly, I can get a paid plan for $9/month + $36/month for one reserved always on instance. I also get 24 hours/day of free on demand front end instances to handle a bit more traffic.

I think that a paid for plan still gets the other free quotas of a free plan and you pay each day for any use over each free limit. Is this right? It looks like you can have 1 always on FE instance, and 1 or 2 on demand FE instances, and a reasonable about of resource use for less than a $100/month.

psm5• 15 years ago

yes a paid plan still gets the free quotas.

ramses0• 15 years ago

I think that's the dumb part though. If you get one user per hour for 12 hours a day, you're still overflowing the "6.5 hour limit" (unless I'm misunderstanding everything).

I'd love to use GAE for the reproduceability of dev environment, but lock in, 10x+ price increases and a VERY obtuse (not honest) explanations of how pricing is measured and billed makes EC2 look much better. I'll need EC2 anyway since you can't run arbitrary binaries (ie: PDF conversion) on GAE.

dwyer• 15 years ago

You get 6.5 CPU hours free with the current model, you'll get 24 instance hours free with the new model.

fernandotakai• 15 years ago

One app I manage is going from $0.05 a day to as high as $4.00.

That's really too much.

tantalor• 15 years ago

If your app can survive on 1 instance, but occasionally uses 2 or more, you should immediately change your "max idle instances" to 1 so you won't be charged for the extra instances.

The new free limit for frontends is 24 CPU hours, or 1 instance. I was seeing my frontend time in the 25-30 hour range each day.

ww5205• 15 years ago

I don't understand how the instance-hours are being calculated. One of my apps has the old 2.5 CPU-hours/day to the new 34 instance-hours/day calculation. The app is not CPU-intensive and 2.5 hours of work sound reasonable. It certainly is not hogging the CPU 34 hours the whole day. Does the new instance-hour include the process idle time of app?

Zakuzaa• 15 years ago

Hours when CPU is ON are counted. Not actual CPU usage or cycles.

ww5205• 15 years ago

So it counts idle time. When a process is idle, it doesn't use the CPU, which can be used by other processes.

This basically punishes IO/network bound apps and favors CPU-intensive apps.

I can see why some of the web apps has 100X cost increase since they spin up a process to handle a web request which can take fair amount of network time but uses very little CPU.

The new pricing model is not web-app friendly but favors heavy CPU-intensive backend processing kind of apps.

StavrosK11• 15 years ago

They calculate how many minutes an instance is active and sum all that. If your application is network/API/I/O bound, you will get highly inflated counts. However, if you take multithreading into account, one instance of an I/O bound app should be able to serve many, many requests, so your usage will go down tenfold again.

That is, unless I got something very wrong, in which case we're all screwed.

ww5205• 15 years ago

I have one new app during design phase. The frontend part is going to be in GAE since I had done couple apps in GAE and familiar with it. A part of the backend will be in AWS because I need to run a custom 3rd party app. With the new pricing model, it doesn't make sense to run webapp in GAE. I'll redesign the thing to run the whole thing in AWS.

flocial• 15 years ago

This pretty much confirms my reservations of investing in a closed stack. However, it's really a shame that Google didn't take the time to provide a clean migration path for people to take their apps out of the platform so they can scale up to a regular hosted or self-hosted application.

ww5205• 15 years ago

I think it's unfortunate that GAE use the term instance-hour for billing, which is quite different from AWS instance-hour. GAE's instance-hour is process-instance-hour while AWS is machine-instance-hour.

The difference is quite important. In AWS, you can spin up dozens of processes in an instance. In GAE, the instance is the process. If the process is idle waiting for IO, you are still being charged. Spinning up more processes mean more instances running and more are charged.

In that sense, GAE's $0.08 per process-instance-hour is quite expensive compared to AWS's $0.085 per machine-instance-hour. "Single-thread" Python process needs multiple processes to handle multiple web requests which counted as multiple GAE instance-hours while only a single AWS instance-hour.

nir• 15 years ago

Very disappointing. GAE for a while was for developers what Tumblr/WP.com/etc are for writers, a way to put an idea online cheaply & easily. The generous quotas made using the proprietary APIs worth it. Now it's just another PaaS.

Seems to me Google is competing in areas it'll never be really good at like social networks instead of using its core competency of running the world's biggest server farm.

riobard3• 15 years ago

The single most import reason that I like GAE is that it used to charge based on CPU usage, so that I could carefully optimize my web apps to reduce costs. This is also why I think cloud computing is a good thing: shared resources are generally efficiently used.

Now that GAE starts charging by instance-hours, however they are calculated, the drive to optimize is significantly reduced: I no longer have to worry about a web app's CPU usage if I have to wait for I/O anyway.

Some will say that's how we, as developers, should allocate our time to improve productivity, but the cloud platform as a whole just becomes a lot more wasteful.

And this change makes GAE much less appealing than AWS. If I'm gonna pay for instance-hours anyway, why not just launch some EC2 instances and kill them when I don't need them anymore? Sure it comes with admin costs, but at least I can migrate to another cloud provider much easier. Judging from the comments on this thread, migrating away from GAE seems very expensive, if possible at all.

jnw2• 15 years ago

I've certainly seen virtualization environments where RAM is a much larger fraction of the physical server's cost than the CPUs. How much RAM are you using when you aren't using many CPU cycles?

riobard3• 15 years ago

How much RAM does a web server need waiting for socket I/O? Not a lot. For most typical web apps, an instance of web frontend consumes a small fraction of the system's total memory. You could fit a surprisingly lot of such instances into a modern machine.

Big consumers of memory tend to be caching layer, which could (should, actually) run on different machines and bill based on memory usage.

I have to admit scheduling CPU and memory is an issue, but that shouldn't be the excuse to adopt a model that discourage optimizing for CPU usage.

Hawramani• 15 years ago

Wouldn't the perfect cloud platform be one that charges based on disk IO, disk space used, network IO, RAM space used, (Ram IO?,) and CPU used? Maybe there are other metrics I'm ignoring.

Someone should start making this.

buff-a3• 15 years ago

That's effectively what is was. Only RAM was missing from the calculation.

sdrinf• 15 years ago

https://www.nearlyfreespeech.net/services/pricing been around since 2002, does automatic load-balancing, have most of the benefits of what people are calling "cloud-computing", makes no presumptions about language of choice, does MySQL, and is extremely competitively priced.

buff-a3• 15 years ago

Indeed. The billing estimator they provide says that, on this one day, I was using 0.02 cpu-hours, and they estimate that under the new system that same activity will be billed as 2.8 instance-hour.

0.02 cpu-hours => 2.8 instance-hours

The only way this can possibly make sense is if they do the EC2 thing of "any part of an hour is billed as an hour", in which case, I might as well go with EC2.

Now, sure, when I'm using just a single instance, GAE is a nice way to get a webserver, a database, memcache, etc all set up and ready to go for a reasonable price. But if my business takes off, and I have enough traffic for multiple servers, and auto-scaling front-ends, etc, I'll be better off moving to EC2 or Rackspace.

StavrosK11• 15 years ago

Didn't the change make I/O free? If I recall correctly, you aren't charged for time waiting for API calls.

andypants3• 15 years ago

The change means that it doesn't matter what you're waiting for. As long as you have an instance up, you are charged for it, even if it's not actually doing anything at that moment.

AndrewDucker• 15 years ago

Yes, this was my feeling too. The great thing about GAE was that you paid for CPU time, not CPUs. Which means that if I want to run something tiny I only pay for the tiny amount of CPU it uses.

2AM• 15 years ago

After I read the email from Google, I didn't think the impact would be huge on my small app that just started gaining users, but it was a little shock, I headed to HN to find out if other people are affected or my app was badly written. I think everyone is affected.

I will be moving my app, if anyone else likes to use a freelancer, please drop me a line: varese4@gmail.com

sriramk• 15 years ago

I just sent some mail to my old colleagues in Windows Azure. If you're working on a cloud provider, a large one or a startup, you and your biz-dev/sales team should be out there actively trying to get people dissatisfied with GAE's announcement today (and from what I hear, that is a significant number).

papaf• 15 years ago

Meanwhile, VPS and dedicated server providers are getting cheaper, faster and more competitive.

I'd imagine that the majority of the people on GAE have found that they don't actually need to scale as much as they thought when they signed up to it.

EastSmith• 15 years ago

When is Python 2.7 coming to GAE?

richardw• 15 years ago

The source of my disappointment is that basically, they couldn't figure out how to slice and dice page serving without dumping you with the cost of a full VM. I was hoping they were committing to researching how to make that work, so if you made an efficient application you never had to worry about the infrastructure. Now, the abstractions have leaked and we have to worry about VM's. Time to update my answer here: http://programmers.stackexchange.com/questions/64727/windows...

I guess the problem of really efficient web serving remains unsolved.

eridius• 15 years ago

Strange, there's no mention of the Go runtime on the pricing page. I realize it's still a beta runtime, but it's still odd to leave it out.

philwise• 15 years ago

I would see this as a move towards 'enterprise' (yes I know people here hate that word), but look at the url...

$9/app/month means that it doesn't really make sense for tiny hobby sites any more: it is comparable in cost to a tiny VPS host, and my VPS currently handles 19 domains.

The place where GAE makes most sense is the 'line of business' app that is basically just a set of forms backed by a database. Those kind of apps don't have any complex things going on that are going to require integration with existing code or custom server configuration: both places where the current crop of PaaS offerings risky right now.

Line of business apps currently require lots of manual labour from DBAs and IS, so paying $9/month to run the HR application is going to be a pretty good deal.

thebootstrapper• 15 years ago

Migrate to EC2 with Appscale is a better way?

datastorebackup• 15 years ago

Those who are talking about being 'locked in' to App Engine, there are solutions, like http://www.datastorebackup.com

The essence of your data is saved. Nothing to worry about then..

And regarding the pricing... We'll see.. I'm not sure WHEN exactly it's going to be shifted - does anyone know?

A1programmer• 15 years ago

It's not only about the data, however. It's also about the x lines of code that are GAE specific. The datastore API is non-standard, and cannot easily be ported elsewhere.

markokocic• 15 years ago

Everyone is talking about huge cost increase for python applications, but I'd like to know what are the numbers for Java applications, since Java is multithreaded?

Is the price increase still tenfold, or something more acceptable?

jasonkiefer2• 15 years ago

Our Java application has gone from $240 per month to $6000. Total bait and switch. This is a business killer.

DennisP2• 15 years ago

The biggest problem I see is that they charge per datastore operation, and last I saw they were defining each entity returned as an operation.

If you were building a social network or twitter clone using the techniques they recommend in this talk: http://www.google.com/events/io/2009/sessions/BuildingScalab...

...you could easily pull back a hundred entities each time you pull someone's feed. It'd cost you a buck for every hundred pageviews or so.

yoknapatawpha• 15 years ago

It's obvious that there are many people who are upset about this price hike, how poorly it has been explained (showing "this is how much more we'll be charging you really soon!" side-by-side with the current pricing really doesn't help), and that it feels like a bait and switch given how AppEngine was originally sold on the basis of scaling against CPU usage rather than instance hours.

Telling us that Python 2.7 may reduce the cost multiplication factor by a bit just isn't very helpful.

Additionally, it also makes Google look a little bit stupid. We're supposed to accept that a world-leading company in the field of data processing, storage and server farms weren't able to determine ballpark running costs for their selling off their excess machine hours until now? Pfff.

In light of the fact that GAE hasn't exactly been the most stable platform, technical support has been untimely and poor, high priority bugs can stay acknowledged for years, a timeline for SSL support is still non-existant, and full search capabilities are only now impending at some unknown date (and how much will that cost when it finally arrives?), it really does make them look like rank amateurs.

The AWS team must be laughing.

jasonkiefer2• 15 years ago

This is a total bait and switch. On the same day that Appengine took our site down for 18 hours with no apology(we support 3000 daily visitors with an average time on site of 13 min). They announced that costs would increase from $240 per month to $6000. SIX THOUSAND! This is truly the definition of evil if you ask me.

Google App Engine leaves preview, new pricing

Related Stories