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.
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.
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.
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?
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.
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?
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.
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.
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.
"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"
"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."
"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.
If you didn't expect a product that had wallowed in practical obscurity for several years with no updates (and no team working on it) to go away then you are a bit silly.
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.
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.
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.
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.
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.)
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...
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
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.
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)
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).
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.
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.
???
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.
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.