Software Defined Networking
SDN enables big data analytics by exposing APIs that can be used to automate the creation and destruction of job processing environments. Because big data environments often contain sensitive information, SDN can provide micro-segmentation for enhanced security as well as automated, policy-based access to the data.

Disaster Recovery
While disaster recovery (DR) is last on the list of low-hanging fruit use cases, it is certainly not the least. DR is important to environments of all sizes.

Software Defined Compute
SDC can allow the flexible creation of certain components of DR environments only in the event of an actual disaster. This saves on ongoing costs.

Software Defined Storage
SDS can be the backbone to a successful DR implementation. Leveraging the APIs provided by the SDS platform, IT organizations can create a robust while granular backup and replication strategy. SDS can enable an IT organization to do data protection based on policy.

This removes the human element of remembering to add the server to a backup job, for example. Rather, policy dictates that all virtual machines in a specific container are replicated to the DR sites with a specific recovery point objective (RPO). SDS can also dramatically simplify the failover automation process. The APIs provided by the SDS platform can be used by a DR orchestration tool to fully control the failover.

Software Defined Networking
Finally, SDN can be used to programmatically create DR network infrastructure on-the-fly. It can also be used in tandem with processes like revision control to keep the DR site perfectly in sync with the production site. In the event of a DR scenario, SDN will provide the tools to allow a seamless failover from an infrastructure perspective that is all controlled by the DR orchestration tool.

Virtual Desktop Infrastructure
Depending on where you are in the process of creating your organization’s unique version of the software defined data center, virtual desktop infrastructure (VDI) can be a big win.

Software Defined Compute
If your organization is not already standardized on virtual desktops, now might be a good time to explore desktop virtualization powered by SDC. This is the process of migrating, or replacing, physical desktops with virtual desktops in an elastic VDI farm.

From an administrator’s standpoint, this simplifies their job and increases security due to the fact that the company data never leaves the data center, even if the endpoint devices are on the other side of the world. From an end-user’s standpoint, VDI allows increased mobility because they can access resources from a variety of endpoint devices.

VDI also breaks the tiring cycle of desktop refreshes by removing physical desktop computers and replacing them with virtual ones and small, cheap endpoints used to connect.

Software Defined Storage
If desktop virtualization is already deployed in your organization, the odds are that there are user-experience and cost challenges that could be easily addressed by implementing SDS. Employee desktops are extremely visible and if SDS can solve a serious pain points such as boot and login times, application slowness, or cutting the infrastructure cost by 50% for an existing VDI deployment, the data center transformation team can quickly become heroes.

Leveraging SDS to create a hyperconverged infrastructure (HCI) for desktop virtualization could potentially eliminate storage performance bottlenecks. Monolithic arrays have been notorious for being crippled by VDI workloads. While plenty of monolithic arrays exist today that can handle the workload, perhaps a scalable, highly performing hyperconverged infrastructure powered by software defined storage can enable more flexibility in the environment.

Software Defined Networking
Finally, depending on scope, perhaps a transition to SDN can be layered on to enable desktops to be created and destroyed in a self-service fashion based on the needs of a business unit. The agility that SDN enables would allow for the secure delivery of desktop services to different business units without sacrificing speed of provisioning new services.

How to Adopt SDDC
The low-hanging-fruit environments make it sound easy, but knowing how to get started is the hardest part of the entire data center transformation process. The modern data center can be extremely complicated in its quest for simplicity and hands-off automation.

When it comes to the SDDC, the first step in the transformation is to gain knowledge about specific products and technologies that will enable the transition. We’ll explore a few ideas for specific technologies that you could dig into implementing SDC, SDS, and SDN.

Then, armed with some knowledge and excitement, the next step is to begin testing a very simple abstraction: a “Hello, World!” sort of experiment with software defined solutions. This will cement a better understanding of how the tools that enable the SDDC to work.

Software Defined Compute
Practically speaking, how do you go about adopting SDC technologies and practices into your business? The answer to that depends largely on which use case (VDI, Test/Dev, etc.) will be the target of the SDC initiative.

There are several questions you’ll need to answer as shown in 6-2.

Cloud or On-Premises?
Depending on the workload target, the first decision to be made is whether on-premises resources or public cloud resources will be used. If public cloud is the chosen direction, SDC is likely already provided. The task, then, is simply to integrate this resource with the management systems and workflows of the rest of the SDDC. If the compute platform is to be built on-premises, there’s many more decisions to make and more implementation work to do.

Virtual Machines or Containers?
The basis of SDC will be some sort of virtualization platform, so it’s best to start with choosing that. Immediately, there’s a fork in the road: whether to implement machine-based virtualization (virtual machines) or operating system-based virtualization (containers). Because other intersections in the data center rely so heavily on the virtualization method, the choice here will impact the direction of other solutions, especially SDS and SDN. Take great care to explore all the differences when choosing the abstraction type.

At this point, the choice comes down to one of three basic options: virtual machines, containers, or both. For many organizations, the choice for now will be “both.”

Hypervisor/OS of Choice?
Assuming your organization has chosen to move forward with both virtual machine and container-based virtualization, the first step of real action is to begin building hypervisors and/or host machines
to perform the virtualization. For virtual machines, choosing and installing a hypervisor will be the first step. For containers, choosing and installing the Linux distribution for the host operating system will be the step there. Either way, a system now exists that has the following software defined features: it abstracts the compute workload from the physical resource running it, it provides a programmatic interface to allow for automation and orchestration, and the compute workloads can be controlled by policy. And just like that, the compute is software defined.

Cloud Management Platform?
For bonus points, deploy a cloud computing suite of tools to leverage the virtualization platform as a resource for self-service provisioning, multi-tenancy, metering and chargeback, and more robust automation. While a hypervisor cluster with a management platform technically qualifies as software defined, the real acceleration from a business standpoint comes when the cloud computing tools are utilized on top of the hypervisor or OS virtualization platform.

Software Defined Storage
Adopting SDS can be either dead simple or quite complex depending on the end goal and the tools or products used to get there. SDS also has a large number of variables that can make planning difficult. But it needn’t be so complicated if you choose the right set of tools.

One of the primary objectives of SDS vendors is to make the process of implementing the technology easier and smoother. The ideal outcome would be to get the business outcomes SDS can facilitate without the technical complexity, and some vendors have succeeded in providing this.

What’s the Objective?
A successful foray into SDS starts with determining the objective. Stephen Covey writes in his best-seller The 7 Habits of Highly Effective People, “Begin with the end in mind.” Nowhere is this more fitting than in storage design. Is the goal for the organizations storage system(s) to be more scalable? To be able to automate storage provisioning? To allow policy-based workload placement and data protection? Or to allow for non-disruptive upgrades moving forward?

Type of Provisioning and Storage?
Once the goal is identified (and of course, it can be multiple goals) the next step is to choose a storage model. Today, the number of options for storage deployment models seems to grow by the day. At a high level, however, there are two primary paradigms for provisioning storage today: monolithic arrays or appliances, and hyperconverged.

SDS will allow one or both of these deployment models to be used, but knowing which model fits the application will help with making SDS decisions moving forward. Also at this stage, the type or storage medium (or the ratio in the case of mixed medium) needs to be determined. Will the performance and capacity requirements necessitate flash storage? Disk? DRAM?

What Can Be Done with What’s Available?
SDS capabilities are commonly overlooked or not utilized due to a lack of understanding. Therefore, one of the steps an organization should take when implementing an SDS strategy is to look at what can be done with what is already available. For example, the organization’s hypervisor of choice might already have the ability to place virtual machines on certain storage based on policy.

This is a facet of an overall SDS strategy that can be implemented immediately with technology that is already owned by the business. Showing this value immediately and without a capital purchase can help increase support for later phases of the transformation. However, you should consider whether using SDS mechanisms that are vendor-specific could be a decision that paints oneself into a corner.

Deploying SDS solutions that are tied to the hypervisor could increase the risk of lock-in.

Software Defined Networking
Adopting SDN might be the biggest challenge of the three. But it can also come with some incredible rewards.

What Is the Business Objective?
The first step in adopting SDN, as with the others, is to identify the business objective. For example, “We want to provide enhanced security of multi-tenant environments,” or, “We want to enable complete application elasticity.” Once a valid business objective is identified, it becomes much clearer which of the candidates for SDN platforms is a good fit.

Hardware or Software?
There’s a dichotomy in SDN that also exists in SDS and SDC, but is not as prevalent. That is that some solutions, while enabling the software defined vision, actually require certain pieces of hardware,
while other solutions are completely software. Neither model is right nor wrong in a universal sense; the challenge is to choose the one that is right for a given situation.

What Test Cases to Try?
After settling on the platform and deploying the SDN infrastructure, the organization can begin to implement different test cases. One of the easier options for just starting out is to begin to segment east-west traffic via policy. While this would be a somewhat involved process with physical infrastructure, it’s really pretty straightforward when the access rules are defined in a policy and the SDN controller handles the programming of the virtual switches.

As your organization becomes more comfortable with the SDN paradigm, perhaps they’ll feel prepared to take on a task like the automated provisioning of new network segments. In multi-tenant environments or large organizations that perform frequent acquisitions, being able to leverage SDN to provision these resources in an automated fashion can save the business boatloads of operating capital in the long run.

When adopting an SDDC approach to transforming your data center, you can’t expect to change everything at once. The SDDC transformation is often a gradual process, starting with compute, then moving to storage, and finally networking and security. However, the most common process isn’t the best for every organization, and there may well be organizations that should transform in the exact opposite order. No matter what, getting measurable improvements to business processes, in terms of reliability and speed, is the end goal. Always aim for that, and the project will likely be successful.