Share this story

SAN FRANCISCO, CA—Google wants your applications and data on its servers. At the Google I/O conference today, Google's Cloud Platform team introduced new public services and tweaks to existing services based on the compute and data storage infrastructure that supports Google's search engine and other applications.

Urs Hölzle, Google's senior vice president of technical infrastructure, unveiled the changes during a developer session on the Google Cloud Platform. The change that got the most applause from the developer audience was the expansion of Google's App Engine service to support applications written in the PHP scripting language. Google's announcement that it would be opening up its Cloud Datastore to applications running anywhere—not just in Google's cloud—got love from the audience too.

All of the changes make Google's public services much more competitive and directly comparable to Amazon Web Services and other public cloud infrastructure providers, and open up Google's infrastructure to a much larger audience. With tight integration into Android development tools and the rest of Google's ecosystem, the services could help Google become more of a one-stop shop for mobile and web app developers.

Zero-administration PHP

The addition of PHP to App Engine, now in limited preview, means that Google can host Web applications like WordPress in its cloud and take advantage of App Engine's auto-scaling to respond to surges in traffic. It will make AppEngine somewhat more comparable (but not directly) to Amazon's PHP services on Elastic Beanstalk. Google will maintain the PHP environment itself, and the service can be bundled with Google's Cloud SQL, the company's implementation of MySQL (which is also available as a standalone service).

App Engine automatically associates Cloud SQL instances with applications when it ramps up new instances. That includes configuring the firewall settings to allow App Engine instances to communicate with the server while keeping out undesired connections without the need for administration.

The addition of PHP to App Engine could be bad news for many shared hosting services. Small PHP websites could be run virtually for free in Google's cloud without service level agreements—the Cloud SQL backend, while free until June, could cost a few dollars a month for low-volume sites.

Google is also offering a limited preview of AppEngine Servers, a way of modularizing applications that allows them to share a data store or in-memory cache, while permitting the modules themselves to be partitioned, deployed individually, and managed by their own scaling and performance rules.

Cloud Datastore can be connected to any application via an HTML interface, and is replicated across multiple Google data centers—ensuring high availability and guarding against data loss in the event of an outage at any given facility. Hölzle said that Cloud Datastore is based on BigTable, Google's proprietary data store used as the storage back-end for Google Apps and many other Google services. "It currently serves 4.5 trillion transactions per month," Hölzle said, "and now it can be used anywhere as a service."

While Cloud Datastore supports atomic transactions, has high availability for data reads and writes, and supports SQL-like queries through Google's GQL query language, it is similar to other highly distributed NoSQL data stores (like Amazon's Dynamo and Hadoop) in that it has "eventual" consistency—that is, changes are eventually spread through replication. However, it can be tuned to provide ACID support—making it suitable for Web-based transactional systems.

Compute on demand

Much of the news centered on Google's Compute Engine, a direct competitor to Amazon's EC2 service launched at last year's Google I/O. Previously restricted to a small set of Google partners, Compute Engine is now available to everyone. Along with that general availability, Google has introduced new "shared-core" instances of the Compute Engine virtual machine for developers and other small-volume users: "small" instances with 1.7 gigabytes of memory and "micro" instances with 0.6 GB.

Those and Google's other Compute Engine instances can be attached to persistent storage, just like Amazon's EC2 instances. However, Google has upped the size limit of persistent storage up to 10 terabytes—ten times the maximum available with EC2.

Hölzle also announced that Google now is supporting advanced routing features for Compute Engine—allowing for encrypted virtual private network connections between on-site systems and Compute Engine instances for "hybrid" cloud deployments. And while Compute Engine instances can be managed through a Web-based console, they can also be provisioned and managed automatically through a RESTful API.

One of the other changes made to Compute Engine was more financial than technical. Now billing for Compute Engine instances can be incremented by the minute rather than by the hour, with a minimum of ten minutes per instance. That, as Hölze said, allows users to get processes done faster—such as large MapReduce tasks—in less time for the same cost as running a single, long-running process.

The beta blues

Dislodging Amazon from its dominance in the cloud space will take more than introducing some incrementally better services—especially when it's not clear how long it will take for some of them to be widely available. For example, developers have been clamoring for the addition of PHP and modular deployments in App Engine, but both are only being offered on a limited basis for now, with no timetable for when they'll be ready for the masses.

What will drive the success or failure of Google's additions to its cloud platform will be how much better a job Google does of pulling developers into its orbit. And in that regard, it has an advantage in the mobile app space because of the ever-tightening integration of its cloud services with Android development tools.

As more app developers build for Android first, they'll find it easier and easier to stay in the warm, comforting embrace of the Google cloud as they move to other platforms. Or, at least, that's what Google is hoping for.

Share this story

Sean Gallagher
Sean is Ars Technica's IT and National Security Editor. A former Navy officer, systems administrator, and network systems integrator with 20 years of IT journalism experience, he lives and works in Baltimore, Maryland. Emailsean.gallagher@arstechnica.com//Twitter@thepacketrat

Getting WordPress running on Google App Engine will be no small feat even with PHP support.

WordPress stores all user-contributed media like images as files on disk, which GAE doesn't allow. So it would need a new media database table, a new image scaling and delivery service, and a new uploader.

The WordPress self-updater and theme/plugin installer wouldn't work at all and there'd be no way to make them work, for the same reason. GAE apps can't modify the filesystem. All updates will have to happen offline, uploaded through the GAE Launcher.

To run with decent performance the architecture would have to drastically change. WordPress, like most PHP apps, are designed to boot up fresh up for every request and then shut down afterwards, all because there's no way to keep an app running across multiple requests in Apache/mod_php. GAE instead is designed to load your app once then feed individual requests through it; that's a much more efficient system, but isn't what WordPress was made for. That'd be a major architecture change effecting an enormous portion of the codebase.

And lastly, there'd have to be a new caching system built that stores the cache in another database table instead of using on-disk files. WordPress really has to have a cache to avoid heavy CPU usage so if you don't have one installed you'll be wracking up GAE's usage fees very quickly.

Edit: Removed paragraph about MySQL as others have pointed out Google now supports SQL syntax with CloudSQL. It did say:

Quote:

WordPress is designed for MySQL and SQL queries are integrated deeply in its architecture (as well as almost all of the more useful plugins and many themes). GAE doesn't support SQL at all so all of that would need to be rewritten.

beebee: GAE both makes them money and gives them other peoples' data to store so they probably won't drop it -- though they might reduce the free tier if they end up spending money to host a ton ton of tiny apps. Google Reader had turned into a free RSS sync service for other better readers, so Google ended up getting no useful customer data and nowhere to shove their ads.

"As more app developers build for Android first, they'll find it easier and easier to stay in the warm, comforting embrace of the Google cloud as they move to other platforms. Or, at least, that's what Google is hoping for."

Getting WordPress running on Google App Engine will be no small feat even with PHP support. WordPress is designed for MySQL and SQL queries are integrated deeply in its architecture (as well as almost all of the more useful plugins and many themes). GAE doesn't support SQL at all so all of that would need to be rewritten.

Wordpress on AppEngine? Sounds sorta neat, but doesn't really solve the big issue which is keeping wordpress up to date with security patches. Performance and clouds are nice and all, but they're not as important when your site is hacked...

I switched to a third party managed wordpress hosting (WPEngine) for some of my sites a while ago and haven't looked back. It's not perfect, but it has a lot of the benefits of "the cloud", with having someone else worry about your automatic updates.

Google Reader had turned into a free RSS sync service for other better readers, so Google ended up getting no useful customer data and nowhere to shove their ads.

Most people used the Reader app, as a moment's search of online reactions will reveal, and several former team members confirmed that there was never a serious effort to monetize it. Any 10-year-old could integrate Adwords on a webpage – it's obvious that it was never part of their plan.

especially when it's not clear how long it will take for some of them to be widely available.

.... or how long Google will keep the service running if it doesn't prove popular. It turns it into a chicken-and-egg problem. It's not smart to depend, especially in any kind of serious way, on a Google service unless it's popular, but if everyone knows that, then very few people will sign up, dooming the service.

And if Google actually is serious about running this stuff no matter what, it's going to take several years for everyone to figure that out, years they could have spent using the service.

I dunno. At this point, I trust smaller companies a lot more than I trust Google. And that's true on multiple fronts, not just their tendency to abandon people. Admittedly, most of the time with Google, you're not actually the customer, but that doesn't mean their actions are any less disruptive.

Small companies where I'm actually the customer strike me as a much smarter way to go, on the whole.

Getting WordPress running on Google App Engine will be no small feat even with PHP support. WordPress is designed for MySQL and SQL queries are integrated deeply in its architecture (as well as almost all of the more useful plugins and many themes). GAE doesn't support SQL at all so all of that would need to be rewritten.

That's very wrong, and I'm surprised your post got so many upvotes and almost no downvotes. Tells me Ars readership knows very little about GAE capabilities. MySQL on GAE can be done in two ways:

1. Simply use Google Could SQL2. Run your own on top of a Compute Engine VM

So you have to rewrite very little. That said, I'd still recommend that your rewrite your app, because GAE gives you a much more manageable environment if you stick to everything but MySQL.

Getting WordPress running on Google App Engine will be no small feat even with PHP support. WordPress is designed for MySQL and SQL queries are integrated deeply in its architecture (as well as almost all of the more useful plugins and many themes). GAE doesn't support SQL at all so all of that would need to be rewritten.

WordPress stores all user-contributed media like images as files on disk, which GAE doesn't allow. So it would need a new media database table, a new image scaling and delivery service, and a new uploader.

The WordPress self-updater and theme/plugin installer wouldn't work at all and there'd be no way to make them work, for the same reason. GAE apps can't modify the filesystem. All updates will have to happen offline, uploaded through the GAE Launcher.

To run with decent performance the architecture would have to drastically change. WordPress, like most PHP apps, are designed to boot up fresh up for every request and then shut down afterwards, all because there's no way to keep an app running across multiple requests in Apache/mod_php. GAE instead is designed to load your app once then feed individual requests through it; that's a much more efficient system, but isn't what WordPress was made for. That'd be a major architecture change effecting an enormous portion of the codebase.

And lastly, there'd have to be a new caching system built that stores the cache in another database table instead of using on-disk files. WordPress really has to have a cache to avoid heavy CPU usage so if you don't have one installed you'll be wracking up GAE's usage fees very quickly.

Google has specifically called out WordPress as one of the apps they want to support in the blog post announcing PHP for App Engine : "We’re bringing one of the most popular web programming languages to App Engine so that you can run open source apps like Wordpress. " I'm assuming that there will be tuning done to their PHP environment to support that use case.

Getting WordPress running on Google App Engine will be no small feat even with PHP support.

This post is so full of misinformation.

How can you say Google App Engine "doesn't support SQL at all" when it's right there in the article that it does? Google Cloud SQL is MySQL, and all indicates it's going to be nicely integrated with PHP on App Engine (with transparent scaling and all that).

Also, just so you know, Java App Engine has an experimental API that emulates file system access by storing file data on the blobstore and hierarchy on the datastore. If the intent is making it easier to move PHP code to App Engine they'll do the same on PHP. You get better performance by using low level APIs for everything, but you don't have to.

Anyway, running WordPress was part of the announcement, and is on the docs, so it's going to happen.

As to the article, I'm surprised they didn't do Node.js first. PHP isn't something Google uses internally as far as I can tell. Javascript isn't something they use on the server-side either, but at least the implementation is under their control.

I'm also surprised the recent Socket API wasn't mentioned. No support for TCP or WebSockets servers, but cool none the way.

Getting WordPress running on Google App Engine will be no small feat even with PHP support.

This post is so full of misinformation.

How can you say Google App Engine "doesn't support SQL at all" when it's right there in the article that it does? Google Cloud SQL is MySQL, and all indicates it's going to be nicely integrated with PHP on App Engine (with transparent scaling and all that).

Also, just so you know, Java App Engine has an experimental API that emulates file system access by storing file data on the blobstore and hierarchy on the datastore. If the intent is making it easier to move PHP code to App Engine they'll do the same on PHP. You get better performance by using low level APIs for everything, but you don't have to.

Anyway, running WordPress was part of the announcement, and is on the docs, so it's going to happen.

As to the article, I'm surprised they didn't do Node.js first. PHP isn't something Google uses internally as far as I can tell. Javascript isn't something they use on the server-side either, but at least the implementation is under their control.

I'm also surprised the recent Socket API wasn't mentioned. No support for TCP or WebSockets servers, but cool none the way.

A lot of folks are looking at SignalR as it has fallback routines if you aren't running the latest and greatest browser.

And if Google actually is serious about running this stuff no matter what, it's going to take several years for everyone to figure that out, years they could have spent using the service.

It has been running for several years. It has been under a series of revisions. They've never dropped a feature that wasn't experimental. It's part of the agreement between you and Google that they won't without months notice. Backwards compatibility has been great. And there are customers who pay thousands of dollars every month to make it so.

Of course, there is the "what if google gets bored with this service and drops it" issue.

Or they feel the need to snoop at your data in order to gain insights into your business and target ads. There isn't an enterprise user on this planet that's ever going to trust Google. Especially when they can't run an MS workload like with EC2 or Azure.

Of course, there is the "what if google gets bored with this service and drops it" issue.

Or they feel the need to snoop at your data in order to gain insights into your business and target ads. There isn't an enterprise user on this planet that's ever going to trust Google. Especially when they can't run an MS workload like with EC2 or Azure.

I'm actually not very concerned with Google snooping around. The more troubling issue (and this is becoming more and more the case with any 3rd party hosting your data) is that the US government loves casting a very very wide net on their fishing expeditions. Because of this the 3rd party is put in a terrible position: Either risk their business by not cooperating with investigations they really don't have anything to do with, or comply and give out potentially damaging information their customers consider private. Either way, it stinks. And I doubt it will change any time soon, with the voting public clearly in favor of putting everyone under surveillance.

Interesting article Sean. While the Arstechnica audience is very technical and specific, I don't think this is a good platform for many Wordpress bloggers and as a traditional hosting company, we're not too worried.

Of course, there is the "what if google gets bored with this service and drops it" issue.

Or they feel the need to snoop at your data in order to gain insights into your business and target ads. There isn't an enterprise user on this planet that's ever going to trust Google. Especially when they can't run an MS workload like with EC2 or Azure.

I'm actually not very concerned with Google snooping around. The more troubling issue (and this is becoming more and more the case with any 3rd party hosting your data) is that the US government loves casting a very very wide net on their fishing expeditions. Because of this the 3rd party is put in a terrible position: Either risk their business by not cooperating with investigations they really don't have anything to do with, or comply and give out potentially damaging information their customers consider private. Either way, it stinks. And I doubt it will change any time soon, with the voting public clearly in favor of putting everyone under surveillance.

Fair point. I think however if you are an American company, they have the same level of access regardless of whether or not it's stored in the cloud. If you are European however you might expect that a German datacenter is untouchable by US authorities. If the laws continue the way they are the next big Cloud provider is going to end up being European, as the EU simply won't put up with it.

As someone who has been wrestling with GAE for a large game server, it is a terrible platform for static web content. The response times out of APP engine are in the 100s of ms at minimal load and we frequently see spikes up to a second or more.

As your request rate goes through its daily sin wave GAE does not react well to changing request rates. Its slow to react to increasing request rates and launches new servers as part of a user request, i.e. making requests wait while a server comes up. As request rates come down GAE re-shards its memcached array frequently invalidating all or most of your cached data leading to spikes in response time.

I wonder if all those hosting companies will keep spending millions of dollars in Adwords after this.

I said it before, they are just financing their own destruction. Because Google is literally after "everyone".

So know that Google competes directly as well against hosting companies and webmasters I wonder if what I said years ago will happen someday.

Who is going to keep advertising in Google if Google decides to leave every internet company out of business?

An terrible awful move from Google. They just want to own the Internet and everything single company or service that makes money on the Internet should watch out, because you are next.

Its clear what Google is trying to do for some many years. They want to be the Internet, they want you to use Google for hosting your data, Google for paying online, Google for selling online, Google for purchasing online, absolutely everything. It would not wonder me if Google tries to leave ISP out of business as well, controlling the connection from the user PC to the end server.

This will surely earn the hate of thousand of hosting companies and even more millions of webmasters that resell hosting or hosted services to their clients.

Hosting your data with Google? No thank you. Internet should be a huge ecosystems of companies, not of one single company.

I'm kinda finding myself growing tired of Google and other companies trying to be my "everything". Looking at Google in "this" instance, seems they are trying to dip into every aspect of computing/information services. We know how that worked out in the past with other companies.

Getting WordPress running on Google App Engine will be no small feat even with PHP support. WordPress is designed for MySQL and SQL queries are integrated deeply in its architecture (as well as almost all of the more useful plugins and many themes). GAE doesn't support SQL at all so all of that would need to be rewritten.

Oops you're right, so I edited my original post. Cloud SQL's new to me, it wasn't there the last time I built a GAE site and had to completely re-do the data storage to a No SQL model.

The other issues I mentioned will still be a big challenge to getting WordPress working unless Google also changes GAE to allow sites to modify their own filesystems and store media on disk. (Plus more dramatic changes to get it working efficiently.) Not impossible, but a big chunk of the code will still have to be rewritten.

It is amazing and wonderful to visit your site.Thanks for sharing this information,this is useful to me...<a href="https://www.besanttechnologies.com/training-courses/python-training-institute-in-pune">python training in pune</a> | <a href="https://www.besanttechnologies.com/training-courses/python-training-institute-in-chennai">python training institute in chennai</a> | <a href="https://www.besanttechnologies.com/training-courses/python-training-institute-in-bangalore">python training in Bangalore</a>