Google App Engine PHP Runtime now available to everyone

The brilliance of PHP is drop files in folders, voila, website.

As soon as you know the terms IaaS, VPS, and PaaS, you know too much to be using PHP.

That is pretty cool. fopen is troublesome over the network though. Correct me if I am wrong, but writing to gs:// means that the writes are replicated to something like 3 physical disks in different data centers, which means it is probably 100x slower than writing to a local disk (but infinitely more durable).

gs:// seems like a great option for file uploads, but it could be a problem with thing like asset pipelines where stat can get called absurdly often. Any thoughts?

Google Checkout.

Google Answers

I supposed, but would you risk your business by locking yourself in to their platform?

I thought Google Reader was too big to be shut down too. It had a small % of all users but a large % of power users.

Yes, or also not investing in it. GAE already feels like they're more interested in adding features that result in new customers over fixing bugs for the benefit of existing customers. Of the ~6000 defects ever opened for App Engine, ~1400 of them are still open. (issue tracker: https://code.google.com/p/googleappengine/issues/list)

It clearly says they can do anything they want, but must give you 90 days of warning.

That doesn't mean much. When google deprecates something, it might as well already be shut off. http://techcrunch.com/2012/09/24/feedburner-experiencing-sta...

As a recovering hardcore Joke Engine user, I suggest not getting too tied up on TOS minutia as arguments against App Engine when there are plenty technical reasons to avoid it like the plague, e.g.:

- Behavioural changes as a result of unannounced internal release process. Go to bed, wake in morning to app serving 500s (happened twice)

- Design flaw that ran so deep they had to redesign the datastore, insisting on people start migrating before they even had migration tools ready. Prior to that, at least one outage event required running the Google equivalent of fsck and leaving "/lost+found" folders in everyone's datastore (WTF?!?!? Not even once, dude!)

- Latency that varies according to the phase of the moon, and you're billed for it anyway.

- Continually changing architectural story around apps. Last year: Memcache is cheap, free, and shared! This year: Dedicated memcache, only $66/gb/month! 2 years ago: elasticly spun up processes! Last year: dedicated hardware thread, only $100/thread/month!

- Let's not forget the wild pricing changes depending on how much the App Engine team had packed in their crackpipes the night before

- Service characteristics you won't see on any other platform (e.g. DB query latency). So regardless of abstraction layers, your app inevitably ends up designed for a single platform

It's a platform that succeeds only at exposing users with RAM-sized datasets to planetary scale problems, all the while charged handsomely for the privilege of the self-delusion that some edge was gained through all the suffering. Seriously fuck all that. I could turn this into an essay but why bother.

Correct, heavily used internally. In fact I'll be talking about that at Cloud Connect in Chicago soon.

They've shut down much more than Reader (seriously, who said anything about Reader? was that even a service a developer could rely on?). Even APIs they don't shut down, such as their OpenID login stack, they routinely replace (dropping a lot of the maintenance and support, which leads to weird failures) with "exciting new APIs" that have no migration path, such as with G+ Login (I am thankfully safe from this issue, as I did something crazy with Portable Contacts that have me Google user IDs that I started storing before we even knew what they meant; so, to be clear: I have very little personal axe to grind on this, but others should be wary).

They thankfully decided to just go commercial-ish with Translate, but the same can't be said about Charts (which had a long deprecation window and a replacement, but the replacement is a fundamentally different kind of API that has different browser requirements and even different charting capabilities). They also happily will just shut down things like Google Checkout and offer no replacement at all for key use cases like "sell a physical product" (if you sell digital goods, you might be able to switch to Google Wallet Objects, an "exciting new API" released a couple weeks before Checkout was deprecated).

Google Checkout was certainly also targetted at enterprises, had a clear business model behind it, and had existed since 2006: everyone who built on that one (again, not me: I avoided Checkout like the plague) got only six months to migrate to a different provider (and figure out how they are going to handle any refund requests from recent customers, which will surely be horribly irritating as they won't be able to just tell Checkout to refund the transaction anymore). There is simply a patterned lack of care for people who may have built things on their stacks.

(Yes, some services have deprecation policies, but let's not forget that those guarantees were themselves attempts to regain faith due to a previous round of services that had been axed with little warning ;P. After the anger died down from that they started reversing course, shortening or removing the policy entirely after the previous guarantees expire. I can only imagine the people who keep citing these deprecation policies don't have much memory of how this has all been going down over the past few years ;P.)

http://googledevelopers.blogspot.com/2012/04/changes-to-depr...

Yes: you might be able to find alternatives to migrate towards... but if, by just acknowledging this pattern, you could avoid that bullet--which could easily come at the "least convenient moment" (such as when you now have some competition out of nowhere while attempting to launch a new product and raise finding), requiring you to suddenly drop everything for a couple weeks coming up with a new implementation of key infrastructure before the clock runs out--why wouldn't you?

I think it's a good thing that Reader shutting down or other unpopular decisions are held against Google's other products. It means that Google poisons all of its products when it screws the users of any one product. It's a very healthy marketplace reaction, in my opinion.

That said, I acknowledge that Google shutting down enterprise products is less likely than shutting down niche consumer products. Another point I want to make, however, is that shutting down a product is not the only thing that can go wrong with something from Google. For example, there are App Engine bugs affecting production that have been left open for years. There's also poor documentation of some of the interactions between Google products. For example, the best documentation of Google Apps secondary domains not being supported by App Engine is a bug report. (https://code.google.com/p/googleappengine/issues/detail?id=6...)

I seem to run into an issue with App Engine every few months only to find that people have been encountering it for years and that despite being acknowledged by Google, it's just been sitting idle in the GAE issue tracker. My point is that a shutdown of GAE isn't the only thing that could go wrong with it, and who knows what GAE bugs might be encountered if one actually made a serious attempt to migrate an app away from GAE.

On balance, I don't regret picking GAE because I think the effort saved outweighs the problems.

yes that's exactly the kind of thing I have been looking for! Many thanks

It's not necessarily a problem, but it's a smell. Modern object-oriented PHP development is done with autoloaders[1]: having to require_once every class file is unnecessary and brittle. It is odd that GAE doesn't provide its own autoloader for its provided classes, and I'd expect that to be addressed in the future.

[1]: http://php.net/manual/en/language.oop5.autoload.php

without autoload its seems useless and as monster. Its seems as broken by design.

I would move my enterprise CRM package over to GAE as soon as this becomes a reality.