Is SDDC a Product or a Mindset?

Bask to Basics - Secure Hybrid Cloud

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 Twitter Time Line
Click to expand

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.

Posted in IT as a Service, SDDC & Hybrid CloudTagged , , , , ,

Leave a Reply

7 Comments on "Is SDDC a Product or a Mindset?"

newest oldest most voted

[…] Is SDDC a Product or a Mindset? […]



That was an exceedingly thoughtful writeup. Thanks for sharing it.

Makes me wonder if we ought to flip things a bit from ‘data center’ to ‘Centers of Data’. ;^)


[…] have not yet been fully finalised, but these are icing on the cake. I agree with Edward that the SDDC is more a mindset than a product. There are many roads to Damascus—many competing technologies to win hearts and minds—but the […]

your idea of SDDC is fairly wide in it’s scope – essentially you’re talking about the mobility if Data, correct? the notion that we need an architecture to normalize, automate and police it is well… ambitious to say the least. kinda waaay ahead of what’s actually available at DC arena nowadays. I think you’re talking about C,D,E when we don’t even have A & B. right know only hyperscales have the commitment and funds to go there. your regular joe type network engineer is still waiting(sometimes with great deal of anxiety) for vendor solutions to hit the market. and vendor… Read more »
Hello, It is pretty wide in scope. This is what I mean that SDDC is more a mindset than anything else. If you have administrators waiting for product to create an SDDC, then they are missing the point. The point is to come up with a way of looking at your data center(s)/data location without needing to worry about products. If we look at everything with this mindset then our SDDC will happen: our architectures will reflect the mindset, the product choices will reflect that mindset, and eventually our physical environment will reflect that mindset. There is no one product… Read more »

hmmm, can you elaborate on how it’s being done today part?
cause so far it sounds a lot like those fluffy vendor marketuctures i’ve been involved in the past.

Hello, First we need to start with an Architecture. I use as my architecture. The design component is picking the tools that you will use as I have done in a general way by telling which products fit where. The whole series of posts is about this concept really. Now that there exists an architecture, an understanding of where our data lives, how it is accessed, etc. We not need to build automation around the environment to deploy workloads, data, etc for use by our users. Personally, I do this by scripting. Yes, I have built my workloads to… Read more »