When it comes to running custom apps in the cloud, there are basically two architectures. One involves an IaaS (Intel-as-a-Service) provider like Amazon with its Elastic Compute Cloud (EC2) where you load your own software stack onto Amazon's pay-as-you-go bare metal (virtual as it may be). The other is to develop your code to run on one of the platforms as a service (PaaS). One such PaaS is Salesforce.com's Force.com. Another is Google's App Engine, which had limitations on its usage because it was free. In this interview, App Engine Product Manager Pete Koomen discusses the business model for App Engine that Google announced yesterday.

Shortly after Google made the announcement on the App Engine blog, I asked Google if we could scramble together an interview to discuss the news. To hear the interview, just click the play button:

Interview with Google App Engine Product Manager Pete Koomen

The interview starts with Pete Koomen giving an overview of what Google App Engine is. According to Koomen, one of the primary goals of App Engine (as is the case with many cloud offerings) is to allow the customer (in this case developers) to focus on what's important to the business instead of having to focus on "database maintenance and server upkeep."

In my mind, App Engine is somewhere between what Salesforce.com offers with Force.com and what Amazon offers with EC2 (and it's storage service S3). In all three cases, customers don't have to worry about purchasing hardware or hiring the people to run it. With Amazon's EC2, customers get to decide what the software stack and resulting programmable platforms will be (e.g., Windows, Java, or a traditional LAMP stack). But they're all essentially Intel-based. With Force.com, customers are totally insulated from the underlying hardware and, instead, they write code in a Force.com-only language referred to as Apex. In between those two sits AppEngine. Like Force.com, customers have no say in the underlying stack and write their code to run on what is essentially a multitenant runtime. But like Amazon.com, the new business model is far more pay as you go (compared with Force.com's subscription model) and the stack is a bit more standard in that it supports the Python programming language.

Koomen was clear that additional language support is coming for App Engine when he said:

Until yesterday, according to Koomen, Google App Engine was free but there were restrictions. Essentially, an efficiently written application (one that didn't abuse some of App Engine's underlying resources) could serve up about 5 million pages per month before its quota would be exceeded and the application would effectively shut down.

Now, developers are free to exceed that quota at their own expense. The costs for the various resources are outlined as follows in the announcement blog post:

In the interview, I ask Koomen about whether Amazon's pay-as-you-go pricing for its services were an inspiration for this pricing. For example, Amazon's standard instance pricing for CPU time is .10 per CPU per hour for Linux/Unix. Likewise, incoming data is charged at .10 per gigabyte, but there are differences on the outbound side. Whereas Amazon has a sliding scale that starts at .17 per gigabyte for the first 10 TB of outbound data, Google charges a flat rate of .12 per gigabyte for outbound data. Koomen thinks the pricing is "competitive."

Amazon and Google are also alike in that, in terms of the services they offer, they've both eschewed traditional (and complex) relational database management systems (RDBMSes) for simpler database technology. Amazon calls its non-RDBMS service SimpleDB. To the extent that Amazon is an IaaS offering, though, customers are of course free to run an RDBMS like MySQL. In contrast, App Engine's database is based on a technology known as Big Table.

In the new business model, resources are currently assigned on a per-application basis, not on a per-customer or account basis. The distinction is important because a developer cannot have multiple applications running on App Engine in a way that all of them are natively accessing a single database. Instead, one gets to natively access the database and the others would have to work through Web-based RESTful interfaces that developers can use to expose the data. App Engine Python apps also are free to use Google's GData interface to access Google services such as Google Docs, Calendar, Spreadsheets, and YouTube.

In the big picture, this move is, of course, a baby step for Google's cloud computing portfolio. But this was an important card that Google had to eventually play if it wants enterprises to take App Engine seriously as a solution as opposed to a demonstration of technology. There are, of course, a great many Python developers out there. But the number of businesses that think "Python" when the time comes to code a new line of business application is relatively few compared with other platforms such as Java or PHP.

Koomen didn't mention what languages were at the top of his mind (I wish I'd asked). But both Java and PHP jump out at me as serious biggies that could open some floodgates. Should Google decide to support Java, that would put them in head-to-head competition with Sun, which plans to offer customers the ability to develop Java apps in the cloud (porting is widely considered to be too difficult because of how most Java deployments rely on proprietary extensions associated with whatever choice of JEE platform was made).

With thousands of PHP-based products already in the market, App Engine could technically become the infrastructure through which the developers of those applications make those apps available in the cloud. Entire Web sites built on PHP could theoretically move their operations onto App Engine.

But so far, it's impossible to say whether either language will be supported. Stay tuned. Whenever that announcement is made, I will look to have the follow-up podcast.

David Berlind is an editor-at-large with InformationWeek. David likes to write about emerging tech, new and social media, mobile tech, and things that go wrong. He can be reached at [email protected] and you can also find him on Twitter and other social networks (see the list below). David doesn't own any tech stocks. But, if he did, he'd probably buy some Salesforce.com and Amazon, given his belief in the principles of cloud computing and his hope that the stock market can't get much worse. Also, if you're an out-of-work IT professional or someone involved in the business of compliance, he wants to hear from you.

Twitter: (@dberlind)
My Facebook Page  (Facebook should have a namespace like Twitter, FriendFeed, and the others)
Flickr (davidberlind)
YouTube (TechWebTV)
FriendFeed (davidberlind)
Del.icio.us (dberlind )
Me on LinkedIn (LinkedIn should have a namespace as well)
Plaxo (davidberlind)
Disqus (DavidBerlind)