When you get to the heart of software-defined networking (SDN) and software-defined storage (SDS), it really just comes down to adding new layers of software to automate most of the things that it has traditionally taken network administrators and systems administrators a lot of manual labor to accomplish. These innovations take over most of the routine, mundane, and tedious tasks that consume time and effort, freeing IT professionals for more productive (and more interesting) tasks.

One of the advantages of adding that layer of software is that these services (storage and network) can expand and contract as necessary, according to what's going on in the environment at any given time. That's abstraction. Software for services means that there are no longer switches or storage appliances tied to the services, meaning the hardware costs can be cut considerably. Though widespread or mainstream use of SDN and SDS are not quite here yet, you can already find stripped-to-the-bone switches, simply using switch chips with a little electronics.

Using SDN & SDS Together

SDN is more highly developed than SDS, currently, and most network administrators already have SDN in place before adding SDS.

Most IT environments start with SDN and then add SDS, but some implement the two concurrently (or plan to). SDN is often seen as being an alternative to the usual proprietary switches. Many software companies are offering the code independently of the switch hardware, which is an indication that SDN has done what it's supposed to do -- provide abstraction between the service and the hardware.

Though SDN and SDS are two separate and distinct things, the network administrator needs to understand how they two work together and what potential issues might come up in an environment that employs both.

In the SDN environment, the network administrator or cloud administrator can establish policies to determine what their tenants are able to do in terms of networking. They can establish templates that allow tenants to fill in form fields to set up VLANs, thereby essentially fool proofing the environment. But in the realm of SDS, there just isn't that level of standardization. Many of the SDS products available are geared toward service virtualization inside the storage box. To many vendors, and especially their marketing departments, if the storage appliance happens to have some software in there, it's marketed as software-defined storage, even when by definition it clearly is not.

SDN is a Little Further Along the Evolutionary Ladder Than SDS

Just now you can begin finding SDS products that aren't just hype and really do feature true software-defined storage. These products can be abstracted from the hardware and be run within a container or VM (virtual machine). But network administrators and other IT pros in charge of purchasing hardware and equipment for their organizations need to be cognizant that not everything marked SDS is truly SDS. It isn't as strictly standardized and well-defined as SDN products tend to be.

The Complexities of SDN & SDS

The virtual approach to storage and networking products becomes even more critical when working with hyper-converged systems. The drives within the notes run independently of tight-bound services, which execute within an array of virtual servers. But don't give in to the temptation to oversimplify the situation -- if you've run several clusters together, you realize that storage can exhibit network and topology issues that tend to affect both the integrity of the data and the performance of the systems. If the network isn't well-designed and fully optimized, there can be significant problems.

Don't expect that you'll achieve a fully homogeneous network even with SDN. Just make it habit to get the compute resources as close as possible to the data storage. Location, location, location: it's the best way to reduce latency and lower that backbone traffic. Ideally, your SDN and SDS need to work as closely together as possible, too.

Examples of When SDN & SDS Together Can Get Complicated

At its core, software-defined anything is just another level of automation. The software takes over tasks that were once done by humans, freeing the network administrator, systems administrator, and other IT workers for more productive tasks.

Picture an application that utilizes numerous instances of a rendering tool to render a huge file. Being a high-priority task, it requires powerful GPU instances. The instances can be set up via orchestration, but that doesn't mean that it's intelligent enough to put all those instances in the same rack as the associated data.

Next needed are wide-lane LAN connections to manage the bandwidth. Ideally, the SDN will be aware enough to select VLAN structures with zippy quad-lane links between those GPU instances and the data store. After that, the data store needs to know what throughput is necessary, and needs some feedback on the speed and portion of the bandwidth allotted to the rendering. That's just one example of how SDN and SDS need to learn how to play nicely together in the virtual sandbox.

Another example is when integrating all-flash arrays in a network. Then the network administrator needs to deal with the physical attributes of the nodes. This is a situation that isn't addressed by the marketing departments of most of the software-defined tools and solutions available today.

Though these are rather complicated illustrations, these kinds of issues have to be addressed with automation or the performance of SDN and SDS together will be nothing short of nightmarish. To correctly deploy software-defined infrastructure (SDI), it's imperative that SDN and SDS are enabled to negotiate and optimize configuration. This is currently outside the capabilities of the products available on the market. Today's systems look at the hardware as totally homogeneous.

The final consideration for the network administrator looking to take on SDN plus SDS is security. More automation demands more security, and more short-lived VLANs mean more chances for attacks, and also making those attacks harder to detect.

The Future of SDN & SDS

Do all these challenges seem a bit much? Honestly, they aren't. It's just the next phase of the evolution of software-defined everything. Sometimes, when working with SDN on a daily basis, it's easy to forget that these technologies are still in their infancy, relatively speaking.

Just as we had to go through the awkward stages of flip phones to get to smartphones and the UNIVAC before we got today's sleek Big Iron, we've got to go through the awkward pubescent stage to get to the true capabilities of the SDI. One of those is the stage of the right hand not knowing what the left is up to, which is the current status of SDN and SDS. Just be prepared, as the network administrator, to be a little hands-on during this evolutionary process.

Want to learn more about SDN and today's greatest networking innovations? View some of our on-demand webinars now.