What is the Software-Defined Storage Model?
Software-Defined Storage Model
VMware’s software-defined storage model literally turns the world (of storage) upside down. It introduces a 180° shift from the ‘bottom-up’ array-centric approach of existing storage options to a ‘top-down’ virtual machine-centric model:
It puts the application and its requirements at the top of the hierarchy, with storage responding to changes in application requirements.
This is in sharp contrast to the current approach, which usually requires configuring static pools of storage resources, and hoping that there’s a match between what applications need and the services that have been provided for them. By comparison, software-defined storage uses application policies (or pre-set rules) to create a “just-in-time” model for storage services. Storage assets and capabilities aren’t configured and assigned to specific applications until they’re needed. And if the policy changes, the storage environment dynamically and automatically changes with it.
These storage services (capacity, performance, protection, encryption, replication, etc., as needed by an application) are ‘made to order’ from available resources, rather than being selected from a static pool of static services. As a result, storage services are precisely-aligned to application requirements.
This shift in approach enables the construction of a “converged” model for IT operations, one where traditionally individual technology disciplines merge to provide dynamic application services. The hypervisor makes this possible. It is positioned between the physical server and the VMs that run on it and manages the underlying storage infrastructure, balancing the needs of each VM and the applications that each VM runs.
This model offers many benefits. As there are far fewer steps (due to automation), they’re usually done by far fewer people, increasing efficiency. There’s no waste: applications get just what they need (performance, capacity, protection, etc.) and no more. Underlying infrastructure can change, but the higher-level automation processes won’t need to. And storage can be built on lower-cost, industry-standard hardware, as opposed to expensive proprietary hardware.
Not all organizations will adopt software-defined storage at the same rate, or in the same way. One useful way of distinguishing different IT organizations is by their preferred automation model, a good indication of their progression towards a software-defined environment:
| USER INTERFACES AND WIZARDS | CUSTOM AUTOMATION | HOMOGENEOUS CLOUD | HETEROGENEOUS CLOUD |
|---|---|---|---|
| Modestly-sized environments | Larger environments | Focus is on moving to the cloud, but at a reasonable pace | Focus is on cloud-style automation and scale |
| Use vendor-supplied tools to configure, monitor, and run infrastructure | Use vendor-supplied user interfaces and APIs for extensive low-level automation of regular tasks (scripting) | Usually have a single-purpose cloud | Cloud is the default platform for all applications |
| Focused on virtualization, not “cloud” | Focused on virtualization, not “cloud” | 10-15% of VMs running in a cloud “sandbox” (i.e., separated for security reasons) | 80-90% of apps running on a self-service platform |
| No interest in additional automation, so unlikely to fully embrace SDS | No management or automation framework | “Custom Automation” for core apps and mission-critical tasks | Strong DevOps team |
| Aspire to the cloud, where policy can replace ad hoc scripts | Will value the ability to create application-centric policies | Will greatly benefit from SDS in all of its aspects | |
| Most aspire to heterogeneous cloud |
