A number of industry and technology trends are fueling what feels like an “Open Awakening” in the IT infrastructure space. Technologies like Software-defined Networking (SDN), Network Functions Virtualization (NFV), and Network Virtualization have brought a new set of considerations for the strategic IT consumer.
But how do we define open? It’s an imprecise term that’s being used to describe five areas of interest within networking. Open, as it is currently used, does not lend itself to the precise discussions needed to address specific networking problems. When evaluating solutions against these selection criteria, it’s important to be precise about which facets of “Open” are most critical.
Discussions around openness frequently gravitate towards technology standards and the bodies that support them (i.e. IETF, ONF). Standards are meant for cross-industry collaboration on a set of technologies that have a high degree of interdependence in multi-vendor environments. When a particular protocol is standardized, for example, it prevents one vendor from using its IP rights around the technology to prevent other vendors from implementing the protocol. In this regard, standards ensure a level playing field.
However, standards do very little to cap technologies. The intent is to capture which technology aspects ought to be commonly specified, but this in and of itself doesn’t prevent or dissuade companies from extending the technology in vendor-specific ways. In fact, this is desired behavior. Because standards bodies use a rough-consensus model, movement will tend to be slow. In early phases of technology evolution, this means technological advances will almost certainly outpace standards activity.
In practice, the most common meaning of openness is interoperable. For many, the end goal is an IT solution that can be effectively deployed in a multi-vendor, heterogeneous environment. From a networking perspective, the most common area of concern is at network or service boundaries because it requires the graceful handling of network state between devices.
Given the broad set of systems for networking gear to integrate, interoperability must be broadly examined to determine fit. In some cases, the surrounding IT systems may actually dominate short and long-term integration costs.
Interoperability considerations will also vary based on where users draw system boundaries. The impacts can be very different depending on whether users consider systems or discrete system components. Regardless of where users draw these boundaries, it’s beneficial to be specific in the desired degree of interoperability. Loose definitions based on undefined objectives will make assessing interoperability difficult to impossible.
Open has also become shorthand for open source. Advocates of open source initiatives are primarily interested in allowing a community of developers to leverage and build upon the work of the collective. Open source is particularly effective at fostering community development and speeding innovation by reducing infrastructure overhead (Open Daylight, for example).
However, open source isn’t designed explicitly to promote interoperability or interchangeability. Despite not having this direct relationship, open source projects are quite valuable to the technology communities they serve. Oftentimes freed from commercial constraints and demands for profitability, open source projects are some of the most effective scientific playgrounds.
If interoperability is the measure of how well devices can interact, interchangeability measures the degree to which multiple items are directly substitutive. Put simply, if device A and device B are functionally equivalent, they are interchangeable. One of the major interests in “Open” solutions is the ability to swap components for those from alternate vendors, mitigating vendor lock-in and keeping price pressure on all vendors. The threat of being replaced is typically enough to prevent vendors from substantial mark ups.
Customization is the enemy of interchangeability. Narrowly supported features become barriers to substitution. While vendors are eager to develop and sell these features, the onus is typically on customers to avoid deploying these features en masse.
Access is perhaps the least common definition for openness, but nevertheless should be considered. In this case, “Open” refers to access to information. This is particularly true for solutions that require API or integration layers. For example, the SDN world has discussed the need for northbound APIs from the controller to applications that would reside on the controller. These APIs can be very specific, so broad standardization isn’t necessarily a requirement. However, for any party who wants to integrate with the APIs, access to API definitions is a necessity. DevOps environments where disparate systems are managed through orchestration tools such as Puppet or Chef require access to abstractions, libraries, and tools for customers to successfully manage integrations.
The “Open Awakening” across the IT and networking industry is absolutely critical to both customer and vendor success. In using openness as a primary selection criterion, customers will ultimately be best served by adopting a more explicit and precise set of objectives, and should consider these five areas to determine the impact and importance of each attribute.
Michael Bushong is VP of Marketing at Plexxi.