Openness is one of the most-cited advantages of cloud-based applications, Software-Defined Networking (SDN) and Network Functions Virtualization (NFV). In this context, what does open really mean? I posit that there are four key attributes that define openness in this context: documented, standardized, open sourced and inclusive. Any claims of openness by suppliers should be evaluated against these criteria if for no other reason than to clarify their position.
A Beginning – Documented and Supported
The most narrow and basic criteria for openness is that the interfaces to a software application are well-documented and accessible by someone other than the author or publisher. For example, a proprietary application like an email program might have application programming interfaces (APIs) that allow another application to send an email. This aspect of openness usually comes as a result of the popularity of a proprietary software program leading to a desire to interact with it programmatically.
A good example of this type of openness is the Microsoft Outlook Messaging API (MAPI). This API is documented on the Microsoft web site, including a getting started guide, a concepts document, sample programs, and programming reference. Many software suppliers provide this kind of open API as a means to drive the adoption of their software. However, the API is subject to change by the supplier, and users of such APIs are then stuck with ongoing maintenance challenges that may affect compatibility.
Moving Forward – Standardized
The desire for stable multi-vendor interoperability often leads a consortium or a standards body defining a standardized interface or protocol. This effort may take years, but if successful, drastically increases the likelihood of smooth interoperability among different implementations of the interface. Such interoperability can also lead to an ecosystem of compatible and complementary programs.
An example of a standardized protocol is the Simple Mail Transfer Protocol (SMTP). SMTP was originally defined by the IETF in RFC 821 as a standard for e-mail transmission across Internet Protocol (IP) networks. SMTP has been adopted not only by standardized email programs, but also by proprietary email programs such as Microsoft Outlook. Because it is standardized by the IETF, changes to SMTP take place in a controlled and technically sound manner.
A Milestone – Open Source
Driven by market need, industry momentum or the success of a standardized protocol or interface, a group of developers may choose to create an open source implementation of a design in order to multiply the efforts. Such an implementation has the advantages of being free (usually) and suitable for augmentation and/or incorporation into larger projects. Software developers will also cite an added benefit of open source – an improved ability to understand the operation and interfaces of a piece of software, as well as the possibility of looking inside the software to analyze and fix issues.
There are numerous examples of open source software, but the most important is Linux and its family of drivers, utilities and applications. The popularity of Linux has driven a virtuous cycle of innovation followed by increased usage, which continues to drive the innovation cycle.
The End Goal – All of the Above, and Adoption by an Inclusive Ecosystem
The proof of success for any open system is its adoption and use by an ecosystem of suppliers that seeks to include, rather than to isolate or exclude participants. Again, Linux is a prime example. Thousands of products, components and applications have been developed around the Linux operating system. Its success has been a key enabler of cloud-based computing, which itself has led to other developments such as OpenStack and OpenFlow.
One might argue that Linux is open but not standardized. However, its popularity and open source nature have led to de facto standardization under the auspices of linux.org. For most people, the most important factor in standardization is the adoption and control by a neutral organization rather than the pedigree of the organization.
What does all of this mean for a classic communications equipment supplier such as Overture? This is a very timely question for us we roll out our Ensemble Open Service Architecture, which features a set of a software components designed to optimize service creation, activation, and assurance. Our customers are demanding open, standard and interoperable solutions. The challenge for us is to support that demand, and to work with an inclusive ecosystem of partners and industry forums to do so. Of course, that is exactly what we are doing.
About the Author
Prayson Pate is SVP of Engineering and Chief Technologist at Overture, where he is also a co-founder. Prayson is a technology evangelist with a proven track record leading teams and delivering products. Since 1983 he has been building Carrier Ethernet and telecom products for service providers and network operators around the world – both as an individual developer and as a leader of development teams. Prayson spends much of his time driving adoption of Overture’s new Ensemble Open Service Architecture, which includes aspects of automation, virtualization, SDN and NFV. He has a BSEE from Duke, an MSECE from NC State and is the holder of nine US patents.
Follow Prayson on twitter: @praysonpate
Contact Overture to learn how you can increase profitability by transforming service delivery.
Copyright © 2016 | All Rights Reserved | Overture Networks