The next evolution of virtualization is the Software Defined Data Center or SDDC, and it is quickly becoming the next logical step in the continued evolution of cloud technology that will give you the ability to run legacy enterprise applications as well as the other cloud services. In my opinion, you could also define Software Defined Data Center as a converged datacenter. My friend and colleague, Edward Haletky, wrote a great article on SDDC and data protection which raised this question: How the heck do we recover SDDC?
Living in Florida, disaster recovery and data protection are topics of conversation that occur constantly, as they should, and the idea of recovery for SDDC got me thinking about how we would design and recover a Software Defined Data Center.
First let’s define what we would need to recover the datacenter. Software Defined Data Center is basically three different components:
- Network Virtualization
- Server Virtualization
- Storage virtualization
For recovery we would need these three components, also called layers, that would all interact with the separate logic layer, which performs all the translation requirements for the applications or vApps. At minimum, you will need the configuration(s) of the infrastructure network, virtual machine, or the applications (vApps) themselves. From an infrastructure level, recovery should not be too difficult, as in most cases high availability of the infrastructure was part of the planning and design; in these cases, recovery from a design point of view should be no problem when working within a private recovery option to similar SDDCs. Recovering or even migrating a specific application or vApp is where things get tricky. Edward Haletky pointed out that there are still lists of items that are missing with backups or vApps:
- Full Tenant Network links (not just what is in the vApp but leading to the vApp)
- Network Configuration (not just IP info, but DNS, and all bits necessary to recreate DNS, AD, etc as necessary)
- vCNS Edge Security Configuration (outside the vApp but crucial)
- vCNS App Security Configuration (inside the vApp but often overlooked and crucial)
- Endpoint Security Configuration (inside each VM of the vApp)
Edwards’s list is concentrating on a vApp within a VMware environment; I want to change the focus to recovery outside of a VMware environment and to a public cloud or other recovery option. Edward’s list is still very relevant in the things we need to consider and plan for, but for things like authentication and DNS, we are for the most part reliant on other team or services to present these functions and make them available, which can drastically slow the recovery process. Next on the list is the different security layers that vCNS took care of and controlled: edge, app, and endpoint. This entire security configuration will be lost on transition, which will bring a great security risk to the application or, in the worst case, complete application failure unless or until another team can be brought in to secure it.
In conclusion, as services get defined and built for the cloud, we need to take a hard look at how the applications or vApps are created, controlled, and defined in a Software Defined Data Center. With networking being virtualized, could security appliances be added as part of the vApp itself? Can we or should we build in or add some form of DNS and authentication to the vApp? How can our applications join the next evolution of virtualization?
I think Edward has it right that we have a ways to go to fully protect our applications and services, but I really think it starts with the way applications are built and configured, leaving part of that responsibility for protection to us to address and enhance moving forward. The next evolution of virtualization is to evolve our applications, methods of development, and deployment.