HP and the Single Pane of Glass, which sounds like the title of a detective mystery, is a pairing that goes back almost as far as the company’s relationship with Alcatel.
Indeed, it's curious that it hasn't copyrighted the term already, since it appears to have an appeal that endures better than several of their CEOs. As with most slogans, it takes a concept with a lot of appeal to techies and turns it into a slogan, which lays the entire idea open to snide misinterpretations ("I paid 600 quid for my 'single pane of glass management interface' but that's only because I need varifocals").
It seems like referring to just the physical manifestation of a computer system is an idea that chimes strongly with virtualisation firms - Citrix had their "three screens" slogan for a year or two, referring to smartphone, laptop, and HDMI TV - an idea which appeared to be strongly proposed by Nokia just pre-Elop, and which spectacularly failed to include the burgeoning importance of the iPad.
Alongside the CloudSystem family of architectures, services and procedural frameworks, HP has been pushing their Care range of support relationships - Foundation, ProActive and DataCentre all being subtypes of support tailored as per its recent announcement on AlwaysOn support. These are not coming from the same part of the management diagram as the .Single Pane of Glass', but you can see a certain consistency of thinking which comes from long exposure to technical deliveries given to non-technical users
So, if there are two parts of the management diagram: what is an HP customer to think? Reading between the lines, what HP and Alcatel appear to mean, is that there's a need to report on the results of a Cloud Orchestration project, and the people best equipped to read or write such a report are going to be the type of hardcore large-scale techies who are already familiar with the HP design and management tools collected under their CloudSystem banner.
I disagree: to explain why, I am going to assume that you, dear reader, are a bit more likely to be an internal networks person looking at a cloud migration, than you are an external telco person looking at wiring up a lot of data centres.
The issue here is definitely all about the physical and financial consequences of a virtualisation project: At the scales this is likely to hit home, there's not much distinction between "virtualisation" as a cloud technology, and "hosted outside the business" as a presumed prerequisite of qualification for the C-word. Big businesses are just as likely to lay a fat pipe to their data centre, in a building they own, as they are to enter into a contractual relationship with an on-demand compute provider.
There's even now a developing third class of large scale cloud project, in which the technologists with the on-demand skills actually deploy them within a computer suite at the owner's address, so one firm delivers the SAN, the next one is doing the nodes, the third one does the tape backup library (titter ye not, this is a growth area for the tape wonks).
Everybody understands that running a lot of servers requires that you keep track of what they are doing, and whether they are unhappy. That's what network and server monitoring tools are about, and once you extrapolate that use case a bit, it's what HP's CloudSystem does.
There are rather a lot of other parts, to be sure: modern cloud monitoring has to allow for new servers to spin up and spin down, for example, as well as VMs to migrate across the server topology and storage distribution, both of these are not small tasks.
However: as with a vast swath of technical designs from the last three decades, the implementers of such systems do tend to forget inconvenient limitations like the speed of light, and living in a continuum with only four dimensions. And sadly, as I have to explain to these guys at pretty much every meeting I attend, those are the ultimate limitations, but far from the only limitations.
Bandwidth of internet links and the cost of increasing it varies immensely, according to time of day, physical location, surrounding population density (many will not be surprised to hear that Soho in London has such a dense population that the normal relationship between that statistic and internet access speed is inverted: Soho has a kind of hyperspeed event horizon, a super-WAN that connects all the companies in the movie Special Effects business together).
To give a small-scale example of this problem: I tried to help a charity a couple of years ago, to get their heads around the new cloud-based extranet cum donations database being developed for them by a "cloud software developer". They had far, far overstepped the capacity of their internal systems and as a result were pretty scared of the overall matter of performance - especially since only 15 of them had maxed out their server, and the idea was to let 15,000 users, potentially, self-update their records by keeping the database in “the cloud”.
So I translated their concern into terms for a developer to answer. How much bandwidth would be needed, I asked, to give just 15 users LANlike response times to the cloud system? Back came the reply: "About a megabyte".
This triggered a nightmarish excursion into the world of buying bandwidth from internet connection providers. Almost none of those approached could make any guarantees about sustained performance: very gradually my client figured out what the beardy, sandal-wearing, slide-rule toting inhabitants of the National Telecommunications Infrastructure have known for at least fifty years (please chaps don't take offence, I am thinking here of my late uncle, who was indeed in such a position).
The big secret is that almost all Internet longish-haul links are contended. It's not as bad as it used to be, of course, though there are scenarios in which it's actually a whole lot worse, due to poorly implemented concepts such as traffic shaping - but the bottom line is, you need to check very carefully, and do it almost daily over again, to make sure that you are really getting the bandwidth you need, and the bandwidth you're paying for.
Just last week I babysat another client who thought he'd bought a solid 10Mbit/s bi-directional fibre connection, but who found one day that it had apparently at random, been dialled back to 5Mbit/s. Now, he's not a cloud person, and in terms of everyday workflow the speed chop had not been detectable - but if he had been a big corporate with varying loads to balance across server resources, then live monitoring of external WAN topologies, SLAs and connections would have told him that things had gone a bit crook, almost at once.
It's that part of the picture - the WAN structure, in short - that the Alcatel products bring to the HP party. My doubt about gluing "Single Pane of Glass" to this is a recast of the old Woody Allen observation about scientists speaking different languages. If anything, the telco people are drawing further away from the computer people, under pressure of technological advances and developments like IPv6, just when they should be drawing closer. And the computer people reading this right now are all furrowed in the brow, because they are thinking "Pie chart. Green bit good, red bit bad - how hard can it be?"
Which just goes to show that they have never been in a meeting to negotiate a whole portfolio of packages and connections and tariffs, from a multinational telco: because they have ways of making your head spin, your link go slow, and your wallet empty: and that's why there's a powerful need for specialised management of cloud communication resources. HP's Single Pane Of Glass omits the fact that in most companies, the breadth of skills and experience required to interpret those live use statistics is almost never found all packed inside the same skull.
As I like to put it; an IT techie will Google for service interruption messages when they see a connection alert, while a telecomms techie will look outside, to see if there's a striped tent in the back corner of the car park. Trying to meet both world views with a single pane of glass, seems like a tall order from here.
