Software Defined Data Centers: Best practices

Truly Software Defined Data Centers (SDDCs) are still a work in progress for most organizations.

In theory, an SDDC allows compute, storage and networking to be automatically provisioned on demand and supports rapid-scaling, pay-as-you go services.

Built primarily on virtualized infrastructure, SDDCs abstract away the underlying complexity of hardware and software and the need for managing individual pieces of kit.

But most firms are a long way from building anything approaching an SDDC. So how can organizations transition from a traditional data center, with a muddle of server virtualization and legacy systems, to something approaching a true SDDC. Here's the analysts' advice.

Automate your infrastructure

Within an SDDC, the underlying pools of virtualized compute, storage and networking should automatically scale up and down to meet workloads, as well as delivering high availability, disaster recovery and business continuity, according to analyst house Forrester. Given that virtualization is a key component of an SDDC, Forrester recommends a fresh assessment of which workloads are suitable for running on a virtualized infrastructure.

The ins and outs of how a firm's virtualized infrastructure is set up should also be captured in a software-readable configuration file to enable its automatic deployment, says Forrester.

Similarly, the capabilities and configuration of each piece of physical infrastructure should be accessible via API, along with the ability to manage these pieces of kit. The analyst house recommends running legacy systems on infrastructure such as Cisco UCS M-Series or HPE Synergy to achieve this, which it says are the only systems it considers capable of creating an "abstracted physical server" necessary for use in an SDDC.

Infrastructure staff should be prepared to move from updating production instances directly to setting up software to handle the task instead. This level of automation is necessary for the rapid deployment demanded of an SDDC.

Abandon suppliers whose products don't support APIs

Replace hardware or software within your infrastructure that doesn't expose its functionality via API. Without a rich API, it becomes far more difficult to build that infrastructure into an SDDC, increasing complexity and cost, and limiting performance.

Break infrastructure into reusable components

In a similar vein, Forrester says firms should buy hardware and software that allows infrastructure to be broken into modular units of compute, storage and network, which can be reused as necessary. Unique configurations that can't be reused are to be avoided, recommends the analyst firm.

Build a management layer

Your business should be able to manage the deployment of resources within your SSDC, both programmatically and manually, says Forrester. It gives HPE's OneView and Cisco's UCS Manager, UCS Central, and UCS Director as examples of management suites that will be deployed in SDDCs in future. Microsoft's Windows Server 2016, combined with System Center 2016, is also singled out by Forrester as delivering "all major components for supporting an SDDC".

But plan for incompatibility

Gartner says that organisations should be prepared to put a lot of work into building a single portal for managing their SDDC, one that can abstract away the complexity of the diverse infrastructure underneath.

"To get that single view requires gluing together multiple different software management tools. That glueing is skill- and consultant-intensive, and at the end of it you may not get exactly what you want -- there may not be a seamless flow," said Rakesh Kumar, managing VP at Gartner.

"The biggest headache with software-defined is the management layer. There is this utopian model of having a seamless flow of information across different management platforms, but we're nowhere close to it at the moment," Kumar added.

Forrester warns against incompatibility between the software-defined network approaches taken by different major network vendors -- a view echoed by Gartner's Kumar: "I think we will have that [incompatibility] for a long time because the vendors tread a careful road between, on the one hand, providing enough technology to allow seamless integration, and on the other hand protecting their investment in their software management tools, to not make it truly portable."

Both analyst firms recommend asking vendors about the extent of third-party compatibility before making a commitment to using their technology.

Build a service catalogue

Build a service catalogue of pay-as-you-go services on top of your SDDC. This catalogue should allow internal staff to rapidly spin services up on demand, and should show them pricing and service levels. The framework for these catalogues is usually provided by vendors, although Forrester says that today's tools for this purpose are immature.

This service layer should be tied to an administrative layer that's capable of role-based deployment, as well as being able to automatically bill departments for resource use and manage that service's lifecycle, says Forrester. This should include the ability to audit changes and encrypt data at rest and in transit.

Expect the pieces of the SDDC to emerge slowly

Each vendor is gradually putting the pieces in place to build SDDCs, but don't expect comprehensive offerings from each vendor, warns Forrester. The analyst firm says that vendors will build products aimed at SDDC around their existing virtualization, cloud, or Composable Infrastructure Systems (CISs), over the course of several years. While virtualization specialists such as Microsoft and VMware will build out SDDC products from their existing hypervisors and management tools, infrastructure companies like HPE and Cisco will build them on the back of existing composable infrastructure offerings.

Carefully compare the major vendors

All of the major vendors -- Cisco, Dell/EMC, HPE, Microsoft, VMware and Lenovo -- are developing portfolios of products and services for use in the SDDC. Forrester recommends carefully comparing emerging CIS from all of the vendors as they are released -- paying particular attention to those you do business with -- before committing to an SDDC strategy.

Carefully choose your SDDC pilot

When choosing which workloads to use in your SDDC pilot, Forrester recommends choosing a part of the business whose workloads require rapid scaling, or may need replicating multiple times. Another good choice are workloads that are run intermittently, but which demand significant resources -- examples could include business intelligence, analytics or disaster recovery.

Who should build your SDDC?

When building an SDDC you could go with a single vendor such as HPE, Cisco or Dell/EMC, and ask them to take care of everything from the server, storage and networking hardware to the software layers on top.

However, no single vendor really has the wherewithal to provide the full stack of technologies needed to build an SDDC. Another major drawback, according to Gartner's Kumar, is that you're then locked into a single vendor to provide the entire hardware and software stack. "In most cases we would advise against this approach because you're sticking to one vendor, instead of best-in-breed technologies," he said.

A better approach is to find a vendor whose stack gets you closest to your goal, says Kumar.

"You may get 60 percent of it covered, but then there's the remaining 40 percent that you've got to piece together. Find a vendor that gives you the biggest coverage of your infrastructure, and the rest you've got to start glueing together yourself."

Building an SDDC in-house, says Kumar, offers the advantage of allowing an SDDC to be gradually pieced together.

He gives an example of how an organisation might proceed: "They would have started testing software-defined storage, for example, and already have some HP storage kit in there. The next upgrade is to a highly virtualized, software-managed layer on top of the HP storage technologies, and therefore software-defined storage. Next they might build a software defined server track."

Another option is to use a third-party integrator, such as Accenture, Wipro or CSC, where the firm gives the integrator the broad outline of the technologies and capabilities it wants and lets them build the data center. This is the more common approach, according to Kumar.

Consult across the business

The success of an SDDC and its ability to benefit the business depends on involving networking and developer teams, says Forrester. Networking is important because network architecture and performance are core to SDDC, as is the implementation of software-defined networking (SDN). For instance, one key consideration will be which protocol is best used for SDN -- OpenFlow, or some vendor-specific alternative. Meanwhile, developer input is valuable for considering how to extend the use of DevOps in an SDDC.