JavaOne Wrap Up

As usual JavaOne was a blur of grandiose general sessions, engaging technical talks, enlightening hallway conversations, and a few raucous parties. It was good to see that even though the economy kept away a few people that the tone of the conference was still vibrant. I heard through the grapevine that there were about 9 thousand at the conference this year. There were a few hints of uncertainly in the minds of some of us at the conference due to the impending purchase of Sun by Oracle. No one knows for certain if this is the last JavaOne. I don't think Oracle would kill the conference but others have commented on the practicality of hosting big conferences like JavaOne and how disruptive they can be. My money is on an Oracle World rollup of JavaOne. How this will affect the tone of the conference is anyone's guess.

My biggest surprise at the conference was how much JavaFX has improved since the last JavaOne. I had maligned the technology last year which is something I'm regretting this year. Sun has created a better runtime environment, components, and a compelling, visual, JavaFX development tool. Things seem to be gelling for JavaFX. It seems that Larry Ellison is a fan of the technology hinting that he'd like to see more of it in the OpenOffice.org suite and that it should replace AJAX as the way to do rich internet apps. I'm not so sure about that last bit but it seems that JavaFX did enter into the OpenOffice.org zeitgeist last December for interface prototyping. I was under the impression that Ellison was thinking bigger.

The most awkward moment was the departure of Jonathan Schwartz, who after his "walk down memory lane" bit at the opening keynote, introduced Scott McNealy, was thanked for his "stewardship", and then left the stage never to be seen again. That was followed by the most bittersweet as McNealy said his goodbyes and was given a standing ovation by the crowd.

The best general session is of course James Golslings' Toy Show where a year's worth of Java innovation, some with little or no commercial potential, is celebrated. I was mostly impressed by Neil Young's LincVolt project car. The LincVolt is a 6000 lbs, gas-electric hybrid but the gas motor isn't connected to the drive train. It is used only to charge the battery. Young is trying to show you can save the environment and still go in style. I love my Prius but driving down the road in an environmentally friendly 1959 convertible Lincoln Continental would be da' bomb. My other Toy Show favorite was the Mifos project which was created to provide open source tools to support micro finance. It's great to see someone working on things like this.

I was able to get up on stage a briefly this year. I was invited by the GlassFish team to come up and say a few words about our business and how we leverage GlassFish. It's a great product backed by a enthusiastic community. Many of our customers have been able to save tons of money without compromising functionality or stability. It will be interesting to see what Oracle does with this gem. Let's keep our fingers crossed. The GlassFish birds of a feather session was packed in spite of the fact that we were competing with the main "After Dark" party.

I'm not sure what will happen next year. I'd like to say I'll be back but I'm not sure there will be a JavaOne next year. Chris Melissinos, who did a standup job as the show's master of ceremonies, optimistically closed the conference by saying "see you next year at JavaOne".

Thoughts on Standard Cloud APIs (whatever that is)

Yesterday I attended a few cloud computing talks at the tail end of Community One. The first was on Cloud Storage which I found to be a fairly good survey of current "database" options for externally hosted systems or applications. The second was a session hosted by RedMonk on standardizing APIs for the cloud. It's this second session which has me thinking and the more I think about standardized APIs for cloud computing the more I don't think we need them, at least not for all things in the cloud. Standard APIs make no sense for the Platform as a Service and the Software as a Service players. I think what we need here is more innovation and support of multiple frameworks as opposed to standard APIs. That is standard APIs across these vendors. We need simpler interface implementations, more innovation, and some notion of application portability to some extent, e.g., it would be nice if writing Django or Java Servlet/JSP apps on App Engine didn't result in applications that couldn't run on standard app servers. Not that I think we are there today but moving your app on or off AppEngine does require some non-trivial effort. So maybe what we need here are implementation specifications or support for more seamless transitions between self-hosted and cloud hosted applications. Make it easier for me to use the standard frameworks I'm used to using or at least a large percentage of those frameworks. Users seem to be fixing things themselves in this regard. The app engine patch project allows users to run unmodified Django apps on app engine. Well mostly unmodified since the App Engine data persistence layer is clearly not a relational db. So do cross service APIs make sense. I don't think so. I don't want Amazon Web Services and Google App engine to have a standard API because I'm using them for different things.

What I believe we do want is for Sun, Amazon, and others who are selling me Infrastructure as a Service (IaaS) to implement some standard management interfaces and APIs for virtual cloud infrastructure. After all a system image, running instance, a network, a disk, or firewall all have common management "interfaces". This is where I probably want something like Sun's Cloud APIs. It makes much more sense to standardize this type of management. But I don't want it to stop there, and here is the challenge to the people who would specifies these APIs, I want those APIs to cut across my firewall. I'd like them to be able to manage my internal cloud as well, say my VMware or Xen infrastructure. That would allow me to seamlessly manage both internal and external cloud installations and might even let me migrate apps in and out of various external and internal cloud system infrastructure. It may even allow me to simplify getting extra capacity for my internal applications by firing up instances on an external cloud or at least it will allow me to use a single management tool/scripting language/console. As much as I'd like to think that IaaS providers would be willing to cooperate you only have to look at traditional system management to see that in the past common management frameworks have failed to materialize. Let's hope they can rise above that.

So let's let the PaaS/SaaS guys innovate. If you're worried about lock in then write and architect your app as you normally would and deploy on Amazon Web Services or Sun's cloud when it's live. Then let's engage IaaS providers and start to push them towards some kind of API standardization. As an alternative, maybe some smart people should write a nice adapter layer that speaks a standard API on one end and vendor specific APIs on the other. Not a bad idea.

Identity Management Roadshow

Looks like Sun is promoting the Identity Management Roadshow on their identity buzz blog. I'm on the dance card and will be speaking about customer deployment experiences. Stop by if you are interested and say hello.