At the time I was using it, it was better than other products. It was fast and easy to understand. It didn't have complex connectivity. Connectivity was very easy. Even the management, in terms of how we access the device, was easier as compared to other devices. I have not done the configuration. It was something that their support used to do for us. They used to send an engineer. 

The compression and de-dupe have been great in terms of space-savings, especially for our prod/stg/qa/dev DB instances (where you gain add'l savings for the de-duped data);  the QOS for IOPS helps us to ensure that no non-prod action can be deleterious to our production-stack data

We're currently working on the Element X operating system with SolidFire, because we're trying to break the combination of hardware and software. We're going for the Element X implementation, where you can use any hardware you like. That's also something where SolidFire's very supportive. Maybe we end up buying the SolidFire hardware anyway, but it's a nice option. You have no vendor-lock; you can purchase the software from SolidFire and use some appliance from other vendors.

I can't really say that I've seen a lot of benefits since we installed SolidFire as our legacy backup storage. I haven't noticed any significant increases in productivity or functionality.

It's the overall simplicity of the platform in that you can learn to operate one of these in half a day. You can stand them up in half a day. Whatever you need to purchase, it has a simple bill of materials. It's great.

Also, agility, absolutely. It takes a typical IT company months, and especially large companies like ours, months and months and months, to acquire gear. We spend a long time to plan, design, and then eventually get our quotes, review these bills of materials, make sure we get everything that we need correct, and it's just a complicated process. It takes time.

It will save a lot of implementation time, complexities; and then you don't have to go ahead with networking the OS separately. It's all one in the same place.

Our use case is all private cloud right now, running OpenStack. All internal, for our internal R&D and engineering.

For us, moving into a private cloud area was a big step for R&D. So while we are just in our infancy right now, it has made a big difference in storage efficiency. Traditional workloads that we ran on AFF, we saw better deduplication ratios, and efficiency ratios on SolidFire than AFF for our workloads. It's a very IOP-driven environment, very IOP intensive, and the SolidFire handles that quite well using the QoS for IOP.

Less complaints from the database administrators as to why an application is so slow; we always get blamed, everything goes back onto storage. SolidFire takes that away from the equation. Now we have a fast system, so the admins have to go back and see where the bottleneck is.

Because of the scalability and being able to add and decrease quickly, it allows us to service our customers at a quick rate, versus how they normally would have done it.

We have approximately 8,000 VMs that we had been running on our traditional storage system and it simply was not able to keep up with the workload, so we've migrated all that to the SolidFire product. Provisioning times have gone down and a lot of the random errors from different things that we've seen across time kind of all went away. It's made everything much more efficient. It has saved us time.

We do a lot of tear-downs and rebuilds in non-production environments, so those processes have been reduced to minutes. It's been tremendously beneficial for our development.

Part of the reason we went this route was we did that storage design workshop with NetApp. So we went for QoS-driven design for our new array. It really helped us not only in delivering the service levels to our users, but also automating that. So it makes it a lot easier for provisioning. It also makes it a lot easier to guarantee performance for our end users.

It's doing SAN, so that would be the major difference. We use NFS file storage much more than we use block storage. SolidFire is our only block storage offering right now. Honestly, we're kind of phasing block storage out, but it's filling that gap for applications that claim they need block storage and can't use file-based. That's kind of its role.

It is just filling the gap of the block client, because maybe 10% of our clients have to use block storage and have a good technical reason. The other 90% we've gotten on a NAS.

We previously had another storage vendor, and we would recompose desktops of 350 VDI desktops or virtual desktops, and it would take us 10 to 12 hours. We then implemented the SolidFire on that same subset of users, the 350 desktops, and we could do it in an hour and a half. It's almost a ten-times savings as far as time for recomposing in our environment or infrastructure.

We went from huge NetApp arrays to essentially a half a rack with the same amount of space that was required as far as data drives. With the footprint being smaller, and performance being way up, we're able to increase IOPS, which will give us better capability to actually mimic the production network on a government network.

For a customer who purchased SolidFire, they don't had reported any issue regarding it's performance or scalability.The end result is better productivity due to seamless performance of any application.

Just moving away from traditional spinning disc to solid state storage is a step forward, and user applications obviously are performing much faster. We have a much smaller footprint within our datacenter, so we've able to reduce overall operating expenses within our datacenter; shrinking costs for our business. It's been a fantastic improvement all round.

The biggest advantage is going to be the QoS settings, being able to maintain a level performance for our customers on whatever application that they're running at that particular time. For us, a business advantage is implementation time; our first cluster, four hours from un-boxing, racked, stacked and having it up and running.

It's provided us the ability to not be concerned with setting SLOs for whatever application we're using. Everything is pretty much tier-one.

Our primary use case is virtualization, right now. We initially purchased it to be incorporated into our own internal cloud, OpenStack-based, KVM-based, so we use it for that. And, we've also branched into standard VMware as well. So we have both.

Based on those use cases we get really good efficiencies. We do a lot of encryption. We initially didn't have any because we were using it for anything, any LUNS, Oracle, whatever, and we didn't get the efficiency. So we positioned the use case over to virtualization and we're getting good efficiencies that way; to make it more cost effective. That's one of disadvantages, the actual cost. We haven't gotten there yet, but...

Right now, we're still in the testing phase but I think it definitely helps in the sense where, with traditional SAN architectures, you have to architect what kind of disk you need and how many of those disks you need in your storage pool and things like that. With the SolidFire, it's really just a number and it’s really just a matter of typing in that number for that certain LUN or whatever it is that you want to allocate for your users.

We were able to migrate some applications from spinning media to SolidFire, and we were having "noisy neighbor" problems before.

With this solution, you can actually do more with less. You can have more tenants and more application with less space and less dollar per gigabyte. By increasing the utilization up to four or five times someone can get more with less.

In Asia, a lot of people are still using the Fibre Channel and Fibre Channel is actually the best part of NetApp SolidFire. By providing the journey, we enable the customer to actually experience the new technology but without the need to make a lasting investment. We have to transition to the next generation because whatever SolidFire is offering it's not common hyperconverged work. It is actually for the centrifugal outlook but, it is not about the Fibre Channel. It's no longer required, The transition to next-generation infrastructure is where the Fibre Channel switch is required.