Hardware vendor lock-in: A long and messy past

Over the last decade, most organizations have learned to avoid server hardware lock-in. Doing so unlocked massive improvements in terms of costs and agility

Today, many organizations are still locked into their switch hardware vendor. Switch hardware vendor lock-in is at least as detrimental to organizations as server hardware lock-in, and must be avoided by any organization seriously considering digital transformation as the means to achieving business goals. This is because being locked into a switch hardware vendor means not just that there is one brand name on your network devices. It also means that how you manage your network, how you troubleshoot your network, how you train and deploy your network staff, and the choices on your next network equipment PO (and their costs) are all determined by that vendor.

Vendor lock-in often forms part of a business strategy that hurts buyers. For example, although Ethernet promised an open, interoperable networking standard, vendors didn’t waste any time in restricting firms’ purchasing freedoms by implementing proprietary VLAN extensions. Some vendors got into courtroom battles over private VLANs – and this helped neither their customers nor the networking industry. In another example, Internet Protocol (IP) emerged as another open standard, but hardware vendors soon launched proprietary routing protocols such as IGRP.

Lock in trade

In light of all the available white box switches, open source device operating systems, and the rise in commoditisation , what is the new hardware vendor lock-in strategy? Hardware vendors have doubled down; by releasing proprietary management solutions and APIs that lock their hardware to their management systems.

Proprietary network management solutions are the ultimate form of lock-in. They are not simply the Simple Network Management Protocol (SNMP) add-ons of the past, but sophisticated network monitoring, configuration and trouble-shooting solutions that will only operate with that one vendor’s equipment. The vendor may tell the customer that their solution is vendor agnostic, but they actually have zero incentive to support a competitor’s solution. If a problem should arise, expect finger-pointing and buck-passing – definitely not the level of support your organization would expect.

But it gets worse. A proprietary management system may also lock in other management systems. Within an enterprise, a vendor may interlock a security management system with a network management system in the data centre. They can also interlock network management for the data centre with a management system in the campus or the WAN. While most enterprises are sophisticated enough to work (or buy) themselves out of lock-in within one domain, doing so across many domains makes the risks to business agility in your digital transformation much greater.

Race against the lock-in

It is as essential as ever that CIOs and infrastructure operators do not rely on a single vendor for the architecture and products of their network. As Gartner cautions, vendor lock-in “results in higher acquisition costs and technical constraints that limit agility,” and successful digital transformation depends on agility.

Age of intent

Intent-based data centre automation starts at the network operations level, and allows your network infrastructure engineers to defines the services and requirements to be delivered and met by their infrastructure. You specify these requirements – they incorporate all the capabilities that your application teams needs from the infrastructure, including: underlay connectivity, overlay, security, compliance, policy, performance, traffic engineering, application performance, SLAs, etc.

Requirement and services definitions are done at the system level – without any dependency or selection of a specific hardware platform or device operating system. Once intent is specified, the user is then free to choose specific hardware devices and operating systems. These requirements are automatically, dynamically, and continuously translated into specific vendor decisions, configurations, and telemetry gathering.

If any hardware vendor neglects or fails to maintain consistency with any of their prior APIs, Intent-based data centre automation simply modifies the interface to that API to take advantage of the latest APIs – revealing the differences and benefits of each vendor’s equipment and features.

In terms of services, intent-based data centre automation is driven by open APIs that are used to integrate with other systems such as ServiceNow, Slack, Infoblox, etc. If lock-in ever hinders the infrastructure team’s ability to support them, the application teams can look elsewhere.

Intent-based data centre automation stands behind the entire system and services delivered by the infrastructure, including the hardware devices that make up this infrastructure. In other words, it acts as the “one throat to choke” without forcing hardware lock-in. Customers get the benefit of choice without the risk of IT servitude.

In short, “software first” intent-based networking breaks the vicious cycle of vendor lock-in by committing to loosely coupled architecture and powerfully open APIs; supporting the widest array of hardware vendor choices; providing a single throat to choke, thus providing choice without risk; And zero lock-in.