ESG says SolidFire storage automation saves the day, but does it?
In a recent post, my colleague Jeramiah Dooley introduced a “A skeptic’s guide to storage analyst reports,” a series of commentaries we’ll be making on a recent report by ESG titled “Quantifying the Economic Value of a SolidFire Deployment.” If you haven’t yet, give it a quick read for better context around what I’ll address here.
The report included a section on automation that caught my attention. Given my background managing and automating large data center environments, I was keen to review some of ESG’s claims, and naturally, to share my perspective.
Given any reporting like this I always aim to understand the criteria under which claims are made. Regarding automation, the report specifies that the numbers are based on calculations made for administrative hours required to operate a typical enterprise storage environment containing 1,000-3,000 VMs as well as the total time-to-completion an end user might experience. These tasks included those specific to problem resolution and ticket management in addition to common storage tasks that include provisioning, monitoring, addressing performance and capacity issues, maintenance, and providing other business values. ESG appears to have the core tasks being evaluated.
Let’s see what ESG determines the impact of automation might yield a SolidFire customer.
I will go ahead and highlight the obvious with this claim: SolidFire is an all-flash solution. Naturally, I would anticipate that we would deliver extremely fast provisioning of virtual machines when compared to many traditional storage systems. In these tests I would assume that they have VMs that they are deploying in an automated fashion and likely simulating a boot storm scenario. ESG supports this claim by highlighting SolidFire’s simplified management, policy-based provisioning, and time savings in dealing with multiple interfaces, coordinating between silos, migrating VMs, and remediating issues due to human error. That’s fair and highlights the burden traditional storage systems are on IT organizations trying to deliver today’s business needs.
SolidFire customers have the ability to leverage our full-featured API through a variety of integrations or direct calls with their automation platform of choice where pre-built integrations do not currently exist.
Two uses cases that I’ve seen customers leverage immediately come to mind:
- SolidFire currently provides a vSphere client plugin that enables administrators to quickly provision and assign new datastores to their vSphere environment. This tool makes direct calls to the SolidFire system and allows the administrator to perform most of their management functions directly through the vSphere client. Leveraging this tool eliminates the unnecessary delays that result from cross-silo requests, and enables vSphere administrators the ability to provision as the demand dictates. Since all tasks are automated under the covers, we’re eliminating likelihood of errors during provisioning.
- Secondly our customers have the ability to programmatically modify volume performance with immediate effect. This can be incredibly useful in provisioning and start-up, as it means a simple one line PowerShell script can be run against datastores to increase their performance profile by modifying their SolidFire Quality of Service values. The increased allocated performance can dramatically speed up these operations and then be reduced to normal operating levels once complete. While not specified in this claim, the same can be applied to systems undergoing change or backup windows.
Claim 2 – 28x faster response to need for increased storage resources.
This claim does not immediately strike as an automation efficiency, but as you read through the support of the claim it becomes clear that the work is so far behind the scenes you almost forget it is there. ESG’s claim is based on the fact that when a need arises to increase resources, a traditional architecture requires that the disks be procured, often requires that additional disk shelves be racked and populated, LUNs created, and finally, provisioned to the virtual environment. If the requirement was to increase performance for the workload then it’s not unlikely that data would have to migrate to the new datastore before it gets the bump it desperately needs.
The SolidFire experience is decidedly different. When a customer decides it is time for more capacity or performance in their cluster, they choose the quantity of nodes they want to add from three node types. If they simply need more performance they may choose our 2405 nodes which contain the smallest drives. If they primarily need capacity (I’m certain they won’t mind the additional available IOPs) they may choose the 9605 node. Customers can mix and match nodes, and once they are added to the cluster those new resources get to work right away. Our architecture starts writing incoming data to those nodes and existing data will begin to replicate to the new nodes as well.
No advanced configuration required. No data migration events necessary to start utilizing the new resources. It will take the system a little time to completely rebalance with the new nodes, and that varies based on the capacity consumed and current I/O utilization. The end result is the same; the back-end architecture automatically makes this possible with little to no effort and avoids negative impact to workloads.
Claim 3 – SolidFire automation can help lower operating expenses by up to 67%
This is one claim that I find to be lower than I would expect, and the reason is primarily related to ESG’s testing methodology. A reduction of operating expenses by 67% is no slouch, so let’s start with how they support this claim.
The report states the SolidFire system presents a single system for all workloads, eliminates management silos, and is designed to automate the most time-consuming administrative tasks. This seems reasonable. Even if an organization is standardized on a single platform from vendors such as EMC or NetApp, the operating tasks involved with maintaining those systems are vastly different than with SolidFire.
Managing performance and capacity separately and independently, without being tied to RAID or LUN constructs, leads to much simpler management on the storage team. Allow those same resources to begin focusing their time utilizing Python, PowerShell, or tool of choice to automate common tasks and you get into double bonus territory. The more they automate, the more time they free up.
Consequently, more complicated tasks can be addressed. I regularly see customers who have completely automated the provisioning of new storage resources to their applications and virtual environments based on real-time consumption. In some cases this begins with a workflow that awaits approval to initiate the expansion, while in others it even initiates work to purchase new nodes as certain thresholds are reached, complete with recommendation for which nodes would be required.
Powerful — and yet only scratching the surface. ESG hit the right notes, but our customers are cranking it to 11.
I see our customers doing incredible things with SolidFire to meet their business’s needs, many of which I described here, and others in the realms of OpenStack and CloudStack integrations, which were not tested. I would not be surprised in the least if each of our customers reviewed ESG’s findings and nodded their heads in agreement. Perhaps they would also feel that the numbers could justifiably be more bullish given the extensibility and relative simplicity of the platform.
I joined SolidFire with the express purpose of doing work that would help our customers make the consumption and management of our systems seamless and practically invisible. In the weeks leading up to and after VMworld you will see a series of posts where I outline some of the ways customers can leverage our rich API and integrations to do things they never knew were possible with storage. These examples should give you a taste of what is uniquely possible for SolidFire customers and lends answers to questions around how much more time and value can be gained, even beyond the strong claims by ESG.
I, for one, am excited to hear from you if you have a story to share. Please leave it in the comments.
Access the ESG Lab Whitepaper “Quantifying the Economic Value of a SolidFire Deployment.”