The API Playground will also become Google's official way to show Javascript samples.

The Playground runs on top of Google's App Engine, which is quickly becoming Google's preferred way of developing and releasing new products.

Ben Lisbakken, a Developer Programs engineer at Google, developed the API Playground as a "20% project." Google also made the source code for the API Playground available under the Apache 2.0 license.

Great for Learning

For students (or anybody who is trying to get his/her head around the basic concepts of using Google's APIs), this could be a great way to get some coding experience with almost immediate feedback and without having to learn the complexities of an IDE.

In this era everything is different - the stack, the players and the potential for value creation. Let's outline the basic shape of this emerging era, in particular defining what makes up the new stack.

At the Top - SaaS: these are the end user services that we actually interact with, such as Basecamp. This is the "final mile". This is what we used to call application software, vertical systems or value added systems. Although SaaS is sometimes also used to describe the layer below, we prefer to label the top as SaaS and the middle as Cloud Computing. Typically this layer has had thousands of companies. These are our bootstrapped Gritty Entrepreneurs.

In the Middle - Cloud Computing: this is the Cloud where we witness the "sound and fury" of BigCos battling it out - Amazon, Google, Microsoft, IBM and others. This layer is the most fluid and where all the deals are. This layer can be seen as two layers, but the difference is very blurry. Some SaaS companies create some "middleware" that they position in this layer. Some start-ups create middleware as their primary focus, with an end game of getting acquired by one of the Cloud BigCos. Over time, these will tend to get rolled up into a few big platforms that compete by providing higher levels of abstraction for developers.

At the Bottom - Core Technology: this is what we might call "traditional Silicon Valley", hard core patent-protected technology sold to big companies that use it as part of their stack. Arista, the latest venture from Andreas Bechtolsheim falls into this category.

Spectators And Players

Most of us are spectators in the Cloud Computing game. It is fun to watch the big guys duke it out and ReadWriteWeb will continue to report on that. Entrepreneurs need to understand the strategies of the big players who will be their "platform partner". But we all have lots of opportunities to be players at the top of the stack, in the SaaS layer. This is where there are low barriers to entry, massively reduced R&D costs and incumbents who will be slow to embrace SaaS for fear of cannibalizing their core business.

Has The Stack Value Inverted?

Traditionally, value was at the bottom of the stack, which is why Microsoft and Intel were so dominant in the past. With a few notable exceptions like SAP, the top of the stack tended to be smaller companies.

It is possible that this has inverted, that the real value is now at the top of the stack and not at the bottom. For example, Arista will probably be very successful, but their market will be limited to the few companies who build huge data centers. Those clients will place huge orders but will also have a lot of negotiating clout.

Lock-In And Network Effects?

So maybe the value is all in the middle now? This is certainly where all the action is today. The two big questions at this layer are:

1. Lock-in? How easy will it be to move your SaaS service between Amazon AWS, Google App Engine, Microsoft Azure and other contenders? Today there is quite a lot of technical lock-in, you cannot move from one to another without some re-coding. But is that a big deal? No, because a) any Platform that jacks up prices will get hammered by their competitors and b) when you do need to move, it may require some coding changes but the move is transparent to end users. So, very little lock-in.

2. Viral Network Effects? Market leaders will get a lower cost of sale, but there is no social media viral effect at the Cloud Computing Platform layer.

Without Lock-In or Viral Network Effects, this layer will be commoditized. It will be very, very big but it will be a thin margin commodity business that is all about scale.

So The SaaS Cream Floats To The Top?

This is our theory. The value is with the small SaaS companies in the "final mile" interacting with end users. This is what we are seeing with our bootstrapped Gritty Entrepreneurs.

What About Players Across Layers?

Next week I will be at Dreamforce, the Salesforce.com annual event in San Francisco. Salesforce.com is the SaaS pioneer that defined the market. At some stage they decided that being on the top layer only was not enough and they created their Force.com "platform" on which others could create applications.

IBM also operates at many layers of the stack. But they do so with separate divisions that would be large companies in their own right.

It will be interesting to see how this stack evolves and specifically how well Salesforce.com succeeds with their mission to operate at both the top and the middle layer.

Google Code Reviews

Google Code Reviews is, as the name implies, aimed at developers. It allows developers to share code for review and propose changes.

Google Moderator

Google Moderator is an application that Google first released for the App Engine just about a month ago. Moderator is basically a forum for group discussions and Q&A sessions, with the ability to vote questions and answers up and down.

Google Short Links

Short Links is a URL shortener like TinyURL or snurl, but works with your own domain name. This allows you to turn complicated and long URLs into short, more memorable ones.

More to Come

According to Google, these are just the first three in a long list of products that will make their debut in Labs for Google Apps. Google also intends to open this platform up to all App Engine developers, but it hasn't provided a timetable for this yet.

Now, we're tentatively raising our hopes once again. As VentureBeat reports, Jaiku is back after several days spent offline in a move to Google's datacenters as they continue their move to Google's App Engine service, the Google answer to Amazon's web services stack. In addition, there is now a brand-new TOS that existing users must accept upon login, which brings the original up to Google standards, presumably.

However, what's most exciting is that users now have unlimited invites to share with their friends, a step we hope is just the first of many in Jaiku's rebirth. Yet, as exciting as a Google Twitter-like service is, so much time has passed that Twitter has the market share and mindshare of those that want to participate in a micro-blogging community. Jaiku has a long battle ahead if they truly want to compete now.

• Pricing options for additional App Engine resources
• Two new App Engine APIs
• Opening up the waiting list

According to Pete and Paul, one of the largest feature requests for Google App Engine was the ability to purchase additional computing resources. If you aren't aware, currently App Engine (a developer tool that enables you to run your web applications on Google's infrastructure) provides free access to persistent storage of up to 500 MB and enough bandwidth for about 5 million page views a month.

Currently there is no ability for developers to purchase additional resources. But towards the end of the year, developers will be able to purchase more resources at the following pricing:

* $0.10 - $0.12 per CPU core-hour
* $0.15 - $0.18 per GB-month of storage
* $0.11 - $0.13 per GB outgoing bandwidth
* $0.09 - $0.11 per GB incoming bandwidth

This pricing does seem competitive with similar offerings from Amazon Web Services.

Two New APIs

The Google App Engine team is also releasing two new APIs. The first will allow web developers to easily do image manipulation - i.e. to scale, rotate, and crop images on the server. The second API allows App Engine applications to take advantage of memcached - a high-performance caching layer designed to make page rendering faster for developers.

Removing Waiting Lists

Another announcement tomorrow will be the elimination of all waiting lists for access to the App Engine. Paul and Pete indicated that currently about 75,000 users have received access. However more than 150,000 developers have joined the product's waiting list over the past 6 weeks alone! But on Wednesday, Google App Engine will be available to everyone.

However, note that until the turn of the year when you can purchase additional computing resources, apps will probably be limited to small test apps.

Still No Support for Languages Outside Python

While all of this is great progress, we're sure that many will be disappointed that App Engine is still limited to Python Apps. Shortly after launching Google App Engine, we created an interactive game that asked you to both predict what Google (and others) would do next and voice your opinion about what should happen. Not surprisingly, 55% of you anticipated Google would begin supporting other languages beyond Python.

It appears this is not going to be the case. While Pete and Paul indicated that this is on the roadmap, they wouldn't provide timelines or indications on which languages would be next. They did provide some insight however into the process necessary to support additional languages - listen to the podcast for those details.

Conclusion

As we commented yesterday, it's nice to see Google wooing web developers. If App Engine is ultimately successful, they'll need those engineers to choose it over Amazon's offerings or future competition from Microsoft and startups. It will be interesting to read the reaction to the announcements at I/O tomorrow. Let us know what you think in the comments below.

Web Apps

Google App Engine: History's Next Step or Monopolistic Boondoggle?

The big news this week was the launch of Google App Engine, "a developer tool that enables you to run your web applications on Google's infrastructure." This will allow startups to use Google's web servers, APIs, and other developer tools to build a web app on top of. Google clearly has the scale and smarts to provide this platform service to developers. However, it begs the question: why would a startup want to hand over that much control and dependence to a big Internet company? Check out Marshall's analysis.

A new feature at ReadWriteWeb is an interactive game helping you to understand and contextualize web tech news in a fun way. This week we posted, via a new app from Impact Games, an interactive game that will let you model Google App Engine's impact in the marketplace. You can play the game here.

Our other coverage: Google App Engine: Cloud Control to Major Tom; HuddleChat: Did Google Just Rip Off 37Signals? and Google Takes Down HuddleChat After Complaints About 37Signals Ripoff

Related: Red Dog: Microsoft's Answer to App Engine and AWS?

How to Get Customer Service via Twitter

There has been a lot of talk lately of companies monitoring social media, be it Twitter, blogs, or social networking sites, for mentions of their company name and responding to customer service issues. Some of this interaction has been in the Twitter community, with Comcast being one of the more active participants as of late. Although in some cases, customers twittered their frustration after failing to receive the support they needed through traditional methods, in many cases, Twitter was the first place the customers vented their frustration, and then were surprised when they received a response from a support rep or company spokesperson.

Related: 5 Ways to Find More Friends on Twitter and Twittermethis Is A Brilliant Marketing Experiment

Seven Tips for Making the Most of Your RSS Reader

RSS is a big deal, as anyone who's subscribed to even a few feeds probably knows. Once you get past just a few feeds, though, it can quickly get overwhelming. RSS can leave you feeling inadequate, brain-dead and uninspired. Trying out new things will help you discover new, magical experiences, though. Letting go of the stress caused by any obligation to read everything will go a long way.

Here are seven tips for making the most of your RSS reader, from simple to more complex.

SEE MORE WEB APPS COVERAGE IN OUR WEB APPS CATEGORY

Web Trends

How Important is Offline Access, Anyway?

In today's world, you're never too far from an internet connection. In developed countries, broadband access is available in more places than ever, and even poorer countries have internet cafes sprouting up left and right. Modern web workers and business travelers even take extra precautions to maintain always-on connectivity - packing air cards in their laptop bags or buying laptops that already have built-in EVDO access.

Despite the broad availability of internet access, it's the dead spots that have been pushing forward the need for offline access to web apps. For how can a web office suite like Google Docs or Zoho compete with desktop software if they become unusable when the internet connection disappears?

Why We Need Web Apps on the Desktop

Sarah Perez conclued in the above post that offline access is important now, but not as important as it once was. And that with the increasing ubiquity of Internet access, it is growing less important every day. However Josh Catone thinks there is an important distinction to be made between offline access to web apps (as Google Gears provides) and desktop access to web apps (as Mozilla's Prism and Adobe's AIR provide). The latter is a very important step in the evolution of web apps.

Where to Find Open Data on the Web

This week there was a story on Techmeme entitled "We Need a Wikipedia for data". The article, written by X-Googler Bret Taylor, discussed the difficulty of finding open data sets on the internet, something which could spur innovation, allowing programmers to build new applications the likes of which have never been seen before. What was interesting about this story, in addition to, obviously, the concept of a Data Wiki itself, was the amazing and insightful commentary around this concept, not just on the blog, but all over the net, something which led to the discovery of some pretty good data sources that are already available.

A Guide to Business Development 2.0

At least once each day I get a call from someone trying to sell me outsourced development services. It's difficult to not be frustrated with these calls and it is increasingly hard to be polite, because they come so frequently. Yet, more than frustrated, I am just puzzled. Does this tactic still work? Who in this day and age would give business based on a cold call? These companies could definitely use a dose of business development 2.0.

Related: Marketing 2.0: Can Meebo Make it Real?

SEE MORE WEB TRENDS COVERAGE IN OUR TRENDS CATEGORY

That's a wrap for another week! Enjoy your weekend everyone.

How it works: in this particular game you can choose to play the role of any of 4 different players: Google, Amazon, Microsoft, a Market Analyst. Then you can either predict what will happen, or voice your opinion about what should happen. Or both. If for example you choose to play as Google, you can predict that Google will open up the languages beyond Python. If you voice an opinion, you are guided by several "advisors" - in this case we have RWW, CNET and Dave Winer. The difference between predicting and voicing an opinion is that you may not necessarily agree with what you predict Google will do, so you can then cast your opinion about what you think Google ought to do!

This is the first in a series of games that we'll run over the next few months on ReadWriteWeb. If you have ideas for other games, please let us know in the comments below.

Disclosure: one of our writers, Sean Ammirati, is on the Impact Games advisory board.

"The App Engine team was looking for some sample apps to help kick the tires on their new system, so we invited Googlers to build some as side projects. A couple of our colleagues here built HuddleChat in their spare time because they wanted to share work within their team more easily and thought persistent web chat would do the trick. We've heard some complaints from the developer community, though, so rather than divert attention from Google App Engine itself, we thought it better to just take HuddleChat down."

It's all a storm in a teacup, because this was just supposed to be a demo app. It was built internally at Google after all, and wasn't meant to be an official Google product that competed with 37Signals' Campfire. Techcrunch's Michael Arrington claims that "this is the first case of censorship on the new Google App Engine platform, and a bad precedent." That's probably going too far, as this was something that was built by Google employees and so I think Google has the right to pull it - if they feel that it reflects badly on them.

More than that though, I'd suggest that Google just doesn't want the latest blogtroversy to get out of hand (as these things are wont to do). But have they given it a second wind instead? ;-)

As many people have noticed, the announcement just screams out for analysis in light of Nick Carr's new book The Big Switch.

Richard MacManus provided an overview of the announcement last night and John Musser at Programmable Web provides a good overview of the technical details. There's an official Google video intro on the right. Most interested developers have already jumped in and looked at as much as they are able to access, though - so now it's time to talk context and consequences.

Scalability

Services like App Engine may very well represent history's next logical layer of abstraction, taking several onerous obstacles off of the to-do list of application developers. That means developers can focus on other things and leverage greater resources than they may have had access to otherwise. Google-sized economies of scale can beat just about anyone on price and in theory it bodes well for uptime. The all-to-frequent downtime experienced by customers of Amazon Web Services begs the question of Service Level Agreements for the Google App Engine - and there doesn't appear to to be any right now. Let's presume that all of that is going to get worked out in time, though. As Carr points out in The Big Switch, the early days of commodified electricity were also filled with worry about safety and reliability. There was an economic imperative to solve those problems, and except for externalities like damage to river ecosystems, asthma from coal plants and nuclear toxification of Native American land, the problems of safety and reliability have been solved in for electricity. Those aren't off-topic matters, either, see Carr's own coverage of Google's new giant server farm here in Oregon, where they want cheap electricity from our rivers to power the apps in App Engine.

Carr says in his book that progress towards technological advancement is more an economic imperative than it is a psychosis or a choice. See the above externalities and ask yourself about psychosis, but point taken - things like commodified computing make so much economic sense that they are in all likelihood inescapable.

Data Portability

It's up to you to decide to use Google Accounts as user authentication in your App Engine app, or to write your own authentication code. Developers tell me that porting these apps out of App Engine should require as little as rewriting some data storage code and perhaps a few webservices - but I'm not hearing people complain about the system being to confining. That's great.

It's very, very important that there be no barriers to leaving App Engine and that the service retains customers based on price and superior service. Anything else, any lock-in, will drive a stake through the heart of innovation.

I expected to hear about OpenSocial support for App Engine, but haven't yet. Hopefully standards discussions have been underway for some time, but it appears that other than being written in a single coding language - Apps will be pretty free to come and go.

It's not ala Carte

Amazon Web Services lets developers pick and choose between a handful of different services, including data storage and processing. Many startups, for example, just use AWS storage and do processing on their own servers. Google App Engine is an all-or-nothing offering and that's a little bit creepy. There may have been factory owners in the early days of commodified electricity who wanted to keep some parts of that world in-house too, so perhaps Google's all-in-one offering will seem reasonable in the future.

Advertising

The fact that Google is now offering to power and host web apps, many of which are only ever monetized by AdSense, is...convenient, for Google. Will other ad networks be allowed on Google App Engine servers? That Google is ultimately in the business of advertising against content and now will sell you a printing press may be nothing more than fair, but it certainly raised concerns about monopolistic conglomerates.

Google's dominance of online advertising is so severe, and the umbrella for innovators that such dominance affords is so large, that it can't help but raise concerns about a single corporate allegiance running between so many development teams in leadership positions in the web 2.0 economy. Now the App Engine feels a little like the minor-leauges, or a place for innovative sharecroppers, all brought together by the Google Dollar and the resources it can provide.

Competing Services

Competition is good. Amazon Web Services already faced some competition from services like Longjump (our coverage), Nirvanix and other cloud computing services (see Larry Dignan's discussion yesterday). Adding Google to the mix could turn up the volume on competition for customer loyalty.

While Google App Engine is only being previewed right now, there's already some people asking wether comparing it to Amazon Web Services is a matter of apples and oranges.

Bret Taylor, the former Google App Engine Project Manager and now founder of red-hot startup FriendFeed, couches his questions in some very nice words about the project.

I am impressed. The App Engine team has done a fantastic job, and I think they have already changed the way I do hobby projects.

The next logical question is: would I run a real business on infrastructure that is so different than everyone else's? If I change my mind about App Engine, what are my options? I am hoping a number of open source projects spring up as alternatives to lower the switching costs over the next year. I will be very interested to see how many startups take the leap and run on App Engine entirely in the meantime.

Taylor posted about his experience testing out App Engine on a lightweight blog that he wrote on the platform itself.

Taylor isn't alone in saying that so far, Google App Engine is a relatively simplistic offering. There's a substantial number of people feeling unsure about Python being the only language being supported at launch, as well, though Google says that other languages will be supported in the future.

The point is, Google App Engine may be neither competitive nor monopolistic - it might just be trivial as Google Pages or Google Base.

So far it seems pretty simple and useful, though. We'll have to take a deep breath, hope that Amazon and others step up their offerings a notch or two in response, and see what the future brings.

In that respect Google App Engine is more like the so-called "Platform-as-a-Service" (PaaS) apps like Bungee Labs, which we profiled firstly in April 2007 and then more recently in February when it launched a new version. Other PaaS contenders include Salesforce.com's Force.com platform (nicely summarised by Dan Farber) and Morfik's Ajax platform.

Google App Engine launches as a closed Beta, with 10,000 developers granted access on a first come, first serve basis. It's free, but during the preview period applications are "limited to 500MB of storage, 200M megacycles of CPU per day, and 10GB bandwidth per day." It has a good set of initial features, which Google's Matt Cutts summarizes well:

"You can store your data in a Google Bigtable using the Google File System (GFS). There’s a bunch of App Engine APIs to simplify things like sending email and fetching urls. Your application can authenticate users that are using Google Accounts, so you can avoid the whole “ask your users to create a new account” issue if you want."

So it's a good start and you can imagine that this is just the beginning, as anyone who has read Nicholas Carr's excellent book The Big Switch will realise. Computing infrastructure is rapidly turning into a utility and Google App Engine is yet another example of this.

Why Would a Startup Want to Use Google App Engine?

There are many compelling reasons for startups to use Google App Engine; and Alex Iskold summed them up in his post Reaching for the Sky Through The Compute Clouds. Alex explained why the likes of Amazon, and now Google, are providing a valuable service to startups:

"We are witnessing a fundamental shift in our ability to compute and this is just the beginning. Amazon is at the forefront of making massively parallel, web scale compute services available to the world. Free from the need to solve the scalability problems, startups are able to focus on the specific problems that their product or service is trying to solve. All of this is happening while the cost of hardware, bandwidth and services overall keep dropping."
(emphasis mine)

However, there are a few downsides to the Google approach. For one thing, it means developers must use Python as their programming language - PHP and Ruby are two other popular languages today. But looking at the bigger picture, startups which use Google App Engine are essentially tying themselves into Google's technology. They'll need to host with Google, do their processing with Google, store their data with Google, etc. And as some people have already speculated, having a web app built and deployed with Google App Engine makes it much easier for Google to eventually acquire that web app.

It does make you wonder: would you want Google to control your entire end-to-end development environment? Isn't that what developers used to be afraid of Microsoft for?