Software-Defined Overview

Introduction

This Software-Defined Overview article begins with a discussion of several underlying concepts that are key to the development of some of the many software architectures and emerging architectures that are part of Software-Defined Networking (SDN) and other Software-Defined technologies.

What is a Software-Defined technology?

Consider any technology that involves both software and the virtualization of some physical computing, storage or networking/communications device(s). The nature and the name of that technology will change over time. For example, when the concept of a physical server was virtualized, the result might have been called a “Software-Defined Server” rather than a “virtual machine” but it was not to be (until years later).

A Software-Defined technology can also involve both software and the virtualization of data or programs apart from the physical device or devices on which the data is stored or on which the programs run. The article “What you need to know about Software-defined Technology?” provides an introduction to SDN, while the Internet Engineering Task Force (IETF) Request for Comments (RFC) 7426 Software-Defined Networking (SDN): Layers and Architecture Terminology provides a more detailed technical description. 

What is the difference between a software architecture and an emerging architecture?

As used in this Software-Defined Overview article, a software architecture is an architecture that has been recognized by and is being supported by at least one standards development organization (SDO). An emerging architecture is an architecture that is being developed by or is currently being supported by at least one software development organization (SWDO) but that has not (yet) been recognized by any SDO.

An SWDO is an organization formed by one or more interested individuals, non-commercial organizations and commercial companies. SDOs are similar to SWDOs in many organizational aspects, but their purposes are quite different. The purpose of an SDO is to develop, publish and maintain standards within a defined scope of responsibility. One purpose of an SWDO is to develop, publish, maintain and possibly even promote use of software (or devices and related software) within a defined scope of responsibility, and (for some SWDOs) another purpose is to function as an SDO for that software. An SWDO may have additional purposes that are not limited to software development, such as hardware development. The scope of any SDO or SWDO may be self-defined or their scope may be defined by a higher-level organization.

What is Virtualization?

The architectural concept of virtualization is older than any of the software architectures or emerging architectures discussed in this Software-Defined Overview article. For further details, see this review of virtualization technology evolution. As this article on technology trends observes:

The trend of virtualization is one of the most powerful forces in technology.

Virtualization is an integral part of any Software-Defined technology. Virtualization can be used to implement some (typically, but not necessarily) hardware-based feature along with some software-based features of that technology solely in software. Virtualization can be used to create an abstraction layer in software that conceals implementation details of one part of the technology from other parts of that technology, or from whomever or whatever is using that technology. For example, early in the evolution of the Software-Defined Networking Architecture, the control plane was an abstraction layer that concealed implementation details of the forwarding table residing in the data plane from the management plane.

During the last 60 years more and more physical information technology (IT) infrastructure resources have been virtualized. Physical computing resources have been virtualized, including memory, processors, displays, sensors, entire servers and even entire networks. Many different types of physical storage resources have been virtualized, including tape and disk drives, channels, storage subsystems and entire storage systems. Physical communications/networking resources have been virtualized, including switches, routers, gateways, firewalls and entire networks. All communications/networking hardware (not just the active resources such as switches, routers and gateways, but also the interconnection resources) can be virtualized. Even data can be virtualized.

More recently, almost all layers of software resources have become virtualized resources, including processor instruction sets, subroutines, applications software, operating systems software, and virtual desktop infrastructure (VDI) software. Complete computing center environments or selected subsets of their components have even become virtualized resources. Multiple such virtualization activities by different SDOs and SWDOs are ongoing, with limited coordination across their individual efforts.

Once something has been virtualized, along with other virtualized resources it is typically:

(This article compares and contrasts the characteristics of virtual machines and containers. This article provides some security recommendations for virtual machines, while this article provides some security recommendations for containers.)

Examples of the evolution of a concept's virtualization

  1. Radio Access Network (RAN) provides a relatively simple example of the evolution of a concept's virtualization.

The original physical RAN was virtualized to (naturally) become a virtual RAN (vRAN). Several vRAN variations quickly appeared, including: a 5G RAN, a “Software-Defined RAN (SD-RAN)”, a “Cloud RAN (C-RAN)”, and then a RAN Edge. New RAN variations keep on coming, such as 2G vRAN (that’s right, 2G!), small cell RAN, 5G New Radio RAN (5G NR), 5G Standalone RAN (5G SA), and 6G RAN. And the concept of a RAN will continue evolving, since SDOs and SWDOs such as the Open RAN (O-RAN) Alliance and an umbrella organization called the Telecom Infra Project are actively developing standards and emerging architectures for Open RANs, with the support of lobbying groups like the Open RAN Policy Coalition, using disaggregated software (note that even the term “disaggregated” has many different meanings, as described in this article). Some O-RAN Standards have already been published. Vodaphone and NTT Docomo, Inc. have published a report on streamlining the process of testing multi-vendor O-RAN products. The European Telecommunications Standards Institute (ETSI) and the O-RAN Alliance have published a report on standardizing O-RAN planes. An Acceleration of Compatibility and Commercialization for Open RAN Deployments (ACCoRD) project is establishing testing protocols for network performance, interoperability, security and research into new open RAN testing methods.

This article briefly describes the architectural elements (hardware and software) of several RAN emerging architectures. This article attempts to explain the differences among the various vRAN and Open RAN emerging architectures, while this article describes various Open RAN Use Cases.

More recently and in a different direction, a different set of SDOs and SWDOs are at work evolving the Open RAN emerging architecture into a private RAN architecture.

  1. Cloud computing is another (considerably more involved) example of the evolution of a concept's virtualization.

Where is the Edge in SDN?

The term “edge” or ‘Edge” is used in different contexts by multiple software-defined technologies that are part of SDN. As described in this article and also in this article, and as shown by the various contexts in which the term “Edge” appears below there are many locations where an “Edge” can appear in SDN.

Software-Defined Topics in this Overview

Software-Defined Networking Architecture

While the adage timing is everything does not always hold true, it has been true during the evolution of the SDN architecture. While there have been previous efforts to change router and switch architectures, the SDN architecture effort has been the most successful. The SDN architecture as originally envisioned (circa 2007) included:

  • A data plane: Hardware that receives and forwards IP packets, that could be physically separated from
  • A control plane: Software in this abstraction layer monitors the forwarding tables residing in the data plane and propagates changes in routing policies to the forwarding tables, and
  • A management plane: Software that maintains the routing policies.

This introduction of an intermediate control plane to propagate changes in the routing policies to multiple forwarding tables was a significant addition during the early evolution of the SDN architecture. The control plane provided the management plane with a single, cohesive abstraction of multiple (possibly dissimilar) forwarding tables in the data planes performing distributed IP packet handling. This enabled the centralized management plane to dynamically determine global network behavior from a single location by maintaining the global routing policies. The separation of mechanism (IP packet handling) from policy (routing policies) is a well-established design principle in computer science.

[SDN Early Tech]

Early SDN technology (circa 2007)

[SDN Layers]

More recent SDN architecture (circa 2012)

 

By 2012, the SDN architecture had evolved to include the following elements:

  • A management plane that became part of the Application Layer: Software called Business/Network Applications control the behavior and performance of a network. One way that Applications do this is by using the services of modules to maintain the routing policies. An Application does not offer any Application Program Interfaces (APIs) to other Applications or to modules. The functionality of Network Applications modules included in different SDN implementations varies widely. The functionality of Business Applications modules is determined by the customer.
  • A control plane that became the Control Layer: Software called Network Service modules in this abstraction layer performs one or more services, providing one or more APIs, allowing modules in the Application or Control Layers to make use of said services and returning one or more results. Some of the services these modules perform include monitoring the forwarding tables residing in multiple networking devices, and propagating changes in routing policies to those forwarding tables. Even though the Network Service modules that make up a Control Layer are installed on one or more physically or virtually separate SDN controllers, the modules function as though they were installed in a common location. This list of commercial SDN controllers and this list of open-source SDN controllers mention several controllers available circa 2018. (Since that time, both lists have grown shorter for reasons described in this article.)
  • A data plane that became the Infrastructure Layer: Upon matching a conditional entry in a forwarding table for a received IP packet, a networking device performs one or more actions, possibly including forwarding the IP packet. The forwarding tables residing in each device are structured to meet that device’s specific requirements. A device may be either physical or virtual. A device manufactured by an original equipment manufacturer may be referred to as a white box. Prior to 2007, the operating system (O/S) for a device was usually provided by the manufacturer of the device. More recently, the O/S for an “open network” (also referred to as an “open networking”) device is sometimes provided by an SWDO rather than by the manufacturer.

The evolution of the SDN architecture did not cease in 2012. If anything, it accelerated! For example, in 2014 an extension to include support for the Internet of Things (IoT) was proposed (SDN Architecture for the Internet-of-Things (IoT)) by a Multinetwork INformation Architecture (MINA) research project. For additional details about the evolution of the SDN architecture, see this 2014 review.

And this evolution will continue – see the Emerging Software-Defined Everything Architectures topic below. As shown by the number of SDN open-source communities in the Points of Contact article, this continuing evolution can result in confusion when implementing SDN.

In the SDN architecture:

  • The Control and Application Layers communicate by means of “Northbound APIs” (NBIs). RESTful and RESTCONF are some examples. This diagram shows an example of communications between the Control and Application Layers using the RESTful NBI. The Open Networking Foundation (ONF) initiated the OpenSourceSDN initiative in 2015 (this initiative is no longer active, but the website was archived in 2017). NBIs developed by that initiative are available on GitHub.
  • The Control and Infrastructure Layers communicate by means of “Southbound APIs” (SBIs). OpenFlow, P4, or NETCONF are some examples.
  • Data modeling languages like Yet Another Next Generation (YANG) can facilitate the use of NBIs and SBIs.
  • For communications within the Infrastructure Layer (originally called the Data Plane), several APIs and API implementations have been standardized, including the OpenDataPlane (ODP) and the Data Plane Development Kit (DPDK).

Different SWDOs may use different terminology to describe the elements of their SDN architecture. A Layer in one may correspond to a Plane or a Tier in another, or not. For additional details about terms in the SDN architecture, refer to this glossary. In the future, the scope of the SDN architecture could expand to include security – see the Software-Defined Security Architecture topic below.

Network Functions Virtualization Software Architecture

The realization that physical network function components (PNFCs) (e.g., firewalls, load balancers or other network elements) could be virtualized was the foundation for the “Network Functions Virtualization (NFV)” software architecture developed by the ETSI Industry Specification Group for NFV (ISG for NFV) SDO. ETSI has also developed an NFV Open-Source MANagement (OSM) and Orchestrator (MANO), aligned with the ETSI NFV software architecture.

For further details, see this three part report from 2018 on the NFV software architecture:

Part 1: Foundations of NFV: NFV Infrastructure (NFVI) and VIM,
Part 2: Rising Roles of MANO, LSO, and Assurance, and
Part 3: State of the VNF Ecosystem.

Some industry observers worry that NFV promises too much too soon, as in this Does NFV Stand For Not Financially Viable? article, while others feel that the terminology describing the NFV software architecture is too complicated, as in this Lean NFV paper. 

[NFV]

NFV software architecture (circa 2013)

 

An NFV software architecture includes the following elements:

  • “NFV Infrastructure (NFVI)”: An interconnected collection of IT infrastructure resources including virtual and physical computing devices, storage devices, networking devices, network functions and sensors. This collection need not be collocated. If the collection resides at more than one location (whether physical or virtual), the virtual and physical networking resources interconnecting those locations are included in the NFVI. The NFVI may even form an NFV cloud using something like NFV Openstack. It is neither assumed nor required that the NFVI uses Software-Defined technologies. In 2019 the Linux Foundation (The LF) and the Groupe Spécial Mobile (GSM) Association (GSMA) SWDO developed an NFVI reference architecture, called Botrange.
  • “Virtual/Virtualized Network Function (VNF)” or "Cloud-Native Network Function (CNF)": A collection of VNF Components (VNFCs) and PNFCs implementing an external network service delivery policy for an NFVI. The properties of each resource in the collection are specified in a VNF Descriptor (VNFD). A VNFD is a template that specifies the operational capabilities, deployment requirements and management characteristics of a VNFC or PNFC,
  • “NFV MANO” or Cloud NFV includes:
    1. NFV Orchestrator (NFVO): may configure and maintain an internal resource allocation policy, may configure and enforce a security policy, and may configure and maintain an external network service delivery policy along with the VNFDs for an NFVI. For example, when multiple NFVIs are running in physically or virtually separate containers, an NFVO can be used to manage them. What an Orchestrator is not is also important.
    2. VNF Manager(s) (VNFM): abstraction layer that instantiates, manages, and terminates VNFs or CNFs in accordance with an external network service delivery policy and VNFDs contained in the VNFs and CNFs of the NVFI.
    3. Virtualized Infrastructure Manger(s) (VIM): abstraction layer that manages the IT infrastructure resources of the NFVI in accordance with an internal resource allocation policy.
  • An “Operations Support Systems/Business Support Systems (OSS/BSS)” or “Lifecycle Service Orchestration (LSO)” element may also be included.

Approaches to controlling interconnected collections of IT infrastructure resources are proliferating. One approach is The LF Open Platform for NFV (OPNFV) Project. Another approach is the emerging Software-Defined Cloud Interconnect (SDCI). A survey of SDCI implementations is available here. Yet another approach is the emerging Software-Defined Interconnect (SD-IX, sometimes called SDI) architecture. (Caution: Do not confuse the emerging SD-IX architecture sometimes called SDI with another emerging architecture also called an SDI mentioned in the Software-Defined Data Center topic below.)

SWDOs and researchers typically employ the use case methodology of systems analysis to identify and clarify implementation requirements and discuss anticipated benefits of specific cases of SDN architecture use or of NFV software architecture, as in the SDN and NFV use cases taxonomy and NFV use cases taxonomy articles. Some SWDOs and researchers may also apply the user story methodology.

For further details about terminology in the NFV software architecture, refer to the ETSI Group Specification NFV 003 Terminology for Main Concepts in NFV. In the future, the scope of the NFVI software architecture could expand to include security – see the Software-Defined Security Architecture topic below.

Software-Defined Internet Exchange Point

Another network function that can be virtualized is an “Internet Exchange Point (IXP)”. An IXP using SDN and possibly other emerging Software-Defined architectures is called a “Software-Defined IXP (or an SDX)” or an industrial-scale SDX (iSDX).

(Note: Do not confuse the emerging SDxI architecture that is the subject of the Emerging Software-Defined Everything Architectures topic below with the network function that is the subject of this topic.)

 Software-Defined Security Architecture

“Software-Defined Security (SDSec)” is an emerging security architecture under consideration for adoption by SDOs and SWDOs, and implementation by various companies in various ways. In SDSec software and emerging architectures, centralized maintenance of security policies could be separated from distributed security policy execution, in a manner analogous with centralized maintenance of the routing policies to the distributed routing policy execution in the SDN architecture. Security policies could specify who can take an action, what actions can be taken and when, where actions may be initiated, and where actions may be executed. As envisioned by the Open Networking Foundation (ONF) in an SDN context, the scope of Applications could be expanded to include configuring and maintaining an external security policy, while Network Service modules could implement that security policy. As envisioned by ETSI in an NFV context, the scope of the Orchestrator in the NFV MANO element could be expanded to include configuring and maintaining an external security policy for an NFVI, while VNFs could implement that security policy. SDSec is also under consideration as an element of the SDx Infrastructure emerging architecture. Yet another approach to implementing an SDSec architecture is with an Endpoint Protection Platform.

Alternative SDSec emerging architectures include Software-Defined Perimeter (SDP) and the more recent Zero Trust Network Access (ZTNA) (which is just one way of implementing Zero Trust Security and sometimes called the Zero Trust Security Model (ZTSM)). (This article summarizes how a Zero Trust SDSec architecture works, this article describes Zero Trust advantages and challenges, this article suggests best practices for transitioning from an older Virtual Private Network (VPN) security architecture to a ZTNA SDSec architecture, and this article describes some Zero Trust use cases. Other SDSec emerging architectures include Software-Defined Protection, MicroSegmentation, Security Services Edge (SSE) and Secure Service Access (SSA). Several aspects of the SSE emerging architecture are explained in this article.

Meanwhile, other companies continue developing and marketing security products using phrases such as Security Information and Event Management (SIEM), Security Orchestration, Automation, and Response (SOAR), Endpoint Detection and Response (EDR), Extended Detection and Response (XDR), Open XDR, and Network Traffic Analysis (NTA). Several security product developers and providers have even joined together to form an XDR Alliance. This article cautions against common misperceptions of XDR and similar security products.

Other Network Virtualization Architectures

In conjunction with the ongoing evolution of the NFV architecture, many “Network Virtualization (NV)” software architectures and emerging architectures are appearing with abstraction layers that conceal (but do not change) the implementation details of the network resources from the network configuration, management or security software, offering hope that network automation may someday become a reality. Just which implementation details of the network resources are concealed, and the functionality of the network configuration, management, or security software vary widely, depending on the specific software or emerging architecture. Several of the benefits, challenges and use cases of network virtualization are described in this article, and at the end of the article is a list of various implementations.

The earlier Wide Area Network (WAN) routing technology MultiProtocol Label Switching (MPLS) continues to be widely deployed for the reasons given in this article, sometimes in conjunction with NV software and other “Software-Defined WAN (SD-WAN)” emerging architectures. This article explains why Internet Protocol version 6 (IPv6) matters for SD-WAN. This article describes the essentials for SD-WAN security. This article describes the SD-WAN service standards established by the Metro Ethernet Forum (MEF) SDO. This article describes some of the pros and cons of both MPLS and SD-WAN.

SD-WAN is sometimes described as an “overlay-based SD-WAN” (or “tunnel-based SD-WAN”, in contrast to another emerging architecture, the “tunnel-free SD-WAN”). Other SD-WAN emerging architectures include "universal SD-WAN (uSD-WAN)", “open-source SD-WAN”, along with "Secure Access Service Edge (SASE)", an open-source SASE, and the MEF SASE Standard Framework (which are not to be confused with the SSE, SSA and other emerging SDSec). Later, the MEF added a Product and Services certification for SASE based on the ratings of its elements (such as SD-WAN, SSE, and ZTNA). This article explains why such certifications are so important. 

The key technologies enabling SASE are reviewed in this article and this article, and their differences are informative. This article compares the SD-WAN and SASE NV architectures, while this article explains how the two are so closely related that they can even be used together in conjunction with an SSE SDSec architecture. This article discusses how SASE can replace some older security technologies.

Some confusion is understandable since SASE and SSE are closely related, as this article explains, in contrast with other emerging NV architectures such as: “Flexible Service Edge (FSE)”, “Intent Based Networking (IBN)” (which recently re-emerged as Artificial Intelligence (AI) Networking), “Network-as-a-Service (NaaS)”, and “Virtual WAN (VWAN)”. 

Open-source software implementations of SD-WAN architectures are also beginning to emerge, and in 2019 the MEF SWDO released an SD-WAN Services Standard 3.0 document, defining standard Edge, Controller and Orchestrator functions.

Implementations of virtual/virtualized “Evolved Packet Core (vEPC)” and virtual/virtualized “IP Multimedia Subsystem (vIMS)” WAN NV, together with network slicing and dynamic network slicing emerging architectures are offered by members of the “3rd Generation Partnership Project (3GPP)” (which is currently developing a 5G-Advanced emerging technology).  Additional early WAN NV emerging architectures are listed in this article.

Originating at the Local Area Network (LAN) level, but not confined to that level, “virtualized Customer Premises Equipment (vCPE)” and "universal CPE (uCPE)" NV emerging architectures are discussed in this SD-WAN and virtualized CPE Report. 

SD-Branch NV emerging architectures are an expansion of the SD-WAN NV architecture as this article explains. Several SD-Branch use cases are discussed in this article, and several SD-Branch security tools and techniques are discussed in this article. SD-LAN emerging architectures are an alternative approach.

LAN NV architectural elements such as VNFCs and PNFCs may also be found in other emerging architectures such as the Software-Defined Data Center.

Independently of the ongoing evolution of the NFV architecture, virtualization is being implemented in a growing number of “Wireless LAN (WLAN)” emerging software architectures. Some examples include “Virtual LAN (VLAN)”, "Fixed Wireless Access (FWA)", “Virtual eXtensible LAN (VXLAN)”, and “Network Virtualization using Generic Routing Encapsulation (NVGRE) LAN”.

Emerging architectures for both physical and virtual networking switch fabrics continue to evolve, as part of a quixotic quest for an SD-WAN that is an all-encompassing Fabric for Universal Networking (FUN). Seriously. 

IT Infrastructure Virtualization Architectures

Abstraction layers can be introduced anywhere in an IT infrastructure. If an abstraction layer is introduced to conceal implementation details in an IT infrastructure from the customer interface to that IT infrastructure, it may result in a Software-Defined Data Center (as described below) or a Software-Defined Workspace (as described below). If an abstraction layer is introduced to conceal implementation details of some applications in an IT infrastructure from the customer interface to those applications, it may result in a Software-Defined Architecture (as described below). If an abstraction layer is introduced to conceal details of some storage resources in an IT infrastructure from the application interface to those storage resources, it may result in Software-Defined Storage (as described below). If an abstraction layer is introduced to conceal details about the attributes of data, or details about the storage resources of an IT infrastructure where data resides, from the applications that access that data, it may result in Software-Defined Data (as described below).

Software-Defined Data Center

Various SWDOs are developing “Software-Defined Data Center (SDDC)” emerging architectures. Broadly speaking, an SDDC is a data center implemented using virtualization together with one or more Software-Defined software or emerging architectures built using a combination of one or more physical and/or virtual network architectures, and each SDDC emerging architecture has been given a name by their SWDO. The SDDC emerging architectures include Software-Defined Data Infrastructures (SDDIs), Software-Defined Infrastructures (SDIs), Software-Led Infrastructures (SLIs), and Platform-as-a-Service (PaaS) (among other names). (Caution: Do not confuse the emerging SDI architecture with another emerging architecture SD-IX sometimes called SDI mentioned in the Network Functions Virtualization Software Architecture topic above.)

Multi-cloud using SD-WAN is an SDDC emerging architecture that combines an SD-WAN emerging network virtualization architecture (several were mentioned above in the Other Network Virtualization Architectures section) with cloud computing to create an SDDC. Since multi-cloud appeared in 2019 it has continued to evolve, by merging with other emerging network virtualization architectures (including edge computing, as described in this article).

An SDDC may include a combination of both physical and virtual: discrete, composable, converged and hyper-converged infrastructure (HCI) resources. This article explores the differences between composable and HCI resources. A composable infrastructure can even be built with composable fabric, as described by this article. An SDDC may even include disaggregated HCI resources (the term “disaggregated” has several meanings, as described in this article).

The customer interface is often called “Infrastructure-as-a Service (IaaS)”. An SDDC is implemented using a combination of local IT infrastructure, fog computing, edge computing and a refinement of edge computing called multi-access edge computing (MEC, originally called mobile edge computing) resources, while fog computing is an expansion of MEC, as this article explains. In 2018 the ETSI ISG for MEC released an MEC standard.

For further details about fog computing versus edge computing, see this article. See this article for some edge computing use cases. The IoT can be used to solve challenges that arise when implementing edge computing, as described in this article, and conversely edge computing can be used to solve challenges that also arise when deploying IoT clusters, as also described by that same article. Their use together can also give rise to a need for edge security. An Open Edge Computing Initiative SWDO is also working to advance edge computing technology. An SDDC implemented using a combination of MEC and HCI could be even better. Just to be clear, edge computing and MEC are not the same thing, as this article explains, nor are distributed cloud and MEC, as this article explains. This Open Glossary of Edge Computing defines terms used when discussing edge computing. (Note: just to complicate matters, there are multiple definitions of “edge’ computing.)

According to this article, based on the IT resources included in an SDDC, an SDDC can be categorized as either:

  1. discrete, physical servers (bare metal) plus other physical IT resources,
  2. virtualized servers (running on hypervisors) plus physical IT resources,
  3. HCI (running on hypervisors), or
  4. HCI (running on hypervisors, while also adding containers to the mix of IT resources included and called an Application-Defined Infrastructure (ADI) by some SWDOs).

The ETSI ISG for MEC and ISG for NFV SDOs are working with the OpenFog Consortium (which, after merging with the Industrial Internet Consortium is now called the Industry IoT Consortium) to establish standardized APIs to enable deploying MEC resources in NFV infrastructures, as described by this article.

An abstraction layer is introduced to conceal various details (which vary with the SWDO) of the internal resource allocation policy and the intrinsic (possibly device-specific) orchestration, management, and provisioning characteristics of the resources in the SDDC.

Different SWDOs may use different terminology to describe their different SDDC emerging architectures. 

Software-Defined Workspace/Workplace

“Software-Defined Workspace (SDW)” (also called Workspace-as-a-Service or an integrated workspace platform) is an emerging architecture. It can be difficult to differentiate from another emerging architecture, Software-Defined Workplace (also called Workplace-as-a-Service). These emerging architectures employ multiple abstraction layers in order to support the use of any type of application on any platform from anywhere via any network.

Different SWDOs may use different terminology when describing the elements of their emerging SDW architectures.

Software-Defined Architecture

“Software-Defined Architecture (SDA)” is an emerging architecture in which an abstraction layer introduces outer APIs (NBIs) and inner APIs (SBIs) for selected applications. The NBIs conceal the implementation details of those applications and their run-time environment from external customers/users. The SBIs conceal these details from other applications. This makes it possible to transparently modify or replace the applications or their environment.

An SDA is a further evolution of the earlier “Service-Oriented Architecture (SOA)” software architecture, and the evolution keeps going on. An SDA is more recently being called a cloud-native architecture by SWDOs, and is used to develop cloud-native applications (often implemented as microservices housed in containers) to support cloud-native infrastructures. This article describes some cloud-native application use cases. Note that not every SOA application can be used to develop a cloud-native application for the reasons given in this article. Different SWDOs may use different terminology to describe the abstraction layer of their SDA emerging architecture.

Software-Defined Storage

“Software-Defined Storage (SDS)” emerging architectures separate virtual and physical data storage resources from the software that manages those storage resources, in a manner similar to the separation of the data plane from the management plane in the early evolution of SDN architecture. This article compares and contrasts SDS emerging architectures with the earlier software architectures: Storage Area Networks (SAN) and Network-Attached Storage (NAS). Various SWDOs are developing SDS emerging architectures, such as this initiative by the Storage Networking Industry Association and the Virtual SAN (VSAN) offerings by Cisco Systems, Inc.

An SDS implementation is typically transparently modifiable while on-line and in-use. For example, without disrupting availability or performance, storage capacities can be increased or decreased, or individual storage resources can be repaired, upgraded or replaced.

This article argues that 5 key attributes must be part of any SDS software or emerging architecture. Different SWDOs may use different terminology to describe their SDS emerging architectures which do not always include all 5 attributes.

Software-Defined Data

Could “Software-Defined Data (SDD)” become the next step in the evolution of SDS? Implementations of this emerging architecture by SWDOs, including DataSphere (ceased operation in 2018) and ViPR (originally developed by EMC Corp, now marketed by DELL Inc), are mentioned in this International Data Corporation Community article.

The SDD emerging architecture would use a combination of data virtualization and structural metadata to create an abstraction layer that separates data from some of its attributes. These data attributes can include format, storage media, access protocol (IPv4 or IPv6) and physical locality. In the SDD emerging architecture, data would be accessible at any time; appear to reside on any storage media; and appear to be accessible using any protocol, whatever the actual location of the data, the storage medium it resides on, the protocol used to access it, the intended use of that medium (such as on-line, archival or disaster recovery), or the format of the data on the storage resource where it resides (all of which could transparently and automatically be changed over time in response to data access patterns).

Emerging Software-Defined Everything Architectures

Several Software-Defined Everything Architectures have been under development since at least 2016 by different SDOs and SWDOs, with only limited coordination between their separate efforts. Some of these efforts are still ongoing.

In 2016 one “Software-Defined Everything" (SDx, originally called “Software-Defined Anything”) emerging architecture became the basis for an inclusive SDx Infrastructure (SDxI). For further details about this SDxI, refer to an eight-part series of articles written by SDxCentral, LLC (originally called SDnCentral, LLC). Network performance management (NPM) elements of this SDxI architecture are defined in this article and application performance management (APM) elements of this SDxI architecture are defined in this article.

(Note: Do not confuse the SDX network function that is the subject of the Software-Defined Internet Exchange Point topic above with the architectures that are the subject of this topic.)