Cloud // Cloud Storage
Commentary
7/3/2012
06:57 PM
Jasmine  McTigue
Jasmine McTigue
Commentary
Connect Directly
RSS
E-Mail
50%
50%

When Standards And Innovation Don't Mix

The problem with protocols is that when we need them most, they're least effective. Enter the age of the API.

Whenever we ask IT professionals about standards vs. proprietary, we get people professing their allegiance to network protocols. If my widget wants to communicate with your widget, they need to speak a common language, right?

The problem with standards is that they're the diametric opposite of innovation. As soon as you define a way in which a particular action must be taken, you eliminate other methods of taking that action. Sometimes support of a standard actually inhibits development of creative solutions to system problems.

Take OVF, the Open Virtualization Format for virtual machines. While almost all hypervisors are capable of doing basic functions with a standard .ovf file, VMware's proprietary--and, yes, innovative--VMDK file format brings a ton of additional features, like thin provisioning. However, a VM must be converted to a VMDK to take advantage. Yes, the OVF format remains useful for passing VMs from hypervisor to hypervisor in a standard, structured way. But the OVF format is also fixed, and because it's fixed, when VMware--or Citrix or Microsoft--wants to support a new feature that requires extension of the functionality at the virtual disk level, it can't do so in OVF. If it could, the standard would be broken and therefore useless. Even though OVF is extensible, if every vendor adds its own extensions to OVF, suddenly the thing is proprietary even though it's technically open. How will Hyper-V read VMware's proprietary OVF extensions? How will VMware read Hyper-V's? What if the extension carries critical machine data?

The kicker is, it's during periods of rapid change and intense innovation when we need standards the most. The move to private clouds and heavily virtualized and automated networks certainly qualifies as intense. But how does IT make the right bet in a world where technology is changing too fast to know what the "correct" standard will be a year from now? Maybe tomorrow some upstart will figure out a much better way to do X, and then standards are out the window, just like VMware tossed the first release of ESX Server.

While it's a challenging time for IT teams that need to integrate dissimilar systems to deliver tangible business benefit via integration, I can't help but feel bad for vendors. Cisco, Microsoft, VMware, and others catch heat for "breaking" standards, but the reality is, they face a delicate balancing act between providing enough of a standard to promote far-reaching interoperability without hamstringing innovation. And virtualization has not made this difficult task any easier.

"Let's virtualize the network," says Company A. Engineers get to work and figure out that they want to use InfiniBand as a carrier interconnect. Company B has the same goals but prefers 10-Gbps Ethernet. Company C thinks PCI Express' SR-IOV is going to make life easier, so it goes with PCI Extension. Who's right? Which of these interconnects is going to win? The answer isn't always clear, and in the multivariate world of pervasive virtualization, unclear outcomes have become the rule rather than the exception.

I believe IT teams need to worry less about standards, or lack thereof, and focus energy on application programming interfaces, or APIs, that define the way outside elements can communicate with a given infrastructure element. Just as virtualization provides a layer of abstraction between a virtual machine and the memory it uses, an API provides a layer of abstraction between the request being made and the way in which the device accomplishes that request. I tell VMware to clone a machine with an API call, and vSphere uses its proprietary cloning technology to physically copy the machine. I can ask both vSphere and Hyper-V to do the same logical action: clone the machine. The way in which those two infrastructures actually get the job done could be radically different; if I'm using the right SAN, for instance, VMware can use another API to leverage the power of the storage array to do the task faster, and that's fine. This is the power of the API--and the reason APIs are becoming a standard feature of virtualized infrastructures. Tear down a machine, put a machine up, restart, failover, give me a new network interface. All these actions can be taken via API calls to underlying infrastructure elements without stifling the vendor's ability to innovate.

For networking pros, the problem with APIs is that they're invoked programmatically. And while there are plenty of code jockeys around, this programming is happening in a new place: the core infrastructure. That's scary. Code is buggy, and yet suddenly, the infrastructure team needs to know how to program, at least if your organization wants to leverage the power of APIs to provide concrete benefits such as automation, orchestration, and self-repair. Can you hire programmers to augment your infrastructure team skill set? Certainly. Do those same programmers understand the infrastructure well enough to work efficiently with the existing team? Maybe, but probably not. Time to start cross training? It is undoubtedly so.

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
MyW0r1d
50%
50%
MyW0r1d,
User Rank: Strategist
7/5/2012 | 2:04:17 PM
re: When Standards And Innovation Don't Mix
"The problem with standards is that they're the diametric opposite of innovation" paints a vague picture with a rather large brush or defines a yard by a single blade of grass. Standards define what are known, proven methods to make something function as advertised. I consider the Steve Jobs, the Bill Gates, the Steve Wozniaks all innovators, but look at their products Cisco, Apple, Microsoft, and almost any other that have made standards (open or proprietary) a critical part of their success. The true innovators are few and far between while there are thousands of wanna bes for each. Standards NEED to be followed in IT production environments where performance depends on service availability and stability. Perhaps you meant ignore standards exclusively in development environments, sandboxes, etc, and perhaps here I could agree, but when you bring it to market or production, set your standards in order to be supportable.
kathymast
50%
50%
kathymast,
User Rank: Apprentice
7/5/2012 | 3:55:21 PM
re: When Standards And Innovation Don't Mix
Good article on a complex topic. I/T has a strategic need for both innovation and standards. I suggest creating a team solely focused on innovation, training or hiring the expertise needed to achieve a breakthrough or new functionality and use your brightest and best to ensure I/T is innovating for the business. When the innovations are ready for real-time production, analysis must be done in regards to standards - will they fit, need to be adjusted, etc. You have to "break the rules" to innovate and should do so to keep your company competitive - in an innovation environment. Then figure out how to make the innovations fit the standards or standards adjusted to support the innovations for production. You really want the best of both worlds!
chachi04
50%
50%
chachi04,
User Rank: Apprentice
7/10/2012 | 7:08:25 PM
re: When Standards And Innovation Don't Mix
Good read on an interesting topic. I work for Juniper and am viewing this from a vendor's lens - while balance is important, innovation should always win out. The lack of mainstream adoption of a standard typically means that the status quo just isn't cutting it. Finding new and creative (and usually better) ways to solve a problem is the way vendors differentiate and continue to add value.

The API is a logical next step in that direction. Bringing the power of users, partners, and other vendors not only opens up access to the (usually brilliant) community, but it provides some tremendous insight into how customers use products and technology.
Google in the Enterprise Survey
Google in the Enterprise Survey
There's no doubt Google has made headway into businesses: Just 28 percent discourage or ban use of its productivity ­products, and 69 percent cite Google Apps' good or excellent ­mobility. But progress could still stall: 59 percent of nonusers ­distrust the security of Google's cloud. Its data privacy is an open question, and 37 percent worry about integration.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - August 20, 2014
CIOs need people who know the ins and outs of cloud software stacks and security, and, most of all, can break through cultural resistance.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.