When planning for a software-defined data center, there's a lot for organizations to consider, ranging from integration...
to automation. Each step in deployment requires an in-depth understanding of what the business needs, and what financial barriers need to be overcome.
While some organizations may want to achieve a software-defined data center (SDDC) with a single vendor, that may not be possible. Examine the SDDC architectures of other organizations -- particularly within large cloud services providers -- to help determine the extent of your needs, and what types of infrastructure will be most beneficial.
Software considerations for SDDC planning
A key feature of an SDDC is the ability to control every aspect through software. This enables much greater agility than physical infrastructure changes or manual control processes. SDDC allows workloads to operate independently from the underlying physical infrastructure. It allows segregation of the infrastructure management from the workload management. Both layers are controlled programmatically, without an army of people at keyboards directing actions. A workload policy, for example, may increase the number of web servers as the load on the existing web servers exceeds a threshold. An infrastructure policy might deploy a security patch to affected hypervisors. These policies, and a collection of automation tools, drive the state of the SDDC.
It is tempting to think that an entire SDDC -- at least from the software side -- should come from a single vendor. The reality is that no vendor provides all of the required parts, and definitely not with a unified product. For example, VMware's vRealize Automation (vRA) suite covers many of the infrastructure components, but does not have the ability to be a continuous integration/continuous deployment (CI/CD) tool. If you ask your developers, a CI/CD system is a crucial part of an SDDC architecture. VRA is also not designed to update the firmware on your physical servers or the microcode on the solid-state drives in your storage array. This is why the SDDC is made up of components from different vendors. It's not a bad thing, but it does complicate SDDC planning.
Integration key during SDDC planning
By looking at the scale of major cloud providers, you will see that building an all-encompassing SDDC is achievable. These cloud providers do not buy their infrastructure from a single provider; they buy parts from multiple vendors and assemble together the collection that suits their needs. Most large cloud providers also have teams of developers that integrate these parts. Think of all of the parts that require integration so that you can have a VM instance deployed in minutes and connected to the right internal and external networks -- all from a self-service portal, a set of script commands or a few Application Programming Interface (API) calls. Then think about the financial scale that these cloud providers need to be able to build this level of SDDC. A large SDDC architecture is expensive to build and the payoff may only happen on a massive scale.
For an enterprise, this scale of integration may not be necessary. First off, a lot of products will have automation built in and simply require integration. Most enterprise companies have some standardization of infrastructure, so they don't need to integrate as many disparate components. Next, the size of your SDDC is unlikely to be the same as in a public cloud provider. An enterprise organization can specify a limited set of integrations that suit its business requirements. However, a cloud provider needs to support all integration scenarios that its customers need.
During SDDC planning, expect to integrate a number of components, such as an end-user portal, server hardware, software-defined networking and software-defined storage. This is where APIs become important, because they will allow one SDDC component to integrate with another. Representational state transfer APIs are very popular if additional scripting is required for bindings to your usual scripting language. Look for products that have APIs, bindings, and ideally, integration templates for your other products.
One of the key considerations for SDDC planning is to define the scope of your vision. Usually SDDCs are most valuable to rapidly changing environments like development and test. You can reduce risk from the initial deployment by not including production. Once Dev/Test is proven and lessons are learned, then production can be rolled in. If your organization isn't developing software using agile and DevOps methodologies, then there may be no value in a CI/CD system. It may be sufficient to deploy a self-service, nonproduction VM platform.
Are blade servers or rack servers the way to go in an SDDC?
Five key considerations for an SDDC
Build more interest in an SDDC