Thoughts on Computing

i have been heads down on a writing project that we hope to be able to announce soon, but every once in awhile I'll pop my head up (sort of Punxsutawney Phil style, but that may be insulting the groundhog) and look around ...

I'll admit to not being much of a Kindle fan, in either it's first or second iterations. Probably because I just like books. There - I'll admit it. I like books. Physical books. Paper, stuff like that. Yes, an inordinate amount of my house is devoted to books ... books on shelves, books in piles, books strewn here and there ... (I'm going to mercifully spare you the Dr. Suess allusion!).

Having said that, my biggest heartburn with the first two Kindles has been the ratio of useful (viewable) screen to other stuff - be it the sort of Soviet-style industrial "design" in the first edition, or the as yet sizable, though clearly better looking case in the second.

So maybe I shouldn't be surprised, but I'm warming up with the Kindle DX. Yes it's pricey, I'm still concerned about the seizure-inducing etch-o-sketch erase flashes, and I still like physical books. Still, I am intrigued, somewhat for the device itself but probably more for the implications for electronic distribution of even more content.

Check out this short video that covers some of both of these points:

This video is from of an interesting startup called Newsy.com, which produces short video reports combining multiple perspectives into a single burst. It's one of the new forms of journalism that I like, but more on that later.

What Happened to Newspapers?
Most of us in the geek world long ago shifted to getting most of our news via the net in one for or another. That trend has clearly spread out to a much broader percentage of the population, enough that newspapers are really struggling.

Not struggling as in trim here, trim there, invest a bit and everything will be ok, but struggling as in mortally wounded, say your goodbyes, and if you work there start thinking about what's next.

This happened for a fairly simple reason - advances in computing technology made it possible.

Some of it was the basic stuff (servers, decent storage, and all that), some of it was ubiquitous net-based distribution, some of it was more usable devices (I do love doing the web on my well-used, not so much better for the wear iphone), and some of it was what people did with it (blogging, aggregation sites, and the like).

Yes a few of the newspapers will make a transition to digital in a form that'll be sort of recognizable, but not too many. The reasons are really complex and outside the bounds of this post (or my expertise, really), but in essence too many of them for too long have thought that they were in a technology-enabled distribution business (typewriters, printing presses, newsprint, kids on bicycles), while in reality they were in the content business (think Clark Kent).

Clouds Enable the Next Big Bang
The funny thing is all of that shifting has been mostly before cloud computing. Most of what has happened to date in the newspaper business has been because the distribution technology shifted, and the new distribution model enabled a bunch of new competitors. It also opened up a bunch of new customers, but that's been harder to realize.

But with the basics of distribution in place over the net, and with devices like the iPhone, Kindle DX & competitors, netbooks and more that make the physical presentation of content better and more ubiquitous, the big race will be on to slice and dice the content that's available in better and better ways.

All of this sifting and sorting and searching is going to take far more computing, storage, and network capacity than anything our industry has done to date.

And I know a perfect platform for all that cool stuff.

By happy circumstance I had an opportunity to speak on a panel this week at the Reynolds Institute of the University of Missouri School of Journalism. The panel was focused on entrepreneurial opportunities, particularly those revolving around content. These guys get that the rules of their business are changing, and are definitely doing some cool stuff.

This is Part 1 of a planned three part series that traces the evolution of the CloudIQ Platform from first idea to what it is today, then considers what it is likely to become.

Right after graduate school we spent a few years living in the foothills of a desert mountain range. I remember the first time that I hiked a narrow trail to the top of the nearest peak - standing at the bottom was rather intimidating; the circuitous ascent itself was such a tangled mixture of switchbacks, short ascents and descents, under cover and open trail that it could only be described as non-obvious (at best). However, it was only upon achieving the original goal that we gained any perspective on how, in fact, we had gotten there.

In this post I will reflect on the evolution of CloudIQ - the truly exciting (if I must say so myself!) cloud application platform that we announced a couple of weeks ago.

Roots
As some pondered the impending Y2K "crisis" and others looked for the best millennium parties, most of our founding team was deeply enmeshed in building, selling, and supporting an enterprise-grade (scalable, reliable, etc.) payment server.

Upon leaving that company I had time to reflect on my enduring frustrations -

why was it so hard to build software that we (and our customers) could rely upon?

It seemed that we were spending 60 to 70% of our engineering efforts not on core functionality, but in our best attempt to ensure that the resulting application could be relied upon.

Later on an early supporter coined the term "reliability tax" to refer to this overhead.

As I asked friends at other companies and enterprise shops most recognized the same problem - a few argued the overhead was actually higher, most thought that the cruel irony was that it was very, very difficult to ensure true reliability for enterprise apps - but all agreed that this just didn't seem right, not nearly 50 years after Gracie Hopper did her most famous work.

With this question just really bugging me I had an opportunity to build the beginning of a digital recording studio. Using completely commodity gear - no name, cheap- I was genuinely shocked at the results. Serious performance, cheap.

So that led to the second question -

why weren't we using commodity stuff like this for problems that we really cared about?

The answer to this seemed easy enough - who could trust this cheap stuff? What if it broke? (and it would break).

In pondering the first question it seemed to us that the core problem for software development was one of complexity - mainstream application architectures were simply too complex, and becoming inexorably more so.

The First Idea
Then it became fairly clear - we could solve both of these problems at the same time by enabling groups of commodity boxes to work together to ensure a stable platform for applications.

But what exactly did that mean? Or more to the point, could we build it? Ever MORE to the point, once we built it, how could people use it, and for what applications would this new thing be useful?

Over the course of a few months the founding team hammered out the first answers to those questions. Throughout this process we were driven by use cases - we wanted the resulting platform to be equally adept at running anything from fine grained, transactional applications to more computationally-intense enterprise applications.

This led to much refinement of the basic idea, which evolved to a self-organizing group of commodity machines that could act like one thing, reliably execute all sorts of applications, grow (and shrink) as needed without affecting the execution of any running applications, and be very simple to both write applications and operate.

The Hive is Alive
We decided to call this hive computing, and on June 12, 2002 we had the first successful demonstration of a running hive. We assembled a few commodity boxes on a re-purposed kitchen rack, loaded the prototype hive software, and ... it worked!

We were able to (carefully) pull a few plugs and the application kept running without missing a beat - in fact, without even losing a bit of data.

Within two years we had our first paying customer (Sprint), a couple of patents filed, and a demonstration system on which we ran an eye-opening benchmark - a wall of 100 commodity computers that could legitimately double Visa's then-current peak transaction load, for a total bill that was well under 10% of the conventional alternative.

The best part? It was arguably far more reliable as well. We were constantly amazed by the resilience and ease of use of this new type of application platform ... though truth be told, we were not yet ready to use the "P" word.

Roadblocks
In our pursuit of the possible we (the founding team) sometimes thought that economics would do all the persuading for us. Well that turned out to be sometimes yes, but mostly no.

In fact, sometimes economics actually worked against us - the combination of 90% lower costs, simpler development, easier operations, and simultaneously increased reliability and scalability simply seemed too good to be true for many people.

The fact that we required some modification of the application also made adoption more complicated. While we supported several languages and multiple operating systems (and could easily support more of each), the plain, simple truth was that you did need to modify - albeit lightly - many components in each and every application.

This raised the adoption barrier a bit higher.

Then there was a little matter of language. Without a native category to call our own, sometimes we were put into all sorts of categories - everything from grid computing to autonomic computing, with several others between.

Early on I even told some folks that we were basically building the "Borg for applications". While hard-core geeks loved that (and usually laughed), it didn't exactly help us build trust with the typically non-technical executives responsible for making the final purchase decisions.

Yet, It Worked ... Well
Despite these go-to-market difficulties the product itself worked well - really, really well. In fact, by mid 2002 several of us became firmly convinced that beyond a shadow of a doubt there would be a time in the future - say 10 or 15 years - where most mainstream computing would be done this way.

The economics and functional advantages were simply too compelling for any other outcome.

The only real question in our minds was when and who - when this transition would begin to occur and who would help make that transition happen.

So as 2004 came to a close we pondered solutions to these issues and continued to press rapidly forward.

In Part 2 we will talk about why this worked so well, and the transition to the application fabric.

Earlier this week there was what seems to be the first large-scale collision of satellites, a commercial Iridium (satellite phone) with an older Cosmos-series satellite.

One of our partners, AGI, specializes in software for understanding these sorts of events. From their press release ...

On February 10 at approximately 1656 GMT, the Iridium 33 and Cosmos 2251 communications satellites collided over northern Siberia. The impact between the Iridium Satellite LLC-owned satellite and the 16-year-old satellite launched by the Russian government occurred at a closing speed of well over 15,000 mph at approximately 490 miles above the face of the Earth. The low-earth orbit (LEO) location of the collision contains many other active satellites that could be at risk from the resulting orbital debris.

Let that picture roll around your head a bit ... this was quite a collision, to say the least.

Over the past year or so we've worked with AGI to cloud-enable some of their "all on all" collision software. While they did not use our stuff in this particular simulation, it should still give you a general sense of of the type of application. Continuing with AGI's press release:

To support the space community in better understanding this unprecedented satellite-to-satellite collision, AGI and CSSI have used their software to reconstruct the event.

In other words, as a demonstration of a broader capability AGI has created a cool video using a small portion of their "all on all" collision software. Without further adieu, here it is:

A 720p HD version of this video can be downloaded directly from AGI.

A Few Thoughts on Cloud Suitability
First of all, while it is easy to see the computational requirements of keeping track of all those orbiting objects and trying to understand what might be in danger of running into what, and when ... there is also a significant data scaling problem in here as well.

Second, keeping track of "all on all" collision possibilities is not a problem that's getting any smaller, to say the least . All you have to do is imagine the debris-field portion of this simulation to gain a certain subjective sense of the problem ... sort of a space-borne version of Wall•E.

Third, while a certain amount of this processing needs to be done all the time. there will be times when collisions and other events occurr - foreseen or not - and there will definitely be a need for a spike in resources as a result.

So an application that needs scale (both data and computational) and flexibility - sounds like a perfect cloud application ... good thing that it is!

Video courtesy of Analytical Graphics, Inc. (www.agi.com). Debris image courtesy of Analytical Graphics, Inc. (www.agi.com). Wall•E and Eve image courtesy of Pixar and Disney. All copyrights belong to their respective holders.

Two applications areas for which cloud computing holds the most promise are in the related areas of intelligence and military applications.

Even if you are not already intimately familiar with the types of computing problems that dominate these application areas, it's easy enough to see how cloud computing - and of course I mean all sorts of clouds, with a particular emphasis on private clouds - can help.

After all, the very attributes of clouds that are so attractive to startups and enterprise alike - easy sense of scale, flexibility, low cost, and more - have tremendous appeal for intelligence and military applications as well.

A Military Perspective
I was recently interviewed for a story that's appearing In the current issue of Military Information Technology. entitled "COMPUTING IN THE CLOUDS". The story covers a number of cloud initiatives, with a focus on some things that are working and challenges that are looming.

Here is a cool quote from the story:

Appistry offers a linchpin technology for cloud computing, called the Enterprise Application Fabric, a cloud application platform for developing and managing large-scale, selfhealing cloud applications rapidly on commodity hardware.

Why Is Appistry a "Linchpin Technology"?
In this quote the story captures precisely one of the concerns of both those pioneering and those contemplating cloud applications in military and intelligence - sure the inherent scale and flexibility are great, but what about the complexity?

Speaking from the IC side of the house, streaming full-motion video from a Predator UAV or a satellite image are huge files to deal with in terms of storage, processing and transport to a soldier in motion...

However, a disadvantage is the added complexity of virtualization, which is inherent in cloud architecture (em. added). “When we virtualize in a cloud, it is more difficult to unwind the problem should it arise. As virtualization increases, logical complexity grows,” Pierce pointed out.

- Ken Pierce, DIA-DS/C4ISR

He went on to say that his organization is already well-positioned to handle the added complexity - but what else can he really say?

The Real Value of a Cloud Application Platform
It is precisely in aggressively taking out complexity - both operational and development - while maintaining all of the goodness of clouds that this emerging thing the industry has begun calling a cloud application platform. delivers the goods.

As you might expect, Appistry EAF as it exists today makes an excellent cloud application platform, and stuff that we're hard at work on - even as we speak - will expand that lead.

And that is why Appistry is becoming a "linchpin technology".

From a great (free) daily feature produced by the WSJ called The Best of the Web by James Taranto comes this awesome bit of irony ...

Think Locally, Act Globally
From the New York Times:

The local food movement has been all about buying seasonal food from nearby farmers. Now, thanks to the Web, it is expanding to include far-away farmers too.

A new start-up, Foodzie, is an online farmers market where small, artisan food producers and growers can sell their products. Foodies in Florida, say, can order raw, handcrafted pepperjack cheese from Traver, Calif., or organic, fair-trade coffee truffles from Boulder, Colo.

What a great idea! And why not take it one step further? Farmers could band together and form large organizations--call them "corporations"--to grow and distribute mass quantities of food. Retail operations could be set up in every town; they would be sort of super farmers markets, or "supermarkets" for short. Soon everyone everywhere would be able to buy local food from all over the world!

Being one, I'm always willing to cut entrepreneurs - particularly the the ones who charge ahead and then look around to see who came with them - just a little bit more slack ... still, this does border on the silly.

Of course silly can be great, especially if you remember to laugh.