Sergey Nivens - Fotolia
A software-defined data center goes far beyond traditional server virtualization and can be challenging to set up for even the most seasoned virtualization administrator.
Software-defined data centers (SDDCs) abstract storage and networking with highly automated software. Although there are several benefits, there are also a number of potential pitfalls, such as SDDC security risks. Admins should address any product compatibility issues, close security gaps, ensure compliance and then enable authentication and automation instead of trying to move from a virtual environment to an SDDC in one leap.
Moving too far, too fast
One of the main issues admins come across when migrating from a virtual environment to an SDDC is size. Admins shouldn't look at an SDDC as an upgrade from one product to a suite of products. Rather, it should be taken as an extended process. If admins go too far, too fast, they run the risk of creating security issues. When admins virtualize their storage or networking, they have to focus on that specific task and not on the larger goal of being fully software-defined.
To do this, admins must securely abstract and pool their storage and network resources. Virtualizing resources and then moving them into the SDDC is a complex process that requires proper design, planning and execution.
Product and security issues
Once admins have set up the foundational pieces, they can configure the systems to work together. This is the point when admins might come up against a few issues. The problem with migrating to an SDDC is the possibility for security risks. When bringing different products together, it's the security aspect -- specifically, the lack of a directory service -- that might delay the migration.
Microsoft has a distinct advantage with Active Directory (AD) because admins can use it as a single source for authentication. VMware can use AD through Single Sign-On, but that can be hit or miss depending on the admin's experience with SSO.
Most VMware products use signed certificates for authentication in place of AD. When certificates work, they're easy to use. But in the event that the signed certificates don't work or admins encounter problems, such as domain name system issues, AD is the next best option.
This doesn't mean AD is the perfect answer to signed certificate problems; it requires a large knowledge base for one thing. But certificates can be confusing and frustrating when admins are short for time. Figuring out the source of issues typically requires some digging. That being said, admins should avoid the temptation to bypass certificate security in favor of getting something to work and leaving the security for after the fact.
This happens all too often when admins are trying to get something complex to work. If it's a permission issue, admins can reduce security or remove it to see if that enables systems to operate successfully. But admins must address security reductions or removals once everything is working. This is why the integration phase of foundational elements is so critical to the overall health and security of an SDDC.
Once admins get everything up and running, the next challenge is automation. The automation must work properly, but the policy and procedures that go along with automation can also cause issues. The security and compliance features that come with an SDDC enable the organization to move on a dime, but the question is whether or not admins are ready to update their security policies and procedures.
Having an agile data center won't do an admin a lot of good if the environment is still stuck with old security policies and procedures. This means changing how the organization and IT department do things. The challenge is that although the SDDC is secure, it might not be familiar to admins. That alone might be enough to dissuade them from migrating to an SDDC, but it's a new way of looking at how they control their environments and how they deploy and secure their applications.