thoughts on computing

A couple of weeks ago I was talking with a group of (primarily) engineering students about how our need for scale is forcing all sorts of changes in our industry … some technological, some economic, some social / cultural, and so on.

As engineers the temptation is to focus on the technological changes, which is good so far as it goes … but there is so much more.

For example, think about the differences between the first bubble and now. For my money the single biggest difference is that now there are some pretty successful economic models in place … ways to monetize crowds, to actually reward investors for taking risk to build an enterprise.

Of course, because of the ability to monetize a crowd, it becomes necessary to serve the crowd … and these crowds are (hopefully) instant mobs, seething, roiling, exploding and demanding more … all the time.

Good.

In that climate there are many businesses that can be built, fortunes made, technology consumed … always a good thing for those of us who enable reliable, cheap scale!

A Curious Imbroglio
What to make of this sort-of three-way argument between Nicholas Carr, Michael Arrington, and Billy Bragg?

The recent sale of Bebo.com for the better part of a gazilion dollars / euros occasioned an opinion piece by Bragg that makes a pretty reasonable case that much of Bebo’s value came from the content provided by musicians. You may be thinking “duh … that’s why it’s called user-generated content”. I’m sure that Michael Birch (a Bebo founder) would contend that he delivered plenty of value to the musicians by providing them exposure, and besides nobody forced any particular musician to upload their stuff on bebo.

True enough.

Michael Arrington then posted a mostly-reasonable, albeit coldly analytical dismemberment of Bragg’s piece. Better than the post itself, is a lengthy and at times entertaining comment thread that continued to argument for awhile. In any case, Arrington’s basic case is something like “that’s just the way the world is now, so deal with it”.

Except that as Nicholas Carr observes Arrington’s whole argument revolves around one central idea:

Recorded music is nothing but marketing material to drive awareness of an artist.

Which is one way to view the world … the world as pure commerce. But doesn’t that seem to be a bit impoverished?

Maybe that’s inevitable when you’re commercializing your words by the pound … so to speak. Not much time to craft a particularly artful post, just barf and run. While that’s probably too harsh, I doubt if anybody who blogs thinks that some future readers will be considering the merits of any particular post forty or fifty years from now.

A week would be pretty good staying power for most posts, two weeks awesome, a month the stuff of legend.

But music is different in this regard … by a lot.

My Take
That the creation and distribution models for all sorts of content are in complete flux is obvious enough … all the economic rules are changing, and in that change is real opportunity.

The music biz is just one example, but it is instructive.

Furthermore, the rapid technological change driven by the rapid commoditization and corresponding ubiquitous nature of computing, bandwidth, and consequently reliable software is adding mega-fuel to this fire.

All of this is good … even very good, but there’s much more.

That this new world (even in the transitional state that we’re in) will provide tons of opportunity is clear enough. I first realized this seven or eight years ago when one of my sons, who was in a jazz-performance program at the time, pointed out that all of his professors (all working jazz musicians) were big proponents of the music-sharing sites.

Why?

They universally hated the labels and the rest of the music distribution business, and were so taken by the opportunity for new avenues to expose people to what they did that they were happy to overlook some rough spots.

Better to be “ripped off” by individual people in the short run … after all, they might become fans someday (even attend a gig and perhaps actually buy some music … presciently agreeing with one of Arrington’s contentions!), than by a label who would be very happy to kill your career if you ever got out of line.

So new economic models, new technological means to create the art, distribute it, even to scratch out a living (or hopefully do even a bit better than that) at the same time … all of those are certainly upon us. Good enough as far as it goes …

But none of that changes the meaning of beauty, of truth … thankfully those have meaning that transcend our economic maelstrom.

I for one, am glad of it.

In this post at gigaom Stacey H. reports on the Scalability Boot Camp Panel (organized by Blaine Cook of Twitter) at South by Southwest.

Most of the comments seemed pretty typical, but one in particular jumped out at me:

ll the talk about failure led to a discussion about how scalability problems hurt or enhance a company’s reputation …

Cook said the press mentions of Twitter’s downtime as a plus, but the irritated users were obviously a minus. (emphasis mine)

NO KIDDING!

Out of curiosity I looked up Blaine Cook’s description at SXSW:

Blaine Cook is the Architect at Twitter. He is currently building and maintaining Twitter’s real-time backend infrastructure that tracks and distributes millions of updates every day to users on the Web, instant messaging, and SMS.

<rant>
Honestly, how naive is this? What kind of sustainable business is built on irritating customers? (and here I mean an actual business, not some mandated thing like the inevitably dreary offices where most of us end up to license our cars etc. )

This is simply bad business.

The worst part? It’s entirely unnecessary … perhaps even negligent to build an infrastructure that is predictably going to go whump every once in awhile, when your customers (and you) least expect it.
</rant>

Blaine, I realize that Twitter’s scaling and reliability problems have been well-publicized, and that you might just be making the best out of a bad situation, BUT all kidding aside … you really should give us a call.

Build to scale from the beginning … it’s the only way that makes sense.

Tomorrow evening I’ll be giving a talk in the “Sterling Hou Lecture Series” at Mizzou, as part of the annual Engineering Week. Here’s the description:

Commodity Computing & the Quest for Scale
Two drivers seemingly at fundamental odds with each other –the desire to do stuff in ever-increasing volumes and the desire to do it cheap – are colliding in computing as we speak.

While those desires may seem as old as the industry, what is new is that for the first time advances in software architectures, network interconnects, commodity processors, & business models are enabling both fundamentally new approaches to age old problems and entirely new economic communities. In this talk we will examine the nature of these advances and consider some of the current and future opportunities.

As in many aspects of life much of the change is fomented through conflict … maybe it’s because anything less makes it hard for most folks to get moving, who knows?

No matter, it’s very clear that we’re just beginning to see the hazy outlines of what the next few years in computing and the net might hold, and that in all likelihood we’ve barely scratched the surface.

Definitely looking forward to this. Mizzou was a great place to get started in computing … I had the run of an image-analysis lab, writing device drivers and generally wreaking barely-controlled havoc while trying to wring every last infitesmal bit of performance out what we had (which made it easy to understand the old-school Scotty in those days).

If you’re in the general area it’d be great to see you. Details are in the flier.

This morning we announced a new developer-friendly initiative that makes it much easier to begin using app fabrics for problems that you care about.

There’s a couple of things that I really like about this program, including

• The Community Edition is the real deal – a five worker, ten core license that you can do with as you wish … play around, prototype, do hard-core development, even put real apps in production. The best part? It’s the full current product (V3.7 – also newly shipping) – nothing held back whatsoever.
• A clean developers portal for the growing Appistry community.
• This program can be used by as many people in an organization as are interested – no limits, no artificial restrictions on size – just cool new tools to get your job done in the best way possible.

Btw, V3.7 includes a really nice implementation of affinity – the ability to have work requests self-guided to end up on machines containing particular resources (such as existing objects) – and a couple of other handy features for achieving serious scale in both HPC and XTP apps.

Of course, these new features work across languages, across platforms, and are fully endowed with the fabric attributes – no hassle for the developer, easy scalability, hard core reliability, self-operations – that make them perfect for commodity deployment.

A Great Time to be in Biz
Over the past few years we have had a gratifying response from enterprise customers, intelligence agencies, startups and more… enabling us to launch this developer’s initiative at this time.

Enjoy!

After today’s announcement of the iPhone SDK and the associated developer program I, like apparently about 20 zillion other people, decided to download try to download the SDK.

I’ve tried off and on for an hour+, and the best I can get is this:

That’s not cool.

I guess I was finally able to upgrade my Apple Developer Account to “iPhone status”, but that’s not all that helpful without any actual bits.

Grrrrrrrrrrrrr.

So today’s Mad Kitty most definitely goes to Steve Jobs & the rest of the crew at Apple, for apparently having about 10% of the servers lined up to support a very much anticipated announcement.

What’s the most irritating part of this? I’m sure I’ll try again tonight or tomorrow until I get the bits.

*Sigh*.

Update: finally got stuff downloaded this morning, fired it up … looks good. Should make for some fun weekend projects.

In last Friday’s post Bob Cringely argued that while the recent announcement of the new z10 mainframe (link from the excellent John Willis ESM blog) from IBM shows that the mainframe is dead, stuff like Azul’s java appliance are the real inheritors of the mainframe title.

He makes some good points, and the comment thread that followed was pretty entertaining – worth checking out.

But that’s gotten me to thinking a bit, and I want to riff on his point a minute. For the purposes of this post, I define a mainframe to be any multi-processor, shared-memory box that boasts about big capabilities. Stuff like the z10, high end boxes from Sun, HP, SGI, and so on. While their fans can rightly point to many individual differences, in reality their broad characteristics are very similar. So with that in mind …

Is the Mainframe Dead?
No … at least not for the foreseeable future.

This is clearly the case for several reasons. First, there’s simple inertia, in this case primarily in the form of legacy software (as in this app just works, and we don’t have anybody who knows how to change it anymore) and operational expertise. Which leads me too …

Second, there’s the accumulated comfort of knowing these systems are reasonably reliable for many of the day to day operational tasks, and the expertise to make them so.

Third, mainframes handle certain problems fairly well, particularly problems involving decent sized amounts of data, particularly where that data is going into a single database.

For years various claimants to the mainframe throne – including the DecSystem 10s & 20s of the 1970s, Sun, HP & SGI boxes of the 80s and 90s (among others) – have vied for the honor of killing the mainframe.

Yet the mainframe remains a real presence in many enterprise shops.

What Then Is Changing?
That mainframes are an expensive way to do computing is pretty obvious to most folks – even if you want to it’s just hard to hide the numbers. Big capital, big operations staff, big iron … they’re really all synonyms, or at least all parts of the same elephant.

Of course everyone would like to reduce expense, if they can.

So here’s the big surprise: what’s beginning to significantly reduce the footprint of the mainframe category (and remember here I include the traditional JEE clusters as well) is their inability to scale.

Pretty ironic, don’t you think?

Choosing a mainframe is sort of like using one of those SuperGuppy planes to carry an entire stage of the latest rocket … if that’s the only way to carry the thing, then go for it.

But what is FedEx using to carry the zillions of packages they deliver each and every day? I’d argue that the FedEx fleet is the airplane equivalent of commodity processors.

Fast, efficient, cheap & capable – especially when working together.

In any case the need for scale – the exact requirement that led to the rise of big iron – is now increasingly what is consigning them to those problems that cannot be done any other way. Furthermore, for all intents and purposes that trend is only in it’s infancy.

Can you imagine FedEx trying to build their business around these ungainly, albeit uniquely capable planes?

The real changes are yet to come.

The Reality of Scale
Just take a look at just about any of the truly web-scale SaaS offerings out there – be they just about any part of Google, Amazon’s own systems, Yahoo!, Facebook, Myspace, or any of the apps built to deploy on clouds such as S3 / EC2 … how many mainframes do you see in there?

Ummm … none? Exactly right.

‘We saw the same thing when laying new new architectures for processing very high-volume satellite imagery, reliably and in real-time.

Hordes of commodity boxes will smoke that mainframe (in this case primarily SGI boxes) in aggregate volume and performance.

Our fabric made that horde self-managing, reliable, & easy to scale without changing a thing, or even taking the running apps down. That is crucial, even necessary … but it’s not the whole story.

Give Me Data Fissures
What makes any of this stuff work is that the workload itself has what I call natural data fissures, or if not entirely natural then at least easily-discoverable data fissures.

This is what the traditional HPC guys might call “embarrassingly parallel” … and I’m ok with that.

The truth is that most enterprise workloads have far more natural data fissures than we realize, but that’s a post for another day.

The point here is that apps that can recognize these independent chunks of data, process them and eventually bring them back together for delivery, are perfect for cloud / fabric deployment.

The New Way to Scale
Think back to the FedEx example – that company lives and dies on their ability to reliably move and deliver a very high volume of relatively modest-sized packages – and to do so with a cost-structure that enables them to be profitable.

Of course they could never have scaled their company with a fleet of those ungainly SuperGuppies … and they didn’t have to since most of their business comes in small boxes and envelopes.

FedEx left it to the guys that needed to move whole rockets at a time to buy the specialized planes that could handle that job.

While the analogy is not perfect, I’m pretty sure that if you squint your eyes a bit, the SuperGuppy is pointing the way to the long-term future of the mainframe.

The whole business of specialized, attached processors (like Azul) is a discussion for another time. Unique economics, unique technical capabilities. Note that there are some very interesting places where commodity comes together with these specialized boxes. For example, check out what some of our friends at Exegy are doing … more on this topic later.