There is a lot of talk in the technology industry of “software defining”, the idea that elements of our technology stack, traditionally based on a hardware appliance can be abstracted from it and made available as a software-only appliance that can be installed on any hardware. But why? Wouldn’t you rather your key assets were installed on custom-built hardware with performance optimisations, resilience and convenient support models? Well, you’d think, wouldn’t you?
Well, perhaps you don’t! If we think about what we need in our modern technology stack one thing stands out, the demand for flexibility, think about virtualisation, initially adopted for efficiency, but for most of us the reality of virtualising our key workloads is the flexibility it gives them, the ability to move them, maintain their availability, provide a range of implementation options because they are not bound by a particular hardware device.
The demands for flexibility will continue to grow as we move beyond our data centre, needing to deploy in multiple locations, branch offices, co-location sites or Public Cloud and this becomes very difficult if our key infrastructure components are bound by hardware. Modern infrastructure can’t afford to be limited by hardware restrictions and this is true of applications, infrastructure and increasingly, our storage.
Software Defined Storage
What brought this into focus for me was a conversation with the software-defined storage team at NetApp, many people know NetApp, the traditional storage vendor, engineered physical boxes delivering storage capacity, but NetApp has changed hugely in the last few years, with innovations in NAND flash, Cloud, and AI amongst other areas. One such area is the abstraction of their storage operating system ONTAP from any hardware dependency and delivering it as a software-only solution known as ONTAP Select.
But why? Why would you want software-defined storage (SDS)? Is our data not better served from a robust hardware platform? Not necessarily, in a modern infrastructure where flexibility is key, the idea of “agility” is behind many of our technology platform design decisions and storage is no different, in fact, flexibility of deployment for storage is becoming increasingly essential for organisations designing their modern data strategies.
Why this increased demand for SDS? Where would we use it instead of a hardware appliance? How about storage for a short-term discreet project where we don’t want the cost of a hardware array? Or we need to deploy storage into a remote site with limited space for hardware but with ample virtual resources? Or we want an automated and repeatable infrastructure we can quickly deploy in any location. These are just a few examples of scenarios where reliance on physical storage hardware is a hindrance and SDS fits extremely well.
But is there a compromise? What do we lose if we take our storage as software rather than an engineered system?
We do of course lose some things, a fully supported hardware appliance can simplify support queries, if your disk array has an issue, call the vendor they own the whole platform and can fix any of it, with an SDS deployment they only own the software, other issues could sit below this elsewhere in the infrastructure stack for example hypervisor, hardware or local disks.
Do we lose anything in terms of enterprise-class capabilities in an SDS deployment? If we take ONTAP Select as an example, then there is almost complete feature parity with their engineered systems. I can build SDS HA nodes, stretch a cluster geographically, present SAN and NAS protocols, benefit from data protection, storage efficiencies, integrations with public cloud, in fact pretty much anything I can do with an engineered NetApp system.
While there remain benefits of a custom hardware deployment if our desired outcome is deployment flexibility, the risk is minimal and maybe worth taking.
The Benefit of Software Defined in your data strategy
The real attraction with Software Defined is the part it can play in a wider data strategy. One of the biggest challenges we face when it comes to data is the need to have it in multiple destinations from core data centre to network edge, branch office, co-lo facilities or the public cloud. How do we do this efficiently and crucially maintain the enterprise controls and protection that our data asset demands?
SDS is core to this, allowing us to deploy the same storage system anywhere we need it, providing consistency of service regardless of location and this consistency is, in my opinion, crucial to delivering a flexible, robust and secure data platform to an organisation.
I’ve used NetApp as an example throughout this post, why? Because by making ONTAP a software-defined platform they are an excellent example of how you can deploy a consistent storage platform across your organisation, with the flexibility to install the same data services across engineered system, virtual or cloud appliance, and this consistency allows us to access the data the same way and use the same Enterprise tools, policies and procedures or third-party integrations we rely on to manage IT, regardless of location or underlying platform.
Flexibility is at the heart of the move to software-defined, the modern enterprise needs flexibility in where it holds data but needs it without compromising how it is protected, secured and managed, software defined is key part of this. The drive toward SDS is unlikely to slow but as with all technology it shouldn’t become a mandate, hardware appliances will still be viable, SDS should just provide us with a deployment option so we can choose as to whether we use hardware, the public cloud or virtual appliance, whatever fits best to deliver what we need.
It doesn’t have to be NetApp of course, other vendors are in this space, but they do have a strong story when it comes to deployment flexibility and provides a very good example of SDS as part of a wider deployment strategy.
You can find out more about ONTAP Select here.
Copyright (c) 2007-2019 – Post #1DF0 – Brookend Ltd, first published on https://blog.architecting.it, do not reproduce without permission.