I woke up this morning to some of the best news I've heard in a while, it looks like there is some progress with putting Perl onto Google App Engine.
More from Brad Fitzpatrick. If you'd like to discuss this or help out, join the perl-appengine mailing list, and submit code to the appengine-perl project on Google Code. For more information see the Perl-on-AppEngine FAQ.
Maybe I won't have to learn Python after all...
Showing posts with label Web Services. Show all posts
Showing posts with label Web Services. Show all posts
Wednesday, July 23, 2008
Tuesday, April 08, 2008
Google App Engine
Over the last couple of weeks there have been rumours running around that Google would be launching something to directly compete with Amazon's AWS suite, and embed themselves even further into the Cloud. Sure enough, while I was asleep, Google announced a preview release of Google App Engine at Campfire One.
But what Google has done is take a totally different approach to Amazon. The Google App Engine is basically a platform for producing and deploying (robust and scalable) webservices, where as Amazon's offering is a more pick and mix affair with storage (S3) and compute (EC2) and databases (SimpleDB) being offered as components rather than being integrated into a single platform.
However, one of the reasons why Amazon's S3 storage service has taken off so rapidly is the fact that it can be viewed as a component, and startups (and much larger firms) can use it transparently. So long as you wrap the service sensibly, if Amazon went bust tomorrow (unlikely) or the service became unavailable or unreliable (slightly more likely, but still unlikely) you wouldn't have to rewrite your entire code base. You buy a whole bunch of servers, assuming you can afford it, rewrite the low level library that handles storage, and you're set. You still maintain control.
Google isn't offering as much control as Amazon, if you build your business on Google's platform you're relying on Google to support your business. It's an interesting choice from Google's point of view, and it'll be interesting to see whether people will bet on Google. It looks like a sure bet, but if I was investing a lot of money into a business I must admit that it would probably make me rather nervous to leave so much control in the hands of another company who of course have their own objectives.
It seems very clear that, unlike Amazon's EC2, the App Engine doesn't have the potential (at least in its current incarnation) to be a general computing platform, it seems to be specifically built to be request driven, and that's okay.
Google's choice of Python as its runtime is probably fairly predictable, when you work for Google you have to use one of the four allowed languages, at least for deployable code, those being C++, Java, Python or JavaScript. Of the four Python is the obvious choice...
While I'm not a Python person, my language of choice to get things done is Perl, due to circumstance I've actually had to write a bunch of Python before. So while I'm not a guru, I can get things done in Python, abet slowly, all the while muttering that I'd get it done faster if I was writing in Perl. So I've put myself into the wait list for a slot in the preview release. I'll let you know if get accepted before they open the doors properly, I guess it'll take a while though...
However the release of Google's App Engine does mean that I'm even more annoyed than I already was, which was fairly, that my travel budget won't quite stretch to a trip out to San Francisco for Google I/O. I've already had to shelf plans to head out for Where 2.0 due to the budget squeeze here in the UK, although since I've already been out to ETech this year and will be heading to OSCON in July maybe I shouldn't complain? My a Dopplr trips list is still looking fairly full after all...
Update: There is some good discussion of Google's new App Engine by Richard MacManus over at Read/Write Web and by Brady Forrest on the O'Reilly Radar, and TechCrunch have had a go at building and launching an application using the new framework.
Update: Guido van Rossum talking about Google App Engine at it's release via Robert Scoble (and QIK) in two parts...
I'd have loved to have seen Larry Wall doing one of his typical off the wall talks at the launch of Google App Engine with a Perl run time. But I guess you can't have everything...
Update: Show your support for Perl as the next language runtime to be added to the App Engine. Right now (10/Apr) this is the second most highly ranked support request, just behind support for urllib and urllib2 interfaces in Python. Surely we can do better than that?
Update: Well, so much for the lock in arguement (via Daring Fireball and the O'Reilly Radar)
But what Google has done is take a totally different approach to Amazon. The Google App Engine is basically a platform for producing and deploying (robust and scalable) webservices, where as Amazon's offering is a more pick and mix affair with storage (S3) and compute (EC2) and databases (SimpleDB) being offered as components rather than being integrated into a single platform.
However, one of the reasons why Amazon's S3 storage service has taken off so rapidly is the fact that it can be viewed as a component, and startups (and much larger firms) can use it transparently. So long as you wrap the service sensibly, if Amazon went bust tomorrow (unlikely) or the service became unavailable or unreliable (slightly more likely, but still unlikely) you wouldn't have to rewrite your entire code base. You buy a whole bunch of servers, assuming you can afford it, rewrite the low level library that handles storage, and you're set. You still maintain control.
Google isn't offering as much control as Amazon, if you build your business on Google's platform you're relying on Google to support your business. It's an interesting choice from Google's point of view, and it'll be interesting to see whether people will bet on Google. It looks like a sure bet, but if I was investing a lot of money into a business I must admit that it would probably make me rather nervous to leave so much control in the hands of another company who of course have their own objectives.
It seems very clear that, unlike Amazon's EC2, the App Engine doesn't have the potential (at least in its current incarnation) to be a general computing platform, it seems to be specifically built to be request driven, and that's okay.
Google's choice of Python as its runtime is probably fairly predictable, when you work for Google you have to use one of the four allowed languages, at least for deployable code, those being C++, Java, Python or JavaScript. Of the four Python is the obvious choice...
While I'm not a Python person, my language of choice to get things done is Perl, due to circumstance I've actually had to write a bunch of Python before. So while I'm not a guru, I can get things done in Python, abet slowly, all the while muttering that I'd get it done faster if I was writing in Perl. So I've put myself into the wait list for a slot in the preview release. I'll let you know if get accepted before they open the doors properly, I guess it'll take a while though...
However the release of Google's App Engine does mean that I'm even more annoyed than I already was, which was fairly, that my travel budget won't quite stretch to a trip out to San Francisco for Google I/O. I've already had to shelf plans to head out for Where 2.0 due to the budget squeeze here in the UK, although since I've already been out to ETech this year and will be heading to OSCON in July maybe I shouldn't complain? My a Dopplr trips list is still looking fairly full after all...
Update: There is some good discussion of Google's new App Engine by Richard MacManus over at Read/Write Web and by Brady Forrest on the O'Reilly Radar, and TechCrunch have had a go at building and launching an application using the new framework.
Update: Guido van Rossum talking about Google App Engine at it's release via Robert Scoble (and QIK) in two parts...
I'd have loved to have seen Larry Wall doing one of his typical off the wall talks at the launch of Google App Engine with a Perl run time. But I guess you can't have everything...
Update: Show your support for Perl as the next language runtime to be added to the App Engine. Right now (10/Apr) this is the second most highly ranked support request, just behind support for urllib and urllib2 interfaces in Python. Surely we can do better than that?
Update: Well, so much for the lock in arguement (via Daring Fireball and the O'Reilly Radar)
Thursday, July 26, 2007
OSCON: Ajax and Web Services
I'm in Mark Pruett's talk on Ajax and Web Services. He's defining an Ajax application as a web service client that runs inside a web browser, and he's going to be talking about both REST and SOAP services.
Mark Pruett's talk on Ajax and Web Services
Mark argues that people go through an evolutionary path in the way they use Ajax, they start off sending back a chunk of HTML, they move on to sending back delimited text, then XML and finally some people move to JSON.
There a bunch of client side Ajax toolkits: prototype, Dojo, GWT (Google), Atlas (Microsoft), Rico, Zimbra, DWR. Some of these, like GWT and DWR are tightly coupled with the server side language. You probably want to pick a toolkit that doesn't do that...
Update: He's talking about the whole SOAP vs REST debate, and arguing that externally you should expose your services via REST, but internally SOAP might be more appropriate, or at least more frequently used. Which isn't necessarily the same thing.
Update: REST uses GET, PUT, POST and DELETE. Where GET will get data, a PUT will create a new resource, POST will update an existing resource and DELETE will delete an existing service. Although of course there are certain limitations to GET which means that you sometimes have to use POST anyway.
Update: He's just totally dismissed synchronous REST requests, arguing that you should always use asynchronous requests. Which seems like a lot of overhead for simpler services. Although he's also arguing that you shouldn't bother with XML, but you should be using JSON instead, which means you can do this,
which I think is probably officially evil.
Update: He's moving on to talk about the cross-domain problems. This is something we've all run into before, because of course you can only do Ajax calls to the server that delivered the original page. One way around this, which actually hadn't occurred to me before, is to use Apache ProxyPass rules and redirect calls to other servers transparently to your client side Javascript.
Mark Pruett's talk on Ajax and Web Services
Mark argues that people go through an evolutionary path in the way they use Ajax, they start off sending back a chunk of HTML, they move on to sending back delimited text, then XML and finally some people move to JSON.
There a bunch of client side Ajax toolkits: prototype, Dojo, GWT (Google), Atlas (Microsoft), Rico, Zimbra, DWR. Some of these, like GWT and DWR are tightly coupled with the server side language. You probably want to pick a toolkit that doesn't do that...
Update: He's talking about the whole SOAP vs REST debate, and arguing that externally you should expose your services via REST, but internally SOAP might be more appropriate, or at least more frequently used. Which isn't necessarily the same thing.
Update: REST uses GET, PUT, POST and DELETE. Where GET will get data, a PUT will create a new resource, POST will update an existing resource and DELETE will delete an existing service. Although of course there are certain limitations to GET which means that you sometimes have to use POST anyway.
Update: He's just totally dismissed synchronous REST requests, arguing that you should always use asynchronous requests. Which seems like a lot of overhead for simpler services. Although he's also arguing that you shouldn't bother with XML, but you should be using JSON instead, which means you can do this,
var my_json;
my_json = eval ("(" + http_request.respinseText + ")");which I think is probably officially evil.
Update: He's moving on to talk about the cross-domain problems. This is something we've all run into before, because of course you can only do Ajax calls to the server that delivered the original page. One way around this, which actually hadn't occurred to me before, is to use Apache ProxyPass rules and redirect calls to other servers transparently to your client side Javascript.
Subscribe to:
Posts (Atom)