㊿ Shades of #Open💎— an essential approach to model-driven customization in next generation data center fabrics
The origins of Open
Computer networks exist to interconnect digital systems. Following the principles of the Open Systems Interconnection (OSI) model as published by ISO in 1984, these systems form a layered stack of functionality, a mix of hardware and software components created by a wide variety of companies and individuals. Both collectively and individually, these elements all have an essential degree of “openness” that is fundamentally required to fulfill their very purpose.
There are technical and non-technical aspects to the notion of “open”. It is generally viewed as a positive characteristic and a source of differentiation for companies (which can lead to interesting and sometimes heated exchanges). We can see a shift from “closed” to “open” over time: From hardware to software (as evidenced by the number of trained engineers for example), from “closed source” to “open source” software, and from “closed core” to “open core” in open source.
At Nokia, we embrace “open” as one of our cultural essentials. It is qualified as “being open minded”, open to new ideas and approaches to problem solving, collaboration. This includes new as-a-service business models, and the inclusion of merchant silicon in some models of our network platforms. Similarly, we introduced SR Linux — our new Network Operating System (NOS) built on top of the well known open source code base. And more recently, not formally part of our portfolio but still primarily created by Nokia engineers, we launched Containerlab — an open source tool/project to deploy multi-vendor virtual networking labs.
Open software in originally closed companies
Companies are formed to create and deliver value in ways that go beyond the abilities of any single person. They are a mechanism to increase the scope and scale of the addressable problem space, for whatever products or services the company provides. Especially in case of hardware and software networking systems, these products are used by other companies as building blocks for their systems and services — creating a stacked value chain of interdependent components and associated suppliers/consumers.
The make-or-buy decision for individual components is central to the question of “open”. Many companies — in particular pre-internet companies like Nokia — have had to design, create and write these components in-house, since no alternatives existed/were known on the open market. By nature, these in-house developments were closed and protected. Over time, specialization and natural selection/market competition led to de facto or formal standardization and commercial availability of alternatives for many of these in-house components. One could say that companies like Nokia were originally “closed”, and are now gradually becoming more “open” — for example, by adopting more and more externally created components in their systems, by participating in open standards forums and interop events, and by increasingly sharing the results of internal developments through GitHub and other platforms.
Open interfaces and standards
Open versus closed source code is but one shade of open. As illustrated by industry forums like the O-RAN Alliance, having open interfaces can be considered an orthogonal dimension of openness. A system may be created using closed source software, but still offer open interfaces for other companies to integrate with. Typically, such interfaces adhere to well defined and documented standards, either vendor specific — like most AWS APIs for example — or industry wide (like IETF RFCs, 3GPP, ITU, etc. ), in order for such systems to be usable in a broader system context and eco-system.
Open standard interfaces promote interchangeability of components. An “open” system is a system in which the components and protocols conform to standards independent of a particular supplier.
Open automatable systems
Increasingly and over time, the systems we build are consumed/operated by other systems — not humans. This has implications not only for the way we build our systems, but also for the tools and capabilities we provide to our “downstream” users such that they, in turn, can build open systems on top of our open systems, preserving the openness.
In SR Linux, a key example of such ‘transitive openness’ is the use of YANG models to define and manage the entire configuration and state. Customers or other third parties can create extension modules or “agents” which can use these very same mechanisms, becoming an integrated part of a single managed system. This “model driven extensibility” is a unique and fundamental feature of the architecture.
Open model-driven systems: An essential approach
In summary, networking platforms and connected systems are “open” by nature. However, there are many degrees of “openness”, and providing standards-based interfaces is but one (table-stakes) example. To successfully and sustainably realize the potential business value and operational benefits promised by an open approach, consider “truly open” solutions that offer model-driven extensibility and manageability — like Nokia SR Linux — because open is only valuable if it can be operationalized.