The need of the hour for Google App Engine : Better adoption and more paying customers

As a developer who is betting on GAE (Google App Engine), the increase in hosting costs due to the recent price changes in GAE came as a surprise to me, as it was to many others too.

Developers who had optimized for the earlier pricing model which focused on CPU based pricing had to now deal with the new pricing model based on instance based pricing. Google realized (a little very late, in my opinion) that its old pricing model was flawed and instances which were alive but not consuming CPU (typically waiting on I/O) were costing more.

So Google had to change the model to match their actual costs, by moving to an instance-based pricing model, which by the way, is also how most other PAAS/IAAS service-providers charge.

As one of the Google developers details in the Google Groups..

..the price changes are a reflection of certain key facts:

a. Google as a company backing the entire platform as a product… instead of being cancelled, we’re coming out of preview mode and become an official product! Google is not a non-profit company and cannot continue to operate services at a loss. our products, and my paycheck’s gotta come from *some*where! coming out of preview means Google is committed to App Engine, and in turn, we’re committed to our users.

b. this service costs the company significant resources… premium services like App Engine and YouTube require a lot of hardware and networking bandwidth. We serve more than 1.5 *billion* pages views a day across all applications!

But Google did listen to the feedback from the GAE developers and addressed their concerns by increasing the free quota from 24 instance-hours/day to 28 instance-hours/day, while extending the 50% discount for instance hours up to Dec 01, 2011, when multi-threading support for Python is likely to be rolled in. This is because, thread-safe applications can serve more requests per instance, which currently is not possible for Python developers, while Java developers already have multi-threading support.

So, coming to the main issue, to remain a sustainable service, Google App Engine needs to have better adoption and more paying customers. Or in simple terms, Google App Engine needs to make money. For this, the developers betting on Google App Engine need to build apps which can solve business needs and be able to sell those apps easily.

There are 2 options available for developers to sell apps built on Google App Engine.

First option is to build the app as a multi-tenant application — segmenting data and restricting access to that segment of data based on the user who accesses the app, a little hard for those not used to multi-tenant apps, but doable — and to charge customers based on tiered-plans, the easiest approach being user-based plans. But this model of charging based on users is so very out-dated and in my personal opinion, a bit unfair too, because resource usage (and hence the costs incurred) need not directly be based on number of users accessing the app.

And the current pricing model changes in Google App Engine further complicates pricing for multi-tenant apps, as there is no way to allocate more computing instances to say, a premium customer or to restrict instances for customers in a basic plan. Even when apps start to meter requests, it is hard to allocate resources in a fair way,  especially when having to deal with instances and latency.

That brings us to the second option, which is for the apps to be installed directly into the customer’s Google App Engine account, for which the customer can purchase hosting resources directly from Google. This option is possible even now, but involves a lot of manual steps — which involves the customers to sign up for Google App Engine, create an application instance, invite the developer who then has to disable code downloads and then upload the code to that application instance — and hence is not very scale-able.

The second option needs to be automated so that any customer can visit a Marketplace for Google App Engine applications, read reviews about the apps and when they like an app, can just click on an “Install Now” button, to have the app automatically installed within their Google App Engine account. This marketplace can also be seamlessly integrated with Google Apps Marketplace, making it easy to install the app as a service directly into the Google App Engine account associated to Google Apps for their domain.

There can be a trial period for such an installed app, after which customers can make a payment ($9/month minimum + additional usage charges) so as to continue using the app, of which Google pays the developer a percentage.

This has now been filed as a feature request :
http://code.google.com/p/googleappengine/issues/detail?id=5821

Below is a quick list of past threads in the developer forums, which have been requesting for a Marketplace for Google App Engine apps, in one form or other..

Clarification of Term 4.4

How to distribute my app?

Questions about the preferred way to handle multiple apps/accounts

‘Add It Now’ Functionality for my own Google App Engine Application

Distributing the same app to multiple domains

Per-domain data stores and selling our apps to people who use google domains…

Is it possible to sell a CMS hosted on Google App Engine without the code being visible ?

Deployment API

Multiple Instances of the Same App

Selling App Engine Apps

Isolated Application Deployment Instances

Creating a Windows desktop deployment utility ie. port of appcfg.py to C# client library

Automating deployment

source code encryption

deploying applicaiton to multiple customers 

1 application, multiple datastores

usage & billing and multiple deployment
 
 
This is just a quick list. There should be more such requests. But it is obvious that this is an important feature which can enable better adoption rates of the Google App Engine, helping both the Google folks building this wonderful platform and the developers who love working on it.
 
If you have not already done so, you can star this feature request: Marketplace for Google App Engine apps, to let Google know that you are interested too.
 
While you can be sure that the custom online database application builder that I am working on will be available on such a marketplace, you can start using it today at http://creator.ifreetools.com.
About these ads

2 Responses to The need of the hour for Google App Engine : Better adoption and more paying customers

  1. Freelancer Chn says:

    Hi raj I’m following your blog and came to know more about gapps from your blogs. I am planning to put an Google Application and i recently understood that GApps has released as SQL version. As i am planning to start now , what will be your recommendation on using SQL instead of NOSQL. How do you compare SQL with NOSQL?

    Is there any advantage in using SQL rather than NOSQL, general suggestions are use both appropriately when i am having my own storage, what would you recommend when i am going over GApps, is there any difference in performance / cost that I can get?

  2. rrajkumar says:

    BigTable datastore will seem to have a lot of restrictions when one looks at it, coming from the RDBMS world. But these are primarily to help scale the application.

    If the application..
    * is going to have a less data (10s of GBs)
    * wants to have data in normalized tables (preferring to use JOIN)
    * wants to make sophisticated queries for custom reporting (queries using GROUP BY, with aggregate function)

    .. then, the NoSQL approach can be difficult to work with and it is better to pay for and use the CloudSQL database.

    The pricing for CloudSQL service is not yet finalized, but cost for an app is not just about this pricing alone. One should also consider cost to implement a feature which is not supported by the database by default.

    But with Google App Engine applications you do not have to choose one over the other. You have the option of using them both, for different usage scenarios within the app.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: