Is Google App Engine successful?
The original title of this post was going to be "Why isn't Google App Engine successful?" You see, I've been frustrated of late at the lack of followup press about the PaaS offering since Google's announcement about it last April. I was beginning to think that no one but a few Facebook application providers were using it, which makes it kind of irrelevant for the enterprise.
Compare Google's coverage to that of Amazon Web Services. Since its announcement in July 2002, the various services contained under the AWS umbrella have received a steady stream of press and accolades. Much of that is due to marketing (and the phenomenal technology evangelism program Amazon put into place), but part of it is also that successful start-ups are passing on their own success stories independent of Amazon.
Two quick examples of this are SmugMug and Animoto. Both are stories that were originally broadcast by the customers themselves, and then evangalized by Amazon. Almost everyone in the "cloud-o-sphere" knows about these guys as a result. In fact, Animoto's story is the most prevalent case study of the value of elasticity in Web applications today.
So, where is the Google equivalent? I've heard about a few Facebook widgets being developed on App Engine (and that is sort of cool), but I certainly haven't heard any other type of start-up trumpet the importance of App Engine to their success. Furthermore, there are zero examples of non-Web businesses using App Engine to change the nature of their IT processes. (See Eli Lilly's story for an AWS counterpoint.)
So, all of this might lead you to believe I'm anti-App Engine, or at least not confident that it is important except as a PaaS example. And until yesterday, you would be right. However, I spent the day yesterday at the Cloud Connect conference, hosted at the Computer History Museum in Mountain View, Calif. Google was much more visible here (in part because they were a "platinum sponsor"), and perhaps more importantly, the "how to" sessions they hosted Wednesday afternoon were packed by interested developers and technologists.
Add to that a conversation I had with Dave Nielsen, one of the founders and organizers of Cloud Camp. He pointed out that Google's market is actually much smaller than Amazon's, being a targeted framework in a specific programming language. If you aren't building potentially large-scale Web applications, or "Big Table-friendly" data processing applications, Google won't work very well for you. So, there are far fewer App Engine customers available to trumpet their success to the market. Point taken.
Finally, Google used this conference to confirm that another programming language is coming to App Engine soon, though they refused to say which one. (The big money is betting on Java, as Google primarily uses Python, Java, and C/C++, the latter clearly being a poor candidate for a PaaS offering.) They must be making that investment for a reason, especially in light of Google killing off other services in the past few weeks.
I'd like to see Google work with their customers to market any successes on App Engine more aggressively, perhaps even finding an Animoto or New York Times-quality case study of how the platform performed in a way that would have been impossible without it. Give me a reason to believe that App Engine will change the world.
Help me out here. Is Google App Engine a success, and why?
James Urquhart is a seasoned field technologist with almost 20 years of experience in distributed systems development and deployment, focusing on service-oriented architectures, cloud computing, and virtualization. James is currently market manager for the Data Center 3.0 strategy at Cisco Systems, though the opinions expressed here are strictly his own. He is a member of the CNET Blog Network and is not an employee of CNET. 
Would you please correct the spelling of Eli Lilly from ELY LILLY to Eli Lilly at the end of the fourth paragraph of the article.
Best Regards
This is requiring a distinct change in the mindset of developers to figure out how to build web applications, which is why AppEngine has a much slower growth curve than AWS. Amazon's offering allows people to do what they've always done, where as AppEngine requires a complete re-engineering.
Going forward we will see new services launched on AppEngine, especially during this moribund economy, specifically because AppEngine is free to develop on. Those of us with an idea, time, and talent, can build out a web app without any need for startup cash.
My app was a small app, so it may not have even been appropriate for Google App Engine, according to this article.
I think the idea behind Google App Engine is great; allowing people to write apps and simply unload them to Google to deploy them. Correct me if I am wrong, but with Amazon one needs to setup an Amazon Machine Image, which seems involved. This may be good (for enterprise clients) to get existing apps and processes into the cloud, but the idea of simply coding an app and then uploading it to Google to deploy seems a lot simpler for new app development.
Google could help itself by providing additional language support, like Java and C#, or the other languages offered by Amazon. That said, Python is a great language.
Finally, why doesn't the author write more articles about Google App Engine, if he thinks news about it is lacking? An interesting piece, otherwise.
First, the benefit of a PaaS is componentisation of lower order systems and hence an overall increase in business agility. With a well formed PaaS, you don't need to be concerned about infrastructure, building and configuring of messaging subsystems, storage subsystems, databases or object stores. This should be provided.
To give an example of its impact, back in the days of Zimki, one of my development team designed built and released a wiki with client side preview in around 30 mins. Componentisation can lead to orders of magnitude in acceleration of development speed. You don't get this with standard Web hosting.
As for the open question ...
Well, the provision of the various layers of the computing stack as a service is only viable if that activity is fairly ubiquitous, well defined and considered to be little more than a cost of doing business. The earliest successful examples of this are in hosting providers (often providing little more than a standard box or rack with power, aircon and networks). Some of the least successful attempts were in the early ASP days where providers aimed to offer applications which were not that ubiquitous (and hence well defined).
This transition from products to services has been occurring over the last decade and "cloud" is simply the latest manifestation of this trend. However, this latest trend represents a full bloodied shift from products to services of multiple layers of the computing stack. It is only viable because those activities ,from CRM to Infrastructure, are so ubiquitous that they can be defined clearly and provide little or no strategic advantage to business. They are simply a necessary operating expense and the activities are little more than commodity-like.
But as with any outsourcing arrangement, the issue of second souring (which covers choice in providers, competitive pricing, strategic control and reduction of lock-in) is of strategic importance.
In a service world, competition should be on price and quality of service rather than product differentiation. We should have the ability to switch easily between providers (what you once called software fluidity). Unfortunately this is not the case with many examples today, and it is why adoption barriers remain so high and concerns are raised over lock-in.
Until markets form and second sourcing becomes viable, this state of affairs will continue to cause problems.
The simple solution has always been open sourced standards (or what we now call open sourced reference models). Eventually we should see a world of providers competing on price vs QoS for the provision of standard services at all levels of the computing stack, with those standards being defined by open source reference models. There will also be a role for proprietary technology in niche areas and in terms of performance improvement over a standard, but on the whole defacto open sourced standard will rule the day.
I commented on this previously when Google AppEngine was launched, see http://blog.gardeviance.org/2008/04/run-rabbit-run-rabbit-run-run-run.html
The problem with Google AppEngine is that whilst they attempted to create an open sourced standard in the the open SDK (i.e it was the reference model and AppEngine was just Google's implementation of it) , adoption has been slow.
The reason for this, I raised in an earlier post (see http://blog.gardeviance.org/2008/04/every-journey-begins.html). In my opinion, the open SDK is not a fully fledged system. Had they released an open SDK which you could build a serious system against and run on your own infrastructure, then adoption would have been higher. In my view this was a tactical error.
As for the next language. Well, the most interesting choice would be JavaScript, but let's wait and see.
To your question:
At Ringful.com we find both GAE and AWS useful for particular sets of tasks.
For example AWS hosts our core Java code that requires near real time control for telephony services.
GAE on the other hand proves to be very useful for quickly prototyping front end applications. In our experience it is not just Google marketing fluff that GAE pushes front ends apps globally. Response time from Asia and Europe is just as good as US. It was a great relief to realize that once we push the code to GAE, we don't need to worry about international access response times.
Another example where GAE proved useful is Web Services front end proxy. We rely on GAE for security aspects such as firewall against DoS attacks, authentication, and authorization. This allows our core servers to focus on the computationally intensive, time sensitive call control and media processing services.
Ringful Team
I recently wrote about my thoughts on this in my blog post, Is Google App Engine Ready for Prime Time?
http://www.sachinrekhi.com/blog/2009/01/02/is-google-app-engine-ready
Thanks for that link. The post is excellent; very informative for those of us without the time to really dig into App Engine technically. I highly recommend that others read it.
James
http://manidoraisamy.blogspot.com/2009/01/who-are-competitors-for-gae.html
<a href="http://manidoraisamy.blogspot.com/2009/01/who-are-competitors-for-gae.html">http://manidoraisamy.blogspot.com/2009/01/who-are-competitors-for-gae.html</a>
http://www.bestwebproxy.net
- by Sekhar-Ravinutala February 24, 2009 12:36 PM PST
- Also, GAE is still in beta, so there's hesitation on launching a production site on it vs. on EC2. This includes concerns on QoS and limitations, like with CPU and file use. I have a site (http://www.allurefx.com) on GAE and used to occasionally get CPU usage warnings for even light usage. They've recently upped the limits however - e.g., file size increased from 1MB 10MB.
- Like this Reply to this comment
-
-
- by Sekhar-Ravinutala February 24, 2009 1:03 PM PST
- What a coincidence, saw this flash right after I posted: Google has introduced paid quotas to handle usage beyond the free limits - see http://cli.gs/95HygM. This is big news, and hopefully it will attract more to launch production sites on GAE.
- Like this
-
(18 Comments)Overall, my experience with GAE has been great. It's really easy to set up, develop, and upload/sync. I was new to Python too, but it's surprisingly easy to learn - a cinch for say Java/C# developers IMO. The performance is great as well (globally too - e.g., really fast responses in Asia), and as already pointed out, it's free to get started as well.