Tuesday, May 27, 2008

Google I/O Wishful Speculation

Unfortunately, I am not attending Google I/O this year, but that won't stop me from speculating on possible announcements that could come out of it. Google is second only to Apple in intensity of hype-generation, so it stands to reason that they would follow their example and use their developer conference as an excuse to drop some kind of bomb on all of us. Here's what I'd love to see, in no particular order:
  • Android hardware. I for one am getting very impatient to see some actual hardware running Android. With an all-but-certain 3G iPhone announcement coming out of Apple's WWDC in two weeks, Google could take this opportunity to zing 'em with one or several actual handsets or devices on display. I've been telling myself that I would hold out on getting a new phone until I see some units shipping with Android. I like the idea of Android better than the iPhone, the API is more open and arguably more capable all around. The reality, however, is that I'm so sick of my phone that I'll probably jump on the new iPhone when it arrives, unless Google wows me this week.
  • One or more new App Engine languages. A week ago I blogged about the possibility of Java being the next App Engine language. They could take this opportunity to prove me right ;) I'd also like to see a server-side JavaScript API like Aptana seems to be doing with Jaxer, (anybody using this? drop your thoughts on it below...), or something like Rhino on Rails. Ideally I'd like to see a Java and JavaScript rollout with GWT integration. Dare to dream...
  • Full App Engine rollout. They could use the developer's conference to end the limited beta that App Engine is currently in and open it up to all comers. I'd also like to see a fully flushed out pricing model instead of this free stuff with quotas. That will happen eventually I'm sure. Not sure if they're ready yet though.
Anybody else got some predictions? Anyone out there going? Looking forward to some good tweets coming out of Moscone tomorrow...

Tuesday, May 20, 2008

Java The Next App Engine Language?

When Google released App Engine, Pythonistas were thrilled to receive such high-profile publicity for their favorite language. They should be, since a lot of people are jumping into Python for the first time, (or the first serious time), because they want to work with App Engine. I think that's cool since Python is a great language, but even in this recent dynamic language renaissance for some reason has not received the same hype-factor as Ruby and RoR.

While a somewhat exotic choice on the surface, it was actually perfectly natural and understandable for Google to go with Python out of the gate. It has long been known that Google uses Python behind the scenes for a great many things, from managing the bazillions of servers and other in-house systems to the implementation of Google Code. I mean Guido works there... on App Engine. I'm sure having the language's creator on staff helped when architecting this thing.

It's not all about Python though. Google has said that they are going to be offering the service in other languages in the future, and those who have played with it know about the 'runtime' property in the app.yaml config file. The documentation states plainly that "Additional runtime environments and languages may be supported in the future."

So what's the next supported runtime gonna be? I have no idea, but if I'm going to speculate I think a good case could be made for Java.

At first blush, that seems pretty divergent from the way that the platform is setup right now. Another dynamic, scripty language with a *nix heritage like PHP, Ruby or Perl would be a much closer match as far as management characteristics in a hosted offering like this go. But Google has no history of using any of these languages, and are reported to be pretty averse to language proliferation in their systems.

Steve Yegge blogged recently about how you are only allowed to write C++, Java, Python and JavaScript code at Google. He went into even more detail here. So if Google is going to go with something other than these it would have to be the result of an explicit change in policy.

So minus said policy change, where does that leave us? I'm going to rule C++ out completely out of hand. I welcome comments that can convince me this is a plausible option. JavaScript? If they were going to do a server-side JavaScript thing the implementation would most likely be Rhino anyway, (for all we know the current App Engine is using Jython), so that brings us to Java.

So how reasonable would it be to offer a hosted Java environment? While almost any hosting provider currently gives you the option of running PHP, lots of 'em give you Perl, etc. virtually nobody except boutique hosting providers let you run Java. There's a good reason for this. First of all, Java is an enterprisey language and the apps that use Java on the server side are not especially well suited to run in a shared environment. Secondly, even if the market existed, there are technical limitations that make running Java in a shared resource pool problematic. While you can chroot PHP to prevent people from accessing the shared, underlying filesystem, with Java you can spawn threads and do lots of other things that make implementing resource consumption quotas problematic. The fact that you can't just run a Java program using an Apache module or through CGI, and the fact that there tends to be a mismatch in the skill sets that *nix ops people usually have and the skill set required to effectively manage a Java app just further muddies the waters.

What you would really need is a customizable JVM that let a hosting provider limit what hosted apps are allowed to do. You may be able to do this with a locked down SecurityManager, but doing the kinds of things that Google is doing with the App Engine Python implementation would be even better. Not very many people have the chops to write their own VM. Google is one of them, and oh yeah, they've already sorta done it. Twice.

GWT is interesting in that you write your applications in Java with certain elements of the API stripped out and the compiler translates your code to JavaScript. Android apps are written in Java with certain elements of the API stripped out and the compiler translate your code to run in Dalvik. Why not do something like this for App Engine and make it a trifecta?

Google is pouring a lot of resources into Java lately and in a public way. Guice is getting lots of attention lately as a Spring competitor.

So here's the prediction: The next App Engine language is going to be Java, but with a limited API, utilizing some kind of translation in the compiler and potentially running on something like Dalvik. They will offer a framework like they do with webapp in Python, but based on Guice.

You heard it here first...

Monday, May 12, 2008

A Few Things...

First off, I've been using Firefox 3 Beta 5 full time for the past several days and holy crap, they fixed everything. It's super fast and memory footprint appears stable, even with Gmail, Google Calendar and Reader running the whole time. I take back all the mean things I said before. It's true, the rest are but followers...

I finally got my Live Mesh invitation on Friday but had not had a chance to play with it until yesterday. It seems to work pretty well, and actually solves a problem for me keeping multiple copies of my photos directory on multiple computers, (which are both imported to from different cameras+phones), in sync without hairy rsync scripts and order-of-operations nightmares. According to the site you get 5GB of online storage. There is an option to not sync to the "Live Desktop" though, so I wonder if that just uses the central servers as a pass-through? Anyway, am interested to see how this platform evolves, when non-MS OSes and devices become supported, etc. I haven't tried Dropbox, but so far this service seems better since you can have multiple directories synced up in arbitrary locations, and even have the directories in different locations on the filesystems of the participating hosts. Neat.

Felix has an interesting take on recent PaaS developments. I commented there about the possibility of merging the AWS and App Engine approaches into a killer-PaaS-app. You could have an offering built on top of AWS, but offering a higher level of abstraction. This thing would still be lower-level than App Engine, in that you could do whatever you wanted to with your images, but would provide hooks into the "container" or whatever for persistence, messaging, etc. I think if you merged this idea of a super AWS-powered virtualization web framework with something like RightScale then you would really have something. Imagine a web app that was instrumented in such a way so that it could autonomously scale itself up and down in terms of number of instances it was running on, etc. The administration utilities would allow you to configure arbitrary rules for how large you would want to let the app grow, what metrics would be used, etc. I think building the hooks for this kind of instrumentation is key though since I don't think load average or something like it is enough in all cases. It would be sweet if there was an API allowing arbitrary exposure of app-specific measurements to factor into this scaling algorithm.

Don't know if RightScale has anything in there like this already. If it doesn't let's start a company and make millions...