Top 3 Challenges of Monitoring Software Defined Everything

Software Defined Everything, or SDx as it’s known – it’s the virtualization of compute, network and storage resources combined with automation and orchestration systems. And, it’s helping today’s enterprises and communication service providers significantly accelerate the time to deliver new applications and services.

Need a new VM? Click a button. Want more storage? Click again. Looking to set up the infrastructure for a video stream between New York and London? You get the picture. The days of racking and stacking new devices and entering in sets of CLI commands by hand are coming to an end.

Now is the time to start thinking about how SDx will impact day-to-day performance monitoring of your infrastructure – no matter which technologies or vendors are in your SDx stack of choice, or whether those resources are on premise or in public clouds.

We see three major challenges to effectively monitoring enterprise and communication service provider SDx infrastructures:

  • Dynamic, Real-Time Change
  • Rapid, On-Demand Elastic Growth
  • Integration of Service Context

Each of these challenges has the potential to create performance visibility gaps if not planned for properly.

Dynamic, Real-Time Change

Currently, enterprise and communication service provider infrastructures are relatively static. Configurations of new devices and services are often done by hand through command-line interfaces. As new devices are added to the infrastructure, another manual process often adds knowledge of these new devices to management systems. Performance monitoring solutions typically run nightly discovery operations to see what’s changed in the environment, and then automatically adjust to monitor the updated network.

The promise of SDx, however, with its ability to automate the provisioning of new converged infrastructures in minutes and impact multiple devices at the same time, changes everything. With SDx, new compute, network and storage devices and features are immediately available for use. If your performance monitoring solution is only running daily checks on what’s new in your environment, these dynamic, real-time changes of configuration can create significant performance visibility gaps.

What’s needed is a performance monitoring solution designed with open APIs. It should integrate directly with SDx systems, looking for new devices or changes, and then immediately modify how the infrastructure is monitored to ensure performance visibility. Think about how virtualized compute automation systems work today as opposed to 5-10 years ago. It used to be that adding new servers to a network would take days or weeks. Teams would order a new physical server, wait for it to ship, unpack it, rack it, power it, etc. Now, with virtualized compute and automation systems, a new virtual server can be initiated through a web-based portal and be up and running in minutes. One of today’s common deployment models is to leverage the open APIs of SevOne to integrate directly with compute automation systems so customers are immediately aware of any changes to a compute service.

As new virtual servers are provisioned, IBM SevOne Network Performance Management (NPM) listens to the automation system and automatically adds the virtual servers. If the servers are modified or moved, SevOne NPM adjusts. If the servers are de-commissioned, SevOne NPM removes them from active polling.

Utilizing these same APIs, SevOne NPM can be integrated with virtualized network and storage systems to eliminate performance visibility gaps caused by the rapid change of SDx-based infrastructures.

Rapid, On-Demand Growth

As creating, modifying and tearing down compute, network and storage infrastructures via SDx systems becomes a trusted process, performance monitoring solutions will need to adjust to meet increased demand. However meeting this demand isn’t as simple as adding the new compute, network and storage devices into a performance monitoring solution. These solutions must be able to add capacity to accommodate the rapid growth of the infrastructure. If they can’t quickly add additional capacity on demand, they can quickly become over-subscribed, creating performance visibility gaps.

To address this challenge, SevOne NPM can be deployed in both physical and virtual appliances. When extra performance management capacity is needed, additional virtual appliances can be added to a SevOne NPM Cluster, enabling performance monitoring to flex with the demands of an SDx system and still provide answers in seconds.

Integration of Service Context

One of the significant trends taking place in the SDx market today is service context. What does this mean, and why is it important?

Let’s suppose a service provider has an SDx-enabled offering with a service portal available for its customers. Customer “A” comes to the portal and orders “HD Video Service: New York to London.” The SDx system provisions the necessary set of compute, network and storage features required to turn up this service. With the integration described earlier in dealing with real-time change and rapid growth, performance monitoring solutions would know about the new devices, but they wouldn’t necessarily know how the devices are related to one another, or that the new devices are related to Customer A and the HD Video Service from New York to London. That’s where service context comes in.

When an SDx system and performance monitoring solution can integrate with service context, an entirely new set of use cases can be supported. For example, instead of a performance monitoring solution listening only for new devices to be added into inventory, it can also listen in context of a particular customer or tenant of the network. As a result, users can ask not only about the health and performance of individual devices or links on the network, but also, “How is Customer A – HD Video Service: New York to London – performing?”

This type of shared context can also be extended to service topology, meaning SDx and performance monitoring solutions share the knowledge of physical and logical connectivity of the devices – both physical and virtual – that make up a service, both in real-time and for historical data.

Envision taking this even further. Imagine an SDx system querying a performance monitoring solution about the health of a particular customer’s service. Based on the performance data, the SDx system could take corrective action to ensure the service level agreement with the customer. This type of continual optimization would leverage shared service context to create a feedback loop between SDx and performance monitoring solutions.

This ability to share service context and service topology is evolving. Similar to how SDx systems are being implemented by different vendors in different ways, the sharing of service context and service topologies varies, but it holds great promise for how SDx-enabled infrastructure can evolve to be monitored and managed more effectively.


It’s still early in this journey to software defined everything. As SDx infrastructures continue to move to production, it’s important to look at how dynamic real-time change, rapid on-demand growth and integration of service context will play a key role in enabling a successful deployment and avoiding performance visibility gaps in your infrastructure.