Google App Engine PHP Runtime now available to everyone

http://googlecloudplatform.blogspot.com/2013/10/google-app-engine-php-runtime-now-available-to-everyone.html

by zafirk • 13 years ago

131 82 13 years ago

googlecloudplatform.blogspot.com

What is it that Google has with Jetbrains? First they move their Android dev to intellij, now this...?

gfosco• 13 years ago

They probably have a lot of respect for their tools. Jetbrains has some incredible products. WebStorm, PHPStorm, ReSharper, AppCode, etc.

In this case, though, it looks like Jetbrains wrote a plug-in for PHPStorm, and Google is just mentioning it as a good method.

yareally• 13 years ago

I believe the Android team members at least have always favored Intellij based on the comments I've seen praising it in the Twitter Feeds prior to Android Studio's announcement and also that it's always been supported along side Eclipse as a way to easily import the AOSP source into an IDE (though only if you look in the source itself) if you choose to do so.

ryan-allen2• 13 years ago

I wouldn't host anything of importance on GAE, since Google has this odd fascination with shuttering services with zero recourse for its user-base.

jmillikin• 13 years ago

Which paid services have Google shut down?

asdfologist• 13 years ago

Google Checkout.

prostoalex• 13 years ago

Google Answers

codonaut• 13 years ago

They do have a history of that, but AppEngine has a huge footprint right now, and Google is only expanding it's cloud platform with Compute Engine, redoing UI, etc. They're clearly investing a lot here, I don't think they'll close this as easily as Google Checkout or others

ryan-allen2• 13 years ago

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

benatkin3• 13 years ago

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.

mountaineer• 13 years ago

That, or drastically changing it's pricing.

jfoster2• 13 years ago

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)

ajessup5• 13 years ago

Hey folks - App Engine actually has an explicit deprecation policy spelled out to make sure this can't happen. See https://developers.google.com/appengine/terms

jcampbell13• 13 years ago

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

benatkin3• 13 years ago

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...

hosay123• 13 years ago

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.

elq• 13 years ago

I'm under the impression that app engine is heavily used inside of google and its use is being evangelized.

This leads me to believe that it won't be killed

petersmagnusson2• 13 years ago

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

petersmagnusson2• 13 years ago

honestly, i thought HN crowd was above continued "omg reader shut down google can pull the plug on anything".

(a) App Engine specifically (and Google Cloud Platform in general) is being sold to enterprise as well, with SLA and deprecation policies.

(b) App Engine has been around since 2008 and is growing VERY strongly.

(c) Even if worst case happens, fine, move your app to somewhere else. Deprecation is officially a year, plenty of time to move. Any company can deprecate any products. GAE has huge usage (over 3 million applications), and we have two (and counting) compatibility partners (CapeDwarf and AppScale) that you can move.

(d) GAE does not lock you in. Won't rehash arguments here, see: https://plus.sandbox.google.com/u/0/110401818717224273095/po...

cheers,

saurik• 13 years ago

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?

jfoster2• 13 years ago

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.

data_app• 13 years ago

That is the talking point of Google haters. Sounds like I am listening to Hannity on Hacker News.

nacs• 13 years ago

This is probably going to sound a bit harsh but is adding general PHP support in 2013 newsworthy? Pretty much every 'cloud' provider has provided support for PHP for years now.

Not only that but listing things like "ability to easily read and write files from PHP" and "support for [..] mbstring and mcrypt" as new features makes me less inclined to try App engine for any PHP work as it seems even the most basic things like writing files and mcrypt require App Engine-specific code.

I'd much rather just deploy to Amazon's EC2/Rackspace/generic VPSs than have to add App engine specific changes to my code.

dragonwriter• 13 years ago

PaaS's are basically hosted specialized frameworks, and as such usually require framework-specific code. App Engine is Google's PaaS offering, and most of your issues seem to be "I don't want a PaaS, but prefer an IaaS or VPS".

As Google has an IaaS offering (Compute Engine), it seems odd that, given those complaints, you'd compare their PaaS offering against other provider's IaaS offerings.

fleitz2• 13 years ago

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.

ajessup5• 13 years ago

Writing to files is hardly App Engine specific. Here's an example:

$fp = fopen("gs://my_bucket/some_file.txt", "w"); fwrite($fp, "Hello"); fclose($fp);

jcampbell13• 13 years ago

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?

ing33k• 13 years ago

I have to agree on other providers supporting PHP supports for years, but this is a good news for PHP devs and companies. PHP is still not completely accepted in big companies, just the news that Google app engine supports PHP will lead to some confidence to invest in PHP and that the language is here to stay .

vargalas• 13 years ago

It was the most requested feature. I also asked it (amongst many thousands of others). And now I also feel, that it's a bit late... You have so many great companies to choose from nowadays. Great service, good infrastructure, etc. Google is great also, but it's a bit too late, isn't it?

tlarkworthy2• 13 years ago

I use GAE with python a lot. But you can't find forum software not implemented in PHP. I wonder how easy it will be to rewire existing PHD apps for GAE?

One serious issue is caching gets. Those rack up your bills in no time unless you memcache stuff.

Interesting stuff though.

ajessup5• 13 years ago

You can use many forum products today if you use Cloud SQL as your storage service (and it's pretty cheap, it starts at ~$10/month).

eg. phpBB - http://fredsa.allen-sauer.com/2013/07/standing-up-phpbb-inst...

tlarkworthy2• 13 years ago

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

justinmk• 13 years ago

you can't find forum software not implemented in PHP

Worth mention: http://www.discourse.org

jsnk• 13 years ago

Please work on supporting Ruby now.

sebastianavina• 13 years ago

and brainfuck

neals2• 13 years ago

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

pekk• 13 years ago

Bizarre that they would have gone for PHP before Ruby... Anyway, App Engine just jumped the shark, so Rubyists should know they don't need it

dancecodes10• 13 years ago

I just saw some lines from GAE for PHP and saw very inconsistent and not quite code.

All modules use require_once... well, well...

And other many issues...

But looks as massive code. Maybe translated automatic.

mortehu• 13 years ago

All modules use require_once... well, well...

Why on earth is that a problem?

itafroma• 13 years ago

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

dancecodes10• 13 years ago

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

hardwaresofton• 13 years ago

long live php!

rjknight• 13 years ago

I assumed from the title that this would be about Google open-sourcing their PHP runtime.

neals2• 13 years ago

Sometimes I worry. All this time I spent learning to maintain my own server, even though I am definitely a developer-first, is it wasted when PaaS are getting more common. Am I holding myself back by sticking to my own setup or am I keeping things cost- and performance efficient? Will this be an issue when I (finally) really need to scale up?

prottmann• 13 years ago

If you scale up, you wish you didnt do the failure of running an own "cost- and performance efficient" solution. We did the same failure for many years.

If you scale up, normally you did not have time to look for better solutions, because you need your time for your product and customers and not for your server. The problem is that you then loose customers or slow down the growth and that cost more then some bucks for a better cloud solution (and yes, cloud cost more).

dancecodes10• 13 years ago

Why you use multiple namespaces in single module? It is not good practise and smell. Official documentation don't recommend this.

dancecodes10• 13 years ago

why not use something base of PEAR coding standards ?

public function foo($bar)

{

  //
  //return (bool) $bar;
  //

}

This can help: http://www.gnu.org/software/emacs/

http://pear.php.net/package/PHP_CodeSniffer/

and enable flymake php linting

smartmohi• 13 years ago

How to host PHP web application on GAE for free is explained in this tutorial. http://www.tinywall.info/2013/10/12/google-app-engine-php-wi...

Google App Engine PHP Runtime now available to everyone

Related Stories