Software Defined shouldn’t be about Infrastructure

The term “software defined” has taken many forms in recent months from Software Defined Datacenter (SDDC), Software Defined Infrastructure (SDI) to even component vendors adopting the tagline to exalt their own agenda with Software Defined Networking (SDN) and Software Defined Storage (SDS). Yet ironically the majority of the vendors adopting the tagline are also dealing with infrastructure product lines that a “software defined” approach is aiming to make irrelevant.

The emergence of the cloud illuminated to the industry that the procurement, design and deployment of the infrastructure components of network, storage and compute were a hindrance to application delivery. The inability for infrastructure components to not be quickly and successfully coordinated together as well as be automatically responsive to application needs has led many to question why traditional approaches to infrastructure are still being considered. In an attempt to safeguard themselves from this realisation, it’s no surprise that the infrastructure vendors have adopted the software defined terminology and consequently marketed themselves as such even though at the end of the day they are still selling what is quintessentially hardware.


From the networking and storage perspective software defined is about abstracting legacy hardware from multiple vendors via virtualization so that the management and configuration is done completely by software. Instead of managing individual components based on their vendor, via APIs these now common pools of network and storage can be quickly and easily managed with automation and orchestration tools. Ironically though this has already existed for some time with examples being HDS’ storage virtualization arrays and Nicira’s pre-VMware takeover initiatives with OpenFlow, OpenvSwitch and OpenStack. Even the vAppliance concept that is taking on a “software defined” spin has been around for several years. Having the data planes and control of what was a legacy hardware appliance now go via a virtual version is nothing new when looked at in the context of VMware vShield Edge firewalls or NetApp’s ONTAP Edge VSA. Looking behind the marketing smokescreen of ease of management & simplification etc. in reality though most if not all of these technologies were invested in and created to do one thing only and that was to take market share away from their competing vendors. By having all your legacy storage arrays or network switches now abstracted and consequently managed and configured by software that is provided by only one of those vendors, the control and future procurement decisions lie firmly in their park. So why do we need to take the software defined approach seriously if at all and what should be our focus if not the infrastructure products that “software defined” seems inherently linked to marketing?


Software defined is incredibly important and vital to IT and the businesses they support because it should bring the focus back on to what matters the most, namely the applications and not the underlying infrastructure.  A true software defined approach to infrastructure that considers the application as its focal point ultimately leads to infrastructure being treated as code where the underlying hardware becomes irrelevant. By configuring all the infrastructure interdependencies as code with an understanding that it needs to support the application and the various environmental transitions it will go through leads to a completely different mindset and approach in terms of subsequent configuration and management of infrastructure. In this case a converged infrastructure approach whereby infrastructure is pre-integrated, pretested and pre-validated from inception as a product ready platform for applications is most suited. Understanding the capabilities of what software defined really is, beyond the hyperbole of infrastructure vendors leads to practices where concepts such as Continuous Delivery, Continuous Deployment and Continuous Integration can take place leading to a radical transformation in the way IT delivers value to the business.
The focus of a Software Defined strategy should be the applications not the underlying infrastructure 

So if and when you do face a sales pitch, a new product line or an infrastructure savvy consultant that espouses to you how great and wonderful “software defined” is, there are several things to note and question. Beyond the workings of the infrastructure components how much application awareness and intelligence is there? How will this enable a DevOps approach and a quicker, more reliable and repeatable code deployment that will meet the requirements of the changing demands of your business? How will this also mitigate risk and ensure that applications will not just have their infrastructure resources automated and met but also their consistency in code from development to QA to an eventual live environment?


It is these questions and challenges that a “software defined” approach addresses and solves enabling significant benefits to a business. Once application code changes become reliable, automated and consequently frequent based on an infrastructure that meets the changing demands of its applications, a business can quickly gain a competitive edge over its rivals. Being able to respond quickly to market trends such as ensuring your website can cater for a sudden upsurge of transactions from its mobile version, or countering a sudden commodity price change etc. are all key to gaining a competitive advantage and consequently require an application delivery process that responds to those needs. A “Software Defined” approach can help businesses reach that goal by automating the time consuming,  human error processes linked with IT, as long as they don’t lose focus that it’s about the applications and not just the infrastructure that supports it.