Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

41 comments

Sorry! There are no comments related to the filter you selected.

!Google Apps Engine (2)

olsmeister (1488789) | more than 2 years ago | (#37280596)

It's Google App Engine. App, not Apps.

community is not happy with this (4, Informative)

dolmant_php (461584) | more than 2 years ago | (#37280610)

The mailing list has been awash in outrage and suprise as prices rise much higher than most can support. Although all knew the price increase was coming, the optimization done for the past models don't apply to the new pricing scheme, and the community is not happy about the quick change (2 weeks). http://groups.google.com/group/google-appengine/browse_thread/thread/a1b7c68db2243932/043cbc3b7c296d06?hl=en [google.com]

Re:community is not happy with this (1)

nmb3000 (741169) | more than 2 years ago | (#37281060)

The mailing list has been awash in outrage and suprise as prices rise much higher than most can support

This is one reason I'm always critical of people who blindly say "Move your $X to Google $SERVICE! It's free for $PREDICATE usage!"

TANSTAAFL, even if it is Google. Sooner or later (usually based on how fast $SERVICE reaches some critical mass) you better be willing to pay up. At least the classic software model tells you how much it costs up front.

Re:community is not happy with this (1)

makomk (752139) | more than 2 years ago | (#37281674)

It's quite scummy really though. They offered it for free or cheap for long enough to allow people to write applications based on it, then pushed up the prices to the point it'd be far cheaper to host them on traditional hosting - but the users couldn't because Google App Engine had proprietary APIs that locked them into that service.

Re:community is not happy with this (1)

PNutts (199112) | more than 2 years ago | (#37281742)

The parent of the link you replied to debunks your claims.

Re:community is not happy with this (1)

makomk (752139) | more than 2 years ago | (#37281788)

It does? Bits of the web-facing APIs are open source (with core underlying functionality like sandboxing stripped out and no guarantee of compatibility) but the backend stuff definitely isn't...

Re:community is not happy with this (0)

Anonymous Coward | more than 2 years ago | (#37284346)

Of course not. Good old "open" Google never exposes the parts that actually make them money.

Re:community is not happy with this (1)

fermat1313 (927331) | more than 2 years ago | (#37282178)

The mailing list has been awash in outrage and suprise as prices rise much higher than most can support

This is one reason I'm always critical of people who blindly say "Move your $X to Google $SERVICE! It's free for $PREDICATE usage!"

TANSTAAFL, even if it is Google. Sooner or later (usually based on how fast $SERVICE reaches some critical mass) you better be willing to pay up. At least the classic software model tells you how much it costs up front.

This is one reason I'm always critical of people who blindly say "Move your $X to Google $SERVICE! It's free for $PREDICATE usage!"

TANSTAAFL, even if it is Google. Sooner or later (usually based on how fast $SERVICE reaches some critical mass) you better be willing to pay up. At least the classic software model tells you how much it costs up front.

I know what you mean, my monthly fees for Google Search, Google Maps, and GMail are *killing* me.

Re:community is not happy with this (1)

hedwards (940851) | more than 2 years ago | (#37282654)

Yeah, and they're policy of allowing me to download all my data is preventing me from moving it somewhere else.

Re:community is not happy with this (1)

Noughmad (1044096) | more than 2 years ago | (#37283420)

That's kind of the point. Changing your default search engine is very easy, changing your mail provider too, especially if you already use an e-mail client. There are also competing map products, although I don't know how good, but nothing ties you in with the three products GP mentioned.

On the other hand, if you developed an app for the App Engine, using Google's API, it's much more work to port a web application to another platform.

I writing a small hobby web app right now, and I decided to use GAE because of its simplicity. So while this strikes me as bad news (especially the quota lowering), I had enough foresight to write it with Django and the django-appengine backend, so I can easily replace the backend and take my business elsewhere.

Google App Engine? (4, Informative)

hedwards (940851) | more than 2 years ago | (#37280692)

If you're not going to tell us what it is, perhaps linking to something that does would be in order.

http://en.wikipedia.org/wiki/Google_App_Engine [wikipedia.org]

Re:Google App Engine? (1)

Spigot the Bear (2318678) | more than 2 years ago | (#37281156)

Also, the title/summary calls it "Apps Engine", which confuses App Engine (cloud hosting) with Google Apps (domain/email/document hosting).

Re:Google App Engine? (1)

gumpish (682245) | more than 2 years ago | (#37281676)

Hey, at least the headline and summary use the actual name and not an initialism.

I've seen at least a dozen stories where the headline and summary use some collection of initials and never even say the full name of the technology in question. (And these aren't stories about mainstream topics like HTML, PHP, W3C, IEEE, IETF, etc.)

Re:Google App Engine? (1)

kmoser (1469707) | more than 2 years ago | (#37282930)

What, only acronyms need to be explained? How about terms like "app"?

Re:Google App Engine? (1)

Inda (580031) | more than 2 years ago | (#37284018)

I see OS projects still think they're being funny with project names.

"The open source Python projects gaebar..."

I smile, but I also think they're doing themselves no favours.

Wonder if that means they can use profiles now (1)

grasshoppa (657393) | more than 2 years ago | (#37280732)

Apps and Profiles/Google+?

Ya, probably not.

Re:Wonder if that means they can use profiles now (1)

devleopard (317515) | more than 2 years ago | (#37281024)

No, it's not really designed to be an integration point for the various Google APIs. However, you can hit those APIs the same way you can with any other platform (theoretically with lower latency), but there's nothing special about those APIs as it related to Google App Engine.

Rather, it's a means to, in a fairly agnostic way, build solutions that do all the normal, boring app things: access a file store, access a data store, message queuing, email, HTTP calls, etc.

Re:Wonder if that means they can use profiles now (5, Informative)

batkiwi (137781) | more than 2 years ago | (#37281446)

Through no real fault of your own you are confusing "google apps" with "google app engine".

"google apps" (what you are referring to) lets you run your own domain/business/school/etc using google services including mail/docs/etc. You ALSO get access to google app engine, but it has no real connection to google apps.

"google app engine" is what is being discussed here. It lets you use python or java to write your own web applciations which are run on google's cloud. You get access to google technologies such as big table/auto scaling/etc.

The issue is, google used to have a free model that was quite generous, and a paid model. The paid model actually allows you to "enable" billing, but still get a MORE generous "free" quota. This was amazing, because you could say "I'll spend up to $20 a month on this app, but simply be letting google charge me they'll let me do more for free." A lot of devs on the paid tiers still got free service. Most importantly, there was NO minimum charge per app. If an app wasn't hit a single time, it'd cost you nothing.

Now they have decreased free limits, set a minimum cost per month, and dropped the entire idea of free quotas for paid apps. This means that, for example, some people who had 5 apps deployed and spent $20/month between them now are paying at least $45, and likely several hundred due to removal/reduction of free quotas for paid accounts.

It's now cheaper to use amazon, PLUS you get more control (which can be good or not) for small open source community apps.

Prices (1)

Aighearach (97333) | more than 2 years ago | (#37280760)

look reasonable to me.

I don't see how hating on this does anything other than discourage companies from offering public beta services.

It was never promised as free coffee for life or whatever the whiners claim they thought they were getting.

And it still has a free level!

The $9 minimum is instead of the $9 fee that they first announced, which effectively is a huge upgrade for the low end paid users.

Re:Prices (1)

zenyu (248067) | more than 2 years ago | (#37281190)

They are very reasonable. The free tier looks like it offers enough to replace what I was paying $70/mo for an old server with just 80GB of storage in a colo facility not so long ago. In particular, it looks like it's easier to host low resource servers for 24/7 for free than with AWS.

Reading the comments it looks like some people have gone hog wild on server resource utilization when it was free. One commenter said his free app was using eight 24/7 servers. But if you're using those kind of server resources you should have what, 500k active users? At that point you should have enough advertising revenue to recover costs.

Re:Prices (1)

makomk (752139) | more than 2 years ago | (#37281802)

Was your server ever serving more than a single request at once, or did it ever signficantly exceed 1-2 requests per second? If so I don't think the free tier would be enough...

Re:Prices (1)

Aighearach (97333) | more than 2 years ago | (#37291172)

It's not a question of if it ever exceeds some number of requests per second as much as the total amount used, when it is a "low resource" app.

With AWS it is actually most expensive per request at the lowest non-zero utilization. If you have a trickle of traffic for 20 hours a day, and low or medium load for a few hours, then AWS is really expensive right in the place where google is free.

The result is that you have a colo or VPS or something to handle the low traffic, and balance off onto AWS when the load spikes.

With google that isn't necessary, you can start with free and then increase incrementally in a smoother price curve if you grow. One setup to manage.

Meh (2)

HuckleCom (690630) | more than 2 years ago | (#37280858)

Meh, at that cost ($9/mo?) - developers using it for non-android purposes will move away to a VPS. Giving the platform really just exclusivity for Android app makers for the publicity perks. The instance and bandwidth expenses are garbage compared to AWS.

Re:Meh (0)

Anonymous Coward | more than 2 years ago | (#37281044)

Google App Engine is PaaS platform. All developers who were there understood the limitations and benefits of not having a VPS. Why would they go to VPS now?

What does your comment have to do with android vs non-andorid? It's a general place to have websites.

Re:Meh (2)

dolmant_php (461584) | more than 2 years ago | (#37281154)

The instance and bandwidth expenses are garbage compared to AWS.

True, but on app engine you don't have to worry about scaling, licenses, upgrades, etc. This is worth the extra cost to some.

Re:Meh (0)

Anonymous Coward | more than 2 years ago | (#37283148)

You do have to worry about scaling (A) because you are charged by the instance hour with all that entails and (B) you have to write your apps in a radically different and sometimes quite challenging and time-consuming way in order to take advantage of scaling. No free lunch.

Really? $9? (-1)

Anonymous Coward | more than 2 years ago | (#37280994)

OMG!! NOT 9 DOLLARS!! Seriously, you people are whining over a $9 a month charge?

Re:Really? $9? (1)

makomk (752139) | more than 2 years ago | (#37281640)

The 9 dollars is just the base fee. If I'm reading this correctly the only thing you get for that $9/month is the ability to pay additional pay-as-you-go usage fees to get more resources; the monthly fee doesn't increase your inclusive resource allocation at all. If your application is actively used most of the time, you'll apparently end up paying quite a bit more [appspot.com] ...

Re:Really? $9? (1)

devleopard (317515) | more than 2 years ago | (#37281828)

If you spin-up an EC2 instance on AWS, with no additional features (like S3, SimpleDB, etc), it will cost you at least $15 a month. (They do have a "free" tier, but that's for the first instance, and not everyone qualifies).

The bigger question, of course, is usage. I need to sit down and really assess a normal app in terms of various resources used. I know that most of those services are dirt-cheap for AWS. (You have to consider that for a decent app, you wouldn't be using the "Micro" EC2, which is the $15 instance, but the Small instance, which start at about $75 a month or so)

Tornado / Redis (1)

codepunk (167897) | more than 2 years ago | (#37282530)

I like the programing model behind app engine, wrote a few apps using it etc. However being locked to the platform you never had real control over sucked.

Today however if I want the same sort of infrastructure all I need to do is install tornado and redis on a ec2 or a rackspace instance and I have all the speed and bandwidth I need.

Re:Tornado / Redis (1)

SanityInAnarchy (655584) | more than 2 years ago | (#37283202)

Actually, I seem to remember someone re-implementing the App Engine Python API on EC2. The dm-appengine layer for appengine-jruby is also relevant -- while that project could use a bit of love, it means you should be able to migrate to other datastores reasonably easily.

Re:Tornado / Redis (1)

slim (1652) | more than 2 years ago | (#37284154)

I'm perfectly happy to delegate "real control" to someone I'm paying. However being locked in to a single provider scares me.

Bring on the competition! Anyone should be able to put up a competing service that provides the same APIs.

I note that AppDrop [github.com] hasn't seen a commit since 2008 - but it shows what can be done.

And also raised. (1)

SanityInAnarchy (655584) | more than 2 years ago | (#37283182)

IIRC, they used to have 6.5 hours of CPU time free, now you get a full day. Doesn't help if you get Slashdotted, but it's still a significant difference.

Re:And also raised. (0)

Anonymous Coward | more than 2 years ago | (#37297986)

No, it used to be CPU time, now it's a day of INSTANCE time. A 200ms request can spawn a new instance that keeps running for 15 mins or 1/2 hour. So your 0.2s of CPU time => 1800s of INSTANCE time. And an "instance" can only handle 1 request at a time. So the generous "increase" isn't that great after all.

Still feels like an increase. (1)

SanityInAnarchy (655584) | more than 2 years ago | (#37298774)

It used to be possible to burn through those 6.5 hours very quickly, and often for the same reason -- if you didn't have an instance constantly running, you'd burn CPU spinning one up if you got a request every few minutes, because the instance would spin down after a few minutes.

But if you ping it repeatedly, that's a significant amount of CPU lost just keeping it running.

An instance makes a lot more sense. If my app actually fits comfortably in the free tier, I'm probably not getting enough traffic for several simultaneous instances to be needed. Running one instance 24/7 for free makes sense, and is going to be a lot more responsive in that "a hit every few minutes" category of usage.

And while they might fire up another instance in response to traffic, that seems unlikely for a low-traffic app -- "1 request at a time" isn't a big deal when you consider that this concerns just the actual processing of the request -- other requests can pile up behind that, and you have a hard limit in how long a request can take anyway.

AppEngine Pricing (0)

Anonymous Coward | more than 2 years ago | (#37284608)

The price change is just outrageous.

Our simple logger application (4000 low latency requests (max 2 datastore ops per request) a day) will move from 9 USD per month to 288 USD per month (+3122%).

The main problems are:

1) AppEngine scheduler is not able to allocate instances economically (which was no problem, when instance time was free). "Always on" used 6 instances to accommodate the load "immense" load of 4000 request a day.
2) The datastore operations are really slow (a search by key name (in only 60.000 records can take over 100 ms))
3) Each instance can only process one requests at a time
4) The loader often fails with timeouts, so having instances preloaded seems to be essential, as soon a your application is moved from trivial to something useful
5) Frontend instances (with only 200 MB RAM) which used to cost 3.00 USD per month are now priced at 57.60 USD per month (+1820%)

Google's offer to only charge 50% of the instance time until end of October (when they think, that multi threading would be ready) will not solve the problems:
1) Instance time is much too expensive even when multi threading is available
2) The limited RAM size will become an issue with multi threading (maybe not for our logger application, but for most others)

Re:AppEngine Pricing (0)

Anonymous Coward | more than 2 years ago | (#37287492)

Our simple logger application (4000 low latency requests (max 2 datastore ops per request) a day) will move from 9 USD per month to 288 USD per month (+3122%).

Who cares. The comparison is completely irrelevant. The ONLY basis for comparison which matters is how it stacks up to comparable service offerings. The fact you previously got extraordinary services for dirty cheap in the past means that the amortized cost over the next few years, even with the higher prices now likely makes GAE exceedingly cheap in foreseeable future. Did you bother to add that into your cost models? Thus far it seems you didn't and you only care to close your eyes and complain.

So please, post again with a valid comparison. I'm sure others, like myself, are interested to see how it comparisons with an apples to apples comparison rather than a baseless rant about how you actually have to pay for resources used from another company.

So please, what do the cost model actually look like in comparison? What does it look like when you amortize the cost over the next several years, including your massive savings over the last previous years?

Boiled frogs (1)

biodata (1981610) | more than 2 years ago | (#37285072)

1 Put frogs in pan of cold water 2 Increase heat slowly 3 ? 4 Profit

Still no SSL (1)

Kagato (116051) | more than 2 years ago | (#37285652)

At that price you'd think they would have added SSL domain support. Or at the very least had it as an option.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>