Thoughts on Computing

Self-healing is at the core of much of what makes application fabrics work - whether you deploy on commodity in your own place or on a cloud.

It just has to be a non-event when stuff breaks - both for the work in progress, and for the "structural integrity" of the app fabric itself. Ensuring both enables the app fabric to provide the simple abstraction of a reliable, uber-scalable computing surface.

At any rate, I was reminded of this a couple of weeks ago when this video first made the rounds... cool stuff.

I particularly like it because it's a great illustration of the value of simple goals & simple organizational rules, both in theory & in practice.

Take a few minutes to watch it, if you have not already ... and ponder how cool it is when application developers can just assume that their underlying infrastructure behaves as resiliently as do these robot blocks.

Enjoy.

The video is courtesy of New Scientist, and the work is being done by Mark Yim and company, of modlab (the Modular Robotics Lab), at the University of Pennsylvania.

Great work guys ... keep it up!

I'll admit that when MarkSu first blogged about building a scalable Twitter / Twitter client about a year ago (he kept going with his second, third, and fourth posts) I just started laughing, because like Stephen Forte I just couldn't figure why anyone would care.

Then I started looking at it closer, drawn primarily out of curiosity about why they kept going whump. Of course, most of the early adopters are fairly vocal, so the commotion over these failures was ... well is high-volume.

After using twitter for a couple of weeks I think I mostly agree with Alex Miller on why he likes twittering.

I think the "rules of engagement" will morph quite a bit as usage grows, and I do think usage will grow. Only, like a growing number of folks I'm not sure there's any particular need for a centralized service, particularly one that isn't stable.

Maybe Twitter will fix it's scaling problems (very doable) and discover a revenue model, or maybe the whole idea of micro-blogging will go decentralized, or maybe some combination of both (which gets my vote for most probably outcome right now).

So MarkSu, I have to admit: you were right!

MarkSu also just bought a SmartCar (actually two - one that's pictured above and obviously already here, one on the way), but I really doubt that he'll get me to do one of those - but you never know!

I read Robert Scoble's post on "noise in the net" with morbid curiousity today. It's a pretty interesting post, really. Seriously.

Oh, the glorious noise! Everyone loves beating me up for causing the noise. No, I am not the cause. I pass it along. You should see my inbound streams. Every second or two a new Twitter is aimed at me. Every few seconds, a new blog post comes into Google Reader. Every few seconds, a new thing on FriendFeed.

Scoble then goes on to give a few ideas on how to get past the noise and make some sense out of it all. The suggestions are OK, but not really great. They're really more thoughtlets than anything useful.

Irony on 'Roids
Anyhow, do you want to know something really ironic? I was just about to remove him from my twitter "follow" list, precisely because the amount of noise and gunk that he's been generating has been enormous, and the value has been ... well, not enormous.

Sort of like the opposite of Dolby Noise Reduction ... but maybe worse. He not only passes along the noise, he adds more to it and injects back into the same stream, making it go from meta-stable to insanity inducing.

Sort of a human positive feedback loop. As in this excerpt (from the linked article)

A system in equilibrium in which there is positive feedback to any change in its current state is said to be in an unstable equilibrium ... the end result of a positive feedback is often amplifying and "explosive", i.e. a small perturbation results in big changes.

Uggh.

I know we're trying to figure out how this can all work, be helpful and all that, BUT ... is that really a good model for social communication? Then out of all that gunk he comes up with something interesting.

Maybe I'll wait until tomorrow to break the loop...

If you're at JavaOne this week make sure to stop by and check out the Appistry booth ... and register to win one of TWO MacBook Airs. I saw them at the office and it kind of bugged me, to tell you the truth, PARTICULARLY since I can't win one of them!

But you can, so stop by and good luck. The guys have some cool demos, & if you care at all about easy scaling, reliability & more on commodity infrastructure, you'll find it well worth your time.

EAF 3.8 beta on the Developer Portal
Also wanted to let folks know that we pushed a late-beta (very few known bugs) of Appistry EAF 3.8 to the developer's portal today. EAF 3.8 contains some cool new Spring support, as well as support for components, a cross-language and cross-platform feature which makes the fabric even easier to use in many more situations.

Of course, as with previous versions EAF 3.8 is available in the Community Edition, which makes it easy to use for problems that you care about.

Almost lost in all of the twittering about Twitter's twubbles last week (sorry CrazyBob, couldn't resist that one!), was the unintentionally quiet announcement of the "Spring Application Platform" (more official posts here and here from springsource).

Pros
An interesting post from Per Olesen (j2ee developer) highlighted these positives:

At a first glance, it looked to me as a lot like a server like the JBoss micro kernel architecture, which could (can) be tailored to only run the exact parts of JEE, that your application needs .. At a second glance, this is actually just a minor part ... they are also using it (OSGi) as the technology for deployment units for the applications running on it ... that is where I see some benefits

Billy Newport (IBM distinguished engineer and driver behind wXS ) thinks this is more or less inevitable:

It looks like what others and I have been planning/hoping to do over the next few years. Most of us are looking for an OGSi based distributed platform with a commercial friendly license (EPL, BSD or Apache)

I see this as the new JVM, a module or bundle oriented runtime that’s also distributed.

I think that probably represents the POV of many java vendors.

Cons
On the other hand, Billy wonders how long the additional work can be licensed (as opposed to being treated as OSS commodity):

Spring DM is Apache licensed, I can see the extra work in the Spring server being clean roomed and made available with EPL or Apache pretty soon and this will remove value from selling the SpringSource server<

Phil Zolo is concerned that this hurts the Spring framework itself:

The Spring Application Platform is the biggest announcement to come out of the Spring team for some time. It also looks like it could be a big mistake. Spring became popular in the first place as a practical, community driven solution to the real problems with Java enterprise applications, with a focus on simplicity. The latest offering seems to be moving in a rather different direction.

Of course, Marc Fleury (of jBoss fame) has some very pointed observations (more here)

Truth is, I care a little bit but not a lot. To me this is a VC driven move ... It is the same thing you had yesterday for free, except it is now under the GPL and a proprietary subscription license. I laugh.

Finally I am fuzzy on how this impacts their relationship with other app-servers. They are not neutral anymore.

That's basically the point (from another perspective) that Billy was making about the license. In any case, after an indirect interchange with Rod Johnson, Marc gets really lit up

Rod is wrong on a couple of things: I DO understand the technology enough to call it out for what it is "an emperor has no clothes" attempt to monetize his ISV base ... this is almost 10 years old. What is new is the licensing gimmick ... Your users are not dumb, they see right through this flat footed license change, don't get mad and patronize them when they call you out.

Ouch!

Final Thoughts
Leaving the personal animosity aside that seems to mix into springsource / jboss conversations, a few points are flowing here and elsewhere:

1. There's value here, but it'll eventually be done in a clean commodity version (for all, including ISVs).
2. Legitimate concern that the Spring framework itself will get stale
3. This still doesn't help with operations, nor does it do much for reliability (a post for another day)

It'll be interesting to see more community reaction at javaone.