November 21st, 2009

Educating IT decision makers

Posted by Paul Murphy @ 12:15 am

Categories: Applications, Enterprise Policy, General, Productivity, Strategy

Tags: Education, Risk, Information Technology, Strategy, Management, Paul Murphy

One of the more difficult questions behind some of the discussion here over the last week or so involves the extent to which we should try to educate our users so they can make informed choices.

The most basic problem, of course, is that it’s easy to support education in the abstract and extremely difficult, particularly when you’re involved with real world decision making, to separate education from advocacy.

I’ve got an unusually nasty version of that problem with a project I’m working on because I’m on both sides of the fence: user and techi. As a user I’m quite sure I know better than anyone else what needs to be done, and as a techi I’m quite sure I know better than anyone else how to get it done - the problem being, of course, that’s there’s no actual evidence to support either belief.

In this particular case, and I suspect often enough in other contexts, what’s going on is that I’ve spent a lot more time on this then they have, and as I help them catch up, both their views and mine are going to get modified. We are, in other words, most likely to educate each other about the specifics of the one and only right way of doing this - i.e. the one that evolves for us over time.

However, if I peer deeply enough into my navel, I think I can clearly group the issues or things about which there’s consensual uncertainty into three categories - and maybe learn something from doing that:

1. there are clear issues of fact on which I’m convinced my conclusions are largely unassailable.

   For example, I expect to use open source software, on Unix, for this - and maintain that for the particular class of application we need, Domino is the only proprietary option that makes the slightest sense, but that would be too expensive. (In fact, it would cost about $250K more upfront than using an open source mix, but in the long run the most likely IT related risk to be realized by this organization is that they hire an idiot to run the system - and using Domino could reduce both the risk of that happening and the rate of IT collapse if it does.)

   On these kinds of issues, therefore, I see no distinction between preaching the obvious to my user colleagues and educating them.

2. there are conclusions I’m equally sure about, but can see counter-arguments on - most are cases where cash costs are knowable, but the costs of what happens if some risk is realized, are not.

   For example, I’m convinced that the risks of using cloud anything vastly exceed the cost of owning and operating almost everything (except the net) ourselves. At the same time, however, bandwidth costs (especially in Canada where they’re more than three times comparable U.S. numbers) make a powerful argument for using other people’s bandwidth, and thus other people’s servers. Notice, however, this this isn’t as simple as it seems: a good compromise may be to do everything in house, but rent space on servers maintained by the three network carriers as store and forward points for bandwidth intensive material like videos.

   On these kinds of issues, therefore, I try to very carefully separate advocacy from education - explaining costs and risks in as nearly objective terms as possible, while stressing that decisions made to minimize risk (as opposed to decisions made to reduce immediate dollar costs) are almost always highly subjective. Thus showing them what the cost choices are is mostly education, but valuing risks avoided is mostly advocacy.

3. there are conclusions that reflect little more than bias and familiarity - but that familiarity is a ticket to both risk and cost reduction.

   I’m comfortable, for example, with limesurvey and think it can do a particular part of the job very well. Is it really the only choice? No, but it’s the only choice I’m immediately comfortable with and therefore the one I’d like to educate my users to choose - except, of course, that’s it’s pure advocacy for me to do so.

So where can we sensibly draw the line between advocacy and education? Logically it’s education if it helps them make their own choices, and advocacy otherwise - but, in practice education is often so slanted as to be indistinguishable from advocacy (even by those involved) unless you already know enough about the subject not to need to education. As a result my bottom line is a cop out: the idea that just making sure that both you and your users are aware of the issue and the impact it has on your working relationship is half the battle - while the other half is both so situation specific and touchy-feebly in nature that it’s like walking through a minefield: every step an adventure, and your first mistake also your last.

November 7th, 2009

The real pros and cons of server virtualization

Posted by Paul Murphy @ 12:15 am

Categories: Enterprise Policy, General, Linux, Productivity, Software Licensing, Strategy, Sun

Tags: Data-processing, Server, VMware Inc., Server Virtualization, IBM Corp., VM, System Utilization, Virtualization, Hardware, Paul Murphy

First, lets be clear: this comment is about server virtualization through ghosting - the business of using one OS to run one or more ghost OSes in lieu of applications each of which in turn is able to run one or more applications - it’s not about desktops, not about N1 type technologies, and not about containerization.

The pre-eminent examples of ghosting OSes are IBM’s zVM - an OS that originated in the late 1960s as one answer to the memory management and application isolation problems confronting the industry at the time- and VMware’s more recent rendition of the same ideas for x86.

Back then, IBM was caught between rocks and hard places: lots of people (including IBM’s own research leaders) were developing system resident interactive OSes aimed at using the computer largely as a central information switch, but its commercial customer base absolutely refused to countenance any advance on the batch tabulation and reporting model around which its management ideas had evolved in the 1920s and 30s.

Thus when the Multics design effort started at MIT in 1959/60, most of IBM’s people didn’t even know there were two sides to the argument but the research people lined up with science based computing while those who made the money for IBM almost unanimously choose the data processing side - and ten years later, after MIT’s people had first won their design battles and then lost the war (by letting data processing get control of the Multics development effort), IBM’s own fence sitting solution: VM, ended up roundly hated by nearly everyone.

Nearly everyone, that is, except people limited to IBM 360 class hardware who had no other means of achieving any kind of interactive use (this was before MTS and a dozen later solutions) - and they, essentially over the objections of IBM’s own management, made VM the success it still is.

All of which brings us to the 90s when available x86 hardware mostly wouldn’t run NT 3.51 and Microsoft’s emergency iVMS port, aka 4.0, contained a misconstrued uaf derivative known as registry that effectively limited it to loading one application at a time - thus forcing buyers to choose between a lot of downtime or rackmounts of dedicated little boxes.

The rackmounts won - at least for a few years; but then data processing got took control of the wintel world and VM, in the VMware incarnation of its ideas, soon became the preferred tool for reducing the rackmount count in the name of their professional holy grail: higher system utilization.

Unfortunately there are two big problems with this:

1. first, NT 4’s limitations went away with NT 4 - addressing them today with VMs achieves a level of absurdity no audience would accept in musical comedy -it’s right up there with using a licensed terminal emulation on a licensed PC to access a licensed server running a licensed PC emulation; and,

2. it is very nearly a universal truth that every gain data processing makes in improving system utilization produces a larger loss in IT productivity for the business paying them to do it.

The reductio ad absurdum example of the latter is Linux running under VM on a zSeries machine: data processing can get very close to 100% system utilization with this approach, but the cost per unit of application work done will be on the order of twenty times what it would be running the same application directly on Lintel; and every variable in the user value equation: from response time to the freedom to innovate, gains a negative exponent.

You can see the latter consequence in virtually every result on benchmarks featuring some kind of interaction processing. For example, the Sun/Oracle people behind their recent recent foray into TPC/C, both demonstrated their own utter incompetence as IT professionals by achieving less than 50% CPU utilization and the user value of this “failure” by turning in response times averaging roughly one seventeenth of IBM’s:

The counter argument I usually hear about all this is that virtual system images are more easily managed than real ones - and this is both perfectly true and utterly specious.

It’s perfectly true that VM style virtualization lets you bundle an application with everything it needs to run except hardware, and then move that bundle between machines at the click of an icon; but the simple fact that this applies just as well to Solaris containers as it does to VM ghosts shows that this is an argument for encapsulation and application isolation, not for ghosting.

Worse, the argument is completely specious because it bases its value claims on two demonstrably false beliefs: first that the only alternative is the traditional isolated machine structure, and second that virtualization lets the business achieve more for less. Both are utter nonsense: Unix process management has worked better than VM since the 1970s, and because virtualization adds both overheads and licensing it always costs more to do less than modern alternatives like containerization or simply letting the Unix process management technology do its job.

Again the quintessential example of this is from the heart of the data processing profession: when you take a $20 million dollar zSeries installation and achieve a 60 way split to produce 100% system utilization from 60 logical machines running applications or ghosts, what the business gets out of it is roughly equivalent to what it would get from four Lintel racks costing a cumulative $500,000.

A more down home illustration is provided by VMware itself - their competitive value calculator computes a cost advantage for their products over those from others on the basis of their belief that their VMs impose less overhead and allow you to get closer to 100% hardware utilization. Thus if you enter values saying you’ve got 200 applications running on NAS connected quad core servers, want to manage virtually, and have average infrastructure costs, they produce a table with this data:

All of which should raise a couple of questions in your mind:

1. first, if the consensus that ghosting doesn’t have significant overhead is right, where is VMware getting the third of the box it claims you can recover by getting its ghosting software instead of Microsoft’s?

2. and, second, wouldn’t the money VMware wants you to spend on ghosting ($241K in this example) be better spent on hiring people who can move these applications to free environments like Linux or OpenSolaris?

So what’s the bottom line? Simple: the real ghost in ghosting is that of 1920s data processing - and the right way to see this particular con job for the professional cost sink it is, is to focus on costs to the business, not ideological comfort in IT.

October 10th, 2009

Clouds vs. Appliances

Posted by Paul Murphy @ 12:15 am

Categories: Applications, General, Strategy

Tags: Data Center, Information Technology, Data-processing, Data Centers, Cloud Computing, Virtualization, Strategy, Storage, Hardware, Data Management

When people talk about cloud computing as the future of corporate IT they’re generally thinking more or less in terms of traditional applications coupled with some processor intensive work in areas like business analytics or numerical analysis. I don’t think any of that’s going to happen - instead I think that cloud computing will evolve mainly into services for smart phones and ultimately form a kind of connective fog: an extension of present internet usage providing the processing needed to accomodate mostly store and forward type functionality.

If the upside of traditionally conceived cloud computing is exactly that of 70s style time sharing - namely, that you neither own nor operate the infrastructure and can therefore largely bypass internal IT to get applications working on it - its nemisis is exactly the same too: cheap local computing.

That’s what the PC promised and why so many corporate managers took advantage of data processing’s eagerness to buy from IBM to order hundreds, and often thousands, of PC/ATs when those first came out - and it’s also why many became even more cynical about IT when the first machines turned out to be laughably inadequate and later ones proved so unreliable that technologies brought in to free users from the data center are now owned by the data center and run by the data center.

Appliance computing, a model under which the customer buys a service delivered via a local processor local IT does not have root access to, had a brief resurgence in the ninties but neither the machines nor the software then available could handle larger, more complex, corporate applications without considerable on site expertise. At the time, therefore, that solution was largely limited to perceived simple and peripheral tasks of the kind we now associate with “purely hardware” solutions (like routing) or hosted services (like running Apache servers).

Today, however, those limits are largely gone and there are no big technical gotcha’s facing a company that wants to sell its customers things like fully vendor installed and vendor monitored ERP/SCP applications running on supplied servers and desktop displays entirely on the customer’s premises and physically in the customer’s control.

To get these the customer would simply sign a usage agreement and provide appropriate space, power, and network access to the vendor. Once installed, users would treat the applications the way they do the telephone: as something that just works and is monitored externally rather than by local data processing people - and, of course, if the vendor went under, they would simply take possession of the equipment, invoke contractual rights to passwords and licenses kept in escrow, and have at least as much time to adapt as they would if traditional IT had brought the applications on board in the traditional way.

The beauty of this approach is that it gives user management willing to accept standardized software direct control of its own IT while reducing both cash costs and business risk - quite the opposite of what this rather inadvertent bottom line comment (from a March 2009 Financial Times report on a gmail shutdown) reveals about the essence of cloud computing:

The glitch that led to the first global shutdown of Gmail since August began on Tuesday, during routine maintenance.

There’ve been what? five so far this year?

September 12th, 2009

Pano, Sun Ray, and the Wintel gestalt

Posted by Paul Murphy @ 12:15 am

Categories: Applications, Development, Enterprise Policy, General, Hardware, Strategy, Sun

Tags: Wintel, Smart Display, PC, Sun Microsystems Inc., Sun Ray, Pano, Desktops, Hardware, Paul Murphy

The latest, most wonderous, hula-hoop to hit Wintel is the zero client - and the process by which a 15 year old Unix innovation finally made it to the Wintel community shared consciousness illustrates both how PC marketing works and something about the consequences of taking the PC press too seriously.

Years ago HP offered the option of putting the keyboard, screen, and mouse on the user desk and the PC on a rack in the data center - but this idea didn’t sell well. In today’s version that physical PC has become a ghost: a virtual PC running in server memory, and quite a few companies are now selling smarter ways of connecting the desktop to it than the traditional Wintel approach in which real licensed PCs run licensed PC emulators accessing licensed virtual PCs.

Right now the company at the leading edge of this seems to be Panologic - makers of the Pano System. The Pano is a neat device: it does no local computing, can provide some cryptology support, and uses the standard network to connect to the host session - now limited to a virtual PC running under some OS like VMware’s.

If that reminds you of the original Sun Ray, it should because other than requiring the server to load and run a 512MB Windows emulation to run a 10K user process, the Pano System offers roughly the same features, costs roughly the same, is managed roughly the same way, and provides roughly the same benefits in terms of cost, heat and noise elimination, manageability, and desktop security.

Lots of PC reviewers love this thing - zdnet’s own Jason Perlow calls it “revolutionary” and sees a big role for future zero clients running Linux.

Now, personally, I’m hoping Pano does extremely well: that Gartner’s projection of 660 million virtual PCs by 2011 turns out an underestimate, because the ideas behind it are both inevitable in the long run and as valuable to business now as they were 15 years ago - but the company’s success in raising its own hype rating raises a question: what makes Pano hot where Sun Ray has long been an untouchable?

The answer, I think, comes in two parts: first Sun marketing refused to sell Sun Ray as what it is: a smart display; and instead insisted on pretending it is what it isn’t: a thin client. Pano’s self description as a “zero client” is lot better; in fact, it’s halfway home because both devices are smart displays and not clients at all.

The second part is more subtle: ever wonder why getting drunk together has been a bonding ritual for thousands of years? It’s the civilian version of playing with the elephant because alcohol, like terror, both cripples and isolates - making getting drunk together a powerful means of forming an Us by imposing the mutual equality of incapacitation on its members while setting up a strong boundary against Them - the sober people outside. Pano’s limitations and marketing are designed, I think, to exploit this phenomenon: to use Pano you have to have Windows, you have to have Active Directory, you have to have VMware (or something similar), you have to have x86, and the sales pitch assumes a whole panoply of popular delusion: from the value of PC style virtualization to climate change guilt - while Sun Ray, of course, presents as the sober opposite: a content agnostic device sold on value.

So what’s the bottom line? if you’re running an all wintel shop and think that’s your future: I suggest you ignore Pano’s sales pitch to take a close look at the cost, security, and managability benefits products like theirs can bring you - and when you find out for yourself how well the smart display idea works, you should then ask whose bad advice led you to not take this route ten or even fifteen years ago.

August 8th, 2009

The! meaning! of! bing!

Posted by Paul Murphy @ 12:15 am

Categories: Apple, Applications, Database Management, Enterprise Policy, General, Strategy

Tags: Dell Computer Corp., Hewlett-Packard Co., Oracle Corp., Information Technology, Sun Microsystems Inc., Microsoft Corp., IBM Corp., Sales Strategy, Strategy, Sales Force Management

On the surface the bing/yahoo deal carries a simple technical message: unstructured search has finally defeated structured search. Less obviously, however, the real meaning of the deal may be financial.

IBM, Sun/Oracle, and Apple are all integrated businesses selling hardware, software, and IT services to customers worldwide. IBM and Sun/Oracle are direct competitors in commercial IT, while Apple sells from a unique consumer communications perspective, but each develops IT and related technology for its own markets and offers its customers everything from career support to systems that work.

In comparison the HP/Dell/MS/Intel grouping is a strategic mess. Between them they cover the same markets the other three do, but no single player dominates; the people they depend on for sales are aging; competition from outside the group is fierce; and technically they’re not in the game with the other three.

So what to do? HP has succeeded in becoming Compaq; but, like the original, they’re hurt by their lack of OS, application, and engineering control. Meanwhile, Dell is just a house branded reseller, Intel continues its long and proud history of popularizing AMD technologies; and Microsoft is constrained by its organizational inability to transcend its own x86 programming and sales models.

To succeed against IBM and Sun/Oracle the Wintel group need more than mere momentum; it needs tighter integration, and a more engineered product focus. When and how that will come about is an open question - but Microsoft’s recent ads for the non existent Microsoft PC suggest, I think, that they’ve chosen to to address this by building an integrated products and services company of their own. Thus the financial meaning of the Yahoo deal might be that Microsoft gets a longer reach, but keeps its cash available for strategic acquisition: presumably either HP or Dell.

That would give the world three big integrated IT suppliers plus Apple: all offering their customers everything from hardware to application support services -with IBM selling into its traditional big money DP markets, Sun/Oracle selling advanced technologies and packaged applications, and the Microsoft PC company straddling in the middle: advertising technology but mainly selling to hobbyists, small businesses, and data processing.

So which one? I’d bet on Microsoft going after Dell now and AMD later because that will force HP and Intel to make some deeply traumatic choices - but there’s no good reason Mr. Balmer couldn’t cut the Microsoft PC company’s long term cost of slaughtering HP by going after both companies right now: he’s got the money; anti-trust in the Obama is just a loyalties issue; and a survivor, if there is one, would be seriously weakened.

May 2nd, 2009

Oracle Office, MySQL, and other dreams

Posted by Paul Murphy @ 12:15 am

Categories: Applications, Database Management, Enterprise Policy, General, Linux, Software Licensing, Strategy, Sun

Tags: Oracle Corp., MySQL, Sun Microsystems Inc., OpenDocument Format, OpenDocument Format (ODF), StarOffice, Open Source, OpenOffice, Databases, Emerging Technologies

Most people don’t know this, but at one time Oracle Corporation ran an extensive internal beta adding a pretty good word processor and spreadsheet to the Oracle Office communications product most recently renamed Oracle Beehive and now positioned against both Exchange and Domino.

At the time I didn’t see the combination as competitive with Applixware or even Q-Office, but recommended it for sale because it did one thing better than any competitive product I knew of: it stored everything as rows in the standard database.

Sun does not own OpenOffice.org and Oracle, accordingly, isn’t buying it - but because Sun does own the StarOffice product and is the primary contributor to OpenOffice.org, Oracle is buying both influence with, and responsibility to, that community.

If Sun and Oracle now recreate the full Oracle Office by combining Beehive with StarOffice, ensuring standardized database storage for all data, and open sourcing some of Oracle’s forms based development tools into the bargain, almost everyone stands to gain.

The obvious effect, of course, is to give OpenOffice a tremendous technical advantage over Microsoft Office while, at the same time, adding communications technologies and a real Access competitor.

I think, however, that two rather more subtle effects would dominate the future impact such a product would have.

First there’s the impact on the whole ODF scene. Right now, and for the past ten years, I’d argue that the eminently logical separation of storage from format is what’s enabled Microsoft to stall on ODF by keeping the brightly colored ball bouncing in the public eye while quietly and effectively selling internal integration as the justification for knee capping ODF at every opportunity.

Force content and format information to be stored in a single, consistent, way however and Microsoft’s wiggle room get reduced while accurate format conversions become easier - meaning that a new Oracle Office would ultimately have an enormous impact directly in terms of getting truly open document format standards widely accepted and used - and indirectly in terms of empowering the Linux desktop.

Second, for this to really work in light of Sun’s existing licensing commitments, Oracle would have to open source the database and communications components for Oracle Office. Since MySQL is well suited to the job and already open source, my guess is that the pros and cons of using it would then tilt in favor - meaning that my hypothetical Oracle Office would boost the MySQL community first by creating long term support commitments and secondly by putting it at the core of a lot of Exchange replacements.

One note:

1. I’m assuming that Oracle will neither want, nor be able, to sell Sun’s MySQL asset as a going concern.

   The reason I’m making this assumption is that Sun’s billion dollars didn’t so much buy an asset as deny IBM the chance to increase Sun’s dependence on Oracle for hardware sales - meaning that there isn’t much there, and simply spinning the commitment off into a tax exempt foundation would return far less to Oracle shareholders than using MySQL to gain credibility and support in the open source community will.

April 25th, 2009

A question about Linux

Posted by Paul Murphy @ 12:15 am

Categories: Development, Enterprise Policy, General, Hardware, Infrastructure, Linux, Strategy, Sun

Tags: HP-UX, IBM AIX, Intel X86, Data-processing, Linux, UNIX, Operating Systems, Open Source, Sun Solaris, Software

Every once in a while I get email like this one:

I’m interested to get your opinion on Linux and how it compares to UNIX and other UNIX-like operating systems. The desktop distributions I have tried have all had their issues, but most of those problems are cosmetic in nature. However, I’m wondering how Linux compares with the other operating systems from a kernel and design perspective. To me it seems like Linux has a lot of backing and buzz, but I also hear rants from people such as Theo de Raadt who say things like “Linux has never been about quality. There are so many parts of the system that are just these cheap little hacks, and it happens to run”. However, the same could have been said about Unix 30 years ago. Personally I prefer FreeBSD due to its simplicity and cohesiveness. I also think that AIX/HP-UX/Solaris are much more capable but will eventually disappear because they cost money (except for Solaris) and Linux doesn’t.

If Linux really is crap and it’s going to kill “better” operating systems, is it a bad operating system in the long run? Thanks for your insight.

To which my typical response runs something like this:

1) kernel comparisons take a lot of time - time I don’t have, sorry.

2) however, Linux is NOT crap. It works -and it works well. Compare Linux to Windows in terms of its failures and susceptibility to attack and it’s insanely great.

What de Raadt and others (including me) mean when we say Linux is a second rate Unix is that Solaris is better for users and OpenBSD is more secure - but remember that the gap between Solaris and Linux is quite small relative to the gulf between Linux and Windows.

The biggest thing both for and against Linux is that it has always been heavily optimized for x86 - it started as a minix kernel hack aimed at making it run better on x86 by replacing object messaging with x86 interrupts. On the ++ side, it’s very efficient and reliable on x86, on the - side the internals can be seen as a collection of appeasements aimed at x86 design weaknesses.

3) and please keep a sense of perspective: Linux works - and if kernel designers like de Raadt get excited about a competitor’s bad choices - well, they’re right, but that should only really matter to people who share their interests. From a user perspective, the weaknesses built into Linux can be seen as operational strengths (provided your hardware is x86).

Notice, however, that this response doesn’t address his last paragraph:

I also think that AIX/HP-UX/Solaris are much more capable but will eventually disappear because they cost money (except for Solaris) and Linux doesn’t. If Linux really is crap and it’s going to kill “better” operating systems, is it a bad operating system in the long run? Thanks for your insight.

And, of course, it’s the claims he makes here, and the question he raises, that I want to address today.

First he postulates that free Linux will kill AIX and HP-UX while hurting Solaris.

HP-UX was always another Unix that sucked horribly but worked extremely well on PA-RISC machines with the memory and bus architecture the 10/11 kernel was designed for, but like Linux with respect to x86, isn’t efficient when ported to other architectures. As a result it scales well on Itanium, but everything runs well below processor potential - and even on the N-Class machines (which had PA RISC CPUs in boards designed for Itanium) performance never rose to two thirds what it should have been based on cycle for cycle comparisons to the predecessor K class.

Thus HP’s slow strangulation of the HP-UX golem on Itanium is simply collateral to their decision to kill PA RISC in pursuit of a strategic role as the service supplier in an HP, Intel, and Microsoft computing world triopoly.

Linux had nothing to do with this - it’s HP’s executive, not Linux, that’s killing off x86 competitors; and, correspondingly, it’s the opportunity to sell x86 against SPARC, and Power (along with Alpha and PA RISC) that powers the company’s support for Linux.

AIX, in contrast, probably has a future simply because Linux on Power hasn’t been a big winner for IBM.

It’s my belief, by the way, that the reason for that has little or nothing to do with technology or applications lock-in and almost everything to do with mindset. Look closely at AIX and what you see is two intermingled, but very different, kernels: the core NCR/AT&T Unix that makes it all work, and twenty years of encrusted competitive and authoritarian enablement making it saleable to data processing people.

Thus what makes it both possible and necessary for IBM to upsell its adherents to AIX from Linux on Power is largely that Linux lacks the control orientation inherent in the data processing mindset - think of it this way: the AIX default on just about everything is Deny, the Solaris default is generally Allow, and lots of data processing people get very uncomfortable around Linux because it falls closer to the Solaris standard than theirs on trusting users.

If, for example, you wanted to migrate a Sybase ASE 12.51 ERP instance running under HP-UX 11i to 15.1 on both Solaris and AIX, you’d find that the Solaris port takes about two hour’s work with a day’s worth of waiting around for things to happen, while the AIX one takes six to ten days - with most of that spent getting disk storage issues resolved (volume management and network storage are performance killers; the job boundaries imposed by the typical IBM data center mean that even trivial changes require meetings and memos; and, of course, the smart thing to do - working directly with AIX local devices - is a lot like hanging wallpaper in the dark) and making sure that both user and system processes have all the right authorizations - because they never do, and you don’t find out until things blow up.

So while I agree that HP-UX appears headed for the scrap heap, I don’t see the data processing mindset relinquishing all the controls and procedural detours they’ve managed to get into AIX any time soon - and in that context IBM’s efforts to get their cell based processors working properly without Linux have something of the slow motion train wreck about them that’s deeply reminiscent of their 1972 decision to can the “future systems” project.

So what’s the bottom line answer here? Linux is a pretty good Unix, and contrary to popular wisdom it’s not killing any other major Unix variant:

• It’s HP, not Linux and not the market, that’s killed PA-RISC and killing HP-UX;

• Linux isn’t killing AIX either because IBM’s decisions about AIX are likely to reflect data processing preferences - and their struggles with Power7 are really about keeping those customers buying.
• Contrary to Red Hat, Linux isn’t killing Solaris either.

  You hear about this all the time, but it’s mostly just FUD being spread by people who want to sell you a free Linux - when you look at the actual decisions people who replace older SPARC/Solaris installations with new Lintel stuff are making, it turns out they’re generally doing it because x86 is now performance competitive at the loads those machines carried, easier to get approved by senior managers who read drug store ads for PCs, and preferable to actually going Wintel.

The second part of his question was whether the role he sees Linux playing in the deaths of HP-UX, AIX, and Solaris makes choosing Linux counter-productive in the longer term. The answer to that, I think, is No - because Linux isn’t killing any other Unix; it’s giving people who want to move to x86 a better, and often cheaper, alternative to Windows.

April 18th, 2009

What Sun can do now - and why you should help.

Posted by Paul Murphy @ 12:15 am

Categories: Applications, Development, Enterprise Policy, General, Strategy, Sun

Tags: Paul Murphy

The new problems Sun’s executive faces now include:

1. Southeastern’s attempt to sell the company out from under management has given at least IBM and possibly others unprecedented access to Sun confidential information - information a competitor should not have and which must now be devalued.

2. The publicity accorded the leaked information about the discussions has caused significant damage to Sun’s long term credibility as a key infrastructure supplier - creating considerable FUD, delaying customer purchase decisions, and causing a lot of “market analysts” and “journalists” to prove their commitments to the more powerful advertisers by presenting unusually vitriolic and uninformed commentaries attacking Sun, its executives, and its customers - this one, by Computerworld’s Thibodeau , for example, ingratiates itself with just the right people to look objective while managing all three forms of attack in only about 360 words.

   Since the marketing organization fundamentally focuses on making large discounted sales to a small group of big customers and, unfortunately, these are the buyers most likely to make long term changes in response to precisely the kind of FUD loosed by this debacle, there’s a real risk the impact will be amplified across the next few customer budget cycles.

3. a lot of valuable Sun people, and not many deadweights, are updating their resumes and talking to friends about new opportunities.

And, in addition, none of the old problems have gone away:

1. quarterly performance pressure drives many executive decisions, forcing short term responses -like the volume customer focus in sales and announced layoffs- sabotaging long term strategies;

2. the Wall Street shell game in which players sell blocks of Sun shares at a small loss per share to drive up the value of a collaborator’s investments in competitors, continues - and, of course, the only guarantee coming out of the “indigo” mess is that, absent significant change, variations on this will happen again.
3. most of the market, and many among Sun’s own staff, have no idea how the SPARC products line up against x86; no appreciation for the differences between Solaris and Linux; and no interest in learning how unloved products from Sun Ray to the CMT cryptology processors can produce huge savings and/or productivity improvements for customers.

   There’s a vicious cycle here: as quota pressure drives salespeople to sell what’s selling, and mass media support drives customers to favor dumb solutions, the people who should be explaining the cost, security, and productivity advantages that go with SPARC/Solaris become increasingly unwilling and unable to do so - and so more and more SPARC sales go to fewer and fewer large customers whose technical strengths lead them to demand the product - and whose technical people are under pressure from within data processing to buy IBM and from the executive suite to buy Wintel.

The basic bottom line on strategies to date is that appeasing Wall Street doesn’t work, that selling to a diminishing number of ever larger customers invokes enormous business risks, and that having great products doesn’t count for anything if neither the customer nor your own sales people want to know about them.

So what to do? How about:

• spin off the x86 business as a separate company - tied to the original through agreements on early technology access, OpenSolaris, and big customer marketing;

• look into the feasibility of setting up the open source software businesses as a charitable foundation;
• take the rest of the company private via a leveraged employee buyout;
• build a new marketing division aimed at selling in ones and twos to smaller customers:
  • work with the tens of thousands of “joe’s computing” shops run by capable people around the world to sell directly to smaller companies looking for precisely the savings, power, reliability, and security offered by the combination of SPARC/Solaris hardware, open source software, and local support;

  • train up “local joe” by providing extensive business and technical support;
  • motivate “local joe” by helping him build pride in his work while selling more support and services to the customer - paid for by the customer’s savings over the default Wintel decision.
• develop a couple of longer term, high visibility, showcase projects for both the technology and the company; and,
• launch one other, major, initiative I don’t want to discuss in public.

And one more thing: a lot of people don’t share my interest in Sun technologies and tell me they’d just as soon see the company go under. Setting aside those with personal motivations (usually some form of fear of competence) for that position, most of the people I’ve talked to who believe this won’t affect them simply haven’t thought it through.

The big reason you should be working to help Sun survive and prosper even if you never want to use any open source product it contributes to, or any product it sells, is that competition is good for the industry.

Witness, for example, Intel’s “new” Nehalem line - it’s great right? By Wintel standards, it is - but if Sun hadn’t lent AMD some people to design x64 and then supported the company by building its own motherboards to demonstrate what x86 multi-core could do, you’d be paying HP’s prices for Itanium desktops - Itanium performance, and Itanium security.

If Sun dies, a lot of innovation dies with it - and you’ll be paying a lot more for a lot longer to Intel, IBM, and Microsoft.

So what’s the bottom line? Simple, Sun can get its act together - and you, whoever you are, should help because their success, even if you never buy from them, forces others to lower their prices while increasing the value you get from the people you do buy from.

April 11th, 2009

Using open source to reduce business risk

Posted by Paul Murphy @ 12:15 am

Categories: Applications, Database Management, Enterprise Policy, General, Linux, Strategy

Tags: Open Source, Paul Murphy

Everything considered, especially the fact that it’s Easter weekend, you’d expect this blog entry to be about Sun’s nearly miraculous escape from IBM and its future as an employee owned business - but it’s not, because I think it’s too early to tell just how much damage IBM managed to inflict and only the sheer viciousness of the personal attacks now being made on Jonathan Schwartz and other key Sun players supports the idea that Southeastern has played its last big card, and lost.

What I’d like to talk about instead is using open source to protect your IT operation from some of the third party risks attendant on the current recession/depression.

The proposition is that if you spend enough on licensing and support for proprietary software that could be replaced by open source products that not paying those fees would let you hire and retain at least two open source developers, then doing so makes sense because it reduces operational risk while increasing downstream flexibility. Read the rest of this entry »

April 4th, 2009

Betting on the future: T2 vs. Nehalem

Posted by Paul Murphy @ 12:15 am

Categories: Applications, Database Management, Enterprise Policy, General, Hardware, Linux, Storage, Strategy, Sun

Tags: T2, Sun Microsystems Inc., Sun Sparc, Advanced Micro Devices Inc., IBM Corp., Nehalem, Sun Solaris, Processors, Servers, Operating Systems

It’s April, quite a lot of senior IT people in larger business and government organizations have signed-off on the typical third to half of the fiscal 2009/2010 IT capital budget they pre-committed during fiscal 2008/9, and are now looking at what changed, and what didn’t change, since the assumptions underlying the other half to two thirds of that budget were made - particularly those with respect to purchases from Sun and the Wintel partners.

My advice? wait - wait until the change implications deriving from Intel’s Nehalem server releases are made clear by others, and wait until the fat lady really does sing on IBM”s attempt to kill Sun’s SPARC/Solaris combination.

One of the things to notice about the Sun mess, by the way, is that none of the assumptions and extrapolations being made by pundits trying to ingratiate themselves with IBM by describing what’s going on as initiated by Sun’s management and then interpreting that assumption as proof positive that Sun’s own senior people think the company should be put out of its misery, are correct.

What’s motivating IBM is precisely the opposite: they know they can’t compete with Sun in the marketplace and are using the opportunities created by the moral meltdown in Washington to shut Sun down via the legal and financial systems.

Sun’s salaried management believes fiercely in the strength of the company -but are employees ultimately responsible to the board. So when a major shareholder first forces that board to consider selling the assets and then “facilitates” that process, people like Jonathan Schwartz have no choice but to mutter “Aye Sir”, saddle up, and march off to do their best at the opposite of what they know is right for the company.

As I’ve said before, the right answer for both IBM and Sun would be for Sun to sell its x86 businesses to IBM along with guarantees on Solaris support - followed immediately by a move to employee ownership, and then putting all the wood behind Solaris and the CMT revolution. That would be good for Sun, good for IBM, good for the OpenSolaris community, good for AMD - and good for the country and the industry because it would increase both technology and price competition in the market while not just letting about 25,000 Sun people keep their jobs, but making those jobs both more demanding, and more rewarding.

Sadly, it’s not likely to happen - but the fat lady hasn’t sung yet and, meanwhile, there are lots of technology planners with money to spend and no real clarity about what to spend it on.

Intel’s Nehalem processors look pretty good in this context: an optimized Solaris (and matching compiler changes) for Nehalem is due out next week, the server processors are a manufacturing step ahead of AMD, and nearly all current x86-64 Linux and Windows software should work out of the box.

Overall, right now, the risks on Nehalem are lower than they are on SPARC - but that’s entirely an artifact of legal and financial manipulation, not the technologies. Thus people considering Nehalem as an alternative to SPARC need to think about three things:

1. Nehalem does not appear to address any of the x86 security issues: from ring 0 vulnerabilities to BIOS based boot processes and the reality that you cannot know what software is hidden in various hardware components, Nehalem offers significant performance improvement on throughput and power use, but does nothing new on security.

   In other words, if you care about security, your choices remain SPARC or Power- and installed Power systems cost close to ten times what comparable SPARC systems do.

2. Neither the Windows software environment nor that for Linux yet takes full advantage of Nehalem’s multi-core structure. As a result, Intel’s advance on its dynamic cache sharing facility in which one or two cores in a four or eight way chipset can speed up while others drop in frequency, can be very valuable in terms of getting some jobs done - but is more useful in workstations or intermittent duty servers than in heavy weight, continuous processing, applications.

   What you need to think about, therefore, is what your workload looks like - if you’re doing file or mail serving to a small number of users Nehalem will be a winner for you, if you’re serving Java pages to a large number of users both Sun’s T2 line and AMD’s latest products will give you more throughput for less money.

3. You also have to think about the consequences of virtualization. Can Nehalem help you consolidate a dozen or more older x86 servers to one new one running many virtual servers? Yes - provided that you don’t have performance killing network or storage bandwidth limits to contend with.

   If, like most people, you do, you’ll find that the T2/super thumper combinations offer hardware support in all the right places, cost less than Nehalem to begin with, and could let you put off fixing your network and/or storage technologies for at least another year or two.

   Still, there are lots of variables here so the right answer is extensive testing - think of it as visible due diligence on the decision and chuckle quietly because it also buys you what you need most: time to see which way the dust settles on both Nehalem and Sun.

In summary:

• Nehalem adds minor technical improvement to what’s really a combination of Intel’s manufacturing and sales capabilities with AMD’s technologies - and the results look pretty good, except that the wintel industry still isn’t ready for multi-core, and the general purpose data center change implications of going this route have yet to be worked out.

• Sun’s T2 and forthcoming ROCK cpus continue to lead the market but are under threat of extinction by IBM.

So what should you do? Wait.

For those of you convinced that Nehalem thumps the T2, I’d suggest reading Anandtech’s typically laudatory report on Nehalem performance. Written by Johan De Gelas, this is a nice piece of work (despite being on a dedicated Intel puff site :) ) but what I suggest you pay particular attention to is the benchmark results he cites - and not just the numbers he shows. Follow up on the public benchmarks cited, and you’ll find many include other, rather less flattering, results relative to SPARC and AMD.

The first one he cites, for example, is the SAP SD2 “ERP benchmark”. Follow that to the sap results site and you’ll find that the dual 2.93Ghz Xeon 5570 (8 cores) Nehalem’s score of 25,000 “saps” is about five times that obtained by a low end IBM Power 570 (2 Processors) but only about two thirds of the 37,650 reached by a Sun 5440 (4 T2+ processors) at 1.4Ghz.