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

September 15, 2011

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.
Advertisements

Why freemium pricing model for CRM / Online databases needs to change

October 13, 2010

The typical approach to pricing in the hosted web-apps space, particularly in the domain I am working on – which is CRM and Online-databases – is to have freemium plans with per-user pricing.

It is interesting to note that the average conversion rate in freemium apps is just 3%. That is, 3% of the users fund 97% of the other users who use the free versions.[1]

While there are a few service providers with seemingly generous “unlimited records”[2], I have seen web-apps offering generous free quotas to close shop/move away from this space, leaving their existing customers looking for alternatives and have also seen others reduce their quotas from something like 100,000 free records to just 1000 free records[3].

I believe such actions (leaving the market, or reducing quotas drastically) by service-providers, which can trigger strong reactions from users, are not something they would like doing. No one would like to piss-off their customers intentionally. The problem for these web-app service-providers is in trying to map the costs incurred – typically in terms of computing resources like CPU, bandwidth and storage, with the pricing model which is in terms of users and records. But to do this mapping is not an easy task, because it is not a simple function of the number of records and the number of users. Assuming a fixed set of users (pick any number between 2 to 5)..

Less records, less requests from users // least cost
Less records, more requests from users // moderate cost
More records, less requests from users // moderate cost
More records, more requests from users // highest cost

This is the simplest level. Next comes the number of write operations. This could be to add new records or to just keep updating existing records. So, for a given set of record limits and request limits…

Less read, less write operations // least cost
More read, less write operations // slightly higher cost
Less read, more write operations // considerably higher cost
More read, more write operations // highest cost

Trying to map it to a simple per-user, max-records based pricing is thus not an easy task. Just to be on the safer side, web-apps usually end up over-charging the least-cost users.

With iFreeTools CRM and Creator, we prefer to take a different approach, based on what really costs us money – the computing power, storage and bandwidth[4]. This means our free-version may not seem very much generous, but our paid-versions have substantially better value for money and also allow more user-accounts per application.

Also, our pricing plans are such that we don’t over-charge our paying customers to fund our free users. In a way, our free users pay for themselves – or so we believe – since our free plans our ad-supported. This enables us to provide generous quotas for our paid-users.

CPU based quotas are also planned to be incorporated, after which we plan to remove away the user-limits altogether and increase the record limits substantially. After all, it costs us just $0.15/GB/month (thank you Google App Engine).

Our pricing page is at http://crm.ifreetools.com/pricing

Do let us know what you think. You can also mail your thoughts to raj@sahasvat.com

Notes

[1] Freemium model – I am of the belief that freemium model works more favorably for vendors of installed-apps, where the only cost incurred for each freemium use was the download bandwidth. With hosted apps though, the computing resources for the free app users are to be provided by the service-provider, in the hope that they would turn into paid customers one day.

[2] “unlimited” quotas – I am really not sure how they can offer such a deal.. I guess they should have some limit which they do not say explicitly or their apps become unusable after some limit, that they know for sure it will not be a problem.

[3] reducing quotas from 100,000 to 1000 – of course, there was some backlash from existing user base, so they had to allow existing users remain with the old quotas, while restricting new ones.

[4] pricing based on costs incurred – Some may frown on the idea of pricing software based on the cost incurred, rather than on the value it brings to the business. Whether we like it or not, pricing of software tends to get lower and is most likely to reach a point where the software becomes just an add-on for the commodity platform services.


“How to become an expert in my core skill (say Java) ?”

June 2, 2010

“How to become an expert in my core skill (say Java) ?”, I was asked recently by someone eager to become one, obviously.

Had sent the following reply, based on my personal experience..

With respect to programming, first find a project that you believe is interesting to work on.

Then think about..
How to write less code to add new features ?
How to reduce existing source code ?
How can things be made faster ?
How can things be made easier to work with ?

Each one is a challenge, which once achieved will make you want more such challenges. And, after some time, you will find people calling you an expert.. but who cares.. that is just a side benefit… you would have enjoyed the process anyway.

Good luck.

From the reply to my mail,…

How much knowing the API matters ? say JAVA has something called “Reflection” which i don’t know until now. If there is a problem which can be solved using Reflection i can use it right ? without knowing it i will be re-inventing the wheel. How people get to know that this is already available with API itself no need to write any custom code.

In java i actually read some books like ***, *** materials etc but still i didn’t know that this exists.

Valid concern.

Here was my reply..

Once you are working on a specific challenge, you will start looking for solutions, discussing with people who you think are experts or in online forums and checking out open-source tools which can help you. You will invariably end up learning what is required to get it done.

You may even end up discovering better approaches involving newer techniques / APIs, while also learning about how it was done until now.

Regarding reinventing the wheel. Remember the goal is to write as little code as possible. So, you would avoid doing it and if in a rare case you end implementing it with little coding.. great !! Now, compare it with the existing code – when you discover that it exists – and learn if your code is good or may be, better.

Feel free to add to the discussion with your comments.

After more than 8 years in Java at an enterprise software co., I am now enjoying interesting challenges with Python over Google App Engine, for my startup. You may check out my work at iFreeTools CRM and iFreeTools Creator – an Online Database Application Builder. You can reach me at raj@sahasvat.com.


PageSpeed is good for your website

May 3, 2010

I was procrastinating on an important feature in Chennai Bus Routes and Suburban Trains Information website, contemplating numerous options on how to implement it, since I feared it can make me go over the free quota in my Google App Engine deployment.

The feature was to enable users to identify hopping/switching points to travel between localities which are not directly connected by MTC buses / suburban trains. This planned feature was going to be a bit resource intensive – either with CPU, if done dynamically or with storage-and-CPU if it is to be indexed and synced periodically for all possible travel combination. I decided to take the CPU route and go the indexing route later, if required.

But, Google Webmaster informed me that even without the planned feature I was already very slow compared to a majority of the websites out on the internet.

So, using PageSpeed, I looked for the culprits.

The issues, apart from loading of a CSS file with lot of unused styles and the loading of separate JS file – both served from my Google App Engine instance, was the loading of numerous third party javascript files and their dependents. These included files from StatCounter Analytics, Google Analytics, Google Adsense (for 3 ads), Google Maps and AddThis sharing widget.

So, I set about fixing the issues..

  • I first removed unused CSS and JS, reduced their size and embedded them within the web page – 2 lesser requests to the server and reduced bandwidth.
  • Enabled memcache of full web-pages – this was useful, because for each page being loaded, Mediapartners-Google,gzip(gfe),gzip(gfe) (Adsense) was making a request for the same page again within a few milliseconds.
  • Next, I removed AddThis and replaced it my own sharing code and icon with just Twitter, Facebook and Delicious links. This would mean limited sharing options and no sharing stats, but I felt it was OK.
  • Removed StatCounter code from the main pages (routes for locality and route details pages) – now on, it will not be possible to easily see the sequence of pages visited, for recent visitors.
  • Reduced the number of Google AdSense ads from a maximum of 3 per page to just 1 – possibly lesser revenue from ads.
  • Increased the expiration time for static resources to 40 days – when those resources are to be changed, I will have to rename them to serve the latest files.
  • Delayed initializing and loading Google Map images, until the route details are requested – much better experience on slower connections and less cluttered look initially.

As a result, the page loading time came down a lot. Google Webmaster was quick to identify the changes in Page loading time (which was now approximately 30% of the original value) and the Kilobytes downloaded per day came down to 25% of original values, though the Pages crawled per day had actually increased a little during this time, as shown in the image below..
MetroCommute.in Crawl Stats

While I also added a new “find hopping/switching-point” feature, which did increase the usefulness of the website, I believe the page speed alone was responsible for better traffic (approximately 50% higher now) after these changes..

MetroCommute.in Google Analytics Dashboard

The reduced number of Adsense ads per page, down from 3 to just 1 per page, currently has a negative effect on the ad revenue, but not on the same magnitude. I believe it will grow better again with increased traffic. Apart from coming up higher for popular keywords, now more people are searching for variations of “metrocommute”. Which means they remember and recall the name of the useful website, which they had visited sometime earlier. Better brand recall, can mean letting go of Adsense and possibly direct CPM ads related to local travel services.

Some other options I did not look into, for improving the page speed are : Asynchronous tracking in Google Analytics, which I may take up later and reducing the actual page size (stripping out spaces, etc.,) – because the typical web page size is already very small, not even big enough to trigger gzip on Google App Engine.

Hope this post encourages you to look into making your website faster. Feel free to share your tips as comments.

Maintaining MetroCommute.in is more of a fun-project for me, while I work on iFreeTools, offering a free CRM app and an Online Database Application Builder over Google App Engine. You can reach me at raj@sahasvat.com.


Grails to iFreeTools CRM

October 21, 2009

Had to gain some domain knowledge on CRM/SFA (Sales Force Automation) and provide a solution for a client, to host in their premises.

My client was not so interested in Python and preferred the use of Java for the solution, more so after knowing my past experience. So after more than a year into Python was back into Java, evaluating frameworks for use in the project.

The search lead me to Grails.

The “Convention over Configuration” and “Don’t repeat yourself” approach which Grails enables was a pleasure to work with. (Except, where I believed that grails was against the DRY principles – having to define “constraints”, even for the sake of maintaining the order of properties.)

But, it was a lot better than having to code XML configuration files. One could easily configure/code Servlet Mappings, Filters and Tags, without having to add/modify a single XML entry. And even better, one could get a compiled war (with all those XML files) and deploy it in any servlet container !!

In the next week or so, building a CRM/SFA prototype using Grails helped me pickup stuff from both the domains. And, the way in which Grails works, made me want to approach Python programming for Google AppEngine with the “Convention over Configuration” and “Don’t repeat yourself” approach.

Though Django enables such features, I was a bit biased against using the full pack, since that would require packaging a “lot of files” – so much that it exceeded the file limits of initial Google AppEngine hosting and needed a new feature (zip packaging) to enable those features. I am allergic to “lot of files”, especially if I will have to modify a few of them to have it working my way.

And with the meta programming features available in python, I believed that it could be easier to implement a simple version for my requirements.

The result of that effort is : iFreeTools CRM (Alpha)


Diagrammr allows you to type in your diagram with sentences

August 27, 2009

Just add sentences and to get a diagram.

The following was generated for relations typical within an NMS (Network Management System)..

webnms

The sentences used to build were…

WebNMS manages ManagedObjects
NetworkElements are ManagedObjects
Interfaces are ManagedObjects
Switches are NetworkElements
Routers are NetworkElements
NetworkElements contain one or more Interfaces
Printers are NetworkElements
WebNMS communicates using Protocol
SNMP is a Protocol
WMI is a Protocol
JMX is a Protocol
NetworkElements may run Services
Services are ManagedObjects
NetworkElements support Protocol

Good tool, this diagrammr !!


Upgraded to Reliance Netconnect Broadband+

August 3, 2009

From my slow speed Reliance Netconnect, which was used as a backup for the Hathway broadband connections at home and office, I upgraded to Reliance Netconnect Broadband+ last week. This was after Hathway went down because of issues with politically advantaged competitor.

Considering that it I have replaced 3 internet connections with one (2 Hathway and 1 Reliance old-gen wireless modem), this works out to be cheaper (even when ignoring the discounted rates applicable for the first year) for my requirements. But, now I don’t have a backup service provider.

Short Review ::

PLUS : There were no installation issues with the current device (unlike my previous Reliance modem) and has a faster startup & good connection speeds.

MINUS : Reliance wants me to visit their website (rcom.co.in) every time I connect the modem – irritating behavior. And, unlike previous versions, it is not possible to make calls or send SMS using this modem.