The traditional storage market has settled into several distinct streams.  On the high end is the EMC approach which is to build very complex storage systems with multiple redundant hardware plus many configuration options and features.  This very expensive approach works for enterprises that really need fast reliable storage and have the budget to justify the investment.  At the low end of the spectrum, there are lots of options for small storage pools — half a petabyte or so – which are generally sold through channels.  The prices for these systems have remained relatively stable at the $1 million for a petabyte range.

For companies that want massive amounts (15 petabytes or more) of cheap storage or a horizontally scalable cloud type architecture, the options have been limited to a few vendors or for the technologically adventurous, a roll your own system.  All this is happening despite the fact that there are now three hard disk manufacturers left, a de facto monopoly, and most users treat hard drives as interchangeable commodities with excessively high failure rates that require massive amounts of duplication.  Any vendor that can demonstrate a system that reduces the need for three data copies to maintain integrity by improving the failure rate from the current 10-15% a year, would deliver a big win for everyone.

As the cloud storage business grows the traditional vertically scalable storage is less and less viable.  There are several companies that are already working on building horizontally scalable storage, Scality and CloudBytes are two that come to mind.  There are also several Open Source projects like Openstack Swift that are taking on the large data store architecture problem as well.  Not all the cloud storage vendors are using a pooled block of storage approach.  ScaleIO turns all the disks in the servers into a pool of storage.  This radically different approach is dependent on the right use case and could have network bottleneck issues. The newer horizontally scaled cloudy architectures, such as Mezeo and Openstack Swift have finally opened up the possibility of building attractively priced massive data pools.

The biggest innovation of late is the incorporation of SSD technology.  Amazon is already offering an all SSD cloud storage service and a number of new storage vendors, such as SolidFire are building SSD only storage systems from the ground up.  SolidFire isn’t the first vendor with an SSD offering, Nimbus Data began selling all-SSD systems more than a year ago. EMC jumped in with a Symmetrix with all SSDs this summer, and others are expected to follow shortly. Texas Memory Systems, Avere, Violin Memory and Alacritech, have all-SSD systems designed to speed SAN and NAS performance for internal storage solutions.  Most storage vendors now give customers the option of installing some SSD alongside hard drives in their systems. In the long run, this is just an interim step as SSD prices will continue to fall over the next few years.  The future is a move to all SSD units coming to a data center near you.

It is good to see innovation coming back in the storage industry after years of slack.  Expect to see more hardware innovation as SSD technology becomes the standard for fast reliable cloud storage and new systems take advantage of more reliable hard disk hardware and continued rise in data densities.  My crystal ball says that we might see a repeat of the massive changes that occurred in the 1990’s as smaller disks rapidly swept away all the incumbent vendors who were focused on their established large customers.  Watch your back EMC…

About the Author

Beth Cohen, Cloud Technology Partners, Inc.  Transforming Businesses with Cloud Solutions

Forrester forecasts the SaaS global market will grow from $25.5 billion in 2011 to $159.3 billion in 2020.  With those numbers, there is no question that SaaS applications in the enterprise are here to stay.  The plethora of new SaaS (Software as a Service) offerings can be extremely tempting to business managers who are told they can have a functioning system in just a few days, not the three months that IT is promising.  Of course the reality is quite different, but the biggest challenge is that since business unit decision makers, not technology leaders, are bringing these applications into the enterprise, they do not have a clear understanding of where they fit in the enterprise big picture.  It is not uncommon to find an enterprise that already has a well established and functioning corporate CRM system, has two, three or more rogue SaaS CRM applications lurking out in different marketing or sales departments throughout the organization.

Handled correctly within the IT framework, SaaS applications can significantly increase agility and competitiveness.  However, like any powerful tool, handled incorrectly they can be a ticking time bomb.    While there is nothing inherently wrong with having SaaS applications out at the edges of the organization, having multiple stealth application outside of the control of IT is at the very least inefficient and at the worse represent a serious threat to the security of the organization as a whole.  The main issues boil down to the usual suspects:  business, technical, operational and security (which includes data integrity).  The following are some of the common problems encountered with “ad hoc” SaaS implementations:

• Technical Issues
  • One off” data models that are inconsistent with enterprise standards
  • Poor or missing integration with existing enterprise applications
• Business Issues
  • Contract issues related to SaaS applications that didn’t deliver the promised functionality
  • Poor performance and SLA issues related to up-time, data loss, or service requests
  • Vendor lock in, application, data and/or contract
• Operational Issues
  • Lack of appropriate DR/BC functionality
  • Unclear ownership of support or lack of internal, third party and vendor support services
• Security Issues
  • Privacy, Security problems, access management, information security, and compliance
  • Unclear or missing Identity Access Management (IAM) – No SSO strategy or federated ID management system in place

The headaches caused by these rogue applications can be endless, but the trick is to first learn what the scope of the problem is.  Once it is clear how many SaaS applications are out there, the next step is to spend some time to understand what is driving the business units to install them in the first place.  In some ways that is half the battle, because once that has been determined, then the final step is to develop a SaaS governance process to allow business units to leverage the value of the SaaS approach, but also maintain the integration and oversight that staying under the IT organizational umbrella brings.

About the Author

Beth Cohen, Cloud Technology Partners, Inc. Moving companies’ IT services into the cloud the right way, the first time!

One of the primary goals of a disaster recovery (DR) plan is to protect business data.  The RTO (recovery time objective) component is often the most time consuming part of a DR plan.  The objective is to shorten the recovery task as much as possible while maintaining trust in your data so that the business can recommence regular operations quickly.  Since the complexity of many applications leave far too many places for bad data to hide, the following recommendations will help speed the recovery process.

Disaster Recovery Preparation

• Implement the fastest replication to your DR site that budget and technology allow. The best option to minimize data loss is synchronous replication of your business critical data to a remote backup site. This ensures full data integrity because the replication logs will record data currency while the transactions are copied to both sites simultaneously.
• The next best option is an asynchronous replication scheme. Even if the delay is measured in minutes or based on periodic file copies, you will still be more prone to some known level of data loss. However, since this option is considerably less expensive, the business owners might decide that the reduced costs will offset the increased risk of data lose. Make sure that everyone understands the impact of data loss on the business recovery process. This includes establishing data loss tolerances, and identifying likely types of data loss during the development of the DR plan.
• Copy verifying data to your DR site along with the primary data. This means finding supporting data from outside the application that corroborates your database. This might include data input forms, activity logs, emails, checksums, or input files. Some of these may be paper-based and could be scanned or copied to the DR site.

Recovery Plan Preparation

• Assess the data at the DR site by knowing both its currency (i.e. how old it is, as precisely as possible) and its consistency across multiple applications. Currency is important because it will identify any lost transactions or updates, while consistency is important because incomplete transactions can cause data corruption problems after you have resumed production.
• Review the replication logs for the last data transmission to establish currency.
• Compare verifying data at the DR site with the recovered data to follow specific transactions and identify the degree of data loss.
• Have the business application users access the data and determine if recent changes to production data are found in the recovered data.
• Execute a build acceptance test (BAT) like the ones used to verify application installation and integrity. These tests often point out data anomalies.
• Have a process and tools in place for tracking and resolving data problems after you return the applications to production.

The above recommendations may not identify all the issues, but they will go a long way toward meeting your RTOs and customer requirements, so that you will be able to start using the application while continuing the verification of the recovered data.

John McWilliams, JH McWilliams & Associates, Business Continuity Consultants