My response to Stephen Foskett’s tweet of a post about the Software-Defined Data Center (SDDC) Symposium led to an interesting conversation about the nature of the SDDC—what it is, what it is not, and why we should care. The software-defined data center is considered by some to be an instrument of vendor lock-in, vaporware, or in many ways just marketing hype. “SDDC” has many different definitions, but I do not believe it reflects any of those commonly used. Instead, I hold that it is a way of thinking, a way of looking at the new world of IT in which we live. This has sparked a quite an interesting Twitter conversation between many interested parties. I have included the beginnings of the Twitter discussion in the image to the right. It started with the view that the SDDC is a concept—an architecture—and not a product. Then, it blossomed from there. Why do I consider it a concept? Or an architecture?
SDDC is software that is used to define a data center, which implies that there are no longer walls around the data center except for those constructed by software. In general, VMware wants us to consider the SDDC to fall within its definition of the hybrid cloud: a local data center and a remote Infrastructure as a Service (IaaS) cloud. I see this as too limited a view of the concept of the SDDC. So, we should go back to the beginning:
What Is a Data Center?
What is a data center? In its simplest form, a data center is one or more places or locations that hold data needed by the individuals and customers of an organization. Organizations may have a data center that is no larger than a closet; is hosted within a service provider; or uses multiple locations around the state, country, or world, or even within a cloud.
What Is a Software-Defined Data Center?
VMware originated the definition of the software-defined data center as an adjunct to the hybrid cloud (a cloud that consists of a local data center and a component of IaaS). Specifically, SDDC is about the software automation required to make the hybrid cloud a unified data center with a single management control location. The goal is most likely to eventually control an SDDC via a single plane of glass, but we are many years from that. However, there is another definition of the software-defined data center that is even more intriguing.
Where Is Our Data?
If we look at how users employ cloud services (whether IaaS, PaaS, Storage Clouds, or even DaaS), we see a different view of the SDDC. We see pockets of user and organizational data in many different clouds for which there is almost no control over that data’s placement. There is almost no security, management, data protection, policy enforcement, etc., over that data. An organization’s data could end up in 5,000 or more different locations within the cloud, with service providers, and in their own miniscule data centers. An organization in this realm could even be an individual. With the advent of the Internet of Things (IoT) concept, our data can end up practically anywhere. That data then becomes part of an organization (depending on the license agreement they have written). In effect, since some data lives on the IoT device, an organization’s data can end up anywhere.
Does it matter where our data ends up? Actually, yes—purely from a jurisdictional perspective—in other words, with regard to current law about crossing jurisdictional boundaries, wherever they may reside. There are specific rules related to medical data that can be extreme.
If our organizational data is everywhere (a valid assumption, given smartphones and tablets), then how do we gain control of our data? Would not these individual pockets of data comprise many distinct data centers, using our simplistic definition?
SDDC, the Concept
SDDC is more than a concept—it is a mindset, a way of viewing all our disparate data centers and of using automation to unify those data centers, regardless of location. Since the location does not matter and is spread over various devices and services, SDDC is NOT about vendor lock-in. SDDC is applying automation to control policy surrounding your data, wherever it may be. This policy could be about data protection, security, operations, etc. There are tools available to help with SDDC, but not one that is an SDDC-only product. To build a proper SDDC, you need software to help manage it, automate it, and find the kernels of data among all the varied services.
To consciously design a software-defined data center, we must accept the fact that the data is everywhere. We have no boundaries, but we have pockets of data everywhere. Each of those pockets resides in a data center or device that may or may not be under our control. Those who design a SDDC look at first how we use cloud and physical resources, how to automate that usage and configuration, while providing first a view of where our data is, and then control over that data. Just like there are thousands of data center architectures, there are thousands of potential SDDC architectures, each meeting a specific need, but all sharing the same concept: pockets of data located in some things we control and some things we do not.
To fully understand the benefits of this new architecture, we must first change our mindset and alter our goals:
- Accept that our data is everywhere and that we have no chance of getting it all back in any one place
- Automate ways to find where our data is
- Automate policy around where our data now resides.
That is my basis to SDDC: automation of policy around many pockets of data to form a software boundary to my data—a software-defined data center. Our starting point will be the Hybrid Cloud whether that be IaaS, SaaS, or some combination.
Share this Article:
Latest posts by Edward Haletky (see all)
- Common Product Security Questions - November 23, 2016
- Sorry Support: Not Getting My Data - November 18, 2016
- Moving to the Future: Strategies for Handling Data Scale - November 14, 2016