Cloud With Confidence
With >1 trillion objects stored in S3, Amazon has clearly led the way in the first wave of enterprise cloud adoption. Amazon and others have proven out that the cloud is viable for bursty and less performance sensitive applications (e.g. test/dev) along with startups looking to ramp IT without heavy capex. The rapid adoption of cloud computing for these use cases continues to prove they are well served by this type of infrastructure.
This market adoption profile is a close parallel to the early years of server virtualization technology. The initial use case for market leader VMware was very similar to what we are seeing in the cloud. However the larger market opportunity was always about getting users comfortable enough with server virtualization to run more demanding applications. With the introduction and maturation of the vCenter suite VMware enticed users to migrate more performance sensitive applications to virtual servers. Fast forward to today where production applications running in virtualized environments is commonplace.
Apply this trajectory to cloud adoption and the question becomes “what is needed for enterprise IT departments to confidently run more traditional applications in the cloud?” The answer: a greater degree of confidence that these applications will have access to predictable and consistent performance.
Cloud infrastructures today are not well suited to meet the performance and consistency requirements of most database-backed applications. This helps to explain why they are still for the most part run on-premise in a dedicated SAN. AWS’ James Hamilton summed up the unique challenge presented by I/O intensive workloads in his recent blog;
“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
| 0 comments
Posted in Other.