[Beowulf] Redmond is at it, again

[Robert G. Brown]

On Tue, 25 May 2004, Jim Lux wrote:

> At 03:44 PM 5/25/2004 +0200, Eugen Leitl wrote:
> 
> >Management is on Microsoft's agenda, though. The company is hiring one
> >programmer to work on a "graphical and script-based user interface for
> >efficient job and resource management across large clusters" and another to
> >create "automated infrastructure to uncover performance and reliability
> >problems with high performance, large-scale server applications."
> 
> Wow! one whole body to work on graphical and script based user 
> interfaces!  Bill must really be quaking in his boots to invest $200K in this.
> 
> 
> >According to job postings, Microsoft is adapting MPI to Microsoft's .Net
> >infrastructure. A key foundation of .Net is the C# programming language and
> >the Common Language Runtime, or CLR, which lets C# programs run on a
> >multitude of different systems.
> 
> Fascinating... A C# binding for MPI?

There is a common and obvious thread to M$ choices under nearly all
circumstances.  It can easily be used to interpret the specific
decisions to make MPI "their own" and eschew TCP/IP, vendor network
drivers, ANSI standard C or C++ or f-whatever, and especially to
interface it with their own version of core network services:

  Standards are bad, unless we own them and can alter them on a whim to
  effectively clone, co-opt, and eliminate all competition from any
  products ever developed that are based on those "standards" and
  actually make money.

The key words here being "make money" of course.  Microsoft won't ever
jump on a cluster computing bandwagon unless it is running on wheels
they own and all of the seats have a highly proprietary "eject" button
somewhere they can use to get rid of all the rest of the instruments.

A corollary of the above is that "Java is Evil" (an opinion shared by at
least some people who don't work for M$:-).  Of course, so is nearly
everything else used in modern networks for the transport layer and most
of the layers above transport in the good old ISO/OSI scheme, so is
http, html, xml, php, perl, python and so forth, and Open Source, Open
Standard software is The Devil Himself -- to M$.

Current systems corporations are thinking "license/lease" and "renewable
revenue stream" instead of "software sales" as the latter era of the
computer revolution draws to a slow end.  Red Hat has gone there.  Sun
is well along the road.  Microsoft is stuck between a fervent wish to go
there and somehow preserve their high margins and the realities of the
expectations of their PC customers that they are "buying a copy" of the
operating system, not the right to use it for a year with automated
prepaid updates.  In the corporate world, however, they've moved a long
ways there and I feel confident that they'll go the rest of the way
soon.

So the interesting question is "where's the money" in this move.  The
HPC market hasn't proven to be exactly a get-rich-quick proposition for
any of the various groups that have prospected in it.  I suspect (given
the reference to "resource management" and "server applications") that
it is seeking to plunder the relatively deep pockets and relatively
non-computer-savvy researchers in the biocluster and medicluster market,
with their bet backed by the proposition that they can reuse their
efforts in a pinch in the HA market (those "server applications").
Bioclusters and biogrids as a market probably does total millions of
dollars per year -- chickenfeed for M$ at this point -- but it also has
some growth potential and integration potential for the future, when we
reach the point where e.g. individuals are bioassayed in real time in
their Dr.'s office, their genes are matched against a huge database
scanning for defects and predispositions and damage and who knows what
else, and genetically matched and tuned therapies are prescribed, where
dog pedigrees and likelyhood of developing hip dysplasia are similarly
determined in real time.

Of course, Moore's law and so forth may eat this market before it fully
matures -- in three or four years at expected rates desktop PCs will
have (possibly multiple) TB size LOCAL SINGLE disks, multiGB of RAM
standard, and at least gigabit interfaces standard with 10 Gbps not
uncommon.  With 10+ GHz CPU clocks, 64 bit and better data paths, really
slick memory and device management, and perhaps some onboard
parallelism, would one NEED a cluster to run such a (relatively simple)
application?  If not, it leaves one back with just the research market,
and that is, I think, a hopeless case for M$ to make back their not
inconsiderable development and sales costs in without a hedge.  They
would at best break even and at worst would both lose money and worse,
lose money EMBARRASSINGLY and publically.

As this list well knows, real, transparent, "windows-level" scalability
is an elusive beast in the parallel HPC world, although you can find
niches where it is possible.  And there is no mass market here, per se
-- even if you can find somebody crazy enough to pay out LARGE software
costs that scale per node, there simply aren't that many customers, and
most of those customers always have several proven alternatives with
costs that DON'T scale per node.  Those customers will pay for support,
they'll pay for service, but they don't like paying for software and
REALLY hate paying for software and getting lousy service and poor
support to go with it.  Plenty of people make money on service and
support, but they don't get (unduly) rich and they work for a living
earning what they earn.

   rgb

> 
> 
> James Lux, P.E.
> Spacecraft Telecommunications Section
> Jet Propulsion Laboratory, Mail Stop 161-213
> 4800 Oak Grove Drive
> Pasadena CA 91109
> tel: (818)354-2075
> fax: (818)393-6875
> 
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
> 

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu