Granted, information about the company has been around for a while, including an article in the New York Times last fall describing how NTT, in the wake of the Tsunami disaster, has been able to effectively leverage Nicira to maintain availability in the midst of rolling data center blackouts.  According to Nicira, other large service providers are also enamored with this technology, citing AT&T, eBay and Rackspace as customers as well. Nicira also cites a large enterprise customer, Fidelity, among those that have adopted its technology.

Why have these very large and well known service providers selected to work with Nicira? Simply put, because Nicira is helping them solve a very large, and fairly well known problem – network complexity in rapidly scaling, highly dynamic virtual environments. My colleague Jon Oltsik  has defined this as Data Center Network Discontinuity. As organizations continue to consolidate data centers, drive increased use of server virtualization technology, and increase their ability to react more quickly to business needs, legacy network solutions will reach a breaking point. Something needs to change in order to drive new and sustainable growth.  Organizations will need to create a virtual network platform to fully abstract the physical layer from the logical one, instead of an even bigger maze of individual boxes.

OpenFlow and Software Defined Networking hold a lot of promise in this regard. Many companies, including HP and IBM/NEC, are leveraging this technology and have recently made some big announcements, while other companies like Arista, BigSwitch, and Juniper have been pursuing their own implementations. Nicira hopes its model will take network virtualization to a whole new level. By placing the intelligence in the virtual switch and leveraging an external controller, Nicira hopes to virtualize (and commoditize) the underlying physical network.

By taking this approach, Nicira proves that it has no hardware agenda and therefore organizations do not have to rip and replace any equipment. It can be deployed in conjunction with existing technology from any vendor. As the customer list suggests, large service providers with cloud environments will receive the most benefit, but those enterprises that have committed to and deployed their own private clouds could take advantage of this technology as well, like Fidelity has done. As more enterprises consolidate data centers and mature their server virtualization environments, I would expect to see more enterprise logos pop up on its website, if the technology works as advertised with its initial customers.

You can read Bob’s other blog entries at Data Center Continuum.

But there is a lot more to using virtualization in this way than meets the eye. Data management and system design challenges, financial constraints, and governmentwide policies about the future of data centers will all influence the options agencies have for using virtualization as a price-slashing business continuity tool. The opportunity is big, but IT executives are going to have to roll up their sleeves to make it happen.

via New options for never-say-die IT — Federal Computer Week.

Background

While IT priorities and challenges are often considered with data centers and other centralized corporate resources in mind, it is important to remember that organizations often have distributed locations that have significant and complex computing requirements. In fact, typical IT challenges are often exacerbated in these remote/branch offices due to distance and lack of onsite IT staff. ESG research found that companies face significant challenges when it comes to delivering applications over the WAN from a central location to employees at branch office locations. According to a recent ESG survey,^[1] nearly half of respondents identified improving application performance for end-users as a key initiative (see Figure 1). Improvements to application accessibility and better collaboration capabilities were also high on the list.

Riverbed Steelhead EX + Granite Overview

Riverbed Technology’s Steelhead product family is designed to provide increased application performance and data transfer speeds over the WAN. Steelhead products address four main solution areas.

• Application Acceleration—Steelhead optimizes both TCP and UDP traffic, addresses application-specific latency, delivers LAN-like performance and availability over the WAN, and enables improved collaboration, file sharing, and productivity for distributed enterprises.
• Bandwidth Optimization—enables network managers to achieve better utilization of existing WAN bandwidth by eliminating redundant WAN traffic.
• IT Infrastructure Consolidation—enables consolidation of IT infrastructure from remote offices to a centrally located facility, maintaining performance, availability, and security, as well as reducing capital expenditure and management costs.
• Backup & Replication Acceleration—enables quick and secure backup and replication from branch locations.

The Riverbed Steelhead family of products is designed to optimize WAN traffic between distributed remote and branch office locations and a central data center. Steelhead appliances run the Riverbed Optimization System (RiOS), which is the software platform that enables data-, protocol-, and application-level WAN optimization and allows a central office to consolidate the majority of its remote office server infrastructure, taking the first step toward true infrastructure consolidation. Riverbed Steelhead EX combines WAN optimization capabilities with VMware on the appliance, enabling a branch to virtualize local servers and minimize the bandwidth required by users and applications.

Granite was developed by Riverbed to deliver edge virtual server infrastructure that extends an enterprise storage area network (SAN) out to remote offices. It enables organizations to centralize and consolidate branch office storage at a primary data center. Steelhead EX + Granite combines Riverbed Steelhead and Granite software capabilities with the goal of serving write-intensive and custom applications in the branch with a global storage infrastructure projected from the data center, eliminating storage at remote branch offices previously considered too difficult to consolidate.

ESG Lab Validation

ESG Lab performed hands-on evaluation and testing of the Riverbed Steelhead EX + Granite WAN optimization and storage consolidation appliance at a Riverbed facility in San Francisco, California. Testing was designed to demonstrate how Steelhead EX + Granite improves application performance and availability, as well as delivers infrastructure consolidation and data security for branch locations in a distributed enterprise.

Getting Started with WAN Optimization

Steelhead appliances at remote locations, along with Steelhead Mobile software on remote user laptops, work together with one or more Steelhead appliances in the corporate data center to optimize traffic flowing over the WAN. Riverbed addresses three areas that affect WAN efficiency: application chattiness, data redundancy, and transport protocol inefficiency.

To speed application performance, application-specific optimizations complete transactions locally in the branch on behalf of servers in the data center, eliminating the need to wait for application responses over a WAN connection. To reduce the amount of data sent over a WAN, Steelhead appliances and software intercept and inspect WAN data to determine whether the data or a portion of it has been seen before. When a user attempts to access data already encountered by the local Steelhead datastore, the data is served locally, eliminating the delay of pulling data over the WAN. With this capability, Steelhead appliances allow users and applications to read and manipulate data, while only requesting or sending unique blocks across the WAN. To overcome transport protocol limitations, Steelhead appliances more intelligently scale and pack TCP payloads, significantly reducing round trips and more efficiently transmitting data across the WAN.

Figure 4 shows the test bed used by ESG Lab, which consisted of a simulated data center and remote office. A Network Nightmare WAN simulation device was used to limit bandwidth and inject latency, simulating a transcontinental T1 link. The data center was configured with one NetApp FAS 2050 connected to both Steelhead and Granite core appliances. The remote office had a Steelhead EX + Granite appliance running Steelhead WAN optimization software, Granite block-storage acceleration, and the Riverbed VSP. The connection between the two environments was limited to 1.5 Mbps (T1 equivalent) and had 100 milliseconds of round-trip latency injected to simulate a remote office connecting to a data center up to 3,000 miles away.

ESG Lab Testing

For the first round of tests, Steelhead WAN optimization was used to optimize typical knowledge worker operating tasks. Data reduction and optimization-related metrics were captured using the Steelhead management console as well as wall-clock timing of certain operations. As shown in Figure 5, simple file transfers, Microsoft Exchange messages with attachments, and Microsoft SharePoint transaction performance were measured with and without Riverbed Steelhead WAN optimization enabled. The corresponding results show performance improvements of anywhere from 5X to 50X, depending on the type of transaction.

The data in Table 1 includes the sizes of the objects used in performance testing and the number of seconds to completely execute each operation. The largest time reduction was seen with the transfer of a 65.3 MB file from a remote client to the corporate file server.

Consolidation of Branch Services

Organizations are using server virtualization to simplify their IT infrastructures while reducing costs in their data centers through consolidation. For services required in branch offices, consolidation (minimizing infrastructure in the branches) is also a key goal. However, organizations are faced with a challenge in that certain applications require local compute and storage resources to meet performance requirements for end-users. Steelhead EX features the Riverbed Virtual Services Platform (VSP) that incorporates VMware virtualization technology to consolidate branch servers and applications onto the Steelhead EX appliance.

ESG Lab Testing

ESG Lab began testing the ease of consolidating branch office services and applications using Riverbed Steelhead + Granite technology by simulating the user experience of moving from a traditional branch office with dedicated servers, applications, and local storage to a virtualized Riverbed WAN-optimized and consolidated model, as illustrated in Figure 6.

ESG Lab first virtualized a Microsoft Windows Server 2008 system in the remote location by installing the VM onto the Riverbed VSP. This is accomplished via the Steelhead management interface. The Steelhead EX + Granite appliance can host up to five end-user virtual machines. ESG Lab connected to the Steelhead EX + Granite appliance through the Riverbed Steelhead Management Console to install the virtual server as shown in Figure 7.

Once the virtual machine was loaded and running, ESG Lab simulated a Microsoft SQL server workload using the Iometer load generation utility. SQL Server is an application that, due to the response-time sensitivity of transactional databases, is often hosted on physical servers with local storage in a branch office. In this test, a 4 KB block size was used with a 67% read, 100% random access pattern.

Figure 8 shows the Iometer results displayed during the test. The most important metric to note here is “Average I/O Response Time (ms).” While the back-end connection to the storage array was over a simulated T1 connection with 100 ms of round-trip latency, Iometer reports only 31 milliseconds of latency to disk because data is being written to the local Steelhead blockstore.

It’s important to note here that without Steelhead EX + Granite, ESG Lab was unable to obtain a usable result due to the restricted bandwidth and high latency of the WAN link. In fact, the connection to the LUN in the data center timed out, and the mount failed.

Consolidating Branch Office Storage

Riverbed Granite extends iSCSI block storage from the data center to the remote site in a way that is transparent to users and applications, and that takes advantage of Riverbed Steelhead WAN optimization technology. Granite enables organizations to maintain local servers at branch offices while actually storing and protecting their data within their data centers. Riverbed VSP provides the ability to host those servers directly on the Steelhead EX appliance.

ESG Lab Testing

ESG Lab tested Granite by mounting iSCSI LUNs from the data center on physical branch server nodes as well as within the virtual machines hosted in the Steelhead EX + Granite appliance. To verify the challenge of accessing “unoptimized” iSCSI storage over the WAN, ESG Lab first attempted to mount an iSCSI LUN directly from a traditional branch server to a data center SAN without Granite, and observed that the connection timed out and the mount failed.

Next, ESG Lab tested whether Riverbed Granite could allow the use of iSCSI over the WAN by configuring Granite appliances in both a data center and a remote office location. Figure 9 shows the basic functional design of storage extended with Granite. In effect, there are two iSCSI connections (working from right to left):

• Within the data center (right), between the actual iSCSI SAN target to the Granite core iSCSI initiator.
• Within the remote site (left), between the production server iSCSI initiator to the Steelhead EX + Granite iSCSI target.

Using the same branch server, ESG Lab was able to successfully mount with no errors or timeouts the same iSCSI LUN that had previously failed to mount in the “unoptimized” test.

The combination of Granite with Steelhead WAN optimization makes it possible for a data center LUN to be successfully mounted by a remote office production server—either a physical server located in the branch or one that is virtually hosted within the Riverbed VSP hypervisor.

Next, ESG Lab examined performance and usability. For this test, ESG Lab (working right to left in Figure 9):

1. Configured multiple LUNs within the data center SAN, which is completely unaware of the Steelhead EX + Granite extended storage scenario.
2. Configured the Granite core iSCSI initiator to mount the LUNs that are to be extended.
3. Assigned a specific Steelhead EX + Granite edge device from the Granite core at the data center to extend each LUN. By doing so, the Steelhead EX + Granite device became an iSCSI target and offered the LUN to devices within the remote site.
4. Connected the LUN to the production Windows server using its iSCSI initiator, with the server being completely unaware that the LUN is not within the remote site but actually extended from the data center.

From there, the LUN behaved like any other iSCSI-attached device and could be mounted and utilized. A common concern about remote storage is that the latency associated with initial use or access requests will have an impact on the end-user experience. To observe the behavior, ESG Lab configured an extended LUN within Steelhead EX + Granite that contained a known data set and requested various randomly selected files.

Figure 10 shows the Steelhead EX + Granite Blockstore Metrics report, which measures the amount of “hits” (requested blocks that were already available at the branch) and “misses” (blocks that needed to be sent from the data center) in megabytes. This, in effect, measures the effectiveness of the Granite technology to pre-fetch and/or quickly transmit the necessary blocks, such that the branch server experiences the storage as though it is local.

ESG Lab used AutoCAD software to open a 33.5 MB file (cifs.dwg). The first time the file was accessed across the WAN, the file-open process took 27.7 seconds. The file was closed and the workstation was rebooted to clear client cache. When the workstation was restarted, the same file was opened using AutoCAD, and the file opened in 5 seconds, the same as baseline testing over the LAN.

While Figure 10 shows the Granite technology’s effectiveness in pulling data from the data center to the branch, Figure 11 shows the behavior of data written at the branch being committed to the data center.

• The dark blue line tracks the amount of data being written to the Granite blockstore.
• The light blue areas show data received but not yet written back to the data center storage array, implying minimal latency in transmitting those blocks to the data center.
• The grey areas show data that has been committed to the data center.

Overall, ESG Lab found the Riverbed Granite extended storage solution to be surprisingly easy to configure and utilize. Neither the production server at the remote site nor the data center SAN felt any impact from the extended distance. The iSCSI implementation was intuitive and performed well over a simulated 3,000-mile WAN connection. The combination of Granite with Steelhead technology dramatically accelerated data transfers over low-bandwidth, high-latency connections.

Remote Office Scenarios and Implications

After the servers were virtualized and the SAN storage was extended from the central data center, ESG Lab was ready to explore the performance and resilience of a Riverbed-enhanced remote office when a WAN link goes down and is restored.

ESG Lab Testing

First, ESG Lab set a baseline by opening several large files that resided on an extended iSCSI SAN volume shared on the remote office LAN by a virtual server hosted in the Steelhead EX + Granite appliance without Granite acceleration. ESG Lab opened a 39.4 MB AutoCAD file named “http.dwg” using a client on the remote office LAN. Without Steelhead and Granite optimization, the file opened in 721 seconds, or just over 12 minutes. The AutoCAD application was completely unresponsive while the file was pulled across the WAN.

Next, the same file-open test was performed with Steelhead WAN optimization and Granite active. The first time the file was accessed, the operation completed in 39.1 seconds. After closing the file and opening it a second time, the file opened in 5.0 seconds. As expected, the second open was much faster, being serviced by the blockstore cache on the Steelhead EX + Granite appliance. Saving the file to a new name took 3.1 seconds.

As seen in Figure 12, at 18:07, ESG Lab disconnected the simulated WAN between the remote office and data center, and attempted to open the same file. The file opened successfully, in 5.6 seconds. Next, the file was saved to a new name, which completed in 3.1 seconds. This is comparable to the performance observed when the WAN was connected.

ESG Lab repeated these procedures multiple times, opening files and saving them to new names. Performance was consistent. Figure 12 shows the data writes/commits report from the Steelhead EX appliance.

As shown in Figure 12, as data was written to the network share, the uncommitted bytes that had been accepted by the Steelhead appliance but not yet transmitted to the data center increased. Note that the entire time that the volume was disconnected, the client and server at the remote site remained connected, and the volume remained online.

After approximately 30 minutes, more than 40 MB had been written to the shared volume. ESG Lab then reconnected the WAN and monitored the data writes/commits report. As can be seen in Figure 13, the Steelhead appliance committed the 43.6 MB of data to the NetApp FAS in the data center in about 45 seconds.

The resynchronization was automatic and completely transparent. Users and applications saw no change in connectivity or access when the WAN link was down, nor when it came back up. Figure 14 shows a network traffic summary report for the time period that the resynchronization was executing.

The port number indicates the type of traffic: Port 7951 is traffic flowing between the Steelhead EX + Granite edge device and Steelhead and Granite core devices in the data center. The actual data transmitted across the WAN link was highly optimized, and, of the 43.9 MB of iSCSI data transmitted by the virtual server, only 3 MB was actually transmitted across the WAN, a reduction of 93%.

Data Protection Scenarios and Implications

When extending storage from the data center to the remote office, data protection becomes multifaceted, incorporating not only backup and recovery of production data, but also protection of remote office data from loss or theft.

Securing Data in the Appliance

Riverbed appliances utilize integrated storage to hold cached data in remote locations, designed to enhance the remote user’s experience by providing local access to frequently used data. The Riverbed Steelhead + Granite appliance offers AES encryption (up to and including AES-256) to securely encrypt the data on disk. The AES key for the Granite blockstore is kept in a secure vault area, which is also encrypted using AES-256.

The default key to each appliance vault is unique, derived from a unique identifier of each appliance. The vault key can be changed by organizations to comply with their own security standards. When an appliance boots, the vault key must be provided, or the contents of the blockstore are not accessible. A visual representation of Riverbed encryption is shown in Figure 15.

Backup and Recovery

When considering backup and recovery, multiple data protection scenarios are either enabled or enhanced, including:

• File/application-based protection of the remote data, from the data center
• Block-based protection of the LUNs used by the branch platforms, from the data center

In principle, because server-centric storage utilized at the branch is in fact extended from the data center via Granite (and user-centric data from the branch is stored locally on Granite-extended volumes), Riverbed suggests that data protection can be done entirely from the data center instance of the data.

ESG Lab audited the operating methods that Riverbed uses for storing its data to understand the viability for customers to use their current data-protection methods within a Steelhead EX + Granite deployed configuration.

Traditional File/Application Backups from Guest-VM Branch Servers

For production servers running at the branch, presumably as virtual machines within the Steelhead EX + Granite (VMware Virtual Server) host environment, traditional file- and/or application-centric backups are still achievable.

ESG Lab looked at how a typical backup agent can be installed within a virtualized production OS to send backup data to the requesting backup server located at the data center, as shown in Figure 16. In this configuration, as files are queued to be sent from the production VM to the backup server, Steelhead WAN optimization is designed to recognize the data that already exists at the data center from previous synchronizations. In this case, while both the remote backup agent and the data center backup server believe that the data is being sent across the WAN, only truly unique data segments and reference “pointers” to previously encountered data actually traverse the network.

Based on how ESG Lab tested file transfers with Steelhead EX + Granite, file-centric data movement during backups should be nearly eliminated. Similarly, application-centric backups that generate storage IO as part of the backup process (such as SQL Server log files) will benefit. In those cases, as the data files are prepared for backup, their corresponding blocks within Granite will be committed to the data center and therefore may not need to traverse the WAN during the actual backup.

SAN-based Backup of the Branch from the Data Center

Perhaps the most intuitive and yet subtle method ESG Lab observed was the ability to back up the extended LUN from within the data center. Because the SAN is unaware of the Steelhead/Granite solution, LUNs can be backed up directly using storage-based snapshots and clones—traditional “serverless” backup solutions.

As seen in Figure 17, ESG Lab observed that by backing up the original LUNs from the SAN, all of the production data could be protected in the data center, including virtualized server-centric data and client-specific data that are Granite-extended.

As shown in Figure 17, ESG Lab found serverless backups of remote office volumes to be potentially ideal choices for those customers who already utilize them within their data centers. The IO burden is removed not only from the production resources, but also from the Steelhead and Granite appliances, freeing them up for production IO exclusively. Like any serverless backup, an understanding of the applications in use and the need for consistency and post-backup processing are keys to success.

Riverbed SAN Hardware Snapshot Integration

Along with extending and potentially enhancing customers’ existing backup methodologies, Riverbed has also developed a Riverbed Hardware Snapshot Provider (RHSP) mechanism to directly integrate its storage-extending capabilities with both the Microsoft Volume Shadow Copy Service (VSS) and SAN arrays from EMC, Dell EqualLogic, and NetApp.

Although RHSP was not tested by ESG Lab, a discussion with Riverbed highlighted RHSP capabilities that directly address the need for application consistency with backup. RHSP installs as a plug-in on Windows clients in the branch office. It is used within the VSS process to place a point-in-time marker into the Granite blockstore. This enables a backup agent to quiesce an application to indicate an application-consistent restore point. In turn, this indicator triggers a snapshot on the data center SAN storage array that can then be used for any required restores or subsequent secondary backups to disk or tape in the data center.

ESG Lab Validation Highlights

• ESG Lab used Steelhead appliances to optimize WAN performance and reduced data by up to 50 times, enabling more productive collaboration between remote and central offices.
• When running an OLTP database workload in a Riverbed appliance-hosted virtual machine, ESG Lab observed latency to storage over the WAN decreased by more than 67%, enabling a remote server to mount an iSCSI volume hosted in a distant data center, and making it possible to consolidate business-critical branch services over the WAN.
• ESG Lab found Granite-extended block-storage performance over a simulated transcontinental WAN link to be remarkably viable, rivaling local-attached storage in both throughput and latency.
• ESG Lab validated that Riverbed improved performance by a factor of 18 to 26 times when opening and editing large CAD files across a high-latency, low-bandwidth T1 link, providing WAN access to centralized project files at LAN-like speeds.
• ESG found that customers’ existing backup methodologies were all potentially viable options for remote offices—in ways not achievable without the combination of WAN optimization and storage extension. Without changing their backup mechanisms, customers may find their solutions enhanced because of how Steelhead optimizes the data streams that Granite has already synchronized between sites.

Issues to Consider

• It should be noted that one key to the performance of the extended storage is the built-in blockstore within the Steelhead EX + Granite appliance itself. When designing the storage to be used at the branch, customers should be aware that the Granite solution does not change normal design considerations around capacity or IO performance. Those aspects should still be considered when determining the size of the Granite edge device to place at a particular branch location.
• While many data-protection scenarios are enhanced through this configuration, for SAN-based backup of the branch from the data center, a minimal amount of effort is still required to ensure the boot volumes of the virtualized VMs on VSP within each branch appliance are protected and recoverable. ESG Lab hopes that Riverbed will address this in future releases, so that even in the VSP scenario, an entire VM can be protected at the data center.
• While many backup processes may potentially gain benefit from a Riverbed Steelhead solution with Granite technology, they do so without any awareness of Riverbed’s changes to infrastructure or topology.

The Bigger Truth

Riverbed provides comprehensive WAN optimization solutions, helping organizations share applications and data across global wide-area networks. Riverbed WAN optimization solutions have been proven in the field to give businesses order-of-magnitude increases in the performance and value of their existing IT infrastructure and mission-critical applications, including file sharing, e-mail, backup, document management systems, IT tools, and ERP and CRM solutions.

Riverbed has applied its field-proven WAN optimization technology to provide similar performance gains for SAN-based block data extended to remote offices. Achieving a data reduction of more than 26 to 1 in ESG Lab testing, Steelhead Granite technology not only reduces the amount of bandwidth needed to connect to data center SAN storage, but also provides access to remote users at local speeds, maximizing the productivity of those remote workers. Steelhead EX + Granite also enables organizations to utilize existing investments in data protection hardware and software and secures that data in the data center.

In a truly fluid enterprise, all data and storage resources will be centralized in the data center. When that occurs, organizations will gain the ability to provide desired performance in the branch and the ability to quickly provision systems and storage wherever or whenever they wish. In addition, data protection becomes much easier and more secure for remote offices—it is executed centrally along with all valuable corporate data in the data center.

ESG Lab confirmed, through hands-on testing, that Riverbed’s Steelhead EX + Granite solution is able to reduce remote office network traffic while extending data center SANs with little impact on remote office servers and clients. The solution integrated well with Microsoft Exchange and SharePoint business applications as well as basic file system services and iSCSI block storage, long considered all but impossible to extend over long-distance, low-bandwidth WAN links. Organizations interested in improving the remote user experience while bringing data-center-class performance and protection to their remote offices should seriously consider Riverbed Steelhead EX + Granite.

Appendix

[2] Source: ESG Research Report, 2011 IT Spending Intentions Survey, January 2011.

[3] Source: ESG Research Report, 2011 Remote Office/Branch Office Technology Trends, July 2011.

[4] ESG Research Report, Remote Office/Branch Office Technology Trends, July 2011.

[5] Source: ESG Research Report, 2011 Remote Office/Branch Office Technology Trends, July 2011.

[6] ESG Research Report, Remote Office/Branch Office Technology Trends, July 2011.

“Enterprises that have mature server virtualization deployments that include workloads beyond basic IT services require more management functionality to reliably deliver applications and efficiently utilize the underlying IT infrastructure,” Bowker said. “At small scale, low consolidation and less critical workloads, the standard vCenter management console offers most of the features and functionality an administrator requires. As IT rapidly scales virtualized environments, drastically increases consolidation ratios and focuses its efforts on the next tier of applications, they need improved visibility, reporting and analytics that ultimately are geared towards driving automation into IT processes. vCenter Ops is focused on exactly this.”

via VMware Simplifies, Automates Virtual/Cloud Management – Network Computing.

This announcement coincides with the publishing of ESG’s whitepaper on “DR in the Cloud” using AWS.

All things being considered, I am very excited about the AWS Storage gateway (AWS SG), mostly because it reminds me in some ways of Microsoft’s for-sale backup product, System Center Data Protection Manager that I used to manage.  DPM wasn’t the most full-featured backup software on the market, but it did at least two very good things:

The AWS Storage Gateway is a credible offering for what its initial release is designed to do.  And like most cloud-based offerings, one can expect it to be enhanced in months, not years, as customers give feedback and operational lessons are learned.  As Terri points out, the AWS Storage Gateway may not be taking over the world of cloud-based storage enablement quite yet.  But the AWS Storage Gateway, when seen alongside all of the other AWS offerings, shows how Amazon is continuing to evolve its Platform-as-a-Service (PaaS) and infrastructure-as-a-Service (IaaS) offerings.   And those evolutions are good not only to Amazon and its ever-growing AWS direct customer base, but also to the partners that will develop even more solutions based on them for the rest of us.

ESG recently authored a white paper on “DR in the Cloud“, based on where we see companies struggling with home-grown DR solutions — and how the AWS offerings can help.

To read the ESG Whitepaper on “DR in the Cloud” using AWS, click here.

Thanks for reading.

ESG recently published our market landscape report on OLFS at www.enterprisestrategygroup.com/2011/12/online-file-sharing-and-collaboration-in-the-enterprise/

Last year, ESG shared its perspectives on BaaS at www.enterprisestrategygroup.com/2011/02/data-protection-backup-as-a-service/

BaaS and OLFS have a lot in common, so their convergence is natural, and frankly, almost inevitable.

• They work by installing an agent on the range of consumer devices that you carry. After installation and a usually user-friendly (wizard or push-button) experience, they routinely if not near-continuously transmit changed data to the cloud.
• They rely on a massive cloud-based storage architecture, whether it is self-maintained by the original vendor or leveraging a public cloud’s storage platform, e.g. Amazon.
• They’re sold usually on a subscription basis, almost always with tiered offerings, based on how much storage you plan to consume

So, what is different between OLFS and BaaS?

• BaaS is focused on multiple recovery points as a key design criteria, often including a definable retention period for past versions
• OLFS is focused on sharing – whether that means across your varied devices, or between you and your friends/coworkers, will vary based on the OLFS offering

Some OLFS offerings do support previous versions, though its usually within the context of restoring that Word document that you just accidently overwrote — and not preserving your data for a year. And while whole-machine recovery may not be a primary design function of most OLFS, the reality is that if your machine is re-image-able from either it’s factory DVDs, a monthly backup to a USB drive, or perhaps your corporate backup solution … and your data is regularly uploaded to some OLFS cloud — then whole machine recovery really can be a fairly trivial event.

BaaS-only solutions know that that they are “backup” solutions, so sharing options aren’t typically part of the model — which makes sense.

So, how does Mozy’s Stash solution stack up?

I took the opportunity to try out both the Mozy Backup and Stash offerings on one of my home machines. The setup for backup was relatively straight forward and I found it interesting how they pre-define data types and then simply prompt you to either back them up or not. I will look closer at its BaaS capabilities in a later blog post (or ESG Lab validation) but for now, I just wanted to get it installed so that I could be one of the millions of Mozy Backup customers that could now try the Stash feature.

Stash functionality enabled pretty easily, with the standard OLFS concept of defining a root-level folder for data storage. And as exciting as it sounds, I dropped some files into it and watched my drive light and network lights start blinking away. Sure enough, by installing the same Mozy client software on my work laptop, the files were there. Yay! But let’s be clear — it is a beta of a first release in the space. I am actually an avid user of another OLFS service which has a key feature that Mozy doesn’t yet offer — sharing between users. For that reason alone, I can’t use it yet. If you don’t share data with others, is Mozy viable for you? Maybe.

Although it is ‘beta’, it isn’t fair to call their offering a ‘1.0’ — because they aren’t standing it up from scratch. Mozy has oodles of experience with what it takes to create a lightweight agent technology across a variety of consumer devices. They understand how to build and operate a cloud-based storage platform at scale. They have millions of subscribers. Some of them may be using another OLFS, and if they aren’t sharing with others, may be happy to run one less agent and pay one less monthly bill. Other Mozy subscribers may have been thinking about OLFS, and the Stash offering will be what gets them started. And don’t forget, it is still only in beta.

So, more functionality will eventually come, and like most cloud-services, incremental features will come months, not years, later. Some of Mozy’s backup users will jump on this (likely increasing their storage consumption subscription in the process) — and Mozy will invariably hear the feedback of what their install base wants vs. needs. And with Mozy’s agility, as well as their commitment to cloud-enabled storage, things can only go up.

What excites me the most is seeing examples of the convergence between BaaS and OLFS. And if Stash helps more folks to get their data into the cloud, that is goodness. Beyond the convergence, I’m also looking forward to seeing what happens with Mozy Stash 1.1 … 1.5 … 2.0.

Why? Because it really is social networking 1.0. People are there because they want to be. They weren’t bribed, cajoled, or threatened. The NE VMUG is the only VMUG (I think) that has NOTHING to do with the mothership – VMware or the national VMUG (which is controlled by the mothership). It’s truly independent. It’s a family affair (the Maine Harney family, to be specific). Built by users, for users. Not built by a corporation with designs first and foremost on controlling everything you see or hear, with the intent of lining their own pockets.

I loved it.

I love it so much that I intend on doing everything I can to make sure it continues to improve (better and better user content, less and and less vendor bullshit), and most importantly, continues to remain independent. I love VMware, but they should leave this alone. This works. This is by the people, for the people. I hope others will take up the cause as well, and offer suggestions on content they would like to see, or even better, to deliver and teach their peers how to progress to higher levels. When that happens, everyone wins. Users win. Vendors win. VMware wins.

I met users from London.

I met users from other parts of the US – and when I asked (two different people) why they came here, they both said “because our VMUGs suck.” People know the difference between value and bullshit–it insults their intelligence when it’s all contrived bullshit.

VMworld is awesome, by the way. It’s the regional VMUGs that seem to suck. They have become “commercialized,” it appears.

1,200 people had registered when they closed it down. On Wednesday, the day before the show – Dawn Harney had over 300 additional requests to join. When does that ever happen?

By 9am, there were over 1,000 people already there.

The venue leaves a bit to be desired, as cool as it is. It’s chopped up and hard to really support the right number of larger rooms for all the breakouts – and you had to go outside to the other side of the stadium (it was freaking cold!), but otherwise, it was a superb event.

Sponsors love it because A: they are charged effectively nothing to be there, and B: because there are 1,000+ legitimate, valid, not made up/fictitious actual IT end-users who buy things. If this was a normal industry event, we would have already been told that over 400,000 IT buyers were in attendance, with the buying power of China. Lying liars.

So bravo to the Harneys for keeping it real.

You can read Steve’s other blog entries at The Bigger Truth.

The session I presented further confirmed:

• There is interest in moving towards more of an integrated computing approach, but most end-users are still absorbing how and why they would transition from their current infrastructure deployment model and what their options are.
• Many end-users are still very concerned about vendor lock-in, hardware lifecycle, and cost.
• The transition from DIY (Do It Yourself) to integrated computing is a long term strategy that vendors have the opportunity to accelerate during hardware refresh cycles.
• The integrated computing options are not well understood. Many end-users were surprised to see the list of 9 different vendors with integrated computing products.

You can find more information here: http://esgnext.com/nevmug/session-vci.html

You can read Mark’s other blog entries at Liquefying IT.

You can read Mark’s other blog entries at Liquefying IT.

“It’s no secret that storage is the biggest challenge in a virtual environment,” Bowker said. “Storage is VMware’s No. 1 support call issue. Virsto snaps into customers’ existing architecture, and can address storage contention issues.”

Bowker said that adding VMware support should significantly increase Virsto’s market presence. “You almost never find a customer not doing server virtualization, so this is an opportunity for them to go in to any customer now,” he said.

via Virsto sets sites on improving VMware storage performance.