Feeds

Convergence as a new new thing

The only way performance can go is up, says Dave Cartwright

Application security programs and practises

Feature Nearly 20 years ago I was technical editor of a weekly networking and telecoms newspaper. In those days the big word was “convergence” – at that time in the context of telephony and data coming together into a single network infrastructure and protocol set. Here we are in 2014, and that word is once again being bandied about – this time in the much larger context of the entire set of components of the technology infrastructure.

The changing face of convergence

When we were talking about CTI convergence in the 1990s it was primarily about bringing telephony into a world where it communicated using the same networks (primarily Ethernet) and protocols (generally IP) as data systems, thus eliminating the need for complex gateways and expensive software that translated between two separate worlds. These days IP is ubiquitous and so there's a far lesser need for gateway devices and inter-protocol translation.

The problem is, though, that a standard such as Ethernet and IP is merely a lowest-common-denominator means of making A communicate with B. If you're basing your applications and systems on a technology because it gives them the ability to communicate, the chances are that at least some of the applications will perform less well with that technology than they did with their own proprietary protocols. Technology is a land of compromise, and it's usually the case that compatibility is achieved at the expense of performance. Convergence, then, is no longer a case of standardising on a chosen set of protocols.

Vertical connectivity

In our 1990s example we were concerned with connecting two devices together and making them communicate with each other. Those devices were, however, pretty much stand-alone entities. You had a phone system (a box with some lights and ports) communicating with a server (another box with some lights and ports). Today, however, both of these devices are considerably more complex – they're no longer single devices but potentially complex stacks of technology.

Let's confine ourselves for the moment to the hardware side of things (albeit both virtual and physical) – we'll get to applications later. Taking a typical server in a virtualised infrastructure we have:

  • An operating system running on a virtual server.
  • A virtual server, running in a hypervisor such as Hyper-V or ESX.
  • A virtual network switch, running on the same hypervisor.
  • A set of physical network adaptors to which the virtual switches connect.
  • A physical server hosting the network adaptors.
  • A Storage Area Network (SAN) connecting the server to external storage media in a SAN – either iSCSI via the abovementioned LAN or Fibre Channel via its own switching fabric.
  • A SAN controller front-ending a set of disk arrays.
  • The disk arrays providing the storage.
  • A LAN connecting the server to other devices in the organisation.

The path from OS to disk is, therefore, considerably longer than it was in the days before virtualisation. Every inter-layer interface introduces a delay of some sort – no matter how minuscule these are on their own, they can add up to something significant and unacceptable. A message from the top layer to the bottom layer travels through the interfaces between each of the pairs of layers. The first obvious reaction is to contemplate the idea of compressing two or more of the layers back into their old model, but this is generally unpalatable since they wouldn't have been split had there not been a good reason.

For example, SAN storage makes more sense than internal dedicated storage because it minimises unused local disk space and enables efficiencies through de-duplication and dynamic storage reallocation. Virtual servers bring similar efficiencies of resource sharing and power consumption when compared to physical servers.

Since we're not going to do away with this more-layers-than-before model, we have a problem – or perhaps we should call it an opportunity for efficiency. For the operating system on server A to talk to the operating system on server B it has to send messages down through the layers, across the LAN, and up through the layers to server B.

It's highly likely that we can't make the communication between the layers any more efficient, so perhaps we could make the process more efficient by short-cutting the communications somehow and cutting out one or more layers in some of our transactions.

Eight steps to building an HP BladeSystem

More from The Register

next story
Sysadmin Day 2014: Quick, there's still time to get the beers in
He walked over the broken glass, killed the thugs... and er... reconnected the cables*
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
Amazon Reveals One Weird Trick: A Loss On Almost $20bn In Sales
Investors really hate it: Share price plunge as growth SLOWS in key AWS division
SHOCK and AWS: The fall of Amazon's deflationary cloud
Just as Jeff Bezos did to books and CDs, Amazon's rivals are now doing to it
EU's top data cops to meet Google, Microsoft et al over 'right to be forgotten'
Plan to hammer out 'coherent' guidelines. Good luck chaps!
US judge: YES, cops or feds so can slurp an ENTIRE Gmail account
Crooks don't have folders labelled 'drug records', opines NY beak
Auntie remains MYSTIFIED by that weekend BBC iPlayer and website outage
Still doing 'forensics' on the caching layer – Beeb digi wonk
Manic malware Mayhem spreads through Linux, FreeBSD web servers
And how Google could cripple infection rate in a second
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.