Earlier this year I was approached about writing a book on cloud computing topics by an editor for one of the big computer book publishers. Given that between my day job and having an infant I barely have time to keep this blog updated, I had to turn down the offer. However I did spend some time taking a second look at various cloud computing platforms like Amazon Web Services and Google App Engine then trying to put myself into the mindset of a potential customer as a way to figure out the target audience for the book. Below are the two categories of people I surmised would be interested in spending their hard earned cash on a book about cloud computing platforms

  1. Enterprise developers looking to cut costs of running their own IT infrastructure by porting existing apps or writing new apps. 
  2. Web developers looking to build new applications who are interested in leveraging a high performance infrastructure without having to build their own.

As I pondered this list it occurred to me that neither of these groups is well served by Google App Engine.

Given the current economy, an attractive thing to enterprises will be reducing the operating costs of their current internal applications as well as eliminating significant capital expenditure on new applications. The promise of cloud computing is that they can get both. The cloud computing vendor manages the cloud so you no longer need the ongoing expense of your own IT staff to maintain servers. You also don't need to make significant up-front payments to buy servers and software if you can pay as you go on someone else's cloud instead. Google App Engine fails the test as a way to port existing applications because it is a proprietary application platform that is incompatible with pre-existing application platforms. This same incompatibility rears its head when you look at App Engine simply as a way for enterprises to do new development. App Engine is based on Python, which if you look at the State of the Computer Book Market 2008, part 4 -- The Languages is not a terribly popular programming language. In today's world, enterprise development still means Java or .NET development which means enterprises will favor a platform where they can reuse their existing skills and technology expertise. Google App Engine isn't it.

So how about Web developers? In my classification, I broke up Web developers who'd be interested in cloud computing into hobbyists (like myself when writing a Twitter search engine on Windows Azure) and professionals (like myself when working on the platform that powers Hotmail's recently launched social features). Hobbyists either don't spend money or spend relatively little so I discounted them as a target audience of interest. The professional Web developers interested in cloud computing would be those who are considering Server or Web hosting but have concerns about scaling up if their service gets successful. After all, it seems like every week you are either reading about scaling hurdles that startup developers have faced as their applications become successful whether it is Bret Taylor's recent post How FriendFeed uses MySQL to store schema-less data or Jeff Atwood's Deadlocked! which talks about how he had to learn more about SQL Server's locking strategy as StackOverflow.com became more popular. The fact that Google App Engine is limited to only Python meaning that it is unavailable to developers using WISC platforms and only a subset of developers using LAMP can participate on the platform. Furthermore, there are key limitations in the platform that make it infeasible to build a full scale application. For example, Bret Taylor mentions that a consequence of having a denormalized database they need to run a background "Cleaner" process which fixes up data references and makes their database consistence. The App Engine DataStore API requires applications to store data in a denormalized way but there is no facility to run background processes to clean up the data as FriendFeed and most other large scale services which use database sharding often do. According to a recent blog post the Google App Engine roadmap has been updated so at least this limitation will be addressed. Other limitations for Python developers are that they can't use all of their existing knowledge of Python libraries since it only supports a subset of Python libraries. Database developers may be relieved that a lot of database management tasks no longer exist but may be chagrined once they see the restrictions on queries they can perform and hear some of the horror stories about query performance. At the end of the day, it just didn't seem to me that there were many professional Web developers who would put up with all of this pain over just going with AWS or dedicated hosting.

That said, Google App Engine does address the long tail of developers which I guess is nothing to sneeze at. Maybe it will see some success from targeting the low end in the same way that AdSense targeted the long tail of advertisers and is now the powerhouse of search advertising. Maybe. I doubt it though.

Note Now Playing: Aerosmith - Livin' On the Edge Note


 

Sunday, 01 March 2009 15:44:44 (GMT Standard Time, UTC+00:00)
Or maybe it is possible that the choice of Python as the App Engine ligua de jure is an ante up - a way to get the system out and and in production as a prelude to rolling out other languages. Some of the folks I have spoken to claim that Python is the preferred tinkerers language at Google, for tools and testing and such. I have no direct knowledge.

I would hope that Google would use its early experience with Python as App Engine's dev language to get the platform services ready for more popular systems, like Ruby or even some more esoteric ones that could benefit from the service.
Sunday, 01 March 2009 20:53:21 (GMT Standard Time, UTC+00:00)
I think (of hope, at least) that this is a situation where you have to take some things away in order to build up in a different way. I see a big opportunity for app developers to target App Engine.

I wouldn't knock Python too much at this point. It is a legit language that has avoided the Rails hype but is not as "sloppy" as PHP.
pwb
Sunday, 01 March 2009 22:12:25 (GMT Standard Time, UTC+00:00)
I agree with your thinking here. Like garbage collected code execution environments, scalable cloud computing systems abstract away infrastructure complexity that is not directly related to specific business algorithms and problems. Businesses can spend more time and devote more current resources to developing and fine tuning business problems that require distributed, scalable complexity (without concurrently working on the problems inherent in managing the distributing scalabe system). In this sense, the programming abstraction layer that interfaces with the cloud runtime should be language-independent. Development tool heterogeneity should be a central component in any successful (widely-adopted) scalable distributed cloud computing service.

C
Sunday, 01 March 2009 23:11:32 (GMT Standard Time, UTC+00:00)
The scaling hurdles you read about every week are written by folk working on the tiny minority of web applications that service huge audiences.

Developers on the other 99.9+% of web applications are far better off keeping things simple and spending their engineering time building things that people want.

Some practical advice on scaling:
http://www.mysqlperformanceblog.com/2009/03/01/kiss-kiss-kiss
Monday, 02 March 2009 03:08:13 (GMT Standard Time, UTC+00:00)
I am using AppEngine for more and more stuff. I did a little test project with it last Spring and liked it enough to try more. While I was not a big Python fan and BigTable felt very foreign at first, I am finding AppEngine gets rid of quite a few headaches.

Also, there is a facility to run "background jobs" now. Granted, they are run from a non-AppEngine computer, but the remote-api tools allow you to interact with your production data store as if the script was running directly on AppEngine. I am thinking about using EC2 to spin up instances to run background jobs as needed.
Monday, 02 March 2009 06:50:44 (GMT Standard Time, UTC+00:00)
In short, it is not wrong but slow. Furthermore, I don't think GAE aims at enterprise segment at least this time.
Monday, 02 March 2009 10:37:06 (GMT Standard Time, UTC+00:00)
I've written lots of intranet software and while I hate ROR I can't imagine running that kind of stuff on GAE.

Call me cynical but I always felt the ultimate purpose of GAE was to make the integration process for Google acquisitions a lot easier....
Tuesday, 03 March 2009 02:21:07 (GMT Standard Time, UTC+00:00)
IMHO, GAE is not a serious cloud computing play and won't be until they commit enough resources to whittle away much of the limitations and add more features. As it is now, I predict it'll be shutdown eventually. Still, it's useful enough to developers like me to tryout half-baked or one-off hacks and ideas.
Wednesday, 04 March 2009 11:58:18 (GMT Standard Time, UTC+00:00)
The only true way to force Google to reach further and become more aggressive with development is serious head to head competition. In the future there will be someone that aims at Google and brings it hard...
Saturday, 07 March 2009 20:08:28 (GMT Standard Time, UTC+00:00)
Not sure I agree with the accuracy of the statement that Python "is not a terribly popular programming language". According to the March 2009 Tiobe Programming Index, Python is more widely used that C# - http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
LFH
Comments are closed.