Tuesday, April 8th, 2008

What does Google App Engine mean for Ajax developers?

Category: Cloud, Google

<>p>

I have been really looking forward to seeing the Google App Engine launch, and get in the hands of developers. This is just a preview release, and I obviously would like to see more languages and frameworks above and beyond Python and what we have now. The non-Pythonistas will all be saying “what about [insert my language and framework]“. Slowly, slowly, catchy, monkey.

What is the Google App Engine?

Google App Engine lets you run your web applications on Google’s infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it’s ready to serve your users.

You can serve your app using a free domain name on the appspot.com domain, or use Google Apps to serve it from your own domain. You can share your application with the world, or limit access to members of your organization.

App Engine costs nothing to get started. Sign up for a free account, and you can develop and publish your application for the world to see, at no charge and with no obligation. A free account can use up to 500MB of persistent storage and enough CPU and bandwidth for about 5 million page views a month.

During the preview release of Google App Engine, only free accounts are available. In the near future, you will be able to purchase additional computing resources.

You have to understand the limitations, and the model that is being used. In my mind this is very different than other solutions like EC2/S3. There are very different use cases at work choosing between a low level (and hence very flexible!) provisioning system like EC2, and a deployment solution that gives you a sandbox to deploy applications. Google App Engine is a full stack.

The stack gives you access to Bigtable, which also means that you are not in the world of booting up MySQL. You do things “the Google way” and some people will like it, and some will not. That is fine!

What excites me about this, is that I often have a bunch of little applications that need a host. Sometimes it can be a pain to setup. Other times you would like to make the service public but don’t want people to go hog wild and give you bandwidth costs and contention for your other apps on your host. Now I have a simple place to put these little apps, and this is where Ajax comes in.

As we develop richer applications with more client side logic, and natural service separations, we can create these modules as Google App Engine apps that do one thing well. There will be a natural fit for applications built with GWT, Flex, and other rich component toolkits.

Google App Engine doesn’t give you something that you couldn’t do in an Ajax application, but it does give you a place to throw up these services in short order. This is one step on the way to the world of DEPLOY. There are other services with different tradeoffs, such as Heroku.

I would love to see JavaScript on the server as an option, but that is back to language wars….

Related Content:

  • Google opens up on App Engine
    Google App Engine product manager Mike Repass discusses competition with Microsoft Azure and Amazon AWS, along with Google's vision for its cloud...
  • Google updates Ajax tool
    Google Inc.'s release of the latest version of its Google Web Toolkit 1.4 for Ajax development is a "major upgrade to the company's open-source...
  • Java on Google App Engine requires different approach
    Google App Engine has risen up from Python to support the Java programming language. This and other cloud platforms are not a natural fit when it...
  • Helping Ajax developers prevent exploits
    Ajax security is increasingly important as attackers have set their sights on Ajax apps. Andrew van der Stock explained what risks developers need to...
  • Running a Web service on Google App Engine
    Google's App Engine for building Web applications in the cloud is beginning to support Java servlet-based Web services. It's still under development,...

Posted by Dion Almaer at 8:55 am
7 Comments

+++--
3.8 rating from 31 votes

7 Comments »

Comments feed TrackBack URI

These announcements are extremely interesting but as a non US-citizens working outside the US for non-US companies I’m very reluctant in storing sensitive data on US-based servers. I’m not alone, see http://www.scribd.com/doc/3697/Privacy-and-the-USA-Patriot-Act and http://www.theglobeandmail.com/servlet/story/RTGAM.20080324.wrgoogle24/BNStory/Technology/home
I quote three sentences from the latter document

Some other organizations are banning Google’s innovative tools outright to avoid the prospect of U.S. spooks combing through their data. [...] “If I were a business manager, I would want to be very careful about what kind of data I made accessible to U.S. law enforcement.” [...] Montreal security strategist Jeffrey Posluns says Google’s software suite may suit some small businesses because cost savings are significant. But he warns that the deciding factor should be the sensitivity of the organization’s information.

So, I find these services very interesting, but I probably won’t be allowed to use them for most real world applications. How about a Google or Amazon server farm outside the US jurisdiction?

Comment by pmontrasio — April 8, 2008

@pmontrasio, while you do have a point with privacy and security, I’d like to point out that: in the 21st century there’s no such thing as privacy and security on the network. You’d maybe like to contemplate your attitude towards information, when your livelyhood depends on secrecy and is connected to an internetworked network. I find that not having proprietary information is easier then worrying about privacy and security.

Comment by pyalot — April 8, 2008

This feels similar to Heroku and I really like where these apps are going. Instead of trying to do a kitchen sink approach and support everything these services are focusing on a niche market. On one hand it reduces their potential customer base by declaring for the customer what language, database and API’s are available. On the other hand there are still plenty of customers and by focusing on one environment they are able to make it really kick ass.

I’m not personally interested in Python but the Heroku does interest me as a Rails developer. Another developer may be more interested in Google App Engine since they might really dig Python. Neither is right or wrong. They are both just trying to capture difference niches in the marketplace.

Given the size of Google they may get greedy and try to capture other niches in the same system. I think this would be a mistake. Even if they got Ruby (or name your favorite system) running under Google App Engine it would always be a second-class citizen that is forced to do things the Python way (or Google’s version of the Python way) instead of the Rails way, or PHP way or Perl way (or whatever your favorite system is).

Comment by Eric Anderson — April 8, 2008

@pyalot: I understand your point and I agree with the spirit of what you write. Nevertheless there are people that can sue me if their data are not protected as the law of my (their?) country mandates. So I have no problem using Google’s servers to store and process the data of some people (US citizens for sure), but I can’t do the same for the data of people of other nationalities.

@Eric: I’m a RoR developer too and I really like Heroku. It suffers from the same problem as Google App Engine. The only way out I can think of is to let customers explicitly accept that all their data are public. That should give me a shield against being sued.

Finally, I’ll give Google App Engine a try. It’s not wise to ignore such a technology only because it’s (momentarily?) server from the wrong place.

Comment by pmontrasio — April 8, 2008

I’m not sure I would go so far as to say it only has limited use because of security concerns. It all depends on the requirements of the app.

If you are doing some financial data then yes you will want to host it on servers you control. But for most apps (e.g. Content Managements Systems, Tickets support system, CRMs) ultra-tight security and confidentiality is not a requirement. The security provided by services like Amazon, Google and Heroku is probably good enough. Even with possible intrusion by police and other government agents. In fact I would argue their security is higher than many systems people create for themselves.

Also using encryption on your data is always an option.

Just all depends on your needs but I would think for 90% or more of apps the security provided by Google and Amazon are good enough. For the other apps then yes look for other solutions.

Comment by Eric Anderson — April 8, 2008

Did you forget Aptana’s Jaxer (http://www.aptana.com/jaxer)?
It allows you to write Javascript for both client and server side and simply decided where to run it. It’s built on top of Gecko.

Comment by enzoaeneas — April 9, 2008

I was JUST telling a co-worker about Jaxer after he turned me on to this post. I agree. Though I am excited that Google is stepping into this arena…though I wish they’d come guns blazing and offer something to compete with EC2. I also think their demo was weak…A heavy handed use of Python for a simple guest book…. written in Textmate? Come on…Don’t tell me we evolved to this advanced state on the web to have such nice things like the Google App Engine only to turn around and use it to make something we had 15 years ago…

Comment by tomm — April 14, 2008

Leave a comment

You must be logged in to post a comment.