1

Featuring research from

Realize the SDN vision: Operationalize your network with SDAS

The only constant is change – a note from Manny Rivelo

Operationalizing the Network: SDN

From the Gartner Files: What Is the Value of a Software-Defined Data Center?

Resources

2

The only constant is change – a note from Manny Rivelo

Nowhere is the axiom “the only constant is change” more true today than in the realm of technology. A constant influx of new devices, new apps and new business models is forcing us to re-evaluate, re-think, and re-architect the networks that have enabled the application economy to become the biggest agent of change across the globe.

We see mobility and cloud computing driving this change. For every mobile device users and consumers want to use there is a corresponding app they expect to be made available for that device. Where once we debated over whether to support Internet Explorer or Netscape or both the focus now is on how to support web, tablet, phone and phablet and in what order. The broadening of client possibilities will only continue with the introduction of smart things and their need to interface with apps, services and other things, leaving us all to struggle with supporting a maddening array of combinations.

The introduction of new application architectures based on microservices and RESTful APIs has resolved many of the issues for app developers, but introduced new ones for the network. What might have once been a single application I now see being decomposed into hundreds of individual services, all requiring a variety of network and security services. Like the sudden increase in pressure on the network caused by server virtualization, this new application architecture results in an explosion of network connectivity and service needs that cannot be effectively handled by traditional and very static network architectures.

That’s because with every new service, app, device and business model comes just as many new network policies and services. It’s not just that there is more of everything, there’s more of everything that needs to be deployed faster and more efficiently across increasingly distributed environments.

We can’t keep using traditional methods of provisioning and managing networks. I’m not surprised that they can’t keep up with the increasing flow of new apps and services intended to grow the business through increased revenue and improved productivity. I know too many organizations whose break-fix and keep-the-lights-on operations are eating opportunity alive, and that’s something we want to change radically.

Software-defined technologies and architectures like SDN (Software-Defined Networks) have emerged not only to address issues with controlling the core costs associated with scaling business and networks but to improve the efficacy with which networks are provisioned, managed and scaled, namely faster time to market with lower operational costs. I believe these goals can best be met by operationalizing the network with software-defined application services and networks.

Operationalization enables IT to meet business priorities by optimizing operational processes using programmability. API-enabled infrastructure, app-centric templates and data path programmability enable integrated architectures and frameworks to consistently and predictably provision the services necessary to deliver highly available, secure and fast applications to users on both sides of the business success equation: profit and productivity. Automation and orchestration, powered by programmable services and systems, ensure operational scale and efficiency that drives down costs and reduces the risk introduced by nearly constant change in the network.

Manny Rivelo EVP Strategic Solutions F5 Networks

3

It’s important to note, though, that a significant challenge in operationalizing “the network” is its natural bifurcation at layer 4, where stateless networking ends and stateful networking begins. We’ve all seen the differences in protocols and demands on resources of these two networking stacks manifest through network solutions focused on one or the other. I find evidence in that it’s impossible to find a single network solution or device offering best-in-class services for the entire network stack. SDN does not change that natural delineation, and I believe that any successful software-defined initiative must be inclusive of both in order to realize the improvements in time to market and reduction in operational costs and risks.

F5, as the leader in application (layer 4-7) service delivery, recognizes this as a real challenge to adopting SDN. That’s why our Synthesis architectural vision ensures not only the operationalization of the layer 4-7 network with Software-Defined Application Services (SDAS) but integrates and interoperates with a wide variety of solutions focused on operationalizing the stateless network. Through our control plane APIs – iControl, iControl REST and BIG-IQ REST – we ensure integration with partners like Cisco, Microsoft, HP and VMware that results in full-stack, comprehensive software-defined offerings that fully operationalizes the network from layer 2 through layer 7.

I don’t think there is much debate about the premise that the network must change not just to accommodate opportunity but to enable it. In this application world business growth means application growth which in turn means network growth. We see the ability to rapidly provision and scale the network services needed to deliver secure, fast and reliable applications to consumers and employees as critical to the future success of the business. Those capabilities can be realized by operationalizing the network using software-defined technologies and architectures like SDN and F5 SDAS.

With change the only constant, the path to future success must be able to adapt rapidly and frequently. Networks are that path, delivering the applications that drive this emerging app economy, and I believe software-defined technologies will bring the agility to the network that’s needed to succeed.

Best Regards,

Manny Rivelo EVP Strategic Solutions F5 Networks

4

Operationalizing the Network: SDN

Our world, our relationships, and our businesses are being transformed by applications. SDN promises to transform the networks responsible for delivering them.

IntroductionApplications are changing the world around us. Every facet of our lives has been impacted by the explosion of applications on the web; on our phones; and in the common, everyday things we use to manage our homes, our cars, and our lives. Whether we’re managing the efficiency of our appliances, our business and personal relationships, or just playing around, applications are enabling us to connect and communicate with everyone and everything around us.

This explosive growth is not without consequences on those who provide the applications. Whether service provider or enterprise, retailer, or manufacturer, applications are driving new requirements for both businesses and networks that require disruptive, radical change.

Business Transformation Business leaders are constantly under pressure to find new ways to attract, engage, and retain customers to encourage the growth necessary to succeed in a highly competitive world. Applications offer an opportunity to redefine convenience with new business models that take advantage of advancements in technology, enabling affordable and powerful computing options across a wide variety of consumer devices.

As the market attempts to satisfy its nearly insatiable appetite for more convenience, more connectivity, and more control over their lives through applications, business must be able to adapt quickly or risk losing an increasingly fickle and hard-to-please consumer base to competitors.

Pressure is increasing on data center leaders to transform the network to support rapid changes in direction and demand.

Network Transformation The networks in place today were designed and built to support a web-based economy. Scalability

models, security, and topology were as fixed as the users and ecosystem of partners and distributors supporting the business. Change was forecasted, growth anticipated, and network capabilities expanded and enhanced on a fairly predictable schedule.

The explosion of new applications and application models has changed that. Users are no longer fixed, ecosystems are selected on-demand, and consumers are increasingly application-oriented – shifting the burden of customer support and engagement from simple web applications and call centers to interactive mobile applications.

Solutions for an Application World: SDN To transform the network from its fixed and predictable architecture to an agile and adaptable one is no small task, particularly without significantly increases costs. Software-defined networking (SDN) promises to do just that, with an architectural approach that reduces operating expenses and improves time to market. SDN is able to achieve this by operationalizing the network through programmatic interfaces (APIs), automation, and abstraction across a standardized platform.

Classic SDN SDN is not a new concept. The notion of separating control and data planes has been around since well before it became the industry darling du jour.

Initial definitions of SDN by the ONF restricted it to stateless network services by relying on OpenFlow as its primary protocol and the inability of its architecture to scale when presented with the need to manage stateful network services.

Over the past few years it has become evident that the classic definition of SDN was insufficient to meet the expectations of a market under pressure to transform the entire data center. The classic focus on stateless networking leaves unaddressed the challenge of operationally scaling stateful network services.

A new SDN model is now emerging that is better able to support the entire network stack.

Networks were not built

to handle the rapid

changes in demand for

one application over

another, nor were they

built to scale and adapt

as quickly as business

requires today.

Automation and APIs Automation, supported by API-enabled infrastructure, is key to SDN architectures and scaling network operations to support the next generation of apps being driven by mobile, cloud, and the Internet of Things.

F5 2014 State of Application Delivery survey results:

46% of respondents rate APIs as very important for infrastructure.

71% who want SDN to reduce OpEx rate APIs as important/very important.

5

Stateful Versus Stateless Networking

A key inhibitor of classic SDN success is that its design principles were largely based on the behavior and needs of stateless network services (L2-4). Stateful network services (L4-7) introduce significant technical challenges that are not easily addressed by classic SDN architectures.

Stateless SDN assumes that all state is centralized in the controller. Rules regarding forwarding of packets are distributed to the data plane as needed. About one in every million packets requires a query to the controller.

Stateful networking services, however, are named as such because they maintain state on a per-flow basis at layers 4-7. Assuming a classic SDN architecture, this would require a query to the controller at most every four packets. Additionally, the controller would need to maintain a massive session table (one per flow) to ensure proper forwarding across the network.

The classic, stateless SDN model does not scale to meet the needs of stateful layer 4-7 services. Without support for stateful layer 4-7 services, SDN fails to operationalize the entire network and organizations will not realize its full potential.

Source: F5

FIGURE 1 Separating Control and Data Plane

Why IT Wants ItOne of the primary benefits touted by classic SDN proponents of its architecture was a reduction in CapEx. That benefit came in third in the F5 survey. 38% of respondents want SDN to reduce CapEx.

66% want SDN to reduce OpEx.

44% want SDN to improve time to market.

Emerging SDN When F5 asked the market its opinion, 59 percent agreed that classic SDN could not support the stateful services applications need. The emergent definition of SDN takes that into consideration and focuses instead on operationalization of the entire network, which offers benefits that align with those the market is demanding.

SDN achieves this by separating control and data planes, and using programmability to encourage automation and orchestration of service provisioning. SDN also uses integration with other systems to transform the network from a fixed, manual model to an agile, automated set of services.

6

How SDN Operationalizes the NetworkTraditional networks comprise hundreds of network devices providing a robust set of services. These range from routing and switching to application performance, availability, security, identity, and access control and mobility.

Manually configuring these devices and services for each and every application consumes a considerable amount of time for both network and operations teams.

By shifting the burden of provisioning and configuration to scripts, templates, and orchestration systems, network services can be deployed in much less time and with greater consistency.

To enable this, network and infrastructure devices must be programmable; they must enable configuration and provisioning via open APIs at a minimum. Application service templates can further reduce risk and improve time to market by encapsulating common tasks into an executable package easily deployed with a single command. Using open APIs further enables integration with network automation and orchestration systems such as Cisco ACI, OpenStack, and VMware NSX. This approach provides an end-to-end network service provisioning model in which app deployments can be supported in hours or days –instead of weeks or months.

Benefits of SDNImprove Time to Market

Operationalizing the network with a software-defined architecture enables faster time to market through automation and orchestration of network service provisioning. By using API-enabled infrastructure, application-driven service templates and data path programmability, network services can be provisioned in hours instead of months.

Decrease Risk

Human error is a significant contributor to network downtime. Troubleshooting configuration errors across the hundreds of devices that make up the network takes time. By centralizing the state of the network, engineers gain greater visibility and control and can easily pinpoint trouble, minimizing disruptive downtime.

Reduce Operating Costs

Operationalizing provisioning processes results in greater efficiency which can translate into lower costs per application deployment. The use of automation and orchestration enables an economy of operational scale not achievable using traditional, manual provisioning methods.

7

Source: F5

FIGURE 2 F5 Simplifies SDAS/SDN working with Partners

The Role of F5 in SDNThe F5 architectural vision, Synthesis, fills the need for stateful L4-7 services required of a comprehensive SDN architecture. It is application-driven and delivers F5® Software-Defined Application Services™ (SDAS™) critical to delivering modern applications capable of meeting user expectations while complying with business and regulatory requirements. F5 Synthesis focuses on transforming the delivery of application services from the static and siloed topologies of yesterday to the dynamic, virtualized and programmatic model required today to take advantage of the emerging application economy.

Conclusion

The focus of SDN is on transforming the network to support applications and meet the expectations of users and businesses that rely on them. Scaling modern networks is challenging due to the explosive growth of compute, network, and application resources – combined with increased mobility of apps migrating to the cloud and users across multiple devices. As an approach to operationalizing the network, SDN enables organizations to achieve greater economies of operational scale through the use of APIs to automate and orchestrate the network, and application services that support applications.

www.F5.com/SDN

Source: f5

8

What Is the Value of a Software-Defined Data Center?

“Software-defined anything” is the new industry buzzword. This research cuts through the vendor “marketecture” and defines the software-defined data center and its value proposition, taxonomy and key attributes that enterprises can use to distinguish vendor hype and offerings.

Key Findings

• Software-defined anything (SDx) consists of software-defined application services (SDAS) and software-defined infrastructure (SDI). The software-defined data center (SDDC) is a component of SDI and is an architectural approach (not a market).

• SDDC’s key value is enabling agility through policy-based automation of the data center and facilities infrastructure.

• SDDC is in the early stages of maturity and will change significantly over the next five years.

• SDDC separates management controls and services from the hardware infrastructure, thus potentially enabling infrastructure automation and optimization innovations in the software layer.

• SDDC goes beyond virtualization and may be used for cloud service infrastructure automation; however, alternative automation architectures could be used to get the desired outcomes.

Recommendations

• Type A enterprises: Evaluate SDDC especially in the context of virtualization and/or cloud computing, agile methodologies or when building a new data center. Type B and C enterprises: Wait two to three years until the market matures before embarking on a large implementation.

• Before selecting SDDC solutions, know your agility, operational efficiency and cost containment drivers, deploying SDDC opportunistically and in a phased manner, to meet your needs.

• When evaluating SDDC solutions, assess vendor lock-in (to APIs, technology and so forth) and develop contingency plans for migration to alternative technology.

• Since IT organizations will likely require many SDDC vendor solutions in their architecture, be sure to assess solution interoperability and integration with higher-level policy frameworks, as well as the support of existing hardware.

• If implementing cloud services and/or agile methodologies (DevOps), ensure deep integration between cloud management platform (CMP) and release automation and SDDC solutions, and the value proposition over and above the automation embedded with cloud management services.

Analysis

SDDC DefinedSDDC is an optional architectural approach for IT infrastructure and facilities management and service engineering. SDDC enables abstraction of the physical infrastructure, with its services exposed via APIs enabling greater levels of automation, policy-based orchestration and reuse, much like service-oriented architecture does for application componentry. The goal of SDDC is to deliver greater business value than traditional, more manual processes and scripts by increasing the agility and speed of infrastructure through policy-based automation of processes. This includes infrastructure selection, security, provisioning, and ongoing life cycle management and optimization. As a result, operational cost savings are also a benefit by both lessening administrative requirements and enabling reusability of automation. In doing so, SDDC enables the migration of the software services residing on proprietary hardware to a higher-level software service layer, with policies driving configuration, automation and deployment across a distributed environment (see Figure 1) and the potential for cost savings in capital expenditure by implementing resource pools containing commodity hardware. Moreover, SDDC may extend legacy hardware investments as well.

From the Gartner Files:

9

As enterprises evaluate SDDC vendor solutions (see Note 1), it will be important to understand what technologies they replace, as well as how existing technologies will need to change as a result of SDDC. Moreover, while SDDC offers automation and optimization capabilities, enterprises need to assess which processes and services are automated out of the box, versus those that must be built by the enterprise. Out-of-the box capabilities and content will reduce the time to value of the overall solution.

SDDC is a key component of SDI, which also includes infrastructure outside data centers, including not only traditional IT infrastructure (such as compute, storage and networking), but also sensors, devices and operational technologies – all of which are increasingly becoming software-defined. SDAS communicates with SDI, and both are under the umbrella term “software-defined anything” (see Figure 2). The main focus of this document is SDDC and its value proposition.

Value Proposition of SDDCKey value propositions of SDDC include the following:

• Increases provisioning and management agility, while optimizing process and service delivery costs. SDDC does this by providing documented

SDDC is often the backbone of public cloud service delivery and SLAs/service-level objectives, enabling automation and policy enforcement activities to be selected through analytics, orchestration and APIs. Private cloud services rarely implement SDDC today; however, they will increasingly do so as SDDC matures.

Even so, SDDC is one of many possible automation architecture implementations, and cloud computing and continuous release automation (DevOps) do not require SDDC. Rather, SDDC offers a solution that, by putting policy controls in software (and not in the underlying hardware), encourages greater ecosystem functionality innovations. In addition, SDDC can be utilized for cloud-based and traditional on-premises service architectures. Moreover, SDDC focuses on enabling automation of infrastructure setup, configuration and pooling, as well as the automation of infrastructure and operations processes, such as infrastructure break/fix automation and capacity automation. In essence, a key goal of SDDC is to enable better and more efficient management and optimization of infrastructure and facilities for on-premises and hybrid service delivery – that is, to become more like a public cloud provider in their management and automation of infrastructure, facilities and processes.

Source: Gartner (September 2014)

FIGURE 1 High-Level View of SDDC

Infrastructure "Data Plane"

Infrastructure "Control Plane"

Layer of Abstraction

Southbound APIs

Northbound APIs

Physical Infrastructure

Service Layer

10

API access to infrastructure, enabling greater control, orchestration and automation across distributed environments.

• Enables movement of functionality traditionally embedded in hardware devices to a software layer that is more modular and easier to change/update. This ability fosters service innovation by suppliers, as well as by the enterprises and IT organizations that implement SDDC. In addition, SDDC potentially extends legacy hardware investments if new SDDC services are layered on top of them.

• Reduces overprovisioning of hardware (because software is typically provisioned more easily and rapidly than hardware, and because SDDC leverages a common pool of hardware resources on which multiple services can run). It may even add services to legacy hardware deployments.

• Fosters greater use of commodity hardware (but ideally supports a heterogeneous commodity in addition to proprietary hardware, thus preserving enterprise investment protection) because the control of that hardware is outside the hardware itself. In fact, much of the value today of proprietary hardware, especially in storage and networking, is derived from the software inside the solution.

• Provides federated policy-based configuration and enforcement across distributed infrastructure devices, thus enabling faster provisioning and changes with fewer IT administrative demands.

• Possibly enables swapping of underlying hardware infrastructure, without affecting the services riding on top it, if APIs are either consistent or mapped by the SDDC control plane.

• Fosters new infrastructure innovations, such as real-time binding of application services to the most appropriate and optimized infrastructure, because configuration control mechanisms are maintained in software outside and independent of devices. This enables organizations to reduce traditional overprovisioning of infrastructure (at the time of initial deployment) and inefficiencies in asset utilization and people resources. It is important to note, however, that these innovations are not classified as SDDC per se, but as infrastructure optimization functionality that leverages SDDC. Not every function that has policy enforcement becomes SDDC; rather, SDDC is an underlying, more flexible enabler of such functionality.

Source: Gartner (September 2014)

FIGURE 2 Hierarchy of SDx

SDx

SDAS SDI

SDDC

Infrastructure outside

data centers

11

SDDC Attributes and TaxonomyKey attributes of SDDC and the minimum criteria for SDDC are as follows:

• Abstraction – Of resources from their physical implementation, thus decoupling a resource from its consumer. Abstraction enables definition of logical models of infrastructure elements that can be instantiated at time of provisioning and reused, thus enforcing standardization.

• Instrumentation – Of infrastructure (physical and virtual) for monitoring, publishing and intelligent analytics.

• Programmable – Enabling not just hands-off automated provisioning services, but all IT processes through documented APIs (typically RESTful APIs).

• Automated – Using the APIs, wiring up the exposed elements using scripts and other automation tools to remove “human middleware” from the equation.

• Policy management – Enabling centralized configuration and reconfiguration of the decentralized infrastructure through pre-established policies to meet business needs.

• Orchestrated – Beyond script-based automation, enabling automation of tasks across resource domains of compute, network, storage, facilities and security, with linkages to policy management for enforcement and optimization.

The combination of the above capabilities will foster innovations that optimize infrastructure and application use of underlying infrastructure. Examples include selecting the right infrastructure for deterministic SLAs, and dynamically optimizing the infrastructure to increase asset utilization. These capabilities may be brought to market independently or as part of a suite of functionality, such as in CMPs.

Figure 3 presents the broader taxonomy of SDDC. SDDC is broken down into its component parts – compute, storage, network and facilities – with

SD = software-defined Source: Gartner (September 2014)

FIGURE 3 Taxonomy of SDx

Software-Defined Anything

Software-Defined Infrastructure

Software-Defined Application Services

Sof

twar

e-D

efin

ed

Man

agem

ent &

Pol

icy

Sof

twar

e-D

efin

ed S

ecur

ity

SD Devices

SD Machines

SD Factory SD House SD Auto

App 1

App 2

App 3

App 4

App 5

App X

Software-Defined Data Center

SD Network

SDN

SD Storage

SDS

SD Facilities

SDF SDC

SD Compute

12

the SDAS on top, requesting infrastructure services through SDDC APIs. Security and management are cross-domain services that span applications, application services and infrastructure. Each component would be accessible and managed through its own control plane (with associated software services) that offers a set of APIs, policy and orchestration. A catalog of logical blueprints or policy templates (see Note 2) enables reusability of a particular infrastructure configuration (such as a “flavor” in OpenStack Compute [Nova] or a workload-specific storage profile for low latency and high input/output operations per second, with certain SLA guarantees). “Software-defined anything” is the umbrella term Gartner uses to describe anything that is software-defined, including applications and infrastructure.

SDDC Basic Versus Advanced FunctionalityFigure 4 shows how SDDC encourages moving functionality traditionally trapped in or aligned to physical hardware into abstracted software that runs on servers (using a software-defined

storage [SDS] example). It shows how traditional physical storage arrays have deduplication services in them (on the left-hand side of the graphic). Storage arrays from different vendors, or even arrays from the same vendor, have had their own siloed functionality, and services have rarely been accessible via APIs. Even if the functionality was accessible via APIs, the APIs were all different from the same vendor and especially across vendors, making it impossible to have programmable infrastructure across heterogeneous devices and providers.

SDDC abstracts those differences and enables a common set of APIs to talk to underlying physical hardware functionality, thus enabling policy-based services and orchestration across the disparate physical environment(s). It also leverages logical models (such as profiles, patterns and blueprints), which foster the use of reuse and repeatability, to gain agility and speed. This can bring tremendous efficiencies in management to administrators and operations personnel.

w/ = with; w/o = without Source: Gartner (September 2014)

FIGURE 4 The SDDC Continuum From Basic to Advanced, Using SDS as an Example

SDDC Continuum Basic SDDC

Advanced SDDC

Dedupe

API

Dedupe

API

Dedupe

API

Software-Defined Storage Layer

Specialized Storage w/ Services

API API API

Software-Defined Storage Layer

Dedupe

"Dumb" Storage w/o Services

13

However, Gartner refers to this implementation as “SDDC basic” because it enables better management of the legacy environments but does not fully abstract the functionality out of the physical implementation and into a logical service layer. The “SDDC advanced” implementation is shown on the right-hand side of Figure 4, which shows the migration of deduplication services to a higher-level service layer, abstracted from the underlying hardware, which has typically been vendor- and model-specific. The underlying hardware could be traditional or commodity in nature, but this has the effect of commoditizing the underlying traditional infrastructure (because you are not making use of its proprietary capabilities and/or are adding new capabilities where they did not previously exist). It also has the effect of greatly improving operational and infrastructure efficiencies through the migration and implementation of storage services in software that gain increased visibility across hardware domains.

While we see SDS, software-defined compute (SDC), software-defined facilities (SDF) and software-defined security (SDSec) evolving to have both basic and advanced capabilities, software-defined networking (SDN) is different. SDN – which was the first of SDDC component architectures to be defined and implemented – requires an advanced implementation to be called SDN (see “Ending the Confusion About Software-Defined Networking: A Taxonomy”). The reason is that SDN was created by the university community to enable networking innovation via software that was independent of the hardware layer and to eliminate proprietary functionality on the physical networking devices themselves. So, although there may be significant value in implementing alternative approaches that improve management and automation of the physical devices and functionality embedded in them, Gartner does not classify those implementations as SDN. In the other SDDC areas of compute, storage and security, however, which are less mature than SDN, early investments by vendors have tended to be more focused on reducing complexity through policy-based orchestration, enabling legacy physical devices to be incorporated into automation and orchestration management tasks, while also introducing new service functionality at the same time.

Figure 5 shows the concept of SDDC services and aggregated integrated infrastructure management services that sit on top of the component

control planes, with additive management and optimization functionality. Services could act on one specific component or across many components. For example, integrated infrastructure systems typically have logical patterns or templates that include compute, storage, networking and security and that enable aggregated provisioning to the distributed environment based on policy. As a result, aggregated management and control services must have federated or deep integration to the underlying component’s services and APIs. An aggregated service may, for example, choose the right internal or external data center when provisioning a service and the right mechanism for cross-site resiliency based on recovery point and time objective SLAs, thus optimizing disaster recovery SLAs to the underlying infrastructure and facility architecture. Moreover, because each SDDC vendor comes at SDDC from its own strength, leveraging its own control point, most IT organizations will require many vendor solutions in their resulting SDDC architecture.

Many organizations are implementing private, hybrid and public cloud services via the use of a CMP and cloud service broker (CSB). These tools enable end-to-end service design patterns or blueprints (with associated policies) that are then provisioned into the right data center and resource pool based on policy (such as capacity, latency and cost). Many of these tools integrate to underlying SDDC component patterns or templates for execution (alternatively, many enable these component design patterns directly in the CMP logical model or blueprint). A key concept is that policies and orchestration are both federated and hierarchical in nature. The design of a new cloud service may be initiated in a CMP but executed through integration with underlying component orchestrations and policies.

An example of this is OpenStack (an open-source CMP), which has Heat templates for resource definitions but executes provisioning of resources through APIs to compute, storage, network and security components. In another example, a higher-level CMP may define a cloud-optimized service blueprint (which defines all the logical application and infrastructure components of a cloud service) and provision it through one or many private or public infrastructure-as-a-service services to the individual infrastructure resource pools. The CMP then may monitor the service and trigger increased capacity by scaling up or out the infrastructure through its aggregated policies and orchestration control layer.

14

How Is SDDC Different From Virtualization?Any abstraction includes virtualization. Virtualization is a necessary and foundational element of SDDC (and SDx). However, SDDC goes beyond virtualization in terms of standardizing the access and control over the resource components in software (rather than only in hardware) and in adding programmability (via APIs), orchestration and policy enablement. As a result, infrastructure can be freely manipulated, ideally in a standard way, enabling applications – especially those built in an agile continuous delivery model (DevOps) – to completely automate the setup, configuration, testing, deployment and ongoing management through its life cycle. Using a standard SDDC software layer could enable the underlying hardware infrastructure to be replaced with minimal or no impact on the applications themselves (because the APIs are common or mapped to each other).

However, care must be taken to use the lowest common denominator of APIs to get the replacement benefit, thus potentially limiting SDDC’s usefulness. Moreover, vendors are motivated to add extended APIs and functionality

outside the common APIs to innovate, but innovation comes at the price of greater lock-in and more difficulty to migrate to an alternative vendor.

How Is SDDC Different From Cloud Computing?One similarity between SDDC and cloud computing is that they both represent architectures built on abstracted infrastructures. However, cloud service architectures are built by a cloud service architect (or owner) for consumption by customers or consumers in a self-service way. SDDC represents an optional infrastructure and data center architecture, enabling infrastructure agility (and potential mobility) through automation, controls and intelligence of the underlying infrastructure. Therefore, SDDC may be used but is not required to enable cloud service provisioning and automation.

SDDC and CMPs are closely tied together because building services for the cloud requires the programmability and other attributes of SDDC, such as policy and orchestration. A CMP embeds SDDC functionality (in its service optimization layer) to orchestrate provisioning the right

Source: Gartner (September 2014)

FIGURE 5 Relationships and Dependencies of Components

Software-Defined Application Services

Sof

twar

e-D

efin

ed

Man

agem

ent &

Pol

icy

Sof

twar

e-D

efin

ed

Sec

urity

Software-Defined Data Center

SD Network

SDN

SD Storage

SDS

SD Facilities

SDF SDC

SD Compute

Aggregated Services

CMP CSB (Service Models,

Policies and Orchestration)

15

infrastructure and in an automated policy-based way, such as provisioning to the right resource pool in the right internal or external data center. A CMP may, for example, utilize its own functionality for network provisioning (such as IP addressing, firewalls or load balancing) or integrate to third-party SDN functionality for network policy and provisioning.

OpenStack represents an open-source-based CMP for virtual compute, storage, networking, DBMS and identity management that embeds SDDC with open-source APIs that can be used for orchestration and automation of cloud services. Vendors of virtual infrastructure write drivers or plug-ins that enable the functionality of the requested APIs. CMP vendors add value to OpenStack (and other cloud resources) by adding the application or service context for complete end-to-end provisioning, orchestration and management of the entire service, across all environments (development, test, staging, production, disaster recovery and so forth). In addition, vendor plug-ins can offer more advanced functionality to OpenStack directly in piece parts rather than through a complete layered CMP offering. For example, plug-ins may add the capability for policy-based placement (to internal or external providers or resource pools), dynamic infrastructure optimization or performance diagnosis.

Cloud computing, however, is focused on designing, provisioning and optimizing cloud services. SDDC goes beyond this to automation around noncloud services and beyond cloud services (for example, to infrastructure, operations and data center processes). For example, automating cloud services (from a consumer perspective) does not address automating the cloud infrastructure (from an administrator perspective). SDDC would enable the programmability for such automation and optimization of the physical infrastructure. It would enable automating processes, such as the integration of new capacity to resource pools and infrastructure break/fix processes, inclusive of vendor notification and integration with internal and external incident management and response processes. In fact, SDDC is the underlying foundation (in combination with process and infrastructure automation) that allows public cloud providers to massively scale their infrastructure with many fewer people resources compared with enterprise data centers.

Does SDDC Absorb the Market for All Infrastructure Software and Hardware?No! Although software and hardware infrastructure functionality will become addressable via documented (open and proprietary) APIs, this does not mean that all the software functionality previously known, for example, as backup and recovery software, infrastructure monitoring software, and security encryption will be reclassified to SDDC. However, policy frameworks that configure and enforce policy across a distributed set of infrastructure devices, such as SDN (for example, VMware NSX and Juniper Networks Contrail) and SDS (such as Atlantis Computing ILIO USX and EMC ViPR), would be classified as SDDC.

Market Hype Versus RealitySDx is in early stages of maturity, as shown in Figure 6, with the SDx technology profiles highlighted on a 2014 Gartner Hype Cycle curve (see “Hype Cycle for Virtualization, 2014”). The primary driver for SDDC is agility through automation and policy enforcement, which allows orchestration across multiple domains. Also, SDDC is often considered when implementing private and hybrid cloud services, including services that have frequent releases (using agile methodologies and DevOps). SDDC should be implemented in an incrementally new environment (where new services are created or existing services are onboarded and/or extended) because it is easier and more cost-effective to create new services using SDDC APIs and policies with orchestration than it is to retrofit existing services.

Another use case of SDDC is more focused on gaining efficiencies in infrastructure and operations. To illustrate, SDDC can be used within and across server, storage and network teams to automate their management processes and repetitive tasks, reduce configuration errors, improve speed of service delivery, and reduce labor costs. For example, some SDS solutions offer an API translation layer that enables one API to talk with multivendor storage devices, thus reducing the complexity of automating and orchestrating management tasks to initiate storage services across devices.

From a component perspective, network and security are more mature, although still in early software-defined stages. SDN controllers are gaining traction (see “Mainstream Organizations Should Prepare for SDN Now”), and network

16

function virtualization (services on top) is rapidly being developed (such as for load balancing and firewall services in software). Not all SDN solutions on the market are architected or implemented in the same manner, and some are automation solutions masquerading as SDN solutions. It may be possible to achieve enterprise goals with an automation solution (that is not SDN); however, the downside is that embedded software or even the hardware may need to be updated to get new innovative functionality that is not already on the device (rather than just the rollout of new software). Additionally, the vendor that controls the embedded software can control the pace and direction of innovation, much like Apple uses control of iOS to limit competition from other browser vendors.

In the same manner, most CMPs are rolled out without SDDC and use alternative means of achieving automation and policy requirements but will increasingly be integrated with SDDC component solutions as they mature over time. Already CMPs are integrating with integrated

Source: Gartner (September 2014)

FIGURE 6 Hype Cycle Highlighting SDx-Related Technology Profiles, 2014

As of July 2014

Innovation Trigger

Peak of Inflated

Expectations Trough of

Disillusionment Slope of Enlightenment Plateau of Productivity

time

expectations

Plateau will be reached in: less than 2 years 2 to 5 years 5 to 10 years more than 10 years

obsolete before plateau

Software-Defined Storage

Software-Defined Compute

Software-Defined Anything Software-Defined Data Center

Software-Defined Networks

Virtualization

infrastructure systems’ SDDC APIs, giving them a standard way to communicate to available underlying aggregated compute, storage and networking functionality. However, each vendor’s integrated infrastructure system offers a different set of APIs; thus, an API abstraction layer in the CMP can help reduce complexity and the impact on changing infrastructure vendors, but at the cost of greater lock-in to the CMP vendor.

Like all automation solutions, SDDC can be disruptive and transformative if applied to the right areas for the right business outcomes. However, enterprises need to recognize the hype and early stage of SDDC technology and tread carefully and methodically in their evaluation. Comments based on enterprise type are as follows:

• Type A enterprises with strong infrastructure and architecture skills are already evaluating SDDC, typically in context of virtualization and/or cloud computing and agile methodologies, and often when building a new data center.

17

• Type B and C enterprises should wait two to three years until the market matures before embarking on a large implementation. However, pilots and smaller implementations to gauge understanding and benefit should be considered, especially if the organization is developing cloud-native or optimized services, is using agile methodologies, or is embarking on a digital business initiative.

Note 1 SDDC Vendors

All traditional data center infrastructure vendors are offering various SDDC-oriented solutions, emphasizing their core strengths. None are complete SDDC solutions (meeting all criteria across all areas), and with a lack of standards, most will not interoperate with each other. As a result, buyers should be cautious.

The following are sample vendors offering solutions for SDC, SDS, SDN, SDF and SDSec:

• SDC: Cisco, Docker, HP, Red Hat and VMware

• SDS: Atlantis Computing, EMC, Nexenta and VMware

• SDN: HP, Juniper Networks, Nuage Networks and VMware

• SDF: Emerson, IO, Nlyte Software and Schneider Electric

• SDSec: CloudPassage, Illumio, vArmour and VMware

Note 2 Catalog of Logical Blueprints or Policy Templates

Each SDDC domain, as well as higher-level services, incorporates the concept of reusable patterns or blueprints. The idea is that these patterns identify specific logical configurations (for example, of storage, compute, networking and security) that can then be instantiated very quickly into the physical or virtual environment upon provisioning.

Source: Gartner Research, G00262841, Donna Scott, Dave Russell, Joe Skorupa, Philip Dawson, Neil MacDonald, 10 September 2014

18

Resources

F5 helps to future-proof your network with an architecture that works across a variety of network technologies – from traditional Ethernet to SDN – and can be rapidly provisioned to support business agility. With F5, you can improve application security, availability, and performance today – while laying a foundation for the network you’ll need tomorrow.

Watch the video: Tomorrow’s Data Center Starts Today with Synthesis

F5 Global Services provides expertise throughout the complete solution lifecycle to assist our customers and partners architect, implement, maintain, and optimize their F5 environment to meet their business needs. A specific example is F5’s Professional Services Solution Definition Workshop. For customers looking to leverage the full capabilities and benefits of SDN to address application delivery requirements, F5 Professional Services can help design an optimal network architecture and create a comprehensive deployment plan. During the multi-day consulting engagement our consultants will facilitate a review of business requirements, map F5 solution capabilities, and deliver a detailed scope of work to fulfill the customer’s specific business requirements.

To learn more about F5 Services please visit: www.f5.com/support

Much of the SDN promise revolves around simplified orchestration and management. To get there, vendors need to be tightly integrated and aligned around common standards. As the bridge between applications and the underlying network routers and switches, F5 works with leading network and SDN providers to ensure the seamless integration our customers require. F5 is working closely with all of the key players to mitigate the risks and increase the value of SDN for our customers.

Find out more, www.F5.com/SDN.

About usF5 provides solutions for an application world. F5 helps organizations seamlessly scale cloud, data center, and software defined networking (SDN) deployments to successfully deliver applications to anyone, anywhere, at any time. F5 solutions broaden the reach of IT through an open, extensible framework and a rich partner ecosystem of leading technology and data center orchestration vendors. This approach lets customers pursue the infrastructure model that best fits their needs over time. The world’s largest businesses, service providers, government entities, and consumer brands rely on F5 to stay ahead of cloud, security, and mobility trends. For more information, go to f5.com.

Realize the SDN vision: Operationalize your network with SDAS is published by F5 Editorial content supplied by F5 is independent of Gartner analysis. All Gartner research is used with Gartner’s permission, and was originally published as part of Gartner’s syndicated research service available to all entitled Gartner clients. © 2014 Gartner, Inc. and/or its affiliates. All rights reserved. The use of Gartner research in this publication does not indicate Gartner’s endorsement of F5’s products and/or strategies. Reproduction or distribution of this publication in any form without Gartner’s prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. The opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see “Guiding Principles on Independence and Objectivity” on its website, http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp.