Google App Engine PHP Runtime now available to everyone(googlecloudplatform.blogspot.com)
googlecloudplatform.blogspot.com
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
84 comments
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.
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.
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.
As soon as you know the terms IaaS, VPS, and PaaS, you know too much to be using PHP.
This is an example of someone who's riding the hate PHP bandwagon. Honestly sick and tired of people who have no idea just what PHP is capable of who like to bash it because it's "cool".
I have come to a conclusion that the biggest haters are the ones who were unable to learn and fully understand the language. They are really quick to bash and hate because that's way easier.
Of course there are flaws and of course there are better designed languages out there, but PHP is not going anywhere.
Of course there are flaws and of course there are better designed languages out there, but PHP is not going anywhere.
It's a waste of time to even point it out.
So which language does a person of your knowledge use?
[deleted]
My money is on Haskell. Or is there another cool language on the block these days?
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);
$fp = fopen("gs://my_bucket/some_file.txt", "w"); fwrite($fp, "Hello"); fclose($fp);
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?
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?
It's certainly slower, and more durable, than local disk for writes. For reads/stat()ing this is mitigated to a certain extent by optimistic caching in memcache.
You also get the advantage, for asset pipelines, in that GCS can serve the generated file directly.
You also get the advantage, for asset pipelines, in that GCS can serve the generated file directly.
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 .
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?
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.
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
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.
- 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.
No kidding, the service should be renamed GA2EE. It's slow as hell, never works, and requires you to custom code for their 'enteprise' platform to solve problems no one even has.
God forbid the bill you'd get for actually scaling to a size that started to require whatever GA2EE really is.
God forbid the bill you'd get for actually scaling to a size that started to require whatever GA2EE really is.
To emphasize your point, look at the downtime some Python users experienced just today (this is a link to the official App Engine Google Groups): https://groups.google.com/d/msg/google-appengine/iRb3wrV8AB0...
My company hosts our app on GAE and I could not agree more with this. GAE is horrible. We are paying close to $1000/month and we could get better performance on a $5 Digital Ocean instance. $700 of that is "premier" support which is a joke. We're lucky just to get a response back. Not to mention they broke Python's debugger(PDB) a while back and it took them three month's to fix it.
Leaving GAE is the best thing I ever did.
It clearly says they can do anything they want, but must give you 90 days of warning.
Actually, the policy is:
"Google will announce if we intend to discontinue or make backwards incompatible changes to this API or Service. We will use commercially reasonable efforts to continue to operate that Service without these changes until the later of: (i) one year after the announcement or (ii) April 20, 2015"
So you have a year, at a minimum.
"Google will announce if we intend to discontinue or make backwards incompatible changes to this API or Service. We will use commercially reasonable efforts to continue to operate that Service without these changes until the later of: (i) one year after the announcement or (ii) April 20, 2015"
So you have a year, at a minimum.
Thanks for that. I stopped reading at:
"Unless otherwise noted by Google, material changes to the Agreement will become effective 90 days after they are posted, except if the changes apply to new functionality in which case they will be effective immediately. If Customer does not agree to the revised Agreement, please stop using the Service."
"Unless otherwise noted by Google, material changes to the Agreement will become effective 90 days after they are posted, except if the changes apply to new functionality in which case they will be effective immediately. If Customer does not agree to the revised Agreement, please stop using the Service."
Yeah, and in those 90 days if things break, they may not work as hard to get it back online, as they would have if there wasn't a deprecation.
They would have to be suicidal to shutter appengine and only give 90 days notice. Won't happen.
"Suicidal"? Realistically what would happen, do you think? They shut down Google Reader, which is probably used by 1000+ times as many people. The average user of Google Apps Engine apps probably has no idea where the service is hosted and will never understand why they should blame downtime on Google.
Comparing this to Google Reader is ridiculous. Google Reader was free, and it had a small potential market. Even if Google Reader had 100% of the market (which I'm sure people will say it did), the number of potential users was not huge, and the amount of revenue they could bring in was pretty small.
Even if App Engine isn't tremendously valuable now, it's a growth market, and easily monetizable. Google isn't going to burn a bunch of customers who could be - if they end up being the next Netflix - worth hundreds of thousands of dollars in recurring revenue.
I wish people would stop with the hyperbolic Google Reader stuff. Google's bread and butter are web ads, and they're a shrinking market. As Facebook can attest, mobile is hard to monetize, and it makes a lot of sense to focus on areas where people can just pay you directly. AWS has already validated this market, Google has the capacity to deliver, they've just fumbled the execution wildly.
Even if App Engine isn't tremendously valuable now, it's a growth market, and easily monetizable. Google isn't going to burn a bunch of customers who could be - if they end up being the next Netflix - worth hundreds of thousands of dollars in recurring revenue.
I wish people would stop with the hyperbolic Google Reader stuff. Google's bread and butter are web ads, and they're a shrinking market. As Facebook can attest, mobile is hard to monetize, and it makes a lot of sense to focus on areas where people can just pay you directly. AWS has already validated this market, Google has the capacity to deliver, they've just fumbled the execution wildly.
Totally agree on this. Reader was a free software. They may not be making billions out of App Engine but a lot of fortunate 500 are moving to this kind of platform and Google has probably invested tens of billions and thousands of engineers into GAE. No way they will kill this in the next 10 years unless market crashed.
That kind of cynical thought should be eliminated.
That kind of cynical thought should be eliminated.
>They may not be making billions out of App Engine but a lot of fortunate 500 are moving to this kind of platform
Not that many.
>and Google has probably invested tens of billions and thousands of engineers into GAE
If we're speculating, I'd say, far far less.
Except for the parts they use themselves too, anyway.
Not that many.
>and Google has probably invested tens of billions and thousands of engineers into GAE
If we're speculating, I'd say, far far less.
Except for the parts they use themselves too, anyway.
But reader was not used by 1000+ times as many people, quite the opposite. They namedropped vice which itself has far more daily readers than Google reader had. That's one customer, there are thousands of others that use app engine to serve billions of page views a day.
Stop wallowing over reader and move on.
Stop wallowing over reader and move on.
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...
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,
P.
(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,
P.
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?
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?
To tack on another argument: Google Maps. Google sharply increased the price of using the Maps API, then decreased it when developers started leaving for other alternatives, such as OpenStreetMap: http://techcrunch.com/2012/06/22/google-maps-api-gets-massiv...
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.
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.
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
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.
Free services are not guarnateed to remain open. Paid services can continue to live for a long time until market share shrinks so low. GAE can't. It has a deep root in the market.
I supposed, but would you risk your business by locking yourself in to their platform?
Peter Magnusson from the App Engine team recently wrote about the lock-in argument: http://venturebeat.com/2013/07/25/google-app-engine-lock-in-...
I recently discovered this project as a replacement if you're using Java on App Engine:
http://www.jboss.org/capedwarf
http://www.jboss.org/capedwarf
There is also https://github.com/AppScale/appscale
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
This leads me to believe that it won't be killed
Correct, heavily used internally. In fact I'll be talking about that at Cloud Connect in Chicago soon.
That, or drastically changing it's pricing.
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)
Which paid services have Google shut down?
Google Checkout.
Google Answers
That is the talking point of Google haters. Sounds like I am listening to Hannity on Hacker News.
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?
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).
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).
What is it that Google has with Jetbrains?
First they move their Android dev to intellij, now this...?
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.
In this case, though, it looks like Jetbrains wrote a plug-in for PHPStorm, and Google is just mentioning it as a good method.
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.
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.
One serious issue is caching gets. Those rack up your bills in no time unless you memcache stuff.
Interesting stuff though.
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...
eg. phpBB - http://fredsa.allen-sauer.com/2013/07/standing-up-phpbb-inst...
yes that's exactly the kind of thing I have been looking for! Many thanks
> you can't find forum software not implemented in PHP
Worth mention: http://www.discourse.org
Worth mention: http://www.discourse.org
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.
All modules use require_once... well, well...
And other many issues...
But looks as massive code. Maybe translated automatic.
> All modules use require_once... well, well...
Why on earth is that a problem?
Why on earth is that a problem?
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
[1]: http://php.net/manual/en/language.oop5.autoload.php
you mean spl_autoload
http://us.php.net/manual/en/function.spl-autoload.php
http://us.php.net/manual/en/function.spl-autoload.php
more refine answer: just use spl_autoload_register
yes its smell
without autoload its seems useless and as monster. Its seems as broken by design.
We don't use autoload because it's slow and doesn't work with APC. Not rocket science.
http://stackoverflow.com/questions/4788452/does-autoload-rea...
http://stackoverflow.com/questions/4788452/does-autoload-rea...
???
this is not argument - spl_autoload very fast its allow only one call to load module - all developers use spl_autoload
APC its legacy and crappy as opcache. I think its smell from Zend. They stop (in old time) because their close ware Zend Studio must sell. And other get pain from that legacy. Im sorry.
check here for start: http://talks.php.net/show/w2e09
APC its legacy and crappy as opcache. I think its smell from Zend. They stop (in old time) because their close ware Zend Studio must sell. And other get pain from that legacy. Im sorry.
check here for start: http://talks.php.net/show/w2e09
fixes:
more refine answer: just use spl_autoload_register
more refine answer: just use spl_autoload_register
needs for speed can be satisfied
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...
why not use something base of PEAR coding standards ?
public function foo($bar)
{
This can help: http://www.gnu.org/software/emacs/
http://pear.php.net/package/PHP_CodeSniffer/
and enable flymake php linting
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
Why you use multiple namespaces in single module? It is not good practise and smell. Official documentation don't recommend this.
Please work on supporting Ruby now.
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
and brainfuck
I would move my enterprise CRM package over to GAE as soon as this becomes a reality.
I assumed from the title that this would be about Google open-sourcing their PHP runtime.
long live php!
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.