SIA Tomorrow

I

  took the redeye from Oakland to JFK (still have yet to have a bad experience flying JetBlue—I'm definitely a fan) with my colleagues John and Nathan. Setting up for a show like this is always a blur of many details. The SIA Technology Management Conference is a bit of a bizarre bazaar. I've never seen so many booths packed so tightly into such a confined space (not even at Super Computing 2006, which was pretty tight). I have no idea what this place will look like when 7,000 attendees show up.

Normally, I don't get too hyped up about shows that I'm attending as a vendor. However, I'm unusually excited about this show. As our press release said this morning, we've got some big announcements this week. First of all, we're very pleased to formalize our relationship with HP. Packaging our software with the leading server manufacturer's hardware makes it as easy as possible for customers to get the power of .NET grid computing on a cluster—and ease of use has always been

We're also glad to further our relationship with Microsoft. We've always viewed them as our most important partner (in fact, we've been a gold certified ISV partner since before our product was released); having them present us in their booth here at SIA represents a new level of cooperation. The Financial Services team at Microsoft has been terrifically supportive—and very excited about what the Digipede Network gives them. They see it like we've always seen it: it's the best way for .NET developers to take advantage of Cluster Compute Server.

So if you're at the SIA Tech Management Conference in the next couple of days, stop by our booth (#4506 upstairs), the Microsoft booth, or the HP booth. I'd love to see you.

Technorati tags: grid computing, SIA, CCS

Computers get slower every day

W

  e have a saying around our office: "Computers get slower every day."

"What?" you ask! "What about Moore's Law? What about 3 GHz Opterons? What about 3.4 GHz Xeons?"

Well, ok, that's true. AMD and Intel are still innovating, and they're still churning out faster and faster chips. But the truth is, they're not keeping up.

As I wrote last fall, increases in processor speed just can't keep up with increases in networking speed and disk density (I referenced this Scientific American article). When you take into account the amount of data that we can effectively move to a computer, the processor itself is relatively slower than it used to be.

Now, combine this ever-increasing network speed with Jim Gray's observations about distributed computing: "Keep the computation near the data." But the corollary is, when you take into account increasing network speeds, "Your data is getting closer and closer every day." In other words, because networks are getting faster and faster, it makes more sense to move data to more processors in order to work on it.

I write all of this because I had first-hand experience with it yesterday. Over on the Digipede Community boards, delcom5 had written to say that he had 15gb files to zip, and ask if the Digipede Network could be used to speed up the zipping process.

I was curious about it, and I set out to try it. It was extremely simple to set up a job to zip files (took me maybe one minute using Digipede Workbench). However, when I ran it, even though I had 10 machines working on zipping, I got barely any speedup. Why? Well, I was dealing with 100MB files--and those take a while to move around my 100 MBit network! I was pretty frustrated.

Then I decided to submit to a subnet that's wired with Gigabit Ethernet. Wow! What a difference. Zipping a gigabyte of files went from almost a minute and a half to fifteen seconds.

A couple of years ago, this wouldn't have made any sense as a distributed computing problem--100MBit networks just weren't fast enough to make it work. If you wanted to zip a bunch of files, you were forced to do it on one machine. But with the order-of-magnitude performance increase that Gigabit Ethernet gives us, you get tremendous improvement by distributing this problem.

The lesson here isn't just about zipping files, of course. As networks get faster faster than chips get faster, more and more problems like this become "eligible" for distributed computing every day.

Technorati tags: grid computing, distributed computing, digipede

CCS Released!

A

  t long last, Microsoft released Compute Cluster Server 2003 today! Kyril Faenov, Ryan Waite and crew have worked for a long time, and they're releasing a great OS (Compute Cluster Edition) and set of HPC tools (Compute Cluster Pack).

I know they'll be making a splash at Tech Ed 2006. Unfortunately, scheduling problems won't permit me to be there. Fortunately, Scott Swigart over at Tech Blender pointed me to Virtual Tech Ed, where I'll be able to follow all of the action!

Anyway: Congratulations Kyril and Ryan! Have blast in Boston.

Technorati tags: ccs, Tech Ed

Unscheduled Uptime on Blogger: Post Immediately!

T

ough week to be blogging on Blogger. There was downtime most of the day, nearly every single day. I'm surprised that I had any hits at all--I could almost never see my own site. In fact, I could almost never see any Blogspot site. Blogger, here's a suggestion: create a status/information page that's hosted on another site so we can get information when you're down!

I'm considering moving--perhaps to my own site on Bluehost, running Wordpress. Any other ideas? I'd be interested in running .NET at a host who supports .NET (I know GoDaddy does), but are there any good .NET blogging packages out there?


We had an exciting week here at Digipede. We nabbed a new customer in the financial services space who will be scaling their SOA using the Digipede Network--I think we'll have a press release out soon. We also continue to prepare for the SIA TMC 2006 conference. The amazing thing about that is that we're now running our VSTO 2005 project in Excel 2007--with no recompiling! Just loaded it up, and it ran. So that means we'll be showing Excel 2007 starting .NET jobs on a grid running on Compute Cluster Edition cluster. Sweet.

I also recorded my .NET Rocks! interview this week. That was a blast; Carl and Richard are smart guys (and if you ever want to see some crazy photos of water cooled super PC's, check out Richard's blog). They're shuffling their schedule right now around TechEd; current projections are that my interview will "air" on June 27th. I'll keep you posted on that.

Technorati tags: blogger, digipede, dotnetrocks

Matrix Multiplication on the Digipede Network

R

ich Ciapala did a great, extensive review of Windows Compute Cluster Server 2003 in the April, 2006 edition of MSDN Magazine. He took a sample application (matrix multiplication) and runs it on CCS three different ways: in a single call, as a distributed application using several calls, and as a single, MPI-enabled application.

It's a great, in-depth article. Rich dove in headfirst, and he dove in deep! Thanks for such a practical, hands-on guide. Matrix multiplication takes a ton of calculation to do and is very parallelizable, so it's a great sample.

In fact, it was such a good sample, I decided to take the same application and implement it using the Digipede Network!

We don't have an MPI implementation (and if you need it, CCS is the right tool for you!), so I'm going to mimic the functionality of Rich's second example: taking their (command line) matrix multiplication tool, and run it using the Digipede Workbench.

First, I created a 5000 row by 5000 column matrix. For my test, I'm going to write code to square it (multiply it by itself). Each of the 25,000,000 cells in the resulting matrix takes 5000 multiplications to calculate.

Next, in order to have a "control" for my experiment, I multiplied it by itself on one machine. I chose one of our faster servers for this: a 3GHz box. Multiplying my huge matrix by itself on that one machine took just over an hour:


Ok, now we've got a baseline. Next, I used our GUI tool, Digipede Workbench, to create a job submission. The MatrixMultiplier takes the following arguments:

MatrixMultiplier.exe [input matrix] [input matrix] [output matrix] [quadrant X] [quadrant Y] [quadrant dim]

For my test, I broke the multiplication up into 16 tasks. For example, the command lines for my first three tasks need to look like this:
MatrixMultiplier.exe InputMatrix.mtx InputMatrix.mtx output0.mtx 0 0 1250
MatrixMultiplier.exe InputMatrix.mtx InputMatrix.mtx output1.mtx 1250 0 1250
MatrixMultiplier.exe InputMatrix.mtx InputMatrix.mtx output1.mtx 2500 0 1250

Fortunately, creating command lines like that are a breeze with the Workbench. I did this whole thing using variables, by the way, so I could re-use it later for more matrix multiplication jobs without going through the whole process again.


First, I gave it the name of the executable:

Then, I gave it the name of the Matrix I was going to multiply.

I defined XQuadrant as a range variable from 0 to 4999 (the size of my matrix), step 1250.



I defined YQuadrant the same way. Then I defined QuadrantSize to be 1250. If, in the future, I want to use this Job to multiply different size matrices (or using different size quadrants), I can change these values on submission.

After telling it where to put the result file, I defined the command line:

Notice all of the variables on the command-line: the file name of the input file (used twice), the output file name, the quadrants (x and y), and the quadrant size.

Then I clicked "Submit!"

The whole job definition process took about 10 minutes or so. And the job took 13.5 minutes to run--nearly a 4.5x speedup!

Here's an aside: With about 10 machines on the network, I wondered why I was only seeing less than a 5x speedup. I looked at the task times, and I realized that my five slowest machines were so much slower than the others that they were actually holding things up. I resubmitted my job; this time, I broke it into 64 pieces (this was really easy; I just had to go through the wizard again, changing my quadrant size and step sizes to 625. Piece of cake!)


And the results were good: it knocked 3 minutes off my run time, bringing it down to 10.5 minutes. By giving finer-grained work to the Digipede Network, I allowed its CPU load balancing to work most efficiently. My grid did 60 minutes of work in 10 minutes; that's a 6x speedup. Considering that I have 4 fast machines and 5 slow machines (much slower than my "control" machine), the 6x speedup was just about optimal for this problem.

[Update 2007-10-17]: We're doing some testing right now, and we've just added two eight-way boxes to our test grid; today it is 14 machines with a total of 35 cores. I just re-ran this test and it took two minutes and 19 seconds. Yum!

Technorati tags: ccs, digipede

Not Another Trademark Dispute!

T

hanks to Paul Shred and the gang over at Grid Computing Planet for mentioning our release of the Digipede Developer Edition and launch of the Digipede Developer Network in yesterday's edition.

However, there seems to be a slight typo in the headline, and I don't want to get in an O'Reilly-esque trademark dispute.


So let's be clear (Bill and Steve, are you listening?): We launched the Digipede Developer Network. I'm pretty sure someone already has something called the Microsoft Developer Network!

Technorati tags: MSDN, digipede

Hey everybody, look at me!

M

y friends and family all know that I'm an attention hound. Well, here are some upcoming events where you can see me, hear me, or maybe even both!

6/6/06 - Developer Webinar: This 30-minute webinar will give a technical overview of the Digipede Network and then dive into Visual Studio, showing how to grid-enable an application. Register here.

6/13/06 - .NET ROCKS: I am very excited to be the guest on .NET Rocks--the Internet Audio Talk Show for >NET developers. Carl Franklin and Richard Campbell are wizards at taking a very technical discussion and making it a very entertaining show. Listen here.

6/13/06 - Finance Webinar: Another webinar, but this one will be lighter on the code and heavier on the application. Thirty minutes, concentrating on uses of grid computing in finance. Register here.

6/20-22 - SIA TMC 2006: The Security Industry Association's Technology Management Conference is Wall Street's E3--the place to see the latest, greatest tech tools being used in capital markets. We'll be there, showing some really cool applications and talking about what our finance customers are doing with grid computing. We'll also have some very exciting partner announcements, but the details on those will have to wait. For those of you in New York, this is a chance to come check out the Digipede Network in person.

Technorati tags: digipede

The more things change, the more they, uh, you know...

T

his quote came across my news alerts today:

Fewer than one in 10 businesses is planning to adopt grid computing because of concerns about cost, complexity and security, according to a survey of IT managers.

It was reported here in Silicon.com, quoting a study done by Vanson Bourne.

The article paraphrases Peter Critchely of Morse, who commissioned the study, saying, "...grid computing is being held back by confusion and myths surrounding the technology."

I was all fired up to write a post about how needless complexity is what has been holding back grid computing for quite a while...and then I remembered that I already wrote that post. Last September. I wrote about how, at Digipede, we felt that addressing complexity issues was our top priority.

We concentrated on ease-of-use in every phase of the product--from how it would be sold, how it would be installed, how developers can work with it, and how it would work for people who have never written a line of code in their lives.

In the intervening 9 months, we've been able to show that grid computing doesn't have to be difficult. There's the bazillion dollar investment fund that ported their trading analysis software faster than their lawyers could examine a license agreement (case study here). There's the media company that took a CPU-starved, multi-threaded application that was threatening to choke their server, and in just a few days had it running on 20 machines on their network (case study here). There are companies scaling their web applications. There are biologists doing complex genetic analysis. There's even weather simulation. All of it happening by doing "grid computing."

And how many clients have we visited? Zero. Nada. Zilch. Oh, sure, Rob and John went to Universal Studios with one client, but that was really for the Mummy ride, not to discuss intricacies of grid computing.

So how have we been able to help our customers if we aren't holding their hands? Simple: our product is radically easier to BILU.

Today, we made it even easier to try out. Today we announced our free Digipede Network Developer Edition. What is the developer edition? It's a fully-functional, full-featured version of our product. It lets any developer working on a Microsoft platform check out the Digipede Network up close and personal. Run our samples. Run your own code. Play with it. We want more developers to experience what our customers already have: Grid computing doesn't have to be hard.

To download the Digipede Network Developer Edition, go here.

Technorati tags: grid computing, digipede

Vogels and Gray

I

 f you're interested in distributed computing (and if you're reading this, you probably are), I sure hope you're also reading Werner Vogel's All Things Distributed. Last week, he mentioned an interview that ACM Queue magazine had published. Jim Gray of Microsoft Research sat down with Werner (CTO of Amazon) and did a terrific interview. Hat tip to ACM for giving them the space to have a great conversation--it runs about 8 pages long.

Reading these two discussing distributed computing is a little like listening in on Bohr and Planck talk atomic theory. They really are two of the world's preeminent authorities in this territory.

The topic of the interview is Amazon's technology, so there is a ton interesting history. Among the nuggets you'll find is that Amazon was a single, monolithic application until 2001. At that time, they changed to a service-oriented architecture (and, as Werner points out, that wasn't a buzzword back then--it's what they had to do to scale).

I won't try to summarize the whole article (you should go read it). It's a great exposition on the practical application of SOA. The relevant thing for this blog--it's distributed computing that makes the whole thing possible.

Technorati tags: distributed computing, amazon

Well, at least they're paying you to go through it...

A

  ccording to this recent review, writing code to run on Sun Grid is a serious pain in the astral plane ("analysis finds hidden costs in Sun platform" and "Sun Grid requires extensive man-hours and code rewriting to run custom applications").

Apparently, Sun is feeling the heat. As I saw in Greg Nawrocki's post today (and other places, including Slashdot but not Techmeme, interestingly enough), Sun is offering $100,000 to anyone who can figure out how to do it as a prize in a contest.

Have fun with that!

Technorati tags: sun grid

Scaling A Web Service--Webcast Tomorrow

O

 ne of the most exciting ways that people are using the Digipede Network is to scale web services. I know it sounds pretty pedestrian; so why is it exciting?

First, people are using web services to do some exciting things these days. The increasing adoption of Service Oriented Architecture, along with the capability of providing useful tools across the internet (think Web 2.0), mean that people are putting more and more cool applications behind web services.

But second, scaling a web service on a grid is the kind of thing that doesn't involve any re-architecture of an application. See, when many people think about the concept of grid computing, they think, "Well, that sounds great for a very special type of application, but it wouldn't work for me"--especially those who haven't seen the light of Object Oriented Programming for Grid.

However, scaling a web service doesn't mean you have to re-architect your application. There's no need to write any "parallelization" code. It just means running your web service on the grid to provide scalability. You can think of it as a CPU Load Balancer. It means that when a user hits your compute-intensive web service, it gets processed by a machine that has CPU capacity ready.

To show how easy it is to wrap a web service in some grid code and have instant scalability, I'm giving a webcast tomorrow morning (10:00AM PDT). I'll give an overview of the Digipede Network, then take a web service and grid-enable it. The whole thing will only take 30 minutes. There's only room for 15 people in the webcast; register here to secure a spot!

No parallelization required.

Technorati tags: grid computing, digipede, web services, soa, scalability

Double Your Pleasure, Double Your Fun

A

 t the risk of linking to Nick Carr once too often, I'm going to offer some comments on his latest incisive post.

Microsoft has an opportunity to integrate the two OSes in a way that can put Google at a significant disadvantage. To put it another way, it has an opportunity to manage customers' transition from the computer OS to the Web OS in a way that furthers its own interests - and damages Google's.

An excellent point, Nick. When I heard about Microsoft's increased capital expenditures, the idea of offering some easy transition from desktop to web OS hadn't really occurred to me. It's a fascinating idea, though, and one that their .NET development tools will help make even easier.

The funny thing is that I did think that perhaps Google was going to open up their server farms to outside software. Last fall, when Google announced their partnership with Sun, I posited that with Google's distributed OS (and ginormous server farm) and Sun's utility computing experience, they may be creating the world's largest grid-for-hire; I noted that one inconvenience was "you're going to have to rewrite your code to run on a different OS."

In an earlier post, I noted that "For an enterprise distributed computing system, enterprises want an OS that is deployed within their enterprise. They want an OS that they develop on all the time."

As Carr points out, Microsoft already has that advantage. They've also got 20 years of putting together world class development tools for that OS.

Carr asks the question

Google could, of course, try to counter Microsoft's advantage by offering its own computer OS - a version of Linux, for instance - but it's hard to imagine such a move succeeding. Would a critical mass of users really make the leap?

Not only that, but does Google want to release GLinux? My comments from last September:

It would surprise me greatly to find out that Google has any interest in all at making an all-purpose operating system. One of the hardest things about making any public OS is the hundreds of thousands of drivers that have to be written to handle peripherals; does Google want to get in the business of making sure every printer on earth works with their OS?

If Nick is right, and Microsoft will indeed be able to bridge "the two OSs," it will be a fascinating battle. Google may be forced to release an OS just to compete. And if that happens, sparks are really gonna fly.

Technorati tags: grid computing, utility computing, microsoft, google

Are the server wars over?

A

 pparently my comment notification system isn't working right--or I just received a comment on a two-month-old post. The misconceptions in the comments were great enough that I thought it deserved its own post.

I had been engaged in a bit of repartee with Nick Carr (one of the best in the blogosphere, IMHO, so click on an ad next time you're on his site) about whether the server market is doomed (one of the few subjects in which I disagree with Mr. Carr). My post is here ( Because 1.21 gigaflops just aren't 1.21 gigawatts).

A reader--Bert Armijo of HotCluster left the following comment:

I'm afraid you're using the exceptions to build your rule.

90% of all compute cycles are exactly the same. If you doubt that, take a quick look at the server marketshare data. The processor, memory and I/O architecture battle has been settled. So, as long as you're running typical business or web applications and not HPC, computing resources can be considered a commodity.

How to deliver that resource is decided. It's TCP/IP over the internet.

What's been missing is a standardized way to organize the usage of remote cycles to power a distributed application. This challenge has also been solved and now we get to see how the market reacts.

As I said in my follow-on comment: There's a standard processor? Is there a standard OS? Are there standard "typical business applications?"

At Mr. Armijo's suggestion, I decided to take a quick look at the server marketshare data. Although he never said it explicitly, I can only assume that he means that the world has standardized on Linux. However, according to this article on LinuxInsider, there is no clear leader in the server market.

In terms of revenue, Windows has the largest share of the market at somewhere north of $17.7B in 2005. Second place? UNIX, of course, at about $17.5B. Linux systems come in third, with about $5B in revenue in 2005--the first time Linux systems have finished that high. Linux is growing quickly, of course, experiencing 20% revenue growth.

Surprising? A lot of people would think so--although not the server manufacturers themselves. I met with a major manufacturer recently who ships UNIX, Linux, and Windows servers, and over 40% of their servers (in terms of units) ship with Windows on them.

My point here? Simply that there is no clear market leader. UNIX was the server leader for more than a decade, and it is slowly slipping out of site (the sad news about SGI this week was one more indicator). Windows has taken the lion's share of the UNIX slice of the pie, but Linux is growing very quickly (and will continue to grow).

Mr. Armijo also says that the processor battle has been settled. Has it? AMD has been enormously successful in the 64-bit arena--so much so that Intel has rethought its entire strategy for the 64-bit platform.

So to say there's a standard is to willingly put blinders on. There are multiple operating systems out there. There are multiple hardware platforms out there. And many are thriving. Many will continue to thrive.

Mr. Armijo didn't explicitly call out any standard operating system, and it's possible that I've mistaken his point. But all software doesn't run on all operating systems, and that's part of my point when I say "compute cycles aren't all alike." Software needs an OS. Those "typical business applications" that he talks about run on different operating systems, and many are dependent on a single OS.

To repeat myself: I'm a believer in utility computing. I think it will have an ever-increasing role in business. But it's not a panacea, and it's not easy. Using utility computing is still a difficult, nasty business (see CRN's review of Sun Grid).

Moreover, there are the concerns I raised in my previous post:

Not all compute problems can be "shipped out" easily. There are huge data concerns. First of all, there are the ubiquitous privacy and security issues: some data people just don't want leaving their building.

Beyond that, though, there's the issue of data size and compute-to-byte ratio. If I need to do a quick search of a huge dataset I just collected from my genome lab or my jet design windtunnel, it may not make sense to move that to a "computing powerplant." Heck, I may be collecting tons of data in real time, and I need to analyze it in real time. I need my computes where my data is. As Jim Gray says, "Put the computation near the data." If your data are with you, that means your computes are with you as well.

For the last time: I'm not arguing against utility computing. But if you think that it will apply to every computing problem, that enterprises are going to get all of their CPU cycles over the net and no one will buy servers anymore, you're just not looking at the real world.

(I also used some numbers directly from this IDC press release, which was the source for the LinuxInsider article).

Technorati tags: utility computing, linux, unix, windows

Grid: No Simple Answers? Or Simpler Than You Think?

D

  riving around Oakland this weekend I saw thousands of Mexican flags--the confluence of Cinco de Mayo the same week as the May Day immigrant protests led to a huge community celebration. I was at a gas station and chanced into a conversation with two Mexican immigrants--one legal, and one illegal. Because I have a passable knowledge of Spanish, they asked what I thought about the situation. My answer: it's a tough nut to crack. There simply are no easy answers.

When it comes to grid computing, people want easy answers, too. It's funny how many very educated people (like, PhD kind of people) want to know if we've found a way to take a single-threaded, monolithic piece of code and run it in parallel on many machines to make it go faster. The answer to that is, of course: no. We're not magicians, and anyone who can tell you they can do that has probably also spent time in a sphere full of water in New York.

So distributed computing isn't magic. That said, it also shouldn't be as hard as people have made it out to be.

There's been an acceptance in the industry that distributed computing is hard (and, to be certain, some aspects of it are very hard). But that has led most industry players to allow all of it to be hard. The prevailing attitude seems to be: "It's difficult stuff; you want to learn how to do it? Install the right flavor of the right version of the OS, learn Perl, spend weeks poring over the message boards, or hire some expensive consultants to do all of that for you."

But it doesn't have to be that hard. You don't need consultants to install most software--why should grid software be any different? Most systems don't prevail upon their users to learn scripting languages in order to take advantage of them--after all, most users aren't programmers. So why do all traditional grid systems rely on scripts?

This isn't to say that people who use those systems don't understand the concepts of ease-of-use. It's just not a feature they've been thinking about. I had a meeting last year with some PhD students who do work on the GLOBUS Toolkit. When they saw the Digipede Workbench (the tool that lets you design and run jobs without having to write scripts), they didn't snicker at a silly Windows tool. They said, "I wish we had one of those!"

That, incidentally, is the tool that the reviewers from CRN magazine used when they compared the Digipede Network to Sun Grid. Of course, their conclusion (as I wrote last Friday): "The difference in ease of use in Sun Grid vs. Digipede was enormous."

We used the same ideas when we designed our critically acclaimed development tools: distributed computing doesn't have to be hard.

So can grid computing make all of your software magically run faster? Of course not.

Does grid computing have to be very difficult to implement? I say, the answer is the same: Of course not.

There may not be simple answers to every question in life, but maybe there are some simple answers in grid after all...

Technorati tags: grid computing, digipede, sungrid, sun

John vs. Jonathan? Digipede Outshines Sun

CRN magazine ("Vital Information for VARs and Technology Integrators") released an article today on Sun Grid (Sun's CEO is Jonathan Schwartz) and the Digipede Network (Digipede's CEO is John Powers): Review: Gridlock Alert For Sun Grid?

The article's subhead says it all:

Analysis finds hidden costs in Sun platform, while competing Digipede offering shines

Now, I'm not sure that the Digipede Network is really a competing offering--after all, Sun Grid lets you rent distributed computing on Solaris boxes by the CPU hour, while the Digipede Network lets you use your own Windows machines (without any hourly charges).

The reviewers found was that Sun Grid was extremely difficult to use. "In the end, the Test Center was unable to complete the project as originally planned, even with the help of Sun engineers." Ouch.

How about doing the same job using the Digipede Network? "The difference in ease of use in Sun Grid vs. Digipede was enormous."

How so? Well, they didn't have to rewrite their application to use NetBeans--the Digipede Network is just as comfortable distributing command-line executables as it is distributing .NET objects--they just used their existing app. They used the Digipede Workbench Job Wizard to define their job ("developers need not learn how to build scripts"). And the result:

Test Center engineers completed the Digipede job in less than one hour vs. five hours for Sun Grid.

Mind you, the five hours they mention aren't the $1 per hour kind: they're talking about human effort time. Expensive time. User time. In less than an hour, they had the Digipede Network up and running their jobs: no recompiling, no relinking, no rearchitecting, and no strange scripting.

One side note: while we love the Microsoft development tools, we know not everyone uses them. In this article, they mention that they built their application using the DOS GNU compiler. We have customers using development platforms as diverse as PHP and Python, as well as many different flavors of Microsoft platforms.

Technorati tags: grid computing, digipede, sun, sungrid

Thanks, Profes...I mean, John!

I had a great meeting yesterday with John Ousterhout of Electric Cloud.

John used to be a professor of Computer Science at Berkeley, and he's one of the reasons I majored in CS. He was really the ideal professor--the kind of guy who knows every single student's name (even in a class with close to 200 people in it), who blends education with humor (I remember the first day of class, he told us that his name is pronounced "OH-stir-howt," but he responds to anything from "Oosterhoot" to "Easterhat"), and is active in cutting edge technology.

In the early 90s when I worked at Quantum Consulting under Margo Seltzer, I even used his Tcl/Tk toolkit when we ported one of our Windows products to run under Solaris.

Professor Ousterhout moved on from Berkeley to Sun as a Distinguished Engineer (and, I guess, stopped being called "Professor"). After Sun, he started Scriptics, which was later purchased by Interwoven. In short, he's had a stellar career thus far. His latest venture is Electric Cloud.

Electric Cloud is a pioneer in distributed builds--they have great technology and an impressive client list.

I really enjoyed catching up with John, and I very much appreciated the hour we spent together. He is quite an incisive guy: within minutes of sitting down, he was offering fantastic advice about Digipede. We didn't talk so much about the technology (although, as someone who has been working with distributed computing for decades, I'm sure he'd be a great technical resource), but about the business.

Clearly, he has a head for business as much as he as a head for software. I valued his opinion because he's done something extremely difficult to do: taken a development tool (a decidedly unglamorous product when compared with the AJAXy/SocialNetworky/Web2.0ish companies getting funded these days), gotten it funded, and brought it to market.

We discussed pricing strategies a fair bit. None of his ideas were brand new, but it is always great to get an outsider's perspective.

One thing they concentrate on at Electric Cloud is the ability to determine who their customers are in three questions: What platform do you develop on? How many developers do you have? How long do your builds take? The answers to those three questions determine whether a company is a prospect.

I can't boil my customers down to three questions--but I'd really like to be able to. This is a great exercise, and it's one we need to undertake at Digipede. It's not just a useful tool for a junior salesperson. It's also great for us, as a company, to be able to define our customers that way. Investors need to know who the customers will be. We need to be able to refine our marketing to hit the right people. We are sure we've got a huge potential audience for our products--unfortunately, it's amorphous and hard to define. My hour with John made it clear that we need to define it clearly, even if that means shrinking it a bit.

Of course, when our customer base is doing things as different as risk management, Monte Carlo simulation, hurricane simulation, Bayesian analysis of text messages, map generation, gathering web content, PDF generation and genetic algorithms, it's a tough nut to crack.

Technorati tags: Electric Cloud, digipede, John Ousterhout

Strange floating point behavior on Xeon

One of the first applications I wrote using the Digipede Framework API was a distributed Mandelbrot app. It's almost a cliche application for a grid computing system--still, it looks pretty and calculates a heck of a lot faster on many machines than on one.

Recently, I was tweaking our calculation code to get better colors out of it. After tweaking it, I noticed something very strange happening: different machines were calculating different colors for the same pixels! Here's a screencap that shows how it manifested itself:


Because different machines calculate different portions of the picture, and those portions may end up right next to each other, it's pretty obvious. The rough edges give you an idea that things just weren't right--I've circled some of them.

At some point, I realized that there was one machine on my testbed in particular that was returning different values than the others. I also noticed that the gradients on the bitmaps from that machine lined up perfectly with the gradients on the bitmaps from the other machines--the colors were just different. Furthermore, the colors were always 1 color off (the colors in my Mandelbrot are stored in an array).



As it turns out, that machine has dual Xeon processors in it, and it's the only one on our network that does. It was pretty clear that the Xeons were causing a problem--and today I decided to pin it town.

To calculate a Mandelbrot set you do a repetitive calculation using complex math. Basically, you start with a complex number z, and you iteratively perform the calculation z = (z * z) + c. You count the number of times you can do that before z is too large to calculate. You then choose your color based on the number of iterations.

I added some code to my calculation object to spit out the results from the calculations. On most machines, it looked like this:

after 0: z = -1.78571428571429 + -1.19047619047619i
after 1: z = -0.0141723356009069 + 3.06122448979592i
after 2: z = -11.1566088075442 + -1.2772455921144i
after 3: z = 121.052849496283 + 27.3089826542847i
after 4: z = 13906.2261232719 + 6610.46985810096i
after 5: z = 149684811.460994 + 183853376.065174i
after 6: z = -1.1396521108449E+16 + 5.50401158655656E+16i
after 7: z = -2.89953366111956E+33 + -1.25453168454679E+33i
after 8: z = 6.83344570443359E+66 + 7.27511369656889E+66i
after 9: z = -6.23129910256229E+132 + 9.94281888781693E+133i
after 10: z = -9.84713565508731E+267 + -1.23913356825186E+267i
after 11: z = Infinity + Infinityi

But on the Xeon machine, it looked like this:

after 0: z = -1.78571428571429 + -1.19047619047619i
after 1: z = -0.0141723356009069 + 3.06122448979592i
after 2: z = -11.1566088075442 + -1.2772455921144i
after 3: z = 121.052849496283 + 27.3089826542847i
after 4: z = 13906.2261232719 + 6610.46985810096i
after 5: z = 149684811.460994 + 183853376.065174i
after 6: z = -1.1396521108449E+16 + 5.50401158655656E+16i
after 7: z = -2.89953366111956E+33 + -1.25453168454679E+33i
after 8: z = 6.83344570443359E+66 + 7.27511369656889E+66i
after 9: z = -6.23129910256229E+132 + 9.94281888781693E+133i
after 10: z = -9.84713565508731E+267 + -1.23913356825186E+267i
after 11: z = NaN + Infinityi
after 12: z = NaN + NaNi

See the difference? After 10 iterations, the calculations were identical. But on the 11th, the first goes to Infinity. The second, though, goes to NaN!

According to the .NET 2.0 documentation on NaN, "This constant is returned when the result of an operation is undefined." And the documentation for Double.PositiveInfinity says "This constant is returned when the result of an operation is greater than MaxValue." Double.NegativeInfinity is, of course, "This constant is returned when the result of an operation is less than MinValue."

MaxValue, by the way, is 1.79769313486232e308. So there's no doubt that the result of squaring z was going to overflow. But I don't see anything to indicate that the result should be NaN--and all of my other machines agree: it should be Infinity.

So is this a problem with the Xeon? The FPU? The .NET 2.0 libraries on my x64 machine? It's a 32-bit app, so I don't see how that would be.

I was able to work around this in code, but it's not the kind of thing developers should have to worry about (see Kim's post on how developers rely on the systems beneath their code).

Still - I'm glad this was only an application drawing pretty pictures. I'd hate to see the calculations on the trajectory of our next Mars probe to go awry based on something like this.

Has anyone else had any discrepancies using .NET 2.0 on the Xeon?

Technorati tags: xeon, mandelbrot, .net20, digipede

MSDN Webcast Resources

Welcome MSDN Webcast attendees!

I said during my webcast today that I'd post a bunch of links and stuff--here they are. Some of these are repeats from my last webcast, but some are brand new.

If you want to download a fully-functional copy of the Digipede Network Developer Edition, just visit www.digipede.net/faster and use the promotion code MSDN.

My first MSDN webcast was called "Object-Oriented Programming for Grid," and is available on demand here.

The paper I mentioned was Web Services and the Grid by Lee Liming of Argonne National Labs. I've referenced this here before. It's a great piece on why web services and grid computing go hand in hand.

I didn't mention this in my webcast, but you also may be interested in reading this article from Ian Foster, one of the fathers of grid computing: Grid's place in the service-oriented architecture.

The blogs I listed were:

Expert Texture: Robert Anderson (CTO of Digipede) on .NET development and grid

A Day in the Life: Kim Greenlee, Digipede Evangelist, on grid computing (including lots of Excel/grid interop)

But if you're interested in distributed computing, you should also check out:

All Things Distributed: Werner Vogel (CTO of Amazon) on, well, all things distributed

Grid Meter: Greg Nawrocki (President of the Globus Consortium) on grid computing

For those who asked about source code: e-mail me! (See link at right)

Update 4/25/06 12:16: Added new links.

Technorati tags: grid computing, digipede, OOP-G

Monday: New York. Tuesday: Everywhere Else!

It's been a busy few weeks at Digipede (which you may have noticed by the small number of posts here).

In addition to planning our next release and some meetings with potential partners, we've been preparing for a couple of events next week.

On Sunday, John and I are going to New York. Microsoft is hosting its fourth annual Financial Services Developer Conference at the Millenium Broadway Hotel. I'm really excited about this--Stevan Vidich of Microsoft has asked us to give a demo during the Capital Markets keynote address Monday morning. It'll be a great opportunity to show off our stuff in front of Manhattan's finest developers--assuming that we can get network connectivity! As usual, it's a pain in the neck to actually get network connectivity at the hotel, which means I may have to give a distributed computing demo without being connected to any computers.

Unfortunately, I'm going to have to miss Tuesday's sessions (I'd really like to see the one by Naresh Bhatia and Stephen Maltzman from Sapient). I'm giving another MSDN webcast Tuesday morning, and I wanted to do that from my office. That all adds up to a hellish itinerary--I won't get to bed Monday night until about 4:30AM Eastern time.

But this should be a great webcast. After giving a good, basic "100" level description of Object Oriented Programming for Grid in my last webcast (you can view that here, by the way), I'm really going to dive in deep in this one. It'll be the most extensive code demo I've ever done. I'll show some practical applications of the Digipede Network, including using it with Excel (which I've shown before) and using it behind a web service and behind a forms app (both new demos).

You haven't registered yet? No fear: register here. Date and time: Tuesday April 25, 11:00 AM PDT.

Technorati tags: excel, digipede

Photo credit: danzo08

Grid Computing and Excel

I get lots of hits on this blog from people searching on "grid computing and Excel" or "cluster computing and Excel," so I thought I'd point people to the Digipede whitepaper page. My colleague Kim recently finished a great whitepaper on using Excel with the Digipede Network; check it out. She describes a bunch of different architectures (depending on your needs and level of expertise), all of which we've implemented in house.

And one of which I'll be demonstrating next Monday at Microsoft's 4th Annual Financial Services Developer Conference in Manhattan.

We've got a couple of other whitepapers up on that whitepaper page as well; if you've been following my blog peripherally but would like to dive in, take a look!

Technorati tags: grid computing, digipede, excel

Resources from MSDN Webcast

After my MSDN webcast, one attendee (ok, it was my wife!) suggested that I put a reading list up on my blog. Thanks, Cindy--good idea (and definitely the first time she suggested that I blog something!). I plan on creating a reading list at some point and putting that in the sidebar. In the meantime, here are the resources I mentioned in my talk today.

The paper I mentioned was Web Services and the Grid by Lee Liming of Argonne National Labs. I've referenced this here before. It's a great piece on why web services and grid computing go hand in hand.

The blogs I listed were:

Expert Texture: Robert Anderson (CTO of Digipede) on .NET development and grid

A Day in the Life: Kim Greenlee, Digipede Evangelist, on grid computing (including lots of Excel/grid interop)

But if you're interested in distributed computing, you should also check out:

All Things Distributed: Werner Vogel (CTO of Amazon) on, well, all things distributed

Grid Meter: Greg Nawrocki (President of the Globus Consortium) on grid computing

[Update 4/11/2006 4:54pm] By the way, the link to the webcast will be up tomorrow. Of course, I'll post it as soon as I get it. The next MSDN Webcast is Tuesday, April 25th at 11:00AM. I'll post a link to that as soon as its listing is correct! Oh, one more thing: there's a Digipede webinar tomorrow morning at 10:00 am PDT; if you're interested, go here for an invitation.

Technorati tags: grid computing, web services

My MSDN Webcast on Tuesday!

My first MSDN webcast is Tuesday April 11th at 11:00AM Pacific time. It's the deepest Object Oriented Programming for Grid talk that I've given outside of Code Camp.

For most of you who are reading this Tuesday morning...what are you waiting for?

Register here!

Technorati tags: OOP-G

Digipede News

I like writing about distributed computing more than I like writing company stuff (I feel so cheap when I do this!), but I also really like to spread good news!

My Gada.be feeds turned up two interesting bits of press about Digipede in the last 24 hours. Just in case you haven't set yours up yet, I thought I'd share them with you:

First, Mario Morejon of CRN magazine wrote a positively glowing piece about the Digipede Network. The headline says it all: Grid Computing Turns .Net Into Enterprise Powerhouse. I won't quote much here--just read the review; it's awesome. He gave us 5 stars!

Second, we were pleased to accept an invitation to Microsoft's BioIT Alliance. The BioIT Alliance is a group of companies "working to further integrate science and technology as a first step toward making personalized medicine a reality." Don Rule put it together--he's a very smart guy, and we're excited to be playing on his team.

Technorati tags: BioIT Alliance, digipede

Vogels on Scalability

Last December I participated in a bit of a debate about scalability. My main point (I was agreeing with Jeremy Wright at the time) was that good software has scalability designed in from the beginning. To quote myself:

...you may actually succeed and build something that people eventually use. Many people. If you are going to make it available on the web, and you're not designing for scalability, then you just aren't planning for success: you're planning for failure.

Well, on Thursday my sentiment was echoed by a pretty powerful voice: Werner Vogels, CTO of Amazon.com.

In his post A Word on Scalability Vogels sums it perfectly:

Why is scalability so hard? Because scalability cannot be an after-thought. It requires applications and platforms to be designed with scaling in mind, such that adding resources actually results in improving the performance or that if redundancy is introduced the system performance is not adversely affected.

Right on! I couldn't have said it better myself (even though I tried).

Vogels goes on to talk about the difficulties inherent in scaling: one he comes up with is the heterogeneity that creeps in when systems are expanded by adding hardware.

Heterogeneity means that some nodes will be able to process faster or store more data than other nodes in a system and algorithms that rely on uniformity either break down under these conditions or underutilize the newer resources.

It's a good point, and it's another compelling reason to use grid behind your SOA or SaaS. Why?

Because when you use a grid infrastructure, you don't have to write the code to handle the heterogeneity. Rather than have to write the algorithms to distribute your code, use a grid system that was designed for that task. It will ensure that your newer, high powered servers are utilized to their fullest potential and will also use your older servers as effectively as they can be used.

Vogels is right. Scalability is difficult. Scalability is important. My suggestion? Throw a grid at it!

Technorati tags: scalability, grid computing

MSDN Webcast: Object Oriented Programming for Grid

If you've seen one of my (or Kim's) presentations or attended a Digipede webinar, you've had a brief introduction to Object Oriented Programming for Grid.

I've been asked by Anand Iyer, a Microsoft Developer Community Champion, to give a couple of webcasts this month to go in depth on this technology. I'm thrilled at the opportunity.

We've outlined two courses; the first will be an introduction to Object Oriented Programming for Grid, along with general information about grid computing. In the second, we'll dive in deeper and show practical applications of grid: using a grid behind a forms app, behind an Excel spreadsheet, and behind a web service.

Sound interesting? The first is a week from tomorrow. Tuesday, April 11th, 11:00 PDT (that's 1900 GMT for you internationalites).

Register here.

The second one is April 25th at 11:00 PDT, and the registration is here.

Technorati tags: grid_computing, digipede, msdn, OOP-G

Cool Financial Applications on Windows

Here are some of the cool Microsoft Partners I met at the Financial Services Partners Summit. As usual, the best part of the summit was meeting other ISVs and find out what amazing things they're doing on the Microsoft Platform.

TAPSolutions: Their TAPMaster product acquires, stores, and manages market feed data.

Xenomorph: High performance database product, along with analytics and pricing tools to go along with it.

Eze Castle Software: Named for a real castle in France, Eze Castle has created a whole fleet of software for investment management firms.

ClusterSeven: They have tools and technology for managing, analysing and auditing Excel spreadsheets--a critical tool for compliance, among other uses.

Unrelated note: this is my 100th post at West Coast Grid. I've certainly enjoyed writing this blog so far, and I'm glad to get comments, questions and notes. I look forward to continuing this conversation!

Technorati tags: Microsoft partner, TAPSolutions, Eze Castle, Xenomorph, ClusterSeven

Microsoft Capital Markets Partner Summit

John and I spent Wednesday in Redmond at the Microsoft Capital Markets Partner Summit: a group of ISVs who provide tools into the Capital Markets space, and the Microsoft team that supports them.

There were some interesting companies there--I'll have another post on that later.

It was very interesting to see how Microsoft is changing their approaches to serving their customers.

On one hand, Microsoft doesn't sell very much direct to customers--indeed, something north of 95% of their revenue comes through partners.

On the other hand, Microsoft has a vested interest in talking with customers, ensuring that the end customers understand both the value of the OS and the value of the tools available on that OS.

That means that Microsoft has to work closely with their partners when talking to customers. The partners--ISVs--need to sell their products; but it's Microsoft's job to sell the platform.

For years, when a large financial company wanted to buy a large system, they went to a consulting company--say, IBM. IBM would put together a team of companies: hardware, OS, middleware, software vendors, and consulting services. It was an easy way for the customer to buy: one company was championing the whole thing (IBM in this example, but there are others). Moreover, from the customer's perspective, there was one "throat to grab" if things went wrong.

Microsoft wasn't selling that way at all. Microsoft got into financial companies the way they got into every other company on earth: selling operating systems for desktops and office applications. Then, in the late 90s and into the 21st century, a funny thing happened: Microsoft wrote a server operating system and a powerful database. Software vendors started writing high end packages on the platform.

But there's a rub: how do you sell this? Microsoft didn't write applications for finance, nor did they employ experts in the field. So they didn't have an effective way to tell potential customers about the virtues of their platform. And the software vendors knew a lot about their area of expertise, but they weren't heavyweight enough to push platform decisions on their customers. (I ought to know--I was writing enterprise software built on NT, SQL Server and IIS back in 1997. The platform was a tough sell)

In the last couple of years (especially in the last year), Microsoft has learned many lessons about selling into these types of enterprises. They have hired aggressively, bringing experts on staff who can speak the language of finance while preaching the benefits of the platform. They've also pursued the integrators: with Accenture, they created Avanade. They also work with many of the other big integrators.

They're holding events like yesterday's Capital Markets Partner Summit to help create a sense of community among partners--partners who may bid against each other on some deals, but are even more likely to have complementary products in many instances.

Finally, they're providing coordination as these efforts go forward. They can approach customers not piecemeal, but together: the platform, the software, and the integrators to make it work. And, by taking the lead, Microsoft is essentially offering up theirs as the "throat to grab."

Microsoft is doing the exact same thing in other industries, too (banking, manufacturing, health care, etc). They are helping us (the ISVs) bring our products to the market.

Most importantly, they are giving their customers a better, more complete picture of what they can have when they choose this platform: OS, database, software vendors, and integrators, all one one page.

It was a great couple of days. Thanks to Ed Muth, Kenny McBride, Rich Feldmann, Stevan Vidich, Christina Fritsch, and everyone who gave the great sessions.

Technorati tags: microsoft partner, microsoft

In Redmond tonight...

I'm in Redmond tonight and tomorrow for the Microsoft Capital Market Partner Summit--a gathering for partners with products and services in the financial realm.

John and I are going to a reception tonight, then we'll be painting Redmond, um, red. Or going back to the hotel and working. We'll see what happens.

We had a productive meeting with one finance ISV already this week--I hope this summit leads to more!

Anyone recommend a dinner place in Redmond? Anyone in Redmond want to talk distributed computing? 510-816-7551.

Technorati tags: microsoft, microsoft partner

What a week!

It was a busy week in Digipede-land, and I haven't found any blogging time at all.

We've been in final QA on our new release, Digipede Network 1.2. Most of the last few weeks has been install and upgrade QA. As it turns out, that's a bunch of work! The new version is fully compatible with both .NET 1.1 and .NET 2.0, and supports mixed-mode operation (some agents running .NET 1.1, some running .NET 2.0, and some running both, and all combinations thereof).

The week was made all the more interesting because my co-worker Nathan's wife had a baby! Exciting for them, and Nathan has been a trooper (literally dashing out of the hospital to hand software off to me on a USB key at one point). But he hasn't been in the office, which means I've been directly supporting customers and potential customers. That's always fun (as a product manager, talking to customers is probably the most rewarding part of my job)--but it's hard to be direct support when trying to get a release out the door!

But all's well that ends well. The release is done (!), and we've got at least one new customer this week (I hope we can release some details about it soon). We've also had some good talks with potential partners.

Technorati tags: digipede

Happy Pi Day

Happy Pi Day, everyone!

Technorati tags: pi day

How will they host it: Writely or wrongly?

Everybody has heard that Google bought Writely today. Congratulations to everyone involved.

Not everyone knows that Writely is built on .NET.

My question: who's going to host it?

Is Google going to port Writely to run on the Googleplex? Will they host it on .NET? Does Google already have .NET hosting ability? Will they use Mono?

To me, it's one of the most interesting facets of the acquisition.

Technorati tags: google, .net, writely

It's the Infrastructure

Update 2006-03-14 11:31 Changed a nonsensical word.

I spend a lot of time explaining the value of what Digipede does to people: whether it's potential customers, potential investors, my mom, or people riding next to me on BART--it's something I like talking about, and it's something I believe very strongly in. Add that together with my love for mellifluous voice, and it's a recipe for me talking about Digipede a lot!

One thing that's come up frequently lately is the idea of grid infrastructure.

Before I go too deeply into that, let me explain something about our customers. I can divide our customers neatly into two camps: customers who bought the Digipede Network to accelerate/scale/distribute a particular application, and customers who are using the Digipede Network for a much broader suite of applications.

To the former group of customers, it's a tool. They had a particular need for a particular piece of software, and they found that the Digipede Network filled that need.

To the second group of customers, though, it's much more than just a tool. It's now part of their development and IT infrastructures. We have one customer who is running at least three different applications on their grid now, and they will undoubtedly do more: they are porting current applications that need increased speed or scalability, but they are also looking at developing new applications. Their developers don't just have a new tool they can use: they also have an infrastructure that allows them to do something they've never been able to do before.

Having a grid infrastructure in place means that developers can begin to take on assignments that seemed impossible before--analyzing more data, or deeper analysis of a particular trade. Having much, much more powerful software means that the users' lives change. Rather than analyze hundreds of trades, they can analyze thousands. Rather than run a trade run once a day (at night, when everyone has gone home), they can run it frequently throughout the day.

A good grid infrastructure does more than just speed up an application. It changes the way the developers work. It changes the way the users work.

Technorati tags: grid_computing, infrastructure, digipede

Snark it up

Scoble, Carr, Winer and Searls have been snarking it up lately.

Robert has written a hilarious XML extension that will finally allow everyone to have full control over their snark...

Snark it up:

To this end, I want to introduce the HyperText Snarkup Language (HTSL) which will initially be described as simply an extension of XHTML with a namespace. This will allow publishers to have full control over their snark.

Technorati tags: snarkiness htsl

How's the generator business?

Nicholas Carr is vigorously defending his stance (Is the server market doomed?) in his latest post (More thoughts on servers).

I think he's still missing the boat.

In response to some counterarguments from Charles Zedlewski and John Clingan, Carr says:

Both argue that if servers become more efficient (through virtualization, for instance), then companies will tend to buy more of them, not fewer. If a product becomes more valuable, after all, you'll want more of it. That's a great point (for unit sales, if not for revenues), though I'm not sure it applies in this case. It's important to remember that what's really being consumed is computing cycles, not servers; through consolidation and virtualization companies may both consume a lot more cycles and buy a lot fewer boxes.

I don't think Carr gets the point at all. He makes a great realization ("what is being consumed is compute cycles"), but he doesn't really follow through with the thought.

The history of computing has shown very, very consistently: the consumption of compute cycles is on an ever-increasing path. Why? Because the faster computers get, the more uses people find for them. Carr seems to be implying that we have finally reached a point that our servers are doing everything they could possibly do: from here on out, making them faster will just diminish the number of servers we need.

He writes "companies may both consume a lot more cycles and buy a lot fewer boxes," but his argument sounds more like "if the number of cycles they need doesn't increase too much, they'll be able to buy fewer boxes." That would doom the server market indeed.

But that's not what happens with computers. Computers get faster. With each increase in speed, incredible new uses are found. They tax the machines. They need faster ones. Repeat.

Virtualization is another great use for machines--but it won't keep software developers from innovating, and it won't keep companies from inventing new, faster servers. Those things will continue to happen.

Moreover, Carr keeps blurring utility computing into his argument. Quoting Frank Sommers, he says:

And with standard application interfaces, such as J2EE, shouldn't a company's IT department be able to deploy an enterprise app into a remote data center's hosting environment?

Ah, there's the rub. There is no one standard. As I pointed out earlier, computes are not all alike.

While I believe strongly that there is a market for selling computes and for data centers, there is no way that will doom the server market.

And one last point to show that, while electricity is not computes, even the electricity analogy doesn't spell doom for the server companies. There was tremendous consolidation in the electric power industry when the idea of a "power plant" came about. But did that kill the industry that manufactures generators? No--there are still companies making billions of dollars manufacturing power generation equipment (I used to work for one of them). There is still tons of research going into ways to make power better.

As I said before: the server industry isn't doomed. It's evolving.

Technorati tags:grid computing, distributed computing, utility computing

Because 1.21 gigaflops just aren't 1.21 gigawatts

In his normally insightful blog this week, Nicholas Carr made a rather off-the-wall suggestion. He posits that the server industry is doomed, and as proof he writes about trends he sees happening: shifts away from high-end servers toward either blades or grids of commodity, off-the-shelf hardware (COTS).

He cites two examples: Sumitomo Mitsui Bank reduced 149 traditional servers with 14 blade servers, and Google runs all of its software on machines it assembles itself.

Of course, I don't think these two examples prove much at all. After all, the blade systems that he is referring to need to be supplied by somebody--and I think we will continue to see the traditional server manufacturers continuing to move in that direction. Blades won't kill the server market; they'll be part of it.

As for Google ("It buys cheap, commodity components and assembles them itself into vast clusters of computers"). Not every company is Google--we can't all buy so many machines that no one even notices when one dies. We can't all have people on staff to build our own machines, then spend their days roaming our aisles of racks pulling out the dead ones. Many of us depend on the quality that the server manufacturers deliver. Google isn't a typical company, or even a typical web company; one might say they're unique. So I don't think their lack of name-brand servers is a harbinger of doom.

But Carr gets way off-track when he then suggests that utility computing will kill the server industry:

If large, expert-run utility grids supplant subscale corporate data centers as the engines of computing, the need to buy branded servers would evaporate. The highly sophisticated engineers who build and operate the grids would, like Google's engineers, simply buy cheap subcomponents and use sophisticated software to tie them all together into large-scale computing powerplants.

I've seen many references to utility computing before, and I just don't buy it.

Partly, it's just physics. All electrons look alike (let's not get into electron spin here: as far as my appliances are concerned, every electron looks the same). It doesn't matter to me if the power that's lighting up my life, running my refrigerator, and powering my PC came from a wind farm, a hydroelectric plant, or a diesel turbine. Well, for environmental reasons, I might prefer the former two, but the point is that when an electron gets to me, I can't tell where it came from.

Computes just aren't the same. Computes look different on different operating systems. Not all software runs on all operating systems. Different people prefer different toolsets, and they always will. Some OSs are better for some things than others, and people choose the appropriate OSs for them. Yes, we've all read about "write once, run everywhere" software--but a small minority of software actually runs that way. OSs are different, and they will continue to be different. People will continue to write software that takes advantage of particular OSs.

Not all compute problems can be "shipped out" easily. There are huge data concerns. First of all, there are the ubiquitous privacy and security issues: some data people just don't want leaving their building.

Beyond that, though, there's the issue of data size and compute-to-byte ratio. If I need to do a quick search of a huge dataset I just collected from my genome lab or my jet design windtunnel, it may not make sense to move that to a "computing powerplant." Heck, I may be collecting tons of data in real time, and I need to analyze it in real time. I need my computes where my data is. As Jim Gray says, "Put the computation near the data." If your data are with you, that means your computes are with you as well.

Don't get me wrong: I'm a big believer in distributed computing, and I'm a big believer in grid computing. But I don't think that, in the future, I'm going to flip on the "compute switch" the way I flip on a light switch today.

Is the server market changing? Of course it is. Blades, virtualization, distributed computing: these are all changing the needs of the market. There will continue to be a high end market. There will continue to be a low end market. But utility computing will not kill servers.

1.21 gigawatts? What was I thinking?

Technorati tags: grid computing, distributed computing, utility computing, google

New SaaS book coming

Scanning Robert's Expert Texture link blog, I see a link to Fred Chong over at MSDN. Fred is a solutions architect at Microsoft, and he's been thinking a lot about SaaS.

In his latest post (SaaS is a journey, walk with us), he gives the table of contents of a book about that he and Gianpaolo are writing about SaaS.

The outline looks great; his summary of key points for architects is perfect:

Scale the application

Enable multi-tenant data

Facilitate customization

At my previous startup, Energy Interactive, we offered a product in the electric industry that we offered as an ASP (that's what we called SaaS back in the twentieth century). We went through everything Fred describes--only we weren't lucky enough to have a book to help us along!

The issues we had with scaling are part of what convinced us that we needed to start Digipede--it just wasn't easy to scale an application. When we looked around our datacenter and saw so many servers that could have been used (and even more when we looked around the rest our enterprise), we wanted an easy way to take an application and scale it out. The tools just weren't out there.

One nit with the table of contents: Fred's chapter on scaling doesn't seem to address distributed or grid computing at all. I'm a little surprised by that. Given the adaptability of grid to service oriented architecture (and I certainly view SaaS as a flavor of SOA) that has been noted lately by experts like Lee Liming and Greg Nawrocki, it seems that Fred and Gianpaolo would mention it. Fred lists the following issues:

Pools: thread, connections etc.

Async

Locks

States

UI/Presentation

How can you scale that application to a cluster? To a data center? How do you plan your hardware so you can handle peak demand without overspending? Whether grid is the answer or not, I'm certain that much SaaS will involve some flavor of distributed computing, and I hope these two go into some detail there.

By the way, it looks like Fred and Gianpaolo are going to cover a lot more than just technical issues--they've got chapters planned on everything from Business Model to Security to Instrumentation and Monitoring. That's fantastic. SaaS is so different in so many ways from traditional enterprise software, and I'm glad to see Microsoft folks lending their considerable wisdom and experience to help people along.

Technorati tags: digipede, grid computing, distributed computing, SaaS, SOA