I’m going to start this blog with a caveat:
I’ll start by saying that as a long time data center guy, I still struggle with calling the infrastructure “in a data center” a “data center”, software defined or otherwise. So, getting passed arguing about the term SDDC, the focus of my blog is on trying to provide an outline of what I see as the some of the needs and opportunities associated with SDDC.
SDDC – What’s new?
Historically the infrastructure has always been defined by the technology, not by a larger service. In other words we had “server guys” and “SAN gals”, but not an “Infrastructure Coordinator”. This differentiation by technology instead of a service has led to a stepped approach to design, change management and release to production. The assumption I’m making with SDDC is that many of the manual “operations” oriented activities could now theoretically be done by one person or group.
Common issues associated with traditional infrastructure management
The majority of enterprise infrastructure environments of yesterday and today rely on a coordination effort that borders on the impossible to ensure that when a new service is introduced it doesn’t wreak havoc on the rest of the infrastructure. It is not uncommon in larger shops to have up to nine (9) or more unique functions responsible for each new application infrastructure environment. The functions include but aren’t limited to the following:
- LAN (Local Area Network) team
- Data Center Capacity/Capability (physical building infrastructure of power, space & cooling)
- Server team
- Operating Systems team
- Storage team
- WAN (Wide Area Network) team
- Firewall team
- Change management
- Compliance or Regulatory
The mere fact that all of these teams needed to coordinate on each new activity meant that even if things went perfectly, it still virtually guaranteed a long process. The darker aspects included issues of poor team dynamics, weak communication, and or a lack of effective leadership. However, the darkest aspect was that there was likely no common vision for how all the infrastructure should fit together, which leads to untold numbers of long term ownership headaches.
The Opportunity for SDDC – It’s in the Org Design too
Treat your infrastructure and its processes as a system or stack (see Data Center Stack by DCP). Yes, in one simple sentence that should be the goal of a SDDC strategy.
The benefits of treating your infrastructure as a system are myriad, but my primary thought here is on functional performance. Besides the time wasted in the traditional infrastructure environment, it’s the fact that most organizations don’t coordinate as effectively as they should. When an IT infrastructure team doesn’t coordinate well, bad things happen to performance, availability, and the ability to effect repairs or improvements. A key potential benefit of the Data Center Stack is that it can improve and simplify communication between affected groups. It even helps the user understand who might be or would be affected by any expected change.
How does SDDC help you treat your infrastructure as a system?
As you would be using a single management platform to govern the use of your entire infrastructure and even many software assets, you would be forced to take on a more holistic approach to how your environment is developed. In theory SDDC should also allow you to control your infrastructure through a single user interface (UI). The benefit of having a single UI is that it “can” mitigate the risk that what the server guy did might disagree with what the SAN gal did etc. The complexity in this strategy lies within the potential tool(s) that you end up using, but the greater complexity is in the process to ensure that all the automation delivers as required the same way every time.
Complexity in defining what gets automated and how it’s monitored and maintained
The great thing about a manual process that isn’t the same every time is that it gives the operator a new chance to think about the potential risks/impacts/variables each time the process is run (I.e., change management for release to production). When you predefine your environments and release to production becomes an automated “DevOps” type model then there is considerably more onus on ensuring you’ve got it right. Because as we all know, “if you automate a bad process, you make bad stuff happen more quickly”. I’ve personally always found it easier to consider all the potential impacts or requirements of a change when it’s real, as opposed to thinking of the “what ifs” in a hypothetical situation.
What are the obvious opportunities of SDDC?
While there are many tactical opportunities associated with SDDC, I really see three higher level benefits. The first is the idea that you can move to generic hardware in each layer of the physical infrastructure and further attempt to commoditize it for improved pricing. However, to me the greater opportunities lie in the ability to do the equivalent of “one click” to push an application environment into production and potentially the more efficient use of each component of your infrastructure.
What does “one click” Release To Production (RTP) really mean?
Going back to my earlier point on the number of groups and individuals that need to be involved in the RTP process, incorporating all the process into an automated tool would provide some incredible benefits.
- Time to production
- Integrated and systems oriented approach to managing and changing your infrastructure
- The same process applied the same way every time
- Reduced risk (the more people and manual steps involved, the more likely an error will occur)
You can achieve these tremendous improvements by incorporating the function of storage setup, OS install, virtualization setup, network path requirements, and firewall security requirements into a single defined and repeatable process through automation.
There are still considerable gaps to fill before the true promise of SDDC is realized
IT teams need to actually embrace the opportunity and build processes that ensure SDDC’s effective and efficient utilization. There are several truisms that apply here; with great power comes great responsibility and a Ferrari doesn’t make you a better driver, just faster. As far as I’ve seen there is no tool available today that would allow you to manage a truly heterogeneous infrastructure environment (I.e., all hypervisors, all network switches, etc.). There will be trouble for a while with specific big box vendors attempting to minimize the SDDC opportunity in failed attempts to protect market share. However, probably the biggest gap is the “organizational gap”. Similar to some of the writings about Agile IT, a new type of organizational model will need to be defined for IT groups that are implementing SDDC. The silo’d approach most commonly seen today will be even less effective and in fact is unlikely to benefit at all from SDDC.
Think carefully about what you expect from an SDDC strategy. How will if fill gaps in performance, availability and utilization that you’re experiencing today.
There is tremendous opportunity for reducing delivery times, while dramatically improving consistency in the application of security, policy, and life-cycle management.
There isn’t a panacea today, but that shouldn’t stop you from getting your arms around the opportunity. In many cases the organization changes alone could take years, so better to get started now. By the time your org is ready, maybe the tools will be as well.