Software-defined infrastructure: Cloud services do SDN one better

Adara Networks has been selling SDN equipment to service providers for years. Adara's chief software architect explains how SDN's advantages extend across the data center

This week, InfoWorld's New Tech Forum hosts Karthikeyan Subramaniam, chief software architect at Adara Networks.

Adara focuses on software-defined networking and infrastructure orchestration. Karthikeyan believes we aren't looking quite far enough in terms of what can and should be automated and orchestrated across the data center.

Rather than limiting SDN to the network, we should be looking to deploy software-defined infrastructure, or SDI, that would separate the control plane for every aspect of the infrastructure, and lead to new ways to manage infrastructure resources and costs. -- Paul Venezia

Running cloud services within budget using SDI

True plug-and-play IT infrastructure is fast approaching. With the advent of cloud computing, many small and medium-sized businesses may soon be able to rid themselves of IT infrastructure maintenance once and for all.

SDN (software-defined networking) is a vital component of effective cloud computing for both the provider and the customer. In fact, it should involve more than just the network -- and extend to all aspects of the infrastructure, from the data center environment to server processing resources. This expanded definition might be better termed SDI (software-defined infrastructure).

It's all about visibility and granularity

In an IT infrastructure based on physical servers, one of the main issues is a lack of visibility. When accounting for IT and data center costs, a large percentage of capital expenditures are actually allotted to bandwidth, storage, and other operational resources. To be properly assigned, these operational resources need a correct method for planning and eventual deployment. Otherwise, these resources may become misallocated -- wasting time and money, potentially on a large scale.

Virtualization by itself is not enough. A hypervisor does not necessarily lend visibility into what services are running inside a virtual machine. Often, overhead within an operating system may consume significant resources. A primitive automation system, for example, can mistakenly spin up another virtual machine to offset the load on enterprise applications that are presumed to be overloaded.

SDN offers the potential for greater visibility and granularity by separating the control plane from the data plane. Academic and research communities have created software components called controllers to serve as the control plane, which provide API or CLI-based interfaces to push rules to switches and manage data flow. These tools are generally too complicated for administrators to learn, program, or manage. Not many administrators are interested in becoming programmers.

A production-ready control plane needs to be simple, yet intelligent enough to parse business SLAs at a granular level and provide the automation needed to enforce them. It should allow system administrators to allocate the appropriate resources with service-level granularity. All protocols, mechanisms, and tools should provide this granular level of control, in contrast to control planes that are tied to physical hardware. SDI unifies the data that's scattered from physical to application layers and illuminates granular, service-level resource usage and control throughout the infrastructure.

Avoiding standards lock-ins

Today's SDN "definition war" is a disturbing trend impeding cloud service providers from implementing practical and useful SDN products that provide granular control to customers. SDN's scope and definition have diminished to the extent that one cannot differentiate it from the term OpenFlow. If these definitions are convoluted and misappropriated by the industry, the useful and dynamic purpose of SDN will become overlooked.

SDN might get the attention of some system administrators, who want to perform traffic engineering and reshaping, but the momentum this new technology brings to network device makers and users alike will begin to subside. After many years of suffering from shortsighted networking protocols and the need for expensive optimizers, accelerators, and adapters to handle their inefficiencies, customers want straightforward products that provide interoperability, granularity, dynamism, and greater visibility. Standards are meaningful only if they provide true value and are extensible.

As customers try to avoid the "vendor lock-in pit" in hope of realizing a cost-effective IT solution, they should not be diverted into the "standards lock-in pit," either. If the propagators of SDN terminology wish to confine their definition to a smaller and simpler southbound protocol like OpenFlow, then it will become just another piece of networking jargon that fades away.

What's needed is SDI, an intelligent and automated control plane that covers the breadth and depth of the IT infrastructure  -- and decouples and unifies the control plane to provide holistic value across the data center. For example, an "SDN" controller should be able to dynamically control everything from HVAC systems to Layer 0 devices such as ROADMs (reconfigurable optical add-drop multiplexers) and everything in between.

Asking the right questions

SDI should enable cloud service providers to ask the right questions to define the control plane parameters for their customers. A true SDI solution should enable the cloud service provider's provisioning interface answer the following:

  • What is your daily/weekly/monthly budget per service?
  • How many users are you expecting for each service at specific times?
  • How many maximum user sessions you would like to provision?
  • When the maximum budget threshold is reached, which services would you like to remove from prioritization, so you can redirect those resources toward specific higher-priority services?
  • Do you want an automatic service scaling or approval-based auto scaling of services?
  • What are the security and administrative restrictions on service consolidation and migration? (Some service customers want to run sensitive services on a private cloud, while the rest run on a multitenanted cloud.)

Implementing true SDI

The ultimate goal of a correctly implemented SDI solution is to provide an autoscaling services infrastructure that's not grossly overprovisioned, thereby optimizing the cloud customer's operating expenses -- while ensuring full operation during periods of expected or unexpected heavy use.

A true SDI solution should be able to balance all that. It should also simplify the infrastructure provisioning process. In addition, a true SDI solution should be able to provide the interfaces and adapters to leverage the real-time information fed from the customer's services and include them in the infrastructure orchestration and service choreography.

For greater visibility and control, a true SDI solution should be able to use its control plane to gather the information from multivendor and multilayer data planes. It should provide an easy-to-use interface for customers to specify their provisioning and autoscaling policies as workflow. Policy-level, service-level, and physical infrastructure-level visualizations, along with an SLA dashboard, are also critical in enabling the customer to realize the dynamism and value of a true SDI solution.

How Adara built robust SDI

Adara has been building the foundation for SDI for many years. Creating a holistic control plane involves creating hierarchical but decoupled management systems for high levels of scalability and performance.

To manage hundreds of thousands of network elements, Adara employs Multilevel Alert Collectors to identify and filter out the false-positive alarms at the lowest layers. Infrastructure events are filtered at multiple layers, and only action-worthy events are sent to the top-level management tiers. Along with OpenFlow, Adara's Meta-Controller supports industry standard protocols such as SNMP, RMON, TL1, SSH/Telnet CLI, WSDL/Restful APIs, and other proprietary protocols.

Adara's data plane is built on top of a dynamic multipath routing and switching overlay. It provides capabilities such as dynamic QoS, TCP acceleration, and data de-duplication as virtualized network functions. Adara Sirius Routers provide dynamic routing based on available bandwidth and real-time latency. To meet the SLAs of the customer applications, it's very important for the data plane to provide this level of agility. As customers' operational or financial SLAs change, Adara's control plane elements (such as SLA Manager or Orchestration Engine) interact with the data plane elements to make the changes in the switched or routed paths. To minimize bandwidth costs, de-duplication-based compression functions are also used on demand.

Adara SLA Manager provides an interface for administrators to specify the true cost of an infrastructure resource at a granular level. For instance, it lets the administrator specify the cost per bit on a physical interface based on an ISP's SLA (time of day, bandwidth cap, and bursts allowed) and the cost per CPU based on the cloud service provider's SLA. Using the cost settings and monitored infrastructure parameters, Adara SLA manager renders the OPEX Dashboard for the business users to visualize how and where their money is spent and allow them to fine tune it.

Adara provides an orchestration GUI for cloud customers to input their expected infrastructure requirements: predicted number of users, expected response time, priorities of their hosted services, and the daily and/or monthly budget. Adara OE starts with an optimal configuration for the specified requirements. It fine-tunes the infrastructure setup automatically to provide best performance without exceeding the specified budget. OE continually learns and optimizes the configuration based on manual and automated training.

Adara SDI Visualizer provides a topological rendering of the hosted services, virtual machines, and underlying network infrastructure. This dynamic GUI enables the cloud administrator to monitor and reconfigure service and VM policies.

These are only few examples of the building blocks that constitute a True SDI. SDN vendors should come forward to provide much more innovative and practical tools for customers instead of fighting among themselves in standards wars. Focusing on providing interoperable solutions is critical to allowing early adopters to appreciate the value of SDI.

New Tech Forum provides a means to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all enquiries to newtechforum@infoworld.com.

This article, "Software-defined infrastructure: Cloud services do SDN one better," was originally published at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies