IBM Squeezes Storwize into its Portfolio

Can you squeeze 20 lbs of flour into a 10 lb bag? That’s what Storwize does and its does so without impacting performance. In fact Wikibon members have indicated that Storwize compression technology actually increases the performance of file-based storage. In one of the industry’s worst kept secrets, as reported by SiliconAngle and Reuters in mid June, IBM has announced a definitive agreement to acquire Israeli startup Storwize. IBM is not disclosing terms but sources indicate Big Blue paid perhaps as much as $140M for Storwize, an Isreali-based startup that has raised about $40M in venture capital from Sequoia Capital, Bessemer Venture Partners and other VCs. The deal will take about 30 days to close so Storwize should officially become part of IBM by the end of August.

If the $140M figure is correct, in my estimate this represents well over a 10X revenue valuation for Storwize, perhaps as much as 20X. Why would IBM pay such a premium for a company with such a small revenue base? The answer in my opinion is that Storwize has solved an incredibly difficult problem and has invented a technology that IBM sees as strategic which can be placed across its substantial storage portfolio, without sacrificing performance. This brings continued differentiation to the IBM product line as the company fights to gain share in the highly competitive storage market space. The problem Storwize addresses is profound and relates to two main factors: 1) Storage growth is out of control and as such, too much storage capacity is wasted; and 2) Access densities are increasing to a point where performance in many applications is becoming too inconsistent and unpredictable.   Furthermore, the availability of high speed, multi-core processors is enabling new compression and storage optimization technolgies to go mainstream.

The value of this acquisition in my view lies not in the Storwize product, an appliance that optimizes file-based storage, but rather in its core technology. Over time, IBM will take this IP and inject it into its vast sales and service system using a process called “Blue Rinse” meaning IBM will take today’s Storwize existing appliance and get it into the sales flow. IBM will also beef up Storwize through a combination of integration, marketing and feet on the street. In the near, mid and long-term, IBM will in my view:

  • Package the Storwize appliance in front of the N-Series (OEMd from NetApp) to both complement and differentiate from NetApp’s product– which uses de-duplication as a means of optimization.
  • Do the same with SONAS – which begs the question of what’s the long-term prognosis of the N-Series?
  • Increase the number of focused Storwize sales reps worldwide to pump up sales volumes.
  • Use Storwize technology to differentiate and open up new “white space” accounts, much in the same way IBM has done with XIV.
  • Eventually embed the technology directly into the storage stack of its systems including block-based storage designs.

On balance I believe this is a very good move for IBM, it adds a strategic element to a massive IP portfolio in a critical area that increasingly is fundamental to storage value delivery.

Storwize is About Capacity AND Performance Optimization

Wikibon first started covering Storwize on a Peer Incite call with Burzin Engineer, VP of Infrastructure Services at Shopzilla. At the time Engineer indicated two things that caught our attention: 1) Storwize consistently enabled him to reduce his capacity by 50% and 2) The technology actually increased performance. Another practitioner on the call from UBS Financial indicated his experience was similar to that of Shopzilla’s. Here’s a podcast mashup of the call where Engineer cites:

When I first looked into this it was to gain efficiencies on the storage side…As it turns out, once implemented, the key benefit was that things were faster…

Earlier this year, using its CORE methodology, Wikibon quantified the impact of storage optimization technologies across a number of vendors within a primary storage use case. The results for Storwize were eye-popping and underscore why IBM (in my view) is so interested in owning the fundamental technology behind Storwize.

Earlier this year, Wikibon CTO David Floyer announced the Wikibon CTO award winners which included Storwize. In his analysis Floyer cited, in addition to the optimization and performance benefits, the reduced elapsed time impact on downstream processes such as tape backup. But the key point Floyer made which ties back to why IBM bought the company is the following statement:

Wikibon believes that in-line compression will become a standard feature of storage arrays in the next two years for both for file-based and block-based storage arrays.

Capacity Optimization – The White Hot Space

Spurred on by NetApp’s A-SIS innovation, primary storage capacity optimization is becoming a fundamental requirement for major storage players.  In other words, as David Floyer wrote recently – the storage optimization stack is becoming integrated. Virtually all major firms have a strategy in this area and many products will hit the market over the next twelve months. Just this year, we’ve seen:

  • EMC announce block level compression as a standard feature
  • HP announce its StoreOnce deduplication technology with indications that it would migrate the IP to primary storage within a year
  • Permabit announce Albireo – a software-based de-duplication technology for primary storage
  • Ocarina get bought by Dell
  • Compellent indicate it would incorporate de-duplication into its primary storage stack

Other than Permabit there aren’t many independents left in this primary optimization space. The trend is clear –optimization is taking its rightful place in storage stack and that place is embedded.

IT as a Service and the Virtualization Playbook

Everything these days is a cloud play, although thankfully that’s not how IBM is spinning this acquisition. Nonetheless, for IT to build private clouds optimized infrastructure is table stakes. The theme of 2009 was ‘do more with less’ and IBM is betting that it will stick with the industry for a while—perhaps indefinitely. Simple, fast, efficient, agile…these are the buzzwords of the infrastructure business and Storwize IP aims directly at fast and efficient, across the portfolio of storage services (e.g. optimize primary, speed primary, reduce backup windows, etc.).

The key to this announcement in my view is that IBM is going to take the Storwize IP and apply it across its storage portfolio, to include block-based storage. Consistent with the virtualization theme, this technology will become ubiquitous and invisible. Specifically, in my discussions with Storwize development engineers it’s clear that the technology can be applied to both file and block use cases. Storwize’s limited development resources forced the company to prioritize and file-based storage was a natural fit. Nonetheless, I can see IBM applying real time compression in key products including SONAS, XIV and perhaps even SVC, conferring advantage to storage offerings behind its flagship virtualization appliance.

IBM’s Acquisition Playbook – Key Questions

This exit marks another successful collaboration between Israel and Massachusetts in the storage arena. IBM has been an aggressive acquirer of Israeli-based companies with Boston connections including Diligent (Framingham), XIV (indirectly because of Moshe and his Hopkinton roots) and now Storwize (Marlborough). IBM’s approach is to identify key technologies that fill gaps in its portfolio (e.g. deduplication) or are potential game-changers (e.g. XIV) or potentially both (Storwize). IBM pays a modest price for the IP of these companies, integrates them and then blasts the technology across its portfolio to achieve an ROI through sales volume.

Observers often underrate IBM’s acquisition prowess but the company has become an M&A machine. From my perspective, as an observer of the IT industry generally and storage specifically, it’s about time IBM took an aggressive posture in this business and IBM using its heft to muscle into key areas of innovation is a sensible strategy. The key as always is execution and I’ll be looking at three main areas:

  1. How IBM organizes Storwize, will it continue to sell OEM, how will it leverage key Storwize talent?
  2. Where it places R&D and how it manages the move to block (assuming my premise is correct) and the integration to IBM’s product line.
  3. How quickly IBM embeds the Storwize technology into its portfolio and how core IBM star technologies like SVC, XIV and SONAS gain traction and competitive advantage.

,

  • Pingback: Tweets that mention IBM Squeezes Storwize into its Portfolio « Wikibon Blog -- Topsy.com

  • http://www.datamobilitygroup.com Joseph Martins

    sorry, accidental duplicate post so I deleted it.

  • http://www.datamobilitygroup.com Joseph Martins

    I have to say, David, while I love what Storwize has done for the field of data compression, and have enormous respect for Ed Walsh, Steve K and others there, I have one currently insurmountable issue with its approach to data reduction: lock-in.

    I've written to Steve Kenniston (Storwize), Mike Davis (Ocarina), and Tom Cook (Permabit) among others in search of an answer to lock-in. Only one answer thus far has satisfied me from both an information management AND an IT perspective. I'll get to that in a minute.

    No matter how we look at it, data compressed by a standalone application can only be accessed and used in the future with that application's assistance. That's lock-in.

    One of the selling points of Storwize (compared to traditional explicit compression) is that compressed files do not appear compressed to users and applications because compression and decompression is performed transparently during transfer over the network. Figuratively speaking, the Storwize approach is one hundred times more convenient than having to manually decompress files first just to be able to open them in their native applications. That's a PITA by any measure. So, Storwize offers all the benefits of compression without the loss of productivity or the need to re-engineer applications to read compressed data.

    So far so good. However, the devil is in the details. Everything processed by the Storwize applicance can only be read with its help. As the amount of compressed data grows from gigabytes to terabytes to petabytes…is that what companies want? Do they really want to store billions upon billions of compressed files that cannot be used without the assistance of the Storwize appliance? What if a company wants to migrate all of the Storwize compressed data to another solution for whatever reason? The thought of processing billions upon billions of files back through Storwize just to be able to use a different solution is not appealing.

    Storwize has ways to ensure high availability, and it offers outstanding compression and performance. But none of those benefits address lock-in. From an information management perspective using Storwize will lock my information assets up in a safe for which Storwize controls the only key. Customers should pucker up and show Storwize some love because they'll be joined at the hips from the day the appliance is installed. Some IT folks may be ok with that, but I imagine many more feel as I do, and I know information management types would be less-than-thrilled about it.

    The solution is to find a way to move the IP down the stack into the storage systems themselves in a way that's compatible with disk I/O today. Philosophically, think of it as NTFS compression on local disk in that it's embedded and transparent. Everything saved to the media is compressed and everything read off the media is decompressed…transparently. Companies can then move data between systems, between media with no dependency on a third party application/appliance. The storage system, the media itself would not “lock you in”. Perambit has already headed in that direction. IBM would be wise to do the same with Storwize.

    Consumers should have choice without fear of lock-in.

  • http://twitter.com/skenniston skenniston

    @Joseph Martins,

    Hey Joe, I was saddened to hear that there was only one good answer to your question on lock-in and since I don't remember answering, I am sure it wasn't mine :)

    That said, I have to agree with you 100%. Lock-in or EMC-in (JK), isn't good for anyone. This is one of the primary reasons behind the fact that of the 35 patents Storwize has, not one has do to with compression. These patents talk about how to make compression real-time and random access. We leverage industry standard LZ compression. Now I will state for the record you can't use WinZip to decompress Storwize compressed data, however we do have a decompress utility on our website that anyone can use to uncompress Storwize compressed data, it is free, easy to use and helps folks out of any type of situation they believe they feel they may be in when it comes to having Storwize compressed data.

    As I had said in my blog post regarding Server + Storage Optimization = Data Center Utopia – that until there are standards around optimization technology, it will be the customers who suffer. I realize that that conversation is as about as fruitful as a conversation saying Data Domain deduplication and NTAP ASIS need to be able to understand each other.

    The ultimate value of all this 'data' comes together at the file system level. Once VxFS could share (read) data with other file systems, it became a viable solution because customers always had a fall back plan and felt safe – same thing here.

    In the 90's we talked about 'stove pipe' organizations. Today it will be 'stove pipe' data. Reinflating data to move it or to read it (in heterogeneous environments) is the next phase and vitally important. Vendors who have an 'optimization' strategy across 'their' portfolio will lose – it will need to span all areas where an application needs that data – just like a file system today.

    So what is different for Storwize today. First, we recognize this as an issue. Second we now have the largest provider in the world of innovative technology to the enterprise, committed to continue investing in us to help make this dream a reality.

  • http://www.datamobilitygroup.com Joseph Martins

    Hi Steve,

    You're right. My questions during our phone conversation were not specifically about lock-in. I inferred lock-in from your answers to other questions. In an effort to be brief earlier–which clearly didn't work out for me–I left out some detail. Thank you for taking the time to respond here. I appreciate it.

    IBM will help make that vision happen Steve. In that I have no doubt. I agree with much of what David wrote. All I can say is I'm glad you weren't acquired by HP. ;-)

  • http://twitter.com/skenniston skenniston

    @Joseph Martins – LOL – ME 2 (RE:HP)

  • http://www.datamobilitygroup.com Joseph Martins

    I have to say, David, while I love what Storwize has done for the field of data compression, and have enormous respect for Ed Walsh, Steve K and others there, I have one currently insurmountable issue with its approach to data reduction: lock-in.

    I've written to Steve Kenniston (Storwize), Mike Davis (Ocarina), and Tom Cook (Permabit) among others in search of an answer to lock-in. Only one answer thus far has satisfied me from both an information management AND an IT perspective. I'll get to that in a minute.

    No matter how we look at it, data compressed by a standalone application can only be accessed and used in the future with that application's assistance. That's lock-in.

    One of the selling points of Storwize (compared to traditional explicit compression) is that compressed files do not appear compressed to users and applications because compression and decompression is performed transparently during transfer over the network. Figuratively speaking, the Storwize approach is one hundred times more convenient than having to manually decompress files first just to be able to open them in their native applications. That's a PITA by any measure. So, Storwize offers all the benefits of compression without the loss of productivity or the need to re-engineer applications to read compressed data.

    So far so good. However, the devil is in the details. Everything processed by the Storwize applicance can only be read with its help. As the amount of compressed data grows from gigabytes to terabytes to petabytes…is that what companies want? Do they really want to store billions upon billions of compressed files that cannot be used without the assistance of the Storwize appliance? What if a company wants to migrate all of the Storwize compressed data to another solution for whatever reason? The thought of processing billions upon billions of files back through Storwize just to be able to use a different solution is not appealing.

    Storwize has ways to ensure high availability, and it offers outstanding compression and performance. But none of those benefits address lock-in. From an information management perspective using Storwize will lock my information assets up in a safe for which Storwize controls the only key. Customers should pucker up and show Storwize some love because they'll be joined at the hips from the day the appliance is installed. Some IT folks may be ok with that, but I imagine many more feel as I do, and I know information management types would be less-than-thrilled about it.

    The solution is to find a way to move the IP down the stack into the storage systems themselves in a way that's compatible with disk I/O today. Philosophically, think of it as NTFS compression on local disk in that it's embedded and transparent. Everything saved to the media is compressed and everything read off the media is decompressed…transparently. Companies can then move data between systems, between media with no dependency on a third party application/appliance. The storage system, the media itself would not “lock you in”. Perambit has already headed in that direction. IBM would be wise to do the same with Storwize.

    Consumers should have choice without fear of lock-in.

  • http://twitter.com/skenniston skenniston

    @Joseph Martins,

    Hey Joe, I was saddened to hear that there was only one good answer to your question on lock-in and since I don't remember answering, I am sure it wasn't mine :)

    That said, I have to agree with you 100%. Lock-in or EMC-in (JK), isn't good for anyone. This is one of the primary reasons behind the fact that of the 35 patents Storwize has, not one has do to with compression. These patents talk about how to make compression real-time and random access. We leverage industry standard LZ compression. Now I will state for the record you can't use WinZip to decompress Storwize compressed data, however we do have a decompress utility on our website that anyone can use to uncompress Storwize compressed data, it is free, easy to use and helps folks out of any type of situation they believe they feel they may be in when it comes to having Storwize compressed data.

    As I had said in my blog post regarding Server + Storage Optimization = Data Center Utopia – that until there are standards around optimization technology, it will be the customers who suffer. I realize that that conversation is as about as fruitful as a conversation saying Data Domain deduplication and NTAP ASIS need to be able to understand each other.

    The ultimate value of all this 'data' comes together at the file system level. Once VxFS could share (read) data with other file systems, it became a viable solution because customers always had a fall back plan and felt safe – same thing here.

    In the 90's we talked about 'stove pipe' organizations. Today it will be 'stove pipe' data. Reinflating data to move it or to read it (in heterogeneous environments) is the next phase and vitally important. Vendors who have an 'optimization' strategy across 'their' portfolio will lose – it will need to span all areas where an application needs that data – just like a file system today.

    So what is different for Storwize today. First, we recognize this as an issue. Second we now have the largest provider in the world of innovative technology to the enterprise, committed to continue investing in us to help make this dream a reality.

  • http://www.datamobilitygroup.com Joseph Martins

    Hi Steve,

    You're right. My questions during our phone conversation were not specifically about lock-in. I inferred lock-in from your answers to other questions. In an effort to be brief earlier–which clearly didn't work out for me–I left out some detail. Thank you for taking the time to respond here. I appreciate it.

    IBM will help make that vision happen Steve. In that I have no doubt. I agree with much of what David wrote. All I can say is I'm glad you weren't acquired by HP. ;-)

  • http://twitter.com/skenniston skenniston

    @Joseph Martins – LOL – ME 2 (RE:HP)

  • Pingback: IBM Completes Acquisition of Storwize « Wikibon Blog

  • Pingback: SiliconANGLE — Blog — Cloud Storage M&A: IBM Completes Storwize Acquisition - HP Dell and 3PAR Next

  • Pingback: mafri