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?
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.
Ed-
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’. ;^)
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 arena in short – pit full of dogs going at each others throats, where there’s still more vertical development then horizontal (better than old days, but still).
so i just don’t this happening any time soon.
cheers.
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 that creates a SDDC, there will be a multitude of products, but without that mindset using those products will be difficult at best and most likely you may have a ‘part’ of a SDDC not one in reality.
We have to start with architecture, but those creating the architecture need to ignore product and have the SDDC mindset firmly in mind. We architect around business goals not products. If we architect around product then we lock ourselves into a single mold that can never be expanded without a large amount of work. An SDDC architecture should be a growing architecture that takes advantage of new ideas and concepts to deal with our data localities and are able to use whatever products hit the market as needed.
We are not at A, B, D, D, or E. we are still at Architecture which requires the proper mindset to create an SDDC. And BTW, it is possible to do all I stated today. It is not easy, it is not canned, and would marry several vendor’s products together. But the technology exists. This is more a mindset about how to go about putting everything together. To me SDDC is a mindset not any one product and it still starts with a valid Architecture. Which requires an architect to have the proper mindset.
Best regards,
Edward L. Haletky
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 https://www.virtualizationpractice.com/picking-secure-hybrid-cloud-security-solution-23556/ 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 aid that scripting (once more part of the architecture and design). With a central concept of policy for data protection, A&A, security, business rules, etc. we can bind together more than one data location regardless of where it is into one software defined data center.
However, this takes a while to complete depending on size of the organization, the datacenters and cloud services in use.
This is why this is about mindset, if you do not realize that there are connections here that can be used, then your architectures do not reflect that mindset and any design based on the architecture will not be complete. Which means that you may still have disparate data centers and cloud systems instead of a software defined data center.
This is not marketecture, this is an architecture. You really have to ignore vendors to come up with your own architecture. If you do not ignore the vendors initially all you are doing is creating silos inside any architecture. The goal of SDDC is to put it all together. Step above the vendors for your architecture, include them in your designs as needed.
To be frank, I am still working on my SDDC but with a solid architecture it becomes easier. The tools exist, the technology exists, you just need to quilt it together today. I have yet to see the ONE product that does this for me automatically but I have seen frameworks that will help me do this (Puppet, Chef, Powershell, Perl, etc.).
Best regards,
Edward L. Haletky