This week the news has been dominated by VMware and VMworld 2013. The major theme has been “Software Defined”, in particular moving to a Software Defined Data Centre (SDDC). The concept of SDDC is a noble one and certainly a target we should be looking to strive towards. However in reality I believe it’s a while away. There are a number of reasons:
Today’s enterprise data centres have a lot of money invested in technology. At the simplest level this means servers, storage and networking equipment. Much of this may not be fully amortised or written down and so needs to be kept deployed for some time. There’s a normal cycle of technology refresh that occurs on 3, 4 or 5 year periods and in some cases more, where transformation is too expensive or impractical due to application re-writes or unsupported new hardware/software. Remember hardware isn’t just the obvious server and storage. Large enterprises have invested in things like specific fibre technology, which is one of the reasons the adoption of FCoE hasn’t been particularly successful. Although companies like Cloud Velocity can help aid the migration into the cloud without application changes, there’s a question still to be answered about the cost benefit of this. Is it even worth spending the time moving existing applications onto cloud-based infrastructure (either on or off premises).
Many applications today simply aren’t suited to SDDC deployments and were architected in a client-server world, or dare we even mention it, for the mainframe. Larger organisations have dozens of legacy applications that have been retained for a variety of reasons. I’ve worked in places where the original source code was lost and programs and their operating systems were kept running because no-one knew how to re-write the application. There are many other technical intricacies to think of too, like server co-location – keeping the application and database layers close together for low latency; networking implications; the BC/DR process (maintaining application consistency during partial or complete infrastructure failures) and many more.
The technical aspect must also reflect the attitude of vendors. Some vendors have been slow to provide suitable licensing or support of their platforms and applications on virtual infrastructure. Even VMware licensing has been changed over time, creating some FUD around ongoing costs.
If there’s one thing I’ve learned over the last quarter of a century in IT, it’s the inertia of change. When new technology comes along, 20% will never get it, 20% will get it immediately (early adopters) with the remaining 60% eventually converting over time. People fear change because not everyone is good at continuous learning or wants to be in a constantly evolving learning process. The result is that the adoption of new hardware technology, new software, new development techniques requires training, recruitment, changes to process and most of all, buy in from senior management.
Buy-in brings us to the last point; risk. “If it ain’t broke, don’t fix it” is a mantra that has worked well for many years. Any system change introduces risk, which means careful risk measurement then mitigation. Many IT departments have difficulty measuring risk and so avoid change as a result. For example, how to I measure the risk of deploying tier 1 applications on a virtual infrastructure like vSphere. Ask that question say, 8 years ago and the answer would have been to avoid virtualisation altogether. Ask that question today, and it’s a no-brainer. All applications can go on vSphere because the ecosystem (provisioning, backup, management, reporting) is there to support every type of application, plus there’s years of accumulated knowledge in the people and the community.
The Architect’s View
So where does that leave us? The SDDC is a transformation of today’s IT landscape. Applications that are simple to understand and encapsulate will be the ones moving first, in exactly the same way that those applications are suitable for cloud deployments. IT departments will evolve their skills to understand risk, change processes and as projects refresh their technology and as budget allows, we will see a gradual migration into SDDC. CxO’s should have a strategy to move to SDDC and address all the issues with making that change, whilst being able to quantify the benefits the change will bring. Get the financial message right, and everything else will follow.
Comments are always welcome; please indicate if you work for a vendor as it’s only fair. If you have any related links of interest, please feel free to add them as a comment for consideration.
Subscribe to the newsletter! – simply follow this link and enter your basic details (email addresses not shared with any other site).
Copyright (c) 2013 – Brookend Ltd, first published on http://architecting.it, do not reproduce without permission.