One of the long term objectives of all the big IT systems vendors is to find the next `big thing’. Selling servers that are now off-the-shelf commodity items, even with infrastructure management software, is now a recipe for disastrously decreasing margins. That next big thing is likely to be the big `S’ word – services. This is why IBM’s recent Blue Cloud announcement is more interesting for the future it presages than what it offers now.

IBM’s laboratories are most certainly not alone in developing technologies that allow users to request packages of services in the form of applications and tools together with the systems resources needed to run them. HP, for one, has been demonstrating just such a capability at its research labs for more than two years. The company may well be kicking itself for not announcing something already – and conspiracy theorists might even be tempted to ponder any possible connection between HP’s Software Universe event next week (a regular focus for new announcements) and IBM’s announcement last week.

Be that as it may, IBM’s Blue Cloud looks at first sight an interesting attempt at providing users with new tools that offer users a far greater operational flexibility. This is where users can start to request packages of applications and resources that can be provisioned dynamically, either when requested (if sufficient resources are available of course) or at a pre-determined time, for a pre-determined time period. Such packages would, of course, come to be seen by users as `services’ called up when required. This would mean that one of the underlying concepts of SOA – getting users to stop thinking in terms of `running applications’ (with all that that entails) – would at last start to become reality.

It would not be unreasonable to suggest that Blue Cloud, as it currently exists as a BladeCenter chassis of Linux-based Blades, is little more than a prototyping tool. But the question for CIOs and IT managers is then – a prototype of what?

It would be easy to suggest that the `production’ system would be a whole datacentre of BladeCenter chassis’ providing a gloriously flexible SOA infrastructure just for one company – an `intra-structure’. But, even with the developments in IBM’s autonomic computing environment announced a couple of weeks ago – where the systems can be expected to care for themselves even more comprehensively – having to provide maintenance and support to such hugely complex datacentres scattered all over the globe would be, to put an unfine point on it, an economic pain in the butt.

However, if those datacentres were fewer, and bigger, and IBM-owned the economics of it all could look a lot brighter, and they would be moving in on the `inter-structure’. In addition, the company would be selling systems to itself to provide a service to end users rather than to end users themselves, or other service providers. This would be an obvious opportunity for the accountancy profession to wax creatively in the area of operating margins.

Let’s face it, when compared to the network `Cloud’, Blue Cloud is a mere wisp of steam from a dying cup of coffee. But for IBM, HP and one or two others, moving towards owning a large tranche of the network Cloud that is not already owned by Google - and providing the services that users will need - is an obvious and important goal.

Getting users experienced in the new ways of working in and through the Cloud – and in particular away from the current psychological barriers to SOA that present themselves in the concepts of `my data’ and `my applications’ – is arguably the most important prototype work that could now be undertaken. Once beyond that, users can start to stop caring about `systems’. Who cares what `system’, `application’ or `operating system’ is being used, for the cloud is the cloud is the cloud.

Is the benchmark for benchmarks that they are no longer worth attempting? The question arises because far less action or brouhaha has occurred in the world of the new TPC-E benchmark than might have been expected. Both Dell and IBM have recently joined Unisys in publishing first results but, strangely, neither has made much fuss about them.

Back in July Unisys became the first server vendor to announce results against the new tests. These set out to simulate the online transaction processing workload of a brokerage firm. This is aimed at giving a much more relevant impression of how a server and database combination will perform in the real world than the old TPC-C benchmark, which while not discredited, has ended up fairly tarnished by rumours and innuendoes about the ways databases and hardware could `tuned’ to improve results.

Being first at anything like a benchtest, of course, will always leave any company on a hiding to nothing. So for a while Unisys had nothing to compare itself against, so no one - even Unisys - had the remotest idea of the relevance of the results. The company has an enviable reputation in many areas, particularly in building infrastructures and systems geared to the specific needs of vertical market sectors. As `a consequence it has usually eschewed the publicity-generating game of `who can build the real screamer’? So could the silence and Dell and IBM about their results have any relationship to that? The answer, at least in part, is yes.

It transpires that building a screamer is what Unisys appears to have done, at least in these early days of TPC-E. Its ES7000/one server came in with a performance of 661 transactions per second (tpsE), running a Microsoft SQL Server 2005 Enterprise x64 Edition database. Dell currently lies second at 220 tpsE, while IBM is third at 170 tpsE. Both of these were running the SP2 version of the same database. This result is no doubt coloured by the fact that the Unisys Server used 16 dual-core processors, while Dell used four and IBM only two.

However, when it came to price/performance, Dell and Unisys reversed positions. Arguably a more important metric for many enterprise users, this showed Dell at $1,020 per tpsE and Unisys at $1,777 per tpsE. IBM came third at $1,898 per tpsE, which might certainly explain its backwardness in coming forward.

The upshot of all this? Well, I do wonder if the reluctance to crow about these things publicly may indicate that there are now some doubts amongst vendors as to what benchmark results actually prove. For example, it is possible to read the price/performance figures to show that Dell can make a 4 processor server that is faster and cheaper than IBM or that Unisys makes bigger, more expensive ones – not much new there, then.

The performance figures can be read to show that the performance, per processor, of SQL Server drops off the more processors that are added, but that is hardly a startling discovery. And without then factoring in the different operating systems each is using – Windows Server Datacenter Edition for Unisys, Server 2003 Enterprise Edition x64 SP1 for Dell and the SP2 Version of that for IBM, getting anything concrete out of the figures gets to be a complex task. Can we say for definite, for example, that ipso facto the SP2 version is slower than SP1? I’m not sure I’d stake my life on it.

For IT managers, maybe this just demonstrates that the old ways of gauging these important issues are still best – get the sales reps to take you out to dinner and have `Scepticism’ set to `High’.

So IBM has decided to cut a deal with arch-rival, Sun Microsystems, that will allow it to offer Sun’s Solaris x86 operating system on its Xeon and Opteron-powered servers. The news has caused something of a stir. Well, I suppose at face value it is a bit exciting, but in practice I suspect it is simply an indicator of how far down the scale of importance technologies such as server hardware and operating systems have slid.

It is no more than should be expected anyway, even if you can afford only a cursory glance at the history of such things. Twenty years ago the actual nature of server hardware design and architecture was still considered the crown jewels for many vendors. Ten years – indeed, up until recent times with the likes of IBM – some operating systems were similarly considered crown jewels. On that basis, the mere fact that IBM has its own Unix – AIX – would be considered more than sufficient justification for banished the very notion of selling arch-rival, Solaris.

But times have changed, and even though this deal specifically covers Solaris x86, which IBM could therefore argue `competes’ with AIX in much the same way as Linux, it does seem as though some true sacred cows are set to be slaughtered. There are strong hints that the deal could be extended to IBM offering Solaris on its pSeries servers – home turf of AIX – and even on the most sacred cow of all, the mainframe systems.

Has IBM gone mad or lost faith in its own technology? I very much doubt either. Instead, this is all about a simple realisation – that there is significant long term business in consulting, architecting, building and extending enterprise infrastructures.

Against that level of business, getting sniffy about the choice of operating system favoured by the customer is a total irrelevance. IBM, like HP, makes no secret of the fact that it would love to eat Sun’s server business, but it also accepts the inevitable – there are a great more many enterprises that like Solaris more than enough not to want to change from it.

This can get a good deal more complicated the bigger and more distributed an enterprise becomes, especially if it is an amalgam of different businesses. You can bet good money that some of them will be, historically, Sun shops and won’t want to change. As most CIOs and IT managers will know in such situations – such changes can be positively harmful.

Think what you like of IBM, it has the experience in building and managing such infrastructures and, in the shape of
Tivoli, some management technology with a more than suitable track record. For an enterprise to bail out of choosing Tivoli because it still wants to run Solaris servers and applications, or for IBM to say “shan’t” until they agree to switch, would now be foolhardy.

So if it marks anything at all, this deal marks the end of the era of the operating system supremacy wars, and a move towards a time when all that is irrelevant. At last businesses may be able to get on with some real work.

The thought has occurred to me that it might be a sign of insipient curmudgeonly luddism on my part that I think Linden Labs’ Second Life is a waste of time. But the thought that it was also a serious waste of energy – at a time when energy management and all things `green’ are amongst the hottest topics (oops, sorry) in infrastructure management – had not really occurred to me. But the issue is an important one, particularly for businesses; there they are running (often) huge server farms and important applications, but not always knowing what their users are doing or, more to the point, what demands their customers are making on the systems.

Second Life customers, it seems, are making significant demands upon the Linden Labs infrastructure. I recently bumped into the Blog of Former Harvard Business Review Executive Editor, Nicholas Carr, where he set out some simple maths which demonstrated that, with an average of around 12,500 Avatars `living’ in Second Life, and with 4,000 servers running flat out to provide their `world’, each Avatar over a year consumed the equivalent electricity to the average Brazilian. Let’s face it, that’s a lot of energy going on….well…..not a great deal really.

The hardware vendors are making significant noises about offering systems with reduced energy consumption, lower heat dissipation and the rest of that good stuff. They are doing their bit. The software vendors are starting to catch on as well, with IBM’s `Big Green Linux Initiative’ being the latest contender – though the sales pitch seems to be “buy more Linux and have a cooler datacentre”. I’m not sure that cause and effect are that closely, or simply, related.

This raise a wider issue in energy consumption arguments: just what demands are being made on the applications, particularly web-based applications, by users? If there is little or no control over those demands, then it matters not how energy-efficient the servers – they’ll just be thrashing away, consuming energy for little return in business terms.

Here’s a simple example. You have a web-based online trading site, together with a very pretty website. Thousands of people seem to spend lots of time faffing around on the site, window shopping but not buying. There are so many of them that the servers are always overloaded and running slow – so you consider buying some more. But the revenues are also worse than expected as most site visitor are not buying, so that is a difficult business decision.

This type of scenario is surprisingly common, with website window shoppers consuming infrastructure resources and slowing systems to the point where real customers abandon ship and go elsewhere. They rarely come back. And all for the lack of some management of what website visitors do when on a site. I wonder how much energy, cumulatively, is wasted in such ways, and how many additional servers are installed in a vain attempt to overcome it?

Perhaps IT infrastructures are comparable to our growing obsession with obesity. Eating more `slimming food’ may not be the best solution when set against controlling what, and how much, gets eaten. It is a part of the energy and infrastructure management equations that has not yet been truly taken in hand.