Powers Unfiltered

OK, here’s where I get to tell the real story about the new release the Digipede Network that I could not fit into the somewhat restrictive form of a press release earlier this month.  For the facts, you can go see “what’s new.”  But for the STORY, well, read on.  First, let’s go deep into the history of Digipede, and into what the Digipede Network is all about.  Hang on — this will be fun.

When we started Digipede back in 2003, we could see the market for distributed computing getting ready to take off, and we could see where we would fit into that market.  Before we started writing code, I went around and interviewed current and former CEOs and CTOs of successful and not-so-successful software companies in distributed computing.  We read, we went to conferences, we shopped the competition.  We went to see customers and prospective customers with real distributed computing needs.  And everywhere we looked we saw — layer after layer of needless complexity.  Customers were clearly being frozen out of the market by what they perceived as an insurmountable threshhold of technical and commercial complexity.

We set three criteria for ourselves and our product very early in the process:

1. The Digipede Network must provide dramatic improvements in application scalability and performance.  This is what grid computing is all about.  Sure, it’s also about asset utilization and virtualization and automation and provisioning and federation and flexible policies and IT agility and a side of fries, but we had to start somewhere.  The Digipede Network v1.0 would be all about improved application scalability and performance.
2. The Digipede Network must be radically easier to buy, install, learn, and use than any other grid solution.  I realize this sounds like marketing language.  Before it ever became marketing language, though, it was a battle cry in our office.  From the moment we started specifying our product until the moment we released it, we kept focussed on simplifying grid computing.  Before this was marketing language, this was hundreds of individual design, development, licensing, and pricing decisions.  Simple is better.
3. The Digipede Network must be the slam-dunk choice for anyone wanting a grid computing solution on the Microsoft platform.  We saw lots of grid work being done on the Linux platform (based in part on grid computing’s academic roots, and in part on IBM’s early recognition of grid’s potential), and very little commercially interesting grid activity on Windows.  An ecosystem of grid startups had formed around IBM; we declared ourselves charter members of the Microsoft grid ecosystem, and set out to make that mean something.

With those principles in hand, we went to work.  Version 1.0 was the product of more than two years of hard-core startup work — long days, long nights, passionate arguments, inadequate resources, testing and more testing, benchmarking, documenting and more documenting, beta feedback, head scratching, and more testing.

Released June 28, 2005, the Digipede Network Version 1.0 soon won critical acclaim and a critical mass of customers, We felt like the market had validated the path we were on — so we went back to work.

Version 1.2 (don’t ask where 1.1 went) made us compatible with Microsoft .NET 2.0; we also added some cool features like easier distribution of .NET objects, integration with Visual Studio 2005, job dependency, and better — you guessed it — scalability and performance.

And then we did something else — while Version 1.2 was out there doing well, we decided to release our SDK to all developers, in a special Digipede Network Developer Edition, for free.  After all, we’d just spent all that time on some pretty developer-friendly features, and we wanted to see what clever things developers could do with it.

And developers just went nuts.

They started to try out the Digipede Network as a way to increase the scalability and performance of their applications.  Word got around (I still frankly don’t entirely understand how), and developers from Bangor to Bangalore started coming at us with every scale-out problem under the sun.  Can we use the Digipede Network to process millions of large image files?  Can we scale out tax return processing?  Can we put a bioinformatic search algorithm behind a Web site and maintain quality of service?  Can we price fixed income assets faster?  Can we predict storm damage more accurately by increasing the number of scenarios analyzed?  Can we embed the Digipede Network inside our genetic algorithms for finding new asset trading opportunities?  Can we create visual If we have SharePoint, and we publish compute-intensive spreadsheets using Excel Services, can the Digipede Network scale out the calculations in the Excel user-defined functions?  And to their surprise and delight, the answer usually came up — yes.

And so we came to a decision for Version 1.3 — time to double down.  Time to focus even more on developers.  We took our already-great APIs and opened them up further, documented them better, wrote up more examples, baked in finer-grained control of jobs and tasks, and took the suggestions of some of our smartest developer-customers to make the grid computing system of developers’ dreams.  (Face it — developers dream about some weird stuff.)  All for the simple reason — the more applications are adapted to the grid, the more everybody needs the grid.

So that’s it — Version 1.3 is about developers, developers, developers.

And it couldn’t come at a better time.  Microsoft announced general availability of Windows Compute Cluster Server 2003 (CCS) last month (earth’s best way to deploy and administer many high-performance Windows servers together), and we’ve got earth’s best way to adapt .NET and COM applications to a grid of Windows machines (running CCS and every other Windows OS since 2000).  It’s never been a better time to develop scalable applications on the Windows platform.  So what are you waiting for — come and get it!