-Dave Wright, Founder & CEO

-Dave Cahill, Director of Strategic Alliances

• Advanced feature development. SolidFire continues to deliver the industry's most comprehensive support for the Cinder block storage service. Enhanced features supported by our OpenStack Driver in the Grizzly release include boot from volumes, QoS settings via volume types, and multi-backend support allowing for the seamless addition of a SolidFire cluster into an existing Cinder environment.
• Cross-ecosystem integrations. To help ease deployment and management of customers' OpenStack-based infrastructure we have announced partnerships with leading OpenStack distributions including both Nebula One and Rackspace's Alamo Private Cloud software.
• Reference architectures & best practices. To minimize friction when deploying SolidFire within an OpenStack-based infrastructure, we have published three different documents including a SolidFire/Cinder configuration guide, reference architecture and a SolidFire/Rackspace Private Cloud Implementation guide.
• Real world deployments. We have a number of customers using SolidFire as the block storage within their OpenStack cloud infrastructure. One that we can talk about today, Brinkster, is quoted in our recent press release. The level of activity and conversations in this space is amazing and we hope to share more of these names with you in the very near future.

From early on at SolidFire we have invested in continued project and community support. Now with some strong customers wins and go-to-market partnerships under our belt, SolidFire is gaining increasing momentum as the block storage of choice for OpenStack. For customers seeking guaranteed performance, high availability, and scale for their OpenStack-based cloud infrastructure, there is no better option.

If you plan to attend the upcoming summit this week in Portland, OR, please drop by our booth. To schedule a meeting or demo while at the show email (sales@solidfire.com) or tweet us (@solidfire) ahead of time.

-Dave Cahill, Director of Strategic Alliances

• SSD (or similar) only
• Some dedupe or similar technology to make it affordable
• Scale-out design where we would get more IOPS per node
• Fully redundant where we should be able to lose a node without downtime
• Integration with OpenStack

We did a lot of searching and found a number of potential products. SolidFire was the only system that checked all the boxes! One feature that SolidFire had that we did not even have in the list of requirements was true Quality of Service (QoS).
 
The SolidFire deduplication and compression made the system affordable even if it is SSD only. With a SSD-only system we can get predictable performance and always deliver high performance and low latency. During our performance tests we got up to 2ms latency during maximum IOPS load. During normal load we achieved sub 1ms latency, which is 10-20 times better than a normal hard-disk-based storage system. With the linear scalability achieved by a scale-out design we can be certain not to run into bottlenecks in the storage system when we grow in capacity. We also see the SolidFire contribution to OpenStack as a big advantage securing the future integration with the OpenStack platform.

Learn more about how Elastx is being Fueled by SolidFire™ .

-Joakim Öhman, CEO, Elastx

In a relatively closed environment such as the compute layer it's fairly easy to guarantee a minimum level of resource availability, but when it comes to a shared storage platform new challenges arise. The hypervisor owns the computes resource and distributes it to the virtual machine it's hosting. In a shared storage environment we are dealing with multiple layers of infrastructure, each susceptible to congestion and contention. And then there is the possibility of multiple external storage resource consumers such as non-virtualized workloads using the same array impacting the availability of resources and the control of distributing the resources.

        - Frank Denneman, Would you be interested in Storage-level reservations? 3/26/13

While it would be fantastic to solve this problem solely from a hypervisor perspective, the reality is that the hypervisor has very little control or visibility of the underlying storage system resources. A cloud infrastructure of any size demands a more coordinated approach across both host and storage resources. Some of the key issues to consider with a hypervisor-centric approach in front of traditional storage include:

• Lack of IOPS control. While the hypervisor can throttle IOPS, it has no control over maintaining the total IOP pool available. With not governance from the underlying storage system there is no way for a hypervisor to truly guarantee a minimum IOP level. In this scenario the hypervisor will always be at the mercy of the storage device.
• Performance degradation. Without visibility into back-end storage resource utilization, there is no way for the hypervisor to know what resources remain available to it on a persistent basis. As storage system utilization increases performance degradation becomes a real concern. With a larger pool of virtual resources contending for the same pool of resources, the lack of any sort of storage system layer isolation effectively creates an IOPS free-for-all. The resulting performance variability is a non-starter for a multi-tenant infrastructure hosting performance sensitive applications.
• Forced overprovisioning. Absent the ability to granularly carve up storage system performance and provision it out to each virtual machine, the only way to ensure a large enough IOPS pool for these VMs is to extensively overprovision your storage. Unfortunately, there is no better way to blow the economics of your shared storage environment than by being forced to deploy 3x as many systems at 1/3rd the utilization rates.
• Lacking coordination. While throttling IOP usage to VMs is a basic form of storage QoS, this solution is more of an indictment of the deficiencies of existing storage systems than an ideal solution to the problems posed in a multi-tenant infrastructure.  True QoS is delivered through end-to-end coordination and orchestration between the host and the underlying storage system to ensure each virtual machine has the resources it needs to properly support the application.

Implementing a storage QoS mechanism like storage reservations at the hypervisor layer, without similar enforcement capability at the storage system level, does little to address the core challenges imposed by these multi-tenant environments. With VMware and others efforting to improve controls at the hypervisor layer, now is the time to demand more from your storage vendors to deliver on their side of this equation. The good news is there is no need to wait. There are options already available today and over time, API-based integration between hypervisors and storage systems, such as that provided by projects like OpenStack Cinder and VMware VVOLs will provide a much more holistic approach to managing storage Quality of Service than what can be obtained from a hypervisor alone.

-Dave Cahill, Director of Strategic Alliances

Delivering Guaranteed Quality of Service in a cloud environment is key to unlocking the true potential of cloud to host business critical applications. However, doing so requires an architecture designed for quality of service, not simply bolt-on features. The final architectural requirement for guaranteeing QoS is the ability for the system to virtualize performance separate from capacity, allowing a user to dial in the exact amount of performance and capacity required from separate pools.

All modern storage systems virtualize the underlying raw capacity of their disks, creating an opaque pool of space from which individual volumes are carved. However the performance of those individual volumes is a second-order effect, determined by a number of variables such as the number of disks the volume is spread across, the speed of those disks, the RAID-level used, how many other applications share the same disks, and the controller resources available to service IO.

Traditional capacity virtualization does not suffice
Historically this approach has prevented storage systems from delivering any specific level of performance. "More" or "less" performance could be obtained by placing a volume on faster or slower disks or by relocating adjacent applications that may be causing impact. However, this solution is a manual and error-prone process. In a cloud environment, where both the scale and the dynamic nature prevent manual management of individual volumes, this approach just isn't possible. Worst of all, significant raw capacity is often wasted as sets of disks get maxed out from a performance standpoint well before all their capacity is used.  

Finally, performance can be managed independent of capacity
SolidFire's performance virtualization removes all this complexity, creating separate pools of capacity and performance from which individual volumes can be provisioned. Performance becomes a first-class citizen, and management is as simple as specifying the performance requirements for an application rather than manually placing data and trying to adjust later.

Furthermore, SolidFire performance virtualization allows performance for an individual volume to be changed over time - simply increased or decreased as application workloads change or as requirements become more clear. SolidFire's ability to dynamically adjust performance gives service providers the complete flexibility to deliver customers the exact performance they need, precisely when they need it.

Separating performance from capacity has the added benefit of providing a consistent way to view the current load on the system, both in terms of the capacity and performance that is actually used. Ensuring that the system doesn't become unexpectedly overloaded is now as simple as reading a gas gauge rather than reading tea leaves. SolidFire's ability to separate performance from capacity in our architecture is the last essential part of guaranteeing QoS. Without it, you're left with a manual process full of guessing games and resulting in poor overall efficiency.

If you'd like to learn more about Quality of Service in cloud computing, join our upcoming webinar with WHIR:

Unlocking the Secret to QoS in the Cloud: The 6 Requirements of Your Storage Architecture
Web Host Industry Review Webinar with SolidFire
Tuesday, April 2, 2:00pm EST

Register now

-Dave Wright, Founder & CEO

As you know from reading our Quality of Service (QoS) Benchmark blog series, guaranteeing QoS takes more than simply having a QoS feature. Without an architecture built from a design that includes all-SSD, scale-out architecture, RAID-less data protection, and balanced data distribution, any discussion of QoS is really just lip service. Another key requirement for guaranteeing Quality of Service is a fine-grain QoS model that describes performance in all situations.

Contrast fine-grain control against today's rudimentary approaches to (QoS), such as rate limiting and prioritization. These features merely provide a limited amount of control and don't enable specific performance in all situations.

The trouble with having no control
For example, basic rate limiting, which sets a cap on the IOPS or bandwidth an application consumes, doesn't take into account the fact that most storage workloads are prone to performance bursts. Database checkpoints, table scans, page cache flushes, file copies, and other operations tend to occur suddenly, requiring a sharp increase in the amount of performance needed from the system. Setting a hard cap simply means that when an application actually does need to do IO, it is quickly throttled. Latency then spikes and the storage seems painfully slow, even though the application isn't doing that much IO overall.

Prioritization assigns labels to each workload, yet similarly suffers with bursty applications. While high priority workloads may be able to easily burst by stealing resources from lower priority ones, moderate or low priority workloads may not be able to burst at all. Worse, these lower priority workloads are constantly being impacted by the bursting of high priority workloads.

Failure and over-provisioned situations also present challenges for coarse-grained QoS. Rate limiting doesn't provide any guarantees if the system can't even deliver at the configured limit when it is overtaxed or suffering from performance-impacting failures. While prioritization can minimize the impact of failures for some applications, it still can't tell you ahead of time how much impact there will be, and the applications in the lower tiers will likely see absolutely horrendous performance.

SolidFire enables the control you've been looking for
SolidFire's QoS controls are built around a robust model for configuring QoS for an individual volume. The model takes into account bursty workloads, changing performance requirements, different IO patterns, and the possibility of over-provisioning. Whether an application is allocated a lot of performance or a little, the amount of performance it gets in any situation is never in doubt. Cloud operators finally have the confidence to guarantee QoS and write firm SLAs against performance. Only an architecture built with a fine-grained Quality of Service model can support these types of guarantees.

Stay tuned to this blog as we discuss the other critical architecture requirements required for guaranteed QoS, and join us on our upcoming webinar with WHIR to learn more:

Unlocking the Secret to QoS in the Cloud: The 6 Requirements of Your Storage Architecture
Web Host Industry Review Webinar with SolidFire
Tuesday, April 2, 2:00pm EST

Register now

-Dave Wright, Founder & CEO

Guaranteeing performance to thousands of applications at the same time is a daunting challenge, but it's essential for anyone wanting to host performance-sensitive applications in a cloud environment. However, delivering true Quality of Service (QoS) requires an architecture specifically designed for the task. As we've shown, true QoS starts with an all-SSD platform, a scale-out architecture, and RAID-less data protection. The fourth architecture requirement for guaranteed QoS is a balanced load distribution across all the disks in the system.

Most block storage architectures use very basic algorithms to lay out provisioned space. Data is striped across a set of disks in a RAID set, or possibly across multiple RAID sets in a storage pool. For systems that support thin provisioning, the placement may be done via smaller chunks or extents rather than the entire volume at once. Typically, however, at least several hundred megabytes of data will be striped together.

Once data is placed on a disk, it is seldom moved (except possibly in tiering systems to move to a new tier). Even when a drive fails, all its data is simply restored onto a spare. When new drive shelves are added they are typically used for new data only - not to rebalance the load from existing volumes. Wide striping is one attempt to deal with this imbalance, by simply spreading a single volume across many disks. But as we've discussed before, when combined with spinning disk, wide striping just increases the number of applications that are affected when a hotspot or failure does occur.

Unbalanced loads cause unbalanced performance
The result of this static data placement is uneven load distribution between storage pools, RAID sets, and individual disks. When the storage pools have different capacity or different types of drives (e.g. SATA, SAS, or SSD) the difference can be even more acute. Some drives and RAID sets will get maxed out while others are relatively idle. Managing data placement to effectively balance IO load as well as capacity distribution is left to the storage administrator, often working with Microsoft Excel spreadsheets to try and figure out the best location for any particular volume.

Not only does this manual management model not scale to cloud environments, it just isn't viable when storage administrators have little or no visibility to the underlying application, or when application owners cannot see the underlying infrastructure. The unbalanced distribution of load also makes it impossible for the storage system itself to make any guarantees about performance. If the system can't even balance the IO load it has, how can it guarantee QoS to an individual application as that load changes over time?

SolidFire restores the balance
SolidFire's unique approach to data placement distributes individual 4K blocks of data throughout the storage cluster to evenly balance both capacity and performance. Data is distributed based on content rather than location, which avoids hotspots caused by problematic application behavior such as heavy access to a small range of LBAs. Furthermore, as capacity is added (or removed) from the system, data is automatically redistributed in the background across all the storage capacity. Rather than ending up with a system that has traffic jams in older neighborhoods while the suburbs are mostly empty, SolidFire creates perfect balance as the system scales.

This even distribution of data and IO load across the system allows SolidFire to deliver predictable performance regardless of the IO behavior of an individual application. As load on the system increases, it happens predictably and consistently. And as new capacity and performance is added, the SolidFire system gives a predictable amount of additional performance. This balanced load distribution continues to stay balanced over time, an essential aspect of delivering consistent performance day after day. You just can't guarantee QoS without it.

Stay tuned to this blog as we discuss the other critical architecture requirements required for guaranteed QoS, and join us on our upcoming webinar with WHIR to learn more:

Unlocking the Secret to QoS in the Cloud: The 6 Requirements of Your Storage Architecture
Web Host Industry Review Webinar with SolidFire
Tuesday, April 2, 2:00pm EST

Register now

-Dave Wright, Founder & CEO

Ensuring Quality of Service (QoS) is an essential part of hosting business-critical applications in a cloud. But QoS just isn't possible on legacy storage architectures. As we've been discussing in this QoS Benchmark blog series, guaranteeing true QoS requires an architecture built for it from the beginning, starting with all-SSD and scale-out architectures. Now let's explore the third requirement to deliver guaranteed performance: data protection that doesn't rely on standard RAID.

The invention of RAID 30+ years ago was a major advance in data protection, allowing "inexpensive" disks to store redundant copies of data, rebuilding onto a new disk when a failure occurred. RAID has advanced over the years with multiple approaches and parity schemes to try and maintain relevance as disk capacities have increased dramatically. Some form of RAID is used on virtually all enterprise storage systems today. However, the problems with traditional RAID can no longer be glossed over, particularly when you want a storage architecture that can guarantee performance even when failures occur.

The problem with RAID
When it comes to QoS, RAID causes a significant performance penalty when a disk fails, often 50% or more. This penalty occurs because a failure causes a 2-5X increase in IO load to the remaining disks. In a simple RAID10 setup, a mirrored disk now has to serve double the IO load, plus the additional load of a full disk read to rebuild into a spare. The impact is even greater for parity-based schemes like RAID5 and RAID6, where a read that would have hit a single disk now has to hit every disk in the RAID set to rebuild the original data - in addition to the load from reading every disk to rebuild into a spare.

The performance impact from RAID rebuilds becomes compounded with long rebuild times incurred by mutli-terabyte drives. Since traditional RAID rebuilds entirely into a new spare drive, there is a massive bottleneck of the write speed of that single drive combined with the read bottleneck of the few other drives in the RAID set. Rebuild times of 24 hours or more are now common, and the performance impact is felt the entire time.

How can you possibly meet a performance SLA when a single disk failure can lead to hours or days of degraded performance? In a cloud environment, telling the customer "the RAID array is rebuilding from a failure" is little comfort. The only option available for service providers is to dramatically under-provision the performance of the system and hope that the impact of RAID rebuilds goes unnoticed.

Introducing SolidFire Helix™ data protection
SolidFire's Helix data protection is a post-RAID distributed replication algorithm. This solution spreads redundant copies of data for single disk throughout all the other disks in the cluster rather than just a limited RAID set. Data is distributed in such a way that when a disk fails, the IO load it was serving spreads out evenly among every remaining disk in the system, with each disk only needing to handle a few percent more IO - not double or triple what it served before like RAID. Furthermore, data is rebuilt in parallel to the free space on all remaining disks rather than to a dedicated spare drive. Each drive in the system simply needs to share 1-2% of its data with its peers, allowing for rebuilds in a matter of seconds or minutes rather than hours or days.

The combination of even load redistribution and rapid rebuilds allows SolidFire to continue to guarantee performance even when failures occur, something that just isn't possible with traditional RAID.

Stay tuned to this blog as we discuss the other critical architecture requirements required for guaranteed QoS, and join us on our upcoming webinar with WHIR to learn more:

Unlocking the Secret to QoS in the Cloud: The 6 Requirements of Your Storage Architecture
Web Host Industry Review Webinar with SolidFire
Tuesday, April 2, 2:00pm EST

Register now

-Dave Wright, Founder & CEO

Welcome to the third blog in the SolidFire Benchmark QoS series, where we've been explaining how guaranteeing Quality of Service (QoS) isn't a feature that can be bolted on to a storage system. It requires an architecture built for it from the ground up, starting with an all-SSD platform. Now let's discuss a second requirement: a true scale-out architecture.

Traditional storage architectures follow a scale-up model, where a controller (or pair of controllers) are attached to a set of disk shelves. More capacity can be added by simply adding shelves, but controller resources can only be upgraded by moving to the next "larger" controller (often with a data migration). Once you've maxed out the biggest controller, the only option is to deploy more storage systems, increasing the management burden and operational costs.

Tipping the scales not in your favor
This scale-up model poses significant challenges to guaranteeing consistent performance to individual applications. As more disk shelves and applications are added to the system, contention for controller resources increases, causing decreased performance as the system scales. While adding disk spindles is typically seen as increasing system performance, many storage architectures only put new volumes on the added disks, or require manual migration. Mixing disks with varying capacities and performance characteristics (such as SATA  and SSD) makes it even more difficult to predict how much performance will be gained, particularly when the controller itself can quickly become the bottleneck.

Scaling out is the only way to go
By comparison, a true-scale out architecture such as SolidFire adds controller resources and storage capacity together. Each time capacity is increased and more applications are added, a consistent amount of performance is added as well. The SolidFire architecture ensures that the added performance is available for any volume in the system, not just new data. This solution is critical for both the administrator's planning ability as well as for the storage system itself. If the storage system itself can't predict how much performance it has now or will have in the future, it can't possibly offer any kind of guaranteed Quality of Service.

Stay tuned to this blog as we discuss the five other critical architecture requirements required for guaranteed QoS, and join us on our upcoming webinar with WHIR to learn more:

Unlocking the Secret to QoS in the Cloud: The 6 Requirements of Your Storage Architecture
Web Host Industry Review Webinar with SolidFire
Tuesday, April 2, 2:00pm EST

Register now

-Dave Wright, Founder & CEO

Anyone deploying either a large public or private cloud infrastructure is faced with the same issue: how to deal with inconsistent and unpredictable application performance. As we discussed earlier, overcoming this problem requires an architecture built from the ground up to guarantee Quality of Service (QoS) for many simultaneous applications.

The first requirement for achieving this level of performance is moving from spinning media to an all-SSD architecture. Only an all-SSD architecture allows you to deliver consistent latency for every IO.

At first, this idea might seem like overkill. If you don't actually need the performance of SSD storage, why can't you guarantee performance using spinning disk? Or even a hybrid disk and SSD approach?

Fundamentally, it comes down to simple physics. A spinning disk can only serve a single IO at a time, and any seek between IOs adds significant latency. In cloud environments where multiple applications or virtual machines share disks, the unpredictable queue of IO to the single head can easily result in orders of magnitude variance in latency, from 5 ms with no contention to 50 ms or more on a busy disk.

The solutions are part of the problem
Modern storage systems attempt to overcome this fundamental physical bottleneck in a number of ways including caching (in DRAM and flash), tiering, and wide striping.

Caching is the easiest way to reduce contention for a spinning disk. The hottest data is kept in large DRAM or flash-based caches, which can offload a significant amount of IO from the disks. Indeed, this is why large DRAM caches are standard on every modern disk-based storage system. But while caching can certainly increase the overall throughput of the spinning disk system, it causes highly variable latency.

Data in DRAM or flash cache can be served in under 1 ms, while cache misses served from disk will take 10-100 ms. That's three orders of magnitude for an individual IO. Clearly the overall performance for an individual application is going to be strongly influenced by how cache-friendly it is, how large the cache is, and how many other applications are sharing it. In a dynamic cloud environment, that last criteria is changing constantly. All told it's impossible to predict, much less guarantee, the performance of any individual application in a system based on caching.

Tiering is another approach to overcome the physical limits of spinning disk, but suffers from many of the same problems as caching. Principally, tiered systems move "hot" and "cold" data between different storage in an attempt to give popular applications more performance. But as we've discussed before this solution suffers from the same unpredictability problems as caching.

Wide striping data for a volume across many spinning disks doesn't solve the problem either. While this approach can help balance IO load across the system, many more applications are now sharing each individual disk. A backlog at any disk can cause a performance issue, and a single noisy neighbor can ruin the party for everyone.

All-SSD is the only way to go
All-SSD architectures have significant advantages when it comes to being able to guarantee QoS. The lack of a moving head means latency is consistent no matter how many applications demand IOs, regardless of whether the IOs are sequential or random. Compared to the single-IO bottleneck of disk, SSDs have eight to 16 channels to serve IOs in parallel, and each IO is completed quickly. So even at a high queue depth, the variance in latency for an individual IO is low. All-SSD architectures often do away with DRAM caching altogether. Modern host operating systems and databases do extensive DRAM caching already, and the low latency of flash means that hitting the SSD is often nearly as fast as serving from a storage-system DRAM cache anyway. The net result in a well-designed system is consistent latency for every IO, a strong requirement for delivering guaranteed performance.

An all-SSD architecture is just the starting point for guaranteed QoS, however. Even a fast flash storage system can have noisy neighbors, degraded performance from failures, or unbalanced performance. Stay tuned to this blog as we discuss the five other critical architecture requirements required for guaranteed QoS, and join us on our upcoming webinar with WHIR to learn more:

Unlocking the Secret to QoS in the Cloud: The 6 Requirements of Your Storage Architecture
Web Host Industry Review Webinar with SolidFire
Tuesday, April 2, 2:00pm EST

Register now

-Dave Wright, Founder & CEO

Host Performance-Sensitive Applications in Your Cloud with Confidence

Citrix Ready Webinar with SolidFire
Wednesday, March 13, 1:00pm EST

Learn how SolidFire storage used with Citrix CloudPlatform powered by Apache CloudStack can help you deliver a cloud infrastructure with the performance, quality-of-service and automation required to confidently, and economically, host mission and business critical applications.

Register now

Learn more about Citrix and SolidFire 

Unlocking the Secret to QoS in the Cloud: The 6 Requirements of Your Storage Architecture

Web Host Industry Review Webinar with SolidFire
Tuesday, April 2, 2:00pm EST

There's lots of buzz around Quality of Service (QoS) these days, and also lots of questions. In this webinar, we'll discuss why QoS is the key to delivering performance for enterprise applications in the cloud and the 6 architectural requirements needed to guarantee it.

Register now

Learn more about storage QoS

Last year some of you followed on the XenServer Facebook page with great interest the physical migration of my CloudPlatform demo cloud.  Some even commented on how cool the storage I was using looked.  Unfortunately, as anyone who has had to deal with datacenter hardware knows all too well, servers which are running might not start back up if powered down, and this is no less true for storage controllers.  As it turned out, one of the controllers in my storage array failed, and it proved just a little bit harder to get it replaced than I had anticipated, so off I went to find a suitable replacement.  Before we go too far down my decision process, it's probably a good idea to review what the two most common storage options are in cloud, and why you might want to choose one over another.

Local Storage
Local storage is by far the simplest of the choices, after all most servers come with at least one disk, and you usually have the option add in several more.  Typically local storage is used in an effort to control storage costs, and with decent shared storage starting in the tens of thousands of dollars, there is the potential for some savings.  Well, up until you understand IO that is.  All spinning disks have spindles, and the amount of random IO you can get out of a spinning disk is a function of its rotational speed and the number of spindles it has.  If you are the sole user of the disk, the number of spindles doesn't matter too much, but as soon as you have multiple users (aka VMs), things can slow down quickly.  Of course SSD is always an option, but with enterprise SSD costing 5-10 times what the same capacity SAS 15k drive does, SSD for local storage isn't really a cost leader.  More importantly, local storage also historically came with an implicit limitation; VMs can't readily migrate between hosts.  Thankfully, the latest versions of both vSphere and XenServer effectively address this problem.

Shared Storage
In server virtualization, shared storage is typically used to allow for more effective host utilization.  If you need to start a new VM, there is no real way to predict which host in a cluster might have the free capacity, but with shared storage the host selection process can be disconnected from the storage management problem.  This is really good because anchoring the storage to a shared storage solution allows for more advanced functionality like automatically restarting VMs if the hardware should fail.  Regardless of whether you use file (NFS) or block (iSCSI) based storage, the IO available to you is a function of the number of disks, their speed and how efficient the storage array is at handling those IO requests.  The problem with traditional shared storage is that controllers don't understand the type of IO they are being asked to deliver.  To them, a database query and a starting VM are pretty much the same, and that leads to a serious problem in the cloud.

How I Arrived at SolidFire
When you look at the state of the world in storage arrays, the core trend today is greater and greater IOPs.  This is wonderful for the storage guys, but organizations are actually over-buying IOPs based on predictions for peak IO requirements.  In the world of IaaS, this is made worse due to a lack of control over the IO demands each cloud tenant has.  Effectively, if careful storage design isn't done, the IO usage of one account could lead to a second account becoming IO starved.  SSDs offer a ton of IO, but that still doesn't solve the core problem of IO control.  Enter the guys from SolidFire.  Yes the SolidFire Storage Solution is SSD based; which is cool.  Yes it offers a ton of IOP capacity, but it goes one level further.  With SolidFire, you actually specify the IOPs you need on a per LUN/volume basis, and associate it with an account.  This allows some pretty granular controls, but more importantly allows you to clearly establish an SLA on the storage side, and ensure that if someone is attempting to abuse the array that the impact on other tenants is easily manageable.

As cool as that is, it's still not the full story.  I'm pretty well known for being a XenServer guy, and I'll freely admit that one of the bigger challenges I've had over the years has been thick provisioning on block based storage.  It's a pretty long story, but suffice it to say that if you want thin provisioning in XenServer your choices are local storage and NFS, or to choose storage based on StorageLink.  Now I have nothing against NFS, and honestly do use it for some of my storage in the demo cloud, but I definitely prefer iSCSI when it comes to storage management.  Here's where the SolidFire solution really got my attention.  Under the covers, they natively perform thin provisioning, data deduplication and compression on each of the blocks; across LUNs.  In real-life this means that despite the fact that I've requested a 20Gb disk from the cluster, I am likely to be using far less than that, and while XenServer thinks it has the full 20Gb, the cluster knows better.  Since I'm running a cloud, there is a ton of commonality between my templates and deduplication is a wonderful addition.

Here's the final, and arguably key point.  Since I was replacing storage, I could have taken the easy route and just got the current version of my existing array.  Nice, simple, and drop it right in.  Instead, I chose to look at exactly how my cloud was being used, and see if there wasn't a better solution in the market.  My key pain points were controlling IO utilization based on unknown workloads for the next several years, and being able to ensure that I wasn't going to run out of storage capacity any time soon.  SolidFire delivered on these, and that's why my cloud is now happily running on SSD.

SolidFire is a Citrix Ready partner in cloud solutions, and if you'd like to learn more about the solution, the Citrix Ready folks are hosting a joint webinar with SolidFire on March 13th, 2013 that anyone is invited to.  Click here to register.

-Tim Mackey, Citrix CloudPlatform & XenServer Evangelist

Being able to guarantee performance in all situations - including failure scenarios, system overload, variable workloads, and elastic demand - requires an architecture built from the ground up specifically to guarantee Quality of Service. Trying to bolt Quality of Service onto an architecture that was never designed to deliver performance guarantees is like strapping a jet engine to a VW Beetle. The wheels will come off just when you get up to speed.

Solving performance from the core
SolidFire gets to the root of the performance problem with a new storage architecture that overcomes every predictability challenge through six core architectural requirements. Together, these six requirements enable true storage Quality of Service and establish the benchmark for guaranteeing performance within a multi-tenant infrastructure.

• All-SSD Architecture
• • Enables the delivery consistent latency for every IO
• True Scale-out Architecture
• • Linear, predictable performance gains as system scales
• RAID-less Data Protection
• • Predictable performance in any failure condition
• Balanced Load Distribution
• • Eliminate hot spots that create unpredictable IO latency
• Fine Grain QoS Control
• • Completely eliminate noisy neighbors, and guarantee volume performance
• Performance Virtualization
• • Control performance independent of capacity and on demand 

Over the next few weeks we'll dive into why you need each of these six architectural requirements to deliver guaranteed QoS. We'll also talk about why, no matter what the feature list says, traditional storage architectures just aren't up to the task, because Quality of Service isn't a feature - it's an architecture. 

-Dave Wright, Founder & CEO

Until recently, cloud service providers have been creating Infrastructure as a Service (IaaS) offerings using mainly technology that was never envisaged for use in a multi-tenanted environment. Achieving a level QoS across a multi-tenanted platform has been very complicated to deliver and difficult to maintain.

The reason why this, for me, is so important is that true cloud is about true agility, allowing clients to flex their utilization of resources as and when they need it -- either automatically or at a touch of a button. Prior to my discovery of SolidFire, enabling dynamic storage provisioning (or guaranteeing the throughput of a SAN) was very expensive, incredibly difficult, and cumbersome.  SolidFire's critical QoS functionality enabled me to meet the exact performance requirements of my customer, and allowed me to react to changes in their requirements, instantly.

Currently, the mainstream IaaS provider struggles trying to fully guarantee workloads within a multi-tenanted platform. Some specialist providers do guarantee them, but they must do so using large dedicated pools of storage, which is hardly efficient.

Until SolidFire, no one had a true on-demand architecture that covered I/O bandwidth and disk I/O while breaking the link to capacity within their offerings.  Most cloud providers offer some sort of guarantee around CPU and memory but start to struggle to guarantee I/O bandwidth and disk I/O. Add in the need to be able to control I/O on a server-by-server basis on the fly, and the traditional storage vendors' offerings struggle to deliver in multi-tenanted environments.

Having the ability to control bandwidth and disk I/O to 1000s of applications is an extremely powerful tool. Coupled with the ability to adapt to changes on the fly, this allows my service offerings to meet the exact demands of my customers and allows them to get very close to true utility computing that comes with performance guarantees. Dynamic QoS function at the volume level encapsulated in SolidFire's products is why this new breed of storage technology is so important.

Another key area of importance in multi-tenanted platforms is when you look at workloads in an enterprise, they normally have a rhythm to the peaks and troughs, but within a cloud environment this doesn't exist. Instead, it's replaced with a randomness that is massively impacted by "noisy neighbour" syndrome.

Until now, these attributes have only been dealt with by isolating the workloads on near dedicated hardware. This in effect forces providers into creating dedicated areas for these applications which is more akin to a managed service than true cloud, and considerably more costly to manage and maintain.

With SolidFire's guaranteed QoS functionality in place, these abilities allow us to create Service Level Agreements (SLAs) that truly meet our clients' requirements, both from an infrastructure perspective but, more importantly, also allows us to tailor them on an application-by-application basis.

The key to SolidFire's technology isn't just that it solves problems that have, in my opinion, caused delays in cloud adoption, but that the solution is "simple." It is simple to deploy in relation to other technologies in this area, and most importantly it is simple to use, operate, and maintain.

From a client perspective, there is a clear desire to move more important and performance-sensitive applications to the cloud, yet with cloud providers unable to manage QoS levels these needs will largely remain unmet. It is my opinion that service providers that embrace these and other new technologies that have been designed specifically for use in the cloud will have the most success - and really allow the cloud to reach its full potential.

About Julian Box, CEO and Co-Founder, Calligo
Julian has over 25 years of experience helping organisations streamline operations through the innovative application of technology, including nearly a decade of delivering dynamic and agile virtualisation and cloud solutions.

Prior to Calligo, he founded and was Managing Director of VirtualizeIT Limited, a provider of virtualisation technology, including server, storage, and network virtualisation. From the time of its inception in 1995, VirtualizeIT won several UK & EMEA industry awards in recognition of its ability to deliver specialised consultancy services and complex virtualisation projects.

In 2008 Julian co-founded Virtustream Inc., a venture-capital backed Enterprise Cloud Service provider where as CTO he led the design and implementation of their industry-leading private multi-tenanted Infrastructure as a Service offering.

-Julian Box, CEO and Co-Founder, Calligo

Prioritization

How it works - Prioritization defines applications simply as "more" or "less" important in relation to one another. This is often done in canned and well described tiers such as "mission critical," "moderate," and "low." 

Why it doesn't really offer QoS -  While prioritization can indeed help give higher relative performance to some apps and not others, it doesn't actually tell you what performance to expect from any given tier. Additionally, it certainly can't guarantee performance, particularly if the problematic "noisy neighbor" is located at the same priority level. So for starters, there is no ability to guarantee that any one application will get the performance it needs. What's more, there is no functionality for one tenant to understand what their priority designation means in relation to the other priorities on the same system. It means nothing to tell a tenant they are prioritized as "moderate" unless they know how moderate compares to the other categorizations. Moderate is also meaningless without knowing what system resources are dedicated to this particular tier. In addition, priority-based QoS can often make a "noisy neighbor" LOUDER if that tenant has a higher priority because that higher priority tenant is allowed more resources to turn up the volume.

Rate limiting

How it works - Rate limiting attempts to deal with performance requirements by setting a hard limit on an application's rate of IO or bandwidth. Customers that pay for a higher service will get a higher limit.

Why it doesn't really offer QoS - Rate limiting can help quiet noisy neighbors, but does so only by "limiting" the amount of performance that an application has access to. This one-sided approach does nothing to guarantee that the set performance limit can actually be attained. Rate limiting is all about protecting the storage system rather than delivering true QoS to the applications. In addition, firm rate limits set on high performance or bursty applications can inject significant undesired latency.

Dedicated storage

How it works - IT managers attempt to deliver predictable performance by dedicating specific disks or drives to a particular application, isolating it from other applications or noisy neighbors.  

Why it doesn't really offer QoS - Dedicating storage to an application goes a long way toward eliminating "noisy neighbors," yet even dedicated infrastructure cannot guarantee a level of performance. A component failure in one of these storage islands can have a massive impact on application performance as system bandwidth and IO are redirected to recovering from the failure. Despite the dedication of resources, this approach still falls short in its ability to guarantee performance at any level. 

Tiered storage

How it works - Multiple tiers of different storage media (SSD, 15K rpm HDD, 7.2K rpm HDD) are combined to deliver different tiers of performance and capacity. Application performance is determined by the type of media the application resides on. In an effort to optimize application performance, predictive algorithms are layered over the system which literally try to predict, based on historical performance information, which data is "hot" and kept in SSD vs. data that is "cold" and kept in HDD.

Why it doesn't really offer QoS - Tiering is the worst of all the "bolted on" solutions designed for delivering predictable performance. Quite simply, this solution is unable to deliver any level of storage QoS. Tiering actually amplifies "noisy neighbors" because they appear hot and are promoted to higher performing (and scarcer SSDs), thereby displacing other volumes to lower performing, cold disks. Performance for every tenant varies wildly as algorithms move their data between media. No particular tenant knows what to expect of their IO as they don't control the tiering algorithm or have any insight into the effect on other tenants. Some tiering solutions try to offer QoS by pinning the data of a particular application into a specific tier, but this is essentially dedicated storage (discussed above) at an even higher cost than usual.

Stay tuned to our blog to learn more about storage QoS and how a scale-out storage system architecture designed from the ground up to deliver and guarantee consistent performance to thousands of volumes simultaneously is the ideal system for building performance SLAs in a multi-tenant cloud environment.

 -Adam Carter, Director of Product Management

(Note: This is a guest post by Simon Robinson, Research Vice President, 451 Research)

• Starting off the year, Amazon launched the all-SSD DynamoDB service
• We ramped our initial integration with OpenStack
• EMC aggressively bought into the scale-out all-flash array market
• We added critical engineering talent with expertise in complex distributed systems
• SolidFire was named a Red Herring Top 100 North America Tech Startup
• We expanded our storage platform with a higher density node
• Amazon validated our QoS vision with Provisioned IOPS launch
• A legacy storage vendor demonstrated the challenges of putting SSDs behind a controller designed for HDDs
• SolidFire aligned with the key cloud building blocks used by our customers
• With the birth of Cinder, block storage receives the attention it deserves in OpenStack
• After an extremely successful early access program we announced full GA...with a strong stable of early customers
• We Set the Record Straight on Software Defined Storage
• Then we got recognized as a Colorado Company to Watch
• Finally, we closed the year with some major additions to our executive team

2012 has been an incredible year for SolidFire. Reading through this list makes me tremendously proud of what our team has accomplished over the last 12 months. No question we still have a lot of work to do, but I could not be more excited about the team we have assembled, the product and culture we have built, and the opportunity in front of us as we move into 2013.

Happy holidays and we look forward to connecting again in the New Year.

-Dave Wright, Founder & CEO

Thanks to VMware's recent $1.26 billion purchase of Software-Defined-Networking (SDN) leader Nicira, and their new marketing push on the Software-Defined-Data-Center, everyone is running around trying to attach themselves to Software-Defined-Anything (SDx). This is as true for the storage market as it is any other segment of the technology ecosystem. It is a safe bet that there are a lot of storage companies, both old and new, scurrying around trying to figure out how to maneuver "Software-Defined" into their messaging.

This whole SDx concept is built on the idea that all virtualized data center resources (e.g. server, storage, networking, security) can be defined in software. These resources are then abstracted into a higher-level control plane where they are dynamically provisioned out in support different applications and/or services. The reason this is called Software-Defined is because we are at least two layers removed from the physical hardware at this point and all management, orchestration and provisioning of these services has to be done in software.

As it relates to storage, Software-Defined-Storage (SDS) is enabled by lower-level storage systems abstracting their physical resources into software in as dynamic, flexible and granular a manner as possible. These virtualized storage resources are then presented up to a control plane as "software-defined" services. The consumption and manipulation of these storage services is done through an orchestration layer like VMware, CloudStack or OpenStack. The quality and breadth of these services are highly dependent on virtualization and automation capabilities of the underlying hardware. More precisely, the control plane's effectiveness is dependent on the virtualized resources it is presented from the layers below it. Without the granular abstraction of physical storage resources, and APIs to define, flex and apply policy to these resources dynamically, the control plane is limited in the services it can provision out to virtual machines or applications.

As you can see from the description above, SDS is a combination of virtualization, abstraction and control. A storage system by itself is not SDS. Storage is a supporting element for anyone looking to manage their infrastructure within the "Software-Defined" framework. There will be a lot of vendors trying to muddy the waters between Software-Only storage and Software-Defined Storage. No matter what anyone tries to tell you, they are not the same thing. Software-Only storage is still requires hardware. The fact that it is sold as software-only is more of a go-to-market strategy and packaging decision than a technology decision. Meanwhile, SDS is a higher-level framework for the orchestration, provisioning and consumption of storage.

In a storage system properly architected to support SDS, all of the management of system resources is done through software. These resources are then presented up to the control plane, in a fine-grained fashion, via REST APIs. These APIs enable the control plane to more precisely provision storage services to the unique needs of the applications running above it. The APIs are effectively relinquishing the management of these resources to the control plane to carve them up and flex as required. This is the way it should be. This communication layer is essential to supporting Software-Defined-Storage.

In the year ahead a lot of vendors will be quick to claim they are "software-defined-storage". However, software-defined storage is NOT a storage system concept. No single product, system or platform makes up SDS, but that won't prevent a lot of people from telling you otherwise. To quickly get to the signal in this forthcoming SDS marketing storm, here are a few more questions to ask:

When your vendor claims they are Software-Defined-Storage ask them how they virtualize the underlying hardware and present it up to the control plane.

• Ask them if they can abstract and provision not only storage capacity but also performance.
• When they claim they can, ask if it is possible to make an API call to the system for a 100gb volume with 1000 IOPS. Then ask them if they can dynamically adjust this policy on the fly through software.
• Ask them if they have a complete API that allows automation of all storage services so that higher-level orchestration layers can fully exploit the benefits of SDS.

The "Software-Defined" movement has the chance to be a major leap forward for how infrastructure resources are provisioned, managed and automated. But a lot of pieces of the infrastructure need to come together to make the vision of a Software-Defined-Data-Center anything close to reality. As it relates to storage, in the coming year don't be fooled by vendor quick claims of Software-Defined-Storage. Using the questions above, dig beyond the marketing smokescreen to understand what that really means. You might surprised at what you actually find.

-Dave Wright, Founder & CEO

(originally posted on Wired.com)

Just last week I was at the Next Generation Storage Symposium delivering a presentation about the undeniable shifts in the computing landscape that are transforming IT as we know it. The combined forces of mobile and cloud are rapidly becoming the solution for an increasing percentage of IT needs.

From a cloud perspective we are still in the early days, but market data confirms the inevitable move to public and private cloud infrastructures. On the supply side of the equation, pure-play cloud providers and managed hosters are responding. The 451 Group recently released a report on the IaaS market predicting 49% annual growth through the year 2015.

On the demand side, Gartner recently released a survey of almost 600 organizations globally regarding customers use of the cloud for production applications.

"A recent Gartner survey found that 19 percent of organizations are using cloud computing for most of production computing, and 20 percent of organizations are using storage as a service for all, or most, storage requirements."

19% penetration for production applications in the cloud is a great start, but it means there is another 81% to go. How long is it going to take to get there? To continually expand the spectrum of applications that can be hosted in a cloud environment requires game changing innovations at all layers of the cloud infrastructure. Until now storage has been a real laggard. Constrained to the options available from existing storage vendors, this advancement of cloud computing could take decades.

We are not willing to wait that long. With the announcement today of general availability for SolidFire's all-SSD cloud-scale storage system, cloud providers can break free from those legacy storage systems. Purpose-built to guarantee performance to thousands of applications simultaneously, SolidFire has set the bar for what a high-performance storage system built for cloud computing should look like. Our early customers, including ViaWest, Databarracks, Calligo and CloudSigma seem to agree. Each is using the SolidFire platform as a springboard to drive more and more production applications to the cloud.

The (r)evolution is here, and it's growing by the day. If you're building a large public or private cloud, come talk to SolidFire about how we're advancing the way the world uses the cloud.

-Dave Wright, Founder & CEO

-Dave Wright, Founder & CEO

-Dave Wright, Founder & CEO

• Deduplication, compression and thin provisioning processes
• Adding and removing capacity to a system
• Linearly scaling of capacity and performance
• Adjusting per volume or tenant quality-of-service settings
• Recovery from failure conditions

When evaluating a high-performance storage architecture you have to be careful. While raw IOPS are important, they are not a viable business model for service providers. You can spend a lot of money on storage performance and still present an unpredictable environment to your customer's performance sensitive applications.

At SolidFire the ability to scale our all-flash design to 5 million IOPS is just the starting point. Equally important as raw performance is the ability to guarantee it at an individual volume level; offering consistent and predictable performance regardless of system activity or condition.

Hosting high performance applications represents a massive growth opportunity for cloud providers. However, without the right balance of performance and predictability, this opportunity remains out of reach. SolidFire helps close the gap for cloud providers, making high-performance applications in the cloud a profitable reality.  Learn how on 11/13/12. Get Ready.

-Dave Wright, Founder & CEO

Application-level SLAs without giving up the economics of multi-tenant: If you deploy an architecture that can control my compute and storage IOPS within your multi-tenant stack, you can give me application-level latency guarantees. With this I can then trust production instances of SAP, and thus my revenue generating systems, on your cloud.

               - The Enterprise: I'm Not Sexy and I Know It, TechCrunch 10/06/12

Advancing the cloud as a viable medium for more than bursty, performance insensitive applications is part evolution and part revolution. The evolution side requires an enterprise to become increasingly comfortable with hosting their business critical applications in the the cloud. But this evolution is stuck in neutral without revolutionary new technology that bridges the gap between today's cloud and the infrastructure required to bring all applications into the cloud.  For the cloud to evolve, enterprises need a greater degree of confidence that production applications will have access to predictable and consistent performance. Up till now that level of confidence and performance guarantee hasn't existed. But that is all about to change.

Starting on 11.13.12 cloud providers world-wide will have access to storage technology from SolidFire that will completely transform customers expectations for what is possible in a cloud infrastructure. SolidFire's all-SSD storage platform delivers the unique combination of performance, control and VM density required for service providers to confidently and profitably host their customers most performance sensitive workloads.

On 11.13.12 service providers will have a choice.  Continue to struggle with differentiation in a hyper-competitive market, or innovate their way to higher profits by delivering guaranteed performance to business critical applications. SolidFire's ability to combine the best of dedicated all-SSD performance with true multi-tenant economics is nothing short of revolutionary.  And yes, we can help you do it all below the cost of HDD systems.

The high-performance (r)evolution is fast approaching, and we want you to join us!  Evolving your cloud to accommodate high-performance applications is easier than you think.  Stay tuned and our team will show how...

-Dave Wright, Founder & CEO

• A Nova-Volume compatible Block Storage Service
• Updates to all of the back-end storage drivers
• NFS as block storage support
• Improved Boot From Volume with ability to specify image at volume creation
• Ability to create an Image From Volume
• Persistent iSCSI targets
• Resuming interrupted volume operations in case of service shutdown

Along with all the work in Cinder, we also ported every bug fix and feature to Nova-Volume. Why you ask? With Nova-Volume being deprecated we wanted to minimize confusion and make the migration process as easy and painless as possible. We also worked on tools to migrate your existing Nova-Volume related database tables to your new Cinder nodes.  The migration tools are included in the cinder-manage utility which can be used to migrate your DB as well as your persistent iSCSI target files.  One thing to keep in mind, in order to make this migration as easy and smooth as possible, it's required that you upgrade your existing Nova-Volume install to Folsom before performing the migration to Cinder.

It's an exciting time for Cinder and we are just getting started. There is significant potential for Block Storage in OpenStack. Now that we have the initial release of Cinder stable and ready for use, we can turn our focus to Grizzly. I look forward to discussing new feature additions and improvements we are working on at the OpenStack Summit in two weeks in San Diego. See you there!

-John Griffith, Senior Software Engineer & Cinder PTL

-Dave Cahill, Director of Strategic Alliances

• Controller Bottleneck. Constrained by the legacy controller design the P10000 can't exploit all of the raw performance provided by the SSDs. Once they max out the controller IOPS each incremental drive is only adding capacity. So while additional drives may improve the $/GB story, the $/IOP metric heads in the wrong direction.
•  Capacity Limitation. The current maximum configuration of the all-SSD version of the P10000 is 512 drives. Using 200GB SLC SSD the maximum raw capacity of this design would be 102.4TBs. In comparison, our recently announced SF6010 cluster starts out at 120TBs of effective capacity and scales to 2 PBs. It is also worth noting that a 2PB SolidFire cluster would require half the rackspace of a maxed out 102.4 TB P10000 configuration.
• System Utilization. Due to the controller constraints alluded to above, the system drive chassis can only be 40% utilized before maxing out the available IOPS. This leaves 60% of the system empty, wasting very valuable real estate.
• Drive Utilization. Based on the IOPS performance HP recently produced to demonstrate the SSD equivalent to its disk-based SPC benchmark, the net IOPS per SSD is in the range of 750-880. This yield is well below the actual SSD drive specifications implying considerable underutilization of expensive SLC media.
• Rack Utilization. An P10000 array maxed out with SSDs (totalling 512 drives) would require five racks of equipment despite a 40% utilization rate per rack. To achieve the same IOPS capacity of this system from a SolidFire 3010 would require a 10 node cluster and 95% less data center real estate (only 10U)
• Power Draw. The required five racks of HP equipment equates to a power draw of 13,295 Watts. This yields an IOPS/Watt calculation of 33.9 IOPS/Watt. In comparison a 10 node cluster from SolidFire under full load has a power draw of approximately 3000 Watts or 166.7 IOPS/Watt.
• Performance Variability. To offset the expensive SLC SSDs HP has "dynamic" tiering software that they refer to as Adaptive Optimization. However moving data between tiers is a reactive process that has the tendency to demote the wrong data to lower tiers. This can expose a customer to dramatic performance variability. In the recent past we have given this topic extensive coverage in prior blogs here, here and here.

So how do these specs compare to the clean slate approach that we have taken here at SolidFire? In a recent article written off the SPC benchmark comparison HP's stated the $/IOP of its all-flash array was $1.98. Based on the 450k IOPS benchmark this equates to a cluster cost of $891,421. In comparison, at current list pricing for a 10 node cluster, SolidFire can deliver 11% more IOPS and 170% more capacity for 33% lower cost, 95% less real estate and 77% less power draw. In the cloud market, where infrastructure cost and efficiency are survival mandates, these significant deltas equate to meaningful competitive differentiation. If these numbers matter to you and your business then let us walk you through the benefits of a purpose-built design in more detail.

-Adam Carter, Director of Product Management

"The key observation is that these random I/O-intensive workloads need to have IOPS available whenever they are needed. When a database runs slowly, the entire application runs poorly. Best effort is not enough and competing for resources with other workloads doesn't work. When high I/O rates are needed, they are needed immediately and must be there reliably."

-James Hamilton, EBS Provisioned IOPS & Optimized Instance Types 8/01/12

In recognition of customers interest in hosting I/O intensive applications, AWS recently followed up their recent announcement of high I/O EC2 instances by introducing Provisioned IOPS for EBS. This service allows a customer to specify I/O rates to specific volumes inside EBS. Up to 1,000 IOPS can be allocated per volume with the ability to stripe up to 10 volumes together per account to compose a 10,000 IOPS virtual volume. 

This provisioned IOPS concept is very similar to the IOPS QoS controls enabled by our performance virtualization technology. It was a year ago this week that Amazon's Hamilton blogged about the merits of SolidFire's approach to provisioning performance;

This system can support workloads that need dead reliable, never changing I/O requirements. It can also support dead reliable average case with rare excursions above (e.g. during a database checkpoint). It's also easy to  support workloads that soak up resources left over after satisfying the most demanding workloads without impacting other users. Overall, a nice simple and very flexible solution to a very difficult problem.

- James Hamilton, SolidFire: Cloud Operators Become a Market, 8/01/11

So what do we think of Amazon's Provisioned EBS announcement? Instilling confidence in IT departments to deploy more of their application footprint in the cloud is going to require a lot more than just our evangelism efforts. In this respect we couldn't have chosen a better ally to help drive the next phase of cloud market growth.

For cloud and hosting providers, today's announcement from Amazon has again raised the stakes. For better or worse Amazon is the benchmark against which all others need to carve out their own unique niche. Success will be dependent on the ability to maintain a differentiated offering across multiple dimensions including cost, quality and breadth of service offerings.

-Dave Cahill, Director of Strategic Alliances

Yesterday morning Amazon announced high I/O EC2 instances designed to run low-latency I/O intensive applications. Building on their initial foray into SSD-based storage, this new service allows a customer to provision dedicated SSD from local storage for each instance. Designed only for EC2 instances the use case is limited to ephemeral storage (i.e. no EBS equivalent). From a cost perspective Amazon is charging $3.10 per instance hour compared to $1.30 for the closest disk-based equivalent. Based on a 30-day month this rolls up to $2200 per month or $0.65/GB/month. In its current form the service is delivered in only one package (2TB of local storage, visible as 2 x 1TB volumes), lacking the ability to tailor storage performance or capacity to workloads that don't fit this profile.

Most SSD-based cloud offerings today have taken a very similar approach to what Amazon has announced today...local SSD's in a box. All the typical tradeoffs of local versus shared storage still apply; lack of sharing or multi-tenancy, no high availability, inability to move data between instances. For some workloads like Mongo or Cassandra this solution should suffice. For traditional enterprise applications however, the lack of reliability remains a major sticking point. Moreover, to achieve the price points required to attract a broader range of applications will require a multi-tenant infrastructure.

Harping further on the limitations of the initial offering misses the broader implications of this announcement. The performance inconsistency that exists in most cloud environments is the most frequently cited barrier to broader adoption of more I/O intensive applications in the cloud. Amazon's broader adoption of SSDs in their cloud portfolio is an extremely important milestone for cloud computing and strong directional indicator of where the market is going. In short order, we fully expect more cloud providers to follow in their footsteps. The good news for now is that Amazon has left the door open for others to come along with a differentiated value proposition. However, when it comes to SSDs in the cloud the train is clearly leaving the station...all aboard!!!

-Dave Wright, Founder & CEO

-Adam Carter, Director of Product Management

• Performance and capacity balance- Rather than force an sub-optimal tradeoff at the system level (i.e. performance or capacity) we instead designed an architecture with a more balanced blend of performance and capacity. Armed with our performance virtualization technology, service providers can now carve up this system to serve the unique needs of many different applications across a wide mix of performance and capacity requirements. This more granular level of provisioning is a far more efficient method for allocating storage resources relative to more traditional system-centric alternatives that force a capacity or performance decision upfront on every application.
• Incremental growth- The recurring nature of the service provider business model necessitated an incremental approach to scale. Each node added to the SolidFire cluster adds equal parts performance and capacity to the global pool. With a more balanced, and linearly scalable resource pool at its disposal, a cluster can more easily span environments both small and large. Traditional controller based architectures require a large investment up-front for redundant controllers, and while adding more disk shelves can increase capacity, in many architectures the performance benefit is limited, or a complex reconfiguration is required.
• Dynamic change- Capacity and performance allocations within the cluster needs to be dynamic and non-disruptive to account for the only two constants in the cloud; growth and change. This requirements applies both at the node and volume level. Node additions to a SolidFire cluster are done non-disruptively with data rebalanced across the newly added footprint. Performance QoS settings for individual volumes can be dynamically adjusted on real-time through the SolidFire REST-based APIs.
• Single management domain- As a storage environment scales it is critically important that the management burden does not do the same. The clustered nature of the SolidFire architecture ensures a single management domain as the cluster grows. Alternative architectures often require additional points of management for each new storage system. Even worse, scale limitations often prevent vendors from addressing such a broad range of capacity and performance requirements from within the same product family. The complexity resulting from multiple points of management across multiple product families can have crippling effects at scale. Multiple clusters can be set up in different fault domains or availability zones as required, but the key decision point about what scale to place in each domain is determined by the customer, not by the storage system.

The scale challenges of cloud environments mandated different design choices for us at SolidFire compared to a solutions intended for more traditional enterprise use cases. Delivering such a balanced pool of performance and capacity with a single management domain is unique in the storage industry today. Layering our performance virtualization technology into the architecture allows service providers to flexibly host a much broader range of application requirements from start to scale. Consequently, I would urge anyone building a scale-out cloud infrastructure to at least consider the above criteria as a starting point for any discussion around scale.

-Dave Wright, Founder & CEO

-Dave Wright, Founder & CEO

-Dave Wright, Founder & CEO

Dave kicked off the day with a presentation on SolidFire's vision for the future of flash storage that really set the tone for the event.  My one line takeaway from his presentation was this: "Sure flash is fast, but what good is all that performance without control". In his talk he expands the argument to include efficiency and scale. The net of all this is that flash is a means to an end but without complementary innovations across quality of service, efficiency and automation the end market is never going to be as big as some industry analysts are predicting. 

At SolidFire we believe that our technology and approach to the market is fundamentally advancing the way the world uses the cloud. In his SSSS presentation I think you will find that Dave paints a clear and compelling picture for where flash is headed and what companies like SolidFire are doing to bring this vision to life. You can find the full presentation from the event on slideshare along with the video posted on Vimeo.

I would also encourage you to check out the panel sessions from the event as well. You will surely find some useful insights across a number of key trends that are shaping the future of solid state.

• Is solid state simply a big cache or a real storage tier? Panel discussion with Chris Evans
• What's the best solid-state storage array architecture panel with Nigel Poulton
• The Future of Solid State Storage Panel with Howard Marks

Hats off to Stephen Foskett and the fantastic moderators that he brought on board for the day.  The content and discussion on these panels are much richer than what you would find at a run of the mill tradeshow.

- Jay Prassl - VP of Marketing

-Dave Cahill, Director of Strategic Alliances

• "The thing I've been publicly asking for has been better IO in the cloud. Obviously I want SSDs in there. We've been asking cloud vendors to do that for a while."
• "The instances available from AWS have similar CPU, memory and network capacity to instances available for private datacentre use, but are currently much more limited for disk I/O."
• "The hard thing to do in the cloud is to do high-performance IO [input-output], but that is starting to change as third-party vendors are figuring out ways of connecting high-performance IO externally, and we've worked around it with our [Cassandra] data store architecture."

Probably the most interesting answer was in response to a question around why it took Amazon so long to roll out an SSD-based offering (referring to DynamoDB). Cockcroft remarked:

"It's purely scale for them. For Amazon to do something they have to do it on a scale that's really mind-boggling. If you think about deploying an infrastructure service with a new type of hardware - if they got it wrong, they can't turn it back out and do it again differently. So they have to over-engineer what they do."

The key point here is that performance (through SSDs) was only part of the problem Amazon had to address. In fact, the bigger challenge for them to overcome was scale. Scale is what differentiates true clouds from small virtualized environments. Everything has to be designed to scale, which imposes a very different set of design considerations and constraints on an architecture. SSD or not, you can't escape this reality. At SolidFire scale is what we do best. There are many options for high-performance storage these days, but only SolidFire is designed for cloud scale. In doing so we are enabling service providers to focus on offering a differentiated portfolio of high performance cloud services and advancing the way we all use the cloud.

-Dave Wright, Founder & CEO

• An All-SSD system is the only way to confidently deliver predictable performance across a large number of tenants and applications in a large-scale cloud infrastructure. A tiered approach may suffice in a controlled setting with a few applications. However, the resource intensity and performance variability encountered in larger QoS-sensitive environments make tiering an unsustainable option.
• Scale-out can mean lots of different things. For SolidFire this means no monolithic storage controllers. It also means a fully distributed design with IO and capacity load evenly balanced across every node in the cluster. At the media layer, data still has to traverse the SAS bus, but ten drives per node are working in tandem to deliver more than enough aggregate performance. Thinking through alternative design choices here, it is important not to lose sight of the fact that any latency encountered at this layer of the stack is an order of magnitude less than what is encountered at the network layer.
• RAID-less means exactly what you think, no RAID. More than any controller bottlenecks, RAID is the biggest performance drag in the storage stack. By rethinking the date protection algorithm you cure a lot of what ails storage system performance today. At SolidFire we have done just that, implementing a replication-based redundancy algorithm where data is distributed throughout the cluster. The result is significant improvements in write performance and drastic acceleration of rebuilds from failure without performance impact.

Sure our storage system does a heck of a lot more than these three things. You can read all about the software innovations embedded in our Element OS on our site. But these three concepts we highlight above are critically important design choices that we made early on. They are foundational components of our architecture that make the rest of the story possible. They are also three fairly tangible concepts to help you differentiate one vendor from the next in the flash-based storage market. Good luck, it's noisy out there!

-Dave Cahill, Director of Strategic Alliances

Chris Mellor, "How to tell if your biz will do a Kodak", The Register

 The Register's Chris Mellor penned a great article the other day reflecting on the continuous cycles of innovation and disruption that have come to characterize the storage media industry. He uses Kodak to paint the picture of an incumbent getting capsized by a media transition. He goes on to cite other examples across tape and optical media where incumbents failed to manage the transition to the next generation media.

As the storage industry has transitioned through different media types there have always been opportunistic stopgap innovations that have bridged the gap from one generation to the next. Virtual Tape Library (VTL) technology is a great example of an innovation serving as a transitional bridge between the tape and disk eras. Once applications were written with the capability to natively interface with disk, deduplication and compression drove down solution costs quickly making it an effective bulk storage medium.  Once financially viable, the flood gates were opened and tape was relegated as a deep archive. Similarly, today we are seeing flash-based caching and tiering technologies forming a similar transitional bridge while the $/GB economics of flash fully converge with, and eventually eclipse, disk.

So with history as a guide for how this plays out, why will the disk to flash media transition be any different than the ones before it? Well, I suspect this cloud thing might have something to do with it.

In the enterprise IT sector, systems always seem to consume features over time. At its core, the cloud is a massive infrastructure system that when used properly is an extension of existing IT. However, cloud infrastructures will increasingly chip away at the incumbent IT footprint by rapidly incorporating new innovations into its architecture. These enabling innovations allow cloud providers to continually expand their portfolio of cloud services. Over time the IT use cases applicable to this medium naturally expand as applications and interfaces catch up, performance improves and the economic value proposition can no longer be ignored.

So what does this mean? From our perspective, the cloud adds a third leg to the innovation sequence we have witnessed in the past. New component level technologies will continue to enable new architectures. But where it gets interesting is when these new architectures drive the performance and economics to enable new cloud services.

In storage, the media innovations that Mellor refers to, and their related price/performance value proposition, are a powerful enabling force behind new storage architectures. Applied to traditional IT cost centers these architectures are interesting, when applied to profit-driven cloud services they are game changing. Amazon's recently announced DynamoDB service is an early instantiation of this extended innovation sequence where component level technologies (SSD), enable new architectures that drive new services. Fortunately for the end-customers, the economics of flash are only getting better from here. Now is it up to the storage industry to innovate on top of this medium, delivering next generation systems that can extend the reach of cloud hosted services to an even wider range of application workloads.

-Dave Cahill, Director of Strategic Alliances

-Dave Wright, Founder & CEO

Cloud-based systems have invented solutions to ensure fairness and present their customers with uniform performance, so that no burst load from any customer should adversely impact others. This is a great approach and makes for many happy customers, but often does not give a single customer the ability to ask for higher throughput if they need it.

As satisfied as engineers can be with the simplicity of cloud-based solutions, they would love to specify the request throughput they need and let the system reconfigure itself to meet their requirements. Without this ability, engineers often have to carefully manage caching systems to ensure they can achieve low-latency and predictable performance as their workloads scale. This introduces complexity that takes away some of the simplicity of using cloud-based solutions.

The number of applications that need this type of performance predictability is increasing: online gaming, social graphs applications, online advertising, and real-time analytics to name a few. AWS customers are building increasingly sophisticated applications that could benefit from a database that can give them fast, predictable performance that exactly matches their needs.

Looking under the covers a bit further here there are two really interesting enabling components of the DynamoDB service that deserve highlighting:

1. All-SSD- the service is deployed using 100% SSDs to provide consistent high performance at a very large scale. This is notable in that it is AWS' first use of SSDs in their cloud architecture.
2. Guaranteed Throughput - The DynamoDB service includes a concept called "Provisioned Throughout". This is essentially a guaranteed QoS model, where a customer can purchase reserved capacity (measured in queries per second), rather than paying for the actual queries run. Applied to a storage service, this would be akin to paying based on guaranteed IOPS. Currently Amazon EBS's current pricing model is based on actual IO operations with no guaranteed throughput or latency.

Amazon DynamoDB is a strong endorsement of several of SolidFire's key principals. The first being that the cloud needs Solid-State Drives (SSD) to adequately support the evolving performance demands of multi-tenant storage. The second is the idea that as more of these performance-sensitive applications make their way to the cloud there is a clear requirement for guaranteed QoS controls that can dynamically support performance requirements at a much more granular level. Finally, and building off the first two, is the validation that when armed with the enabling architecture to confidently and economically deliver performance-based services, service providers can stand-up cloud service offerings based on committed performance.

Amazon is a great indicator on the pulse and direction of the industry. The broader implications here for running performance sensitive applications in a cloud environment are intriguing to think about. Here at SolidFire, the continued innovations around the enabling architectures required to make this a reality are what get us really excited.

-Dave Wright, Founder & CEO

-Dave Wright, Founder & CEO

-Dave Wright, Founder & CEO

• Ability to Provide Predictable Performance
• Massive Scale
• Multi-Tenancy
• Lack of Application-level visibility

Individually, each of these factors impose unique pressures on the IT environment. Taken together, they demand an entirely new approach. Deeply understanding the architectural implications of these collective burdens provides a more constructive lens from which to assess the viability of one solution versus another in a cloud-scale setting.

A frequently debated topic that highlights the importance of evaluating customer requirements from a more holistic viewpoint is that of automated storage tiering. Originally blogging on the topic back in July, we have continued to evolve our thinking on the topic and I would like to introduce a blog series in which we cover our view on tiering at length. 

Talk to any IT manager about how they are keeping up with performance demands and you will increasingly hear talk about resorting to unpredictable and resource intensive band-aids like tiering. In a controlled single system environment the dynamic tiering of data between SSD and SATA drives would seem to make sense. Unfortunately, the economics of these more tactical approaches, while viable in smaller topologies, start to break down under the burdens imposed in a cloud environment.

Once you introduce the elements of multi-tenancy, multiple applications, and the need to scale across multiple systems, a tiered approach exposes CSP customers to "all or nothing" performance disparity. Working around the unpredictable nature of this setup requires human intervention eroding the proposed cost benefits of the automated tiering value proposition. When evaluated against criteria above, the shortcomings of an automated tiering approach start to become very clear. Cloud service providers are forced to seek out alternative solutions that are better aligned with both the performance controls required in a multi-tenant cloud environment, and the efficiency mandated by the hyper-competitive nature of the cloud services market.

There is little debate that Quality of Service (QoS) is a key competitive differentiator for CSPs.  Consequently, they cannot afford to gamble with the performance variability inherent to a tiering or cache-based solution. The manual intervention required to tune and optimize these architectures on an ongoing basis is the antithesis of a profitable cloud-scale management model.  Coming out of the holiday break we will further explore storage tiering in even greater detail.  We will look at the differences between capacity and performance tiering, dive into the true economics of tiered solutions, and hash out the merits of local versus global deduplication. As always, please provide your feedback here on our blog.  We look forward to the conversation.

Happy and safe holidays to everyone and we look forward to seeing you in 2012.

-Dave Wright, Founder & CEO

-Jay Prassl, VP of Marketing

To wrap up our VMworld video series hosted by Silicon Angle TV, I sat down with Virtustream's Matt Theurer and Softlayer's Duke Skarda to discuss as a group, some of the challenges faced by cloud service providers. This conversation focuses largely around the barriers that these two companies face with traditional storage systems in the cloud, and the opportunities that flash storage presents.

For both companies, the use of all-SSD based technologies is changing the way they think about storage, and how they approach resolving the gap between server and storage performance.  Matt discusses how SSD technology has inverted the capacity / performance imbalance that has existed for many years and how capacity will soon be the limiting factor within cloud storage architectures; a much easier metric to manage.  Duke explaines how block storage is a fundamental building block of cloud infrastructure, and traditionally the most problematic part to deal with.

I also got a bit of airtime to talk about the history of SolidFire and how my experience at Rackspace, and evaluating how traditional storage is used within the cloud, both helped me shape the technology of SolidFire and the market focus of the company.  It is important to keep in mind that SSDs do not constitute a different approach to storage.  SSDs are just part of the system.  How that system is architected, the functionality designed around the SSDs, and deep knowledge of your customer and their key feature-set, are all required when delivering a next generation storage solution. 

Many thanks to Matt and Duke for sharing their views on performance storage in the cloud, and to Silicon Angle TV for hosting us!

-Dave Wright, Founder & CEO 

At VMworld earlier this fall Matt Theurer, SVP of Solutions Architecture and Rodney Rodgers, Chairman and CEO of Virtustream took some time to sit down with the folks SiliconAngle TV to discuss some of the challenges that cloud service providers are facing.  During their discussion they talked about the specifics of their business and their focus on enabling high performance applications like SAP within their shared infrastructure.  Key to their success in this space has been their ability to carve up compute, networking and IOPS and bundle them into what they call an "infrastructure unit".  Customers can combine as many IUs as needed to meet their requirements, and this enables Virtustream to provide some of the most comprehensive SLAs in the industry.

Matt takes the conversation a bit deeper discussing some of the more granular performance challenges posed by traditional spinning media.  He discusses how the ability to guarantee storage performance would allow them to be even more exacting in their SLAs and raise their overall efficiency.  At SolidFire, one of our primary goals is to enable cloud service providers to allocate storage performance as easily as they allocate storage capacity; and to do so for thousands of volumes within a shared infrastructure.  This capability allows companies like Virtustream to wrap SLAs around exact performance metrics and maintain customer performance expectations regardless of the activity within the system.

-Jay Prassl, VP of Sales & Marketing

Nathan Day and Duke Skarda of SoftLayer were kind enough to talk with the guys from Silicon Angle/Wikibon.org on the Cube at this years VMworld. During their discussion they touched on a major challenge that many cloud service providers are dealing with today… storage performance.   One of the points that was brought up was fine grain control on Quality of Service. They referred to "per volume" or "per account" control as storage nirvana. At SolidFire, our architecture was designed from the ground up with this in mind. The ability to guarantee consistent QoS to thousands of applications and thousands of customers is how SolidFire is making storage nirvana a reality.

-Adam Carter, Director of Product Management

-Dave Wright, Founder & CEO

-Adam Carter, Director of Product Management

-Dave Wright, Founder & CEO

-Adam Carter, Director of Product Management

There are certainly advantages to server-side SSD caching. Most notably, it reduces load on storage arrays that are being taxed far beyond what they were originally designed for. However, in the long run I think we'll see server-side SSD caching as nothing but a complex stopgap making up for deficiencies in current array designs.

If you look at "why" it's claimed server-side cache is necessary, it basically boils down to:

-The array can't handle all the IO load from the servers, particularly when flash is used with advanced features like dedupe

-The reduction in latency from a local flash cache

The first is a clear indication that current array designs aren't going to scale to cloud-workloads and all (or mostly all) solid state storage levels of performance. Scale-out architectures are going to be required to deliver the controller performance needed to really benefit from flash.

The second is based on the assumption that the network or network stack itself is responsible for the 5-10ms of latency that he's reporting. The reality is that a 10G or FC storage network and network stack will introduce well under 1ms of latency - the bulk of the latency is coming from the controller and the media. Fix the controller issues and put in all-SSD media, and suddenly network storage doesn't seem so "slow". Architectures designed for SSD like TMS, Violin, and SolidFire have proven this. Local flash, particularly PCI-attached, will still be lower latency, but that micro-second performance is really only needed for a small number of applications.

EMC and Netapp have huge investments in their current architectures, and are going to try every trick they can to keep them relevant as flash becomes more and more dominant in primary storage, but eventually architectures designed for flash from the start will win out.

-Dave Wright, Founder & CEO  

To be sure, on the surface the concept of automated tiering sounds great - your hot data goes in fast SSD storage, while seldom accessed data is on cheap spinning disk.  The problem with this type of optimization is that it is executed from a global perspective across the entire storage system.  The storage array optimizes the IO load across all of the data it controls. If you only have a single application, or perhaps a small number of applications running on your storage array, this global optimization probably works pretty well.

That's a good fit for a traditional enterprise SAN deployment, but consider a cloud environment where you have hundreds or thousands of virtual machines and applications, with new applications coming and going all the time. From the perspective of an individual application, storage performance can be radically unpredictable. One day, the array may decide the application's data is "hot" and serve it out of SSD with < 1ms response time, the next day another hot application may come online and suddenly response times jump to 10ms as the data gets pushed out to a SAS or SATA tier. This type of unpredictability is especially problematic in a multi-tenant service provider environment, where customers aren't aware of each other and any radical change in performance is likely to trigger a support call. It's not the storage array's fault - it's still trying to globally optimize, but try telling that to a customer whose website or database is suddenly slow.

So if tiering isn't the answer, what is? Simply putting all the data on SSDs helps, but doesn't take advantage of the fact that some applications and data are actually more active than others, and there is a hesitance to "waste" SSD performance on less active data. At SolidFire, we think the answer to these issues is performance virtualization. SolidFire's unique performance virtualization technology de-couples capacity from performance and allows service providers and their customers to dial in the exact performance required for each application. Have a lot of data that doesn't need much performance? No problem, those IOPS aren't wasted - they're simply available for other more demanding applications on the storage cluster. Either way, you get the performance you expect day after day, without any surprises, and if you need more or less, you can change it instantly. Skip the data tiering stopgap and get an all solid-state solution that can optimize performance across thousands of applications.

-Dave Wright, Founder & CEO

-Jay Prassl, VP of Sales & Marketing

• Is it really possible to build an all-SSD storage system that scales to petabytes of capacity and millions of IOPS?
• Can that performance and scalability be achieved at a price per gigabyte similar to disk?
• Can you really guarantee IOPS to thousands of individual volumes and put an SLA around storage performance?
• Can efficiency technologies like deduplication and compression actually be built to run in real-time without affecting performance?

We certainly think so, having built the first storage system that can do all this and more. If you'd like to find out how, come talk with us and see what SolidFire can do for you.

-Dave Wright, Founder & CEO

Founder and CEO Dave Wright explains why traditional storage just doesn't work at cloud scale.

-Dave Wright, Founder & CEO

-Dave Wright, Founder & CEO

-Dave Wright, Founder & CEO

By historical standards, solid state storage is now amazingly inexpensive. The myth that flash is expensive is propagated by enterprise storage vendors selling flash modules for $25-$50/GB or more. The performance benefits of flash allows customers to justify the ridiculous price, but also limits their use of flash to only the most critical, most performance sensitive applications.

The reality of the situation is that flash chip prices have been on a dramatic decline over the last 5 years, dropping in price by 50% or more a year as demand increases and process sizes shrink. Spot prices for MLC flash are now around $1-$1.25/GB, and high-capacity MLC SSDs can now be had for under $2/GB. Of course, most enterprise storage vendors aren't using MLC. The limitations of their architecture often don't allow it. However an architecture designed from the ground up around SSDs, balancing use of SLC and MLC technologies, is a different story.

In comparison to Enterprise SATA drives which sell for $0.15/GB, $1/GB for flash may still seem expensive. For applications where capacity is the only concern, that's certainly true, and will continue to be the case for many years. However for primary storage applications, those that require even a modest number of IOPS, a comparison to SATA drives does not make much sense.  A better comparison with flash would be 10K & 15K SAS drives, or even complex tiered solutions that use SSD, SAS, and SATA.  With 15K SAS drives at $1/GB or more, flash is not far from closing the gap.

For SolidFire however, the really exciting part is what happens when you combine the falling price of solid state storage with efficiency technology that dramatically increases effective capacity and requires a fraction of the power, cooling, and space of spinning disk. Suddenly spinning rust doesn't look so cheap after all, does it?

-Dave Wright, Founder & CEO

-Adam Carter, Director of Product Management

-Dave Wright, Founder & CEO