The last three weeks at 3PAR have been very satisfying. People throughout the industry have been calling us and emailing their regards, congratulations and best wishes regarding 3PAR's pending acquisition and future.
Last week at the VMworld conference, we saw a significant boost in customers coming to our booth to learn about our company and products. It was obvious that a lot of people were responding to the recent news stories and wanted to know what all the commotion was about. Some of these customers had never seriously considered 3PAR before because we were a smaller company than they typically do business with, but they were now anticipating that our products will be sold by a company that they already have a long-standing relationship with.
It was a bit like coming to an opening on a trail after walking through a forest and seeing a vast expanse of land before you. There is an enormous potential ahead for 3PAR. New customers will be much easier to find and pursue. These new customers will bring a different perspective to 3PAR's business, including new expectations and requirements that we will have to invent solutions for.
The good news is that we already understand the process of innovating at 3PAR and we've always been able to bring new, unique functionality to the market. That's where the satisfaction has always come from and where it will continue to come from. The recent recognition in the news has certainly been gratifying for all of us at 3PAR and it validates the way we have always approached this business.
As part of HP, 3PAR will become a key element of HP's Converged Infrastructure strategy, which encompasses server, networking and storage products. This is a much larger vision than we've been able to afford as a smaller best-of-breed storage company and it will be exciting and challenging to work out the details of this vision in our products. Dave Donatelli has a reputation for being very intelligent and having a strong compassion for our business. The fact that he has taken such an important role in the future of 3PAR speaks volumes. The best for 3PAR is yet to come.
### This communication is for informational purposes only and is not an offer to purchase or a solicitation of an offer to sell securities. The tender offer described herein is being made only pursuant to the Offer to Purchase, Letter of Transmittal and related materials that Hewlett-Packard Company and Rio Acquisition Corporation filed with the SEC on a Tender Offer Statement on Schedule TO on August 23, 2010. In addition, 3PAR Inc. filed a Solicitation/Recommendation Statement on Schedule 14D-9 with respect to the tender offer on September 7, 2010. The Tender Offer Statement (and related materials) and the Solicitation/Recommendation Statement contain important information that should be read carefully before any decision is made with respect to the tender offer. Those materials may be obtained free of charge from Innisfree M&A Incorporated, the information agent for the tender offer, toll-free at (888) 750-5834 (banks and brokers call collect (212) 750-5833). In addition, all of those materials (and all other offer documents filed with the SEC) are available at no charge on the SEC’s website at www.sec.gov.
Statements in this communication that relate to future results and events are forward-looking statements based on 3PAR’s current expectations. Actual results and events in future periods may differ materially from those expressed or implied by these forward-looking statements because of a number of risks, uncertainties and other factors. All statements other than statements of historical fact are statements that could be deemed forward-looking statements, including the expected benefits and costs of the transaction; management plans relating to the transaction; the expected timing of the completion of the transaction; the ability to complete the transaction; any statements of the plans, strategies and objectives of management for future operations, including the execution of integration plans; any statements of expectation or belief; and any statements of assumptions underlying any of the foregoing. Risks, uncertainties and assumptions include the possibility that expected benefits may not materialize as expected; that the transaction may not be timely completed, if at all; that, prior to the completion of the transaction, 3PAR’s business may experience disruptions due to transaction-related uncertainty or other factors making it more difficult to maintain relationships with employees, licensees, other business partners or governmental entities; that the parties are unable to successfully implement integration strategies; and other risks that are described in 3PAR’s Securities and Exchange Commission reports, including but not limited to the risks described in 3PAR’s Annual Report on Form 10-K for its fiscal year ended March 31, 2010. 3PAR assumes no obligation to update these forward-looking statements.
To a lot of people, especially those who are unfamiliar with the storage industry, one of the obvious questions is "Who are these people and where did they come from?"
The answer is that the company was formed by a group of server-cluster engineers from Sun and has been around for over a decade developing and selling large scale storage products designed for something that used to be called "utility computing" seven years ago, but today is just called "the cloud".
We've been very successful with our cloud strategy and have 7 of the top 10 IAAS (infrastructure-as-a-service) customers as clients. 3PAR products work very hard in the background for a lot of household-name customers. Most people don't know or care.
However, cloud industry vendors know 3PAR because they are also very heavily involved with those same customers, competing with their own products. They see our storage systems in those large data centers and our customers tell them that they need to make sure they work with us. There's nothing unusual about that sort of thing, but we definitely are a player.
Here's what we do very well:
Handle mixed workloads in multi-tenant environments. That means we can service a wide range of applications concurrently from multiple servers (or virtual servers) concurrently. If you are a cloud service provider and you need to have the confidence that your infrastructure will deliver consistently - even if your business changes radically - 3PAR is a very safe choice.
Operate efficiently at high utilizations. Most storage in the world today is underutilized, which gets under people's skin because there is a high cost associated with that. 3PAR has led the industry with thin storage technologies that started with our implementation of thin provisioning many years ago and has been recently enhanced through thin reclamation, thin conversion and thin persistence software features. Again cloud service providers need to keep the cost of their operations under tight control.
Give administrators the highest levels of automation. Administrative work on storage has historically been difficult and time consuming, which has been problematic for cloud service providers who have to be able to increase and reconfigure resources to meet fast-changing business demands. 3PAR storage lets system administrators make adjustments more quickly and confidently.
The thing that we didn't completely understand at 3PAR was how quickly the onset of the virtualized data center was going to tilt the storage world in our direction. 3PAR storage systems are based on a highly advanced, granular storage architecture. It's not always the easiest thing for people to understand because it is so different than any other vendor's architecture. However, people familiar with virtualized server features have a much easier time understanding how our technology works. There is nothing like a terrific, relevant analogy for explaining how your different widget works.
3PAR is a relatively small company, competing with much larger companies who use the benefits of their size, global reach and service organizations against us every day in sales opportunities. It hasn't been easy, but we've continued to grow our business in a very hotly contested arena where our competitors like to position us as the "small, new company" Storage purchases in this market are high stakes and careers can be made or lost on the right decision. We certainly don't win all the deals we are in, but we very seldom lose on technical merit. Usually it's because we are lesser known or because we can't match the service offerings of our larger competitors.
It appears that some of those variables will be changing for us relatively soon.
There is no question that I'm going to get a lot of ribbing from friends of mine in the business when they read about this. After all, I was at Convergenet prior to it's acquisition by Dell and then again years later at EqualLogic when it was acquired by Dell and - as some have teased me about the inevitability of another Dell acquisition - it now appears that Dell intends to acquire 3PAR too. I only banged my head into the wall once when I was told about it.
At this point, it's all very new so I don't have much to say on the matter, but there are some things about this news that make me think it could be a very good thing. First, Dell clearly wants to be in the storage business, as they've proven the last several years. The EqualLogic acquisition was a starting point for them and they appear to be looking to become a much more serious enterprise storage player now with 3PAR's technology and products.
Second, the way I understand it, they want to have a bigger presence here in the valley, which is about time. As much as it might seem in Round Rock, the technology world doesn't revolve around Texas and it's important to have a corporate and development facility here.
Finally, I like both EqualLogic's and 3PAR's technologies and the people from both companies. Hopefully this will work out so that I'll be able to cover both in StorageRap because that would be fun - serious fun. But for now it's all conjecture and waiting to see what unfolds. You have to wonder about lightning that hits you three times.
# # #
The planned tender
offer described in this blog post has not yet commenced. The description
contained in this blog post is not an offer to buy or the solicitation of an
offer to sell securities. At the time the planned tender offer is commenced,
Dell will file a tender offer statement on Schedule TO with the Securities and
Exchange Commission (the "SEC"), and 3PAR will file a
solicitation/recommendation statement on Schedule 14D-9 with respect to the
planned tender offer. The tender offer statement (including an offer to
purchase, a related letter of transmittal and other tender offer documents) and
the solicitation/recommendation statement will contain important information
that should be read carefully before making any decision to tender securities
in the planned tender offer. Those materials will be made available to 3PAR’s
stockholders at no expense to them by contacting 3PAR’s Investor Relations
department at 510-897-4622. In addition, all of those materials (and all other
tender offer documents filed with the SEC) will be made available at no charge
on the SEC's website: www.sec.gov.
Statements in this
blog post that relate to future results and events are forward-looking
statements based on 3PAR’s current expectations. Actual results and events in
future periods may differ materially from those expressed or implied by these
forward-looking statements because of a number of risks, uncertainties and
other factors. All statements other than statements of historical fact are
statements that could be deemed forward-looking statements, including the
expected benefits of the transaction; management plans relating to the
transaction; any statements of the plans, strategies and objectives of
management for future operations, including the execution of integration plans;
any statements of expectation or belief; and any statements of assumptions
underlying any of the foregoing. Risks, uncertainties and assumptions include
the possibility that expected benefits may not materialize as expected; that
the transaction may not be timely completed, if at all; that, prior to the
completion of the transaction, 3PAR’s business may experience disruptions due
to transaction-related uncertainty or other factors making it more difficult to
maintain relationships with employees, licensees, other business partners or
governmental entities; that the parties are unable to successfully implement
integration strategies; and other risks that are described in 3PAR’s Securities
and Exchange Commission reports, including but not limited to the risks
described in 3PAR’s Annual Report on Form 10-K for the fiscal year ended March
31, 2010. 3PAR assumes no obligation and does not intend to update these
forward-looking statements.
A couple weeks ago, one of the major storage vendors had two major problems to resolve after one of their arrays suffered a firmware bug-induced failure at one of their cloud (email) service provider customers. They had to:
Help the customer get back to normal service levels after they had become unacceptable.
Confront a public relations problem after it was exposed by a leading storage publisher.
Meanwhile, their service provider customer had four major problems to resolve:
Get service levels back to acceptable levels.
Communicate to their customers what the problem was and how it was being addressed.
Re-engineer a solution to avoid the same happening again.
Credit customers for not delivering against SLA terms.
A vendor employee tried to address their public relations problem this way in his blog:
"OK, I'll take the blame for this -- sort of. We pride ourselves in putting a lot of thought into our customer designs. I'd argue that we're really, really good at it as well.
But not everyone is 100% sure of how their application will grow over time -- unfortunately, we're not psychics. And, let's be honest, not everyone necessarily wants to pay for redundancy we like to put into our designs.
We don't always get to directly engage all the time, either -- with products such as the (blanked out), most of this stuff moves through the channel. Somebody calls up one of our partners, says that they want to buy one of our products, and one gets sold -- and a lot of product gets sold that way."
I understand the desire to explain how messes become messy, but I'm not sure why he felt the need to speculate that his company's business partners or that their customer's budget were key elements of the problem. That is tantamount to saying, "All of our (blanked out) customers could have the same thing happen to them too." Anybody who has ever been close to one of these melt-downs knows there are many variables involved - including vendors underbidding each other and shaving elements from their bid in order to win the business.
From a distance, it looks like the vendor's response to the customer was good, although there apparently were some issues with failure notification from the array when the event occurred. I wouldn't call these sorts of things "Perfect Storms", but there are unfortunate scenarios where multiple things go awry. All vendors have these sorts of bad days, which serve as painful learning experiences. Unfortunately for customers, it's one of the ways vendors improve their customer support processes.
The customer also wrote in his blog, explaining the situation to their customers:
"Our SAN vendor analyzed the system logs for the event and determined that the service processor failure occurred due to a unique bug in the specific version of firmware on the system. Our vendor performed an emergency upgrade. The newer version of firmware includes a fix for the bug. We are taking additional corrective actions to make certain that there is enough spare capacity on the SAN. This will assure it performs without performance degradation in the event of a single hardware failure."
The reparation sounds reasonable, but it's not what I would call best of breed either. I'll explain why in the remainder of this post.
The old trusted dual controller just can't keep up
The explanation the service provider gave to their customers was only half correct. Yes, the failure in one controller was due to a firmware bug -and yes, all vendors find out about some of them at customer sites - but the inability of the surviving controller to handle the workload was another matter altogether.
The major defect of all dual controller designs for service provider applications is the uselessness of write cache when operating in degraded mode on a single controller.
When a dual controller array has a controller failure, all traffic is failed over to the surviving controller. However, this controller can't afford to place writes in cache because if this controller also fails any un-flushed writes in cache would be lost- making the recovery process all the more painful. As a result, the throughput of the controller degrades significantly because writes now take several orders of magnitude longer to process as each write must be completed at the physical disk level, instead of in fast cache memory. When you consider the sort of read/write ratios involved with an email application (heavy writes), it's not surprising to hear that it took 32 hours for the system to get caught up. I suspect that if the surviving controller had been able to use write cache, the customer might have experienced some amount of service level problems, but not nearly as bad as they suffered.
Write performance during array component failures is an important point that many customers give insufficient weight to when making their purchases. Public service providers certainly need to understand this. The exact same scenario - controller failure and subsequent drop in service levels - could certainly happen to a traditional data center customer, but the ramifications of this scenario are not as ugly as they are for a multi-tenant public service provider.
This case is a perfect example of how an older architecture is incapable of meeting the requirements of the new cloud service business model. If you are a cloud service provider reading this and wondering if you might have a similar exposure to a controller failure (including 3PAR customers with dual -controller arrays), my advice is to review what you have and start thinking about what you should expect if you have a controller failure and how you might want to deal with it on both a short-term and long-term basis. Best of breed cloud storage should not include dual controller arrays.
Their solution is to buy more and utilize it less
One of the identified corrective actions is having "enough spare capacity on the SAN", which in this case involves installing a second array. Without knowing the inside scoop, it looks like the idea is to split the workload across the two arrays so that if a controller failure occurs in either array, the performance drop won't be as noticeable. The array that doesn't suffer the failure will keep working as expected and the array that has the failure will only have half the load to deal with.
There are two primary problems with this "fix"
Performance will still suffer on the array with the controller failure
The I/O load will continue to increase over time
You are always going to have performance degradation of some sort when you can't use write caching, unless you are only reading data - which isn't the case here. It is flat out wrong to assume that a performance problem will not occur. Regardless, with the new two-array SAN, whichever system has the controller failure should be able to get caught up much faster than the 32 hours this customer had to wait. Of course, the customer's capacity and I/O load will almost certainly increase over time, and as that happens, the strategy of splitting the load between two arrays loses its effectiveness.
Along with adding the controllers, they are also certainly adding disk drives, and some notion of what "reasonable" utilization limits should be for them. The problem with limiting utilization as a best practice is that it puts the stamp of approval on inefficiency - not only for capacity utilization abut also for the power and cooling required to support all those underutilized drives. Most legacy arrays have built-in inefficiencies in the way data is laid out on disks, making it virtually impossible to achieve uniform utilization across all disk resources. The result is uneven consumption of disk capacity, as well as uneven I/O service levels among different disk groups, which is another variable in how much performance degrades following a controller failure in a dual controller array.
Finally, the customer now has two arrays to manage, including multipath connections, SAN zones, and all other aspects of the configuration, which all contribute down the road to change management complexities. The result is a net drag on administrator effort and an increased TCO.
How many do you need?
A true best of breed solution would address the root-cause deficiency in the array's design, without creating additional management and cost burdens to the customer. Obviously, more than two controllers are needed. But how many controllers does a cloud service provider need in an array? The answer is at least three. Why? Because when a single controller fails, there can still be two surviving controllers working together, mirroring their cache contents, and performing fast writes to cache memory. That said, controllers are usually packaged in pairs for redundancy purposes, which means that the most likely configurations will have four controllers.
If you compare a single quad controller array with two dual controller arrays there are some key advantages that immediately jump out:
No or limited loss of performance after a controller failure
All drives and cache can be used to service all workloads
Managing a single array significantly reduces cost and complexity
A better recipe for maintaining performance levels
The next question is; "Is there a suitable quad controller array that the customer could have used instead of the two dual controller arrays they have?" Yes, 3PAR's F400 or T400 arrays are both quad controller arrays. The disk drives in these arrays can be either SATA or FC, or a mix of both types if the customer wanted to implement tiering. Product information of the F400 can be found here, and the T400 here.
However, simply putting four controllers in an array does not necessarily guarantee that they will be able to sustain write caching if one of them fails. The array must have the ability to remap and re-mirror the write cache contents of all four controllers to the surviving controllers following the loss of a controller. It's an interesting geometric sort of problem: There are four controllers, each with their own cache and cache that is mirrored from the other controllers in the array. All cache contents, including mirrors, need to be distributed evenly across all controllers to avoid congestion and load imbalances. All cache content, including mirrors needs to be accounted for within the array so that if a controller fails, the other controllers will be able to identify all the surviving original and mirrored copies of data. For cache data that has lost either a primary or mirrored copy, a second (new) copy needs to be made. Finally, the amount of data in cache may need to be re-leveled (decreased) to fit into the degraded cache capacity (3 controllers instead of 4).
The software for doing this in a 3PAR array is Persistent Cache. Product information on Persistent Cache is here (PDF)
I made a 9 minute last year video describing how Persistent Cache works. Here it is again. Thanks for watching.
There have been some excellent discussions recently in the storage blogosphere and on Twitter about the concept of Storage Federation among a number of storage people; known by their Twitter IDs as @stuiesav, @storageanarchy, @rootwyrm, @davegraham, @bwhyte, @ianhf, @esignoretti, me (@3parfarley) and others - as the interest continues to increase.
There are two aspects of the discussion that I think are fascinating: first is the role of social media as the means to include customers, vendors and others in an open discussion that typically is conducted privately by a vendor preparing to release a new product or feature, second is the challenge of defining a storage capability with sufficient focus and vendor independence so that is is meaningful. There has been some amount of skepticism about this effort, suggesting that we are predetermined to end up with ambiguous terms that can be interpreted (spun) by anybody (any vendor) to mean anything (our product does it). I'm hopeful the results can be better than that, but subjectivity is the only constant of social media and it's not likely that everyone will like whatever happens.
In general, the language of digital storage has many overlapping meanings, which causes a fair amount of confusion in our industry. I've been dealing with this problem for many years, going back to when I wrote Building Storage Networks and had the challenge of trying to invent generic terms for functions that had been coined by vendors and tied to specific products. My interest in defining Storage Federation goes beyond my role as an employee for 3PAR.
The notion of federated storage has been around for several years, but recently it came to light when Pat Gelsinger of EMC referred to it during a press briefing on March 11. EMC blogger Chuck Hollis wrote about it afterward and there was some chatter, culminating in a blog post by @Stuiesav on April 2, which proposed that the discussion about Storage Federation was just marketing hype attempting to rebrand storage virtualization. EMC's Barry Burke (@Storageanarchy) and I (@3parfarley) both agreed that this was not the case this time around and then in the last couple days the discussion fired up again. The problem with Twitter is the limitations of 140 characters per tweet. It's surprising what can be done with so few characters, but it does have limitations.
Skeptics Allowed
This weekend, @ianhf posted in his Grumpy Storage blog echoed @Stuiesav's skepticism and expressed his perspective (as a customer) as to the things he would like to see when new technologies - in this case Storage Federation - are introduced. Here are some of the items from his list (Some of them don't fit our definition exercise because they assume there is a new product being introduced, which is not the case here).
The specific customer requirements & problems this addresses & justify how
The use cases this feature / function applies to, and those that it doesn't
Why & how this feature is different to that own vendor's previous method for solving this problem
Provide clarity over the non-functional impacts of the feature
before, during & after it's use - ie impact on resilience, impact
on performance, concurrency of usage etc (including provide up-front
details of constraints)
Naturally you'll also expect me to require TCO & ROI of the
feature, and any changes to the models as a result of this feature
So lets get started (already!):
The definition of Storage Federation that was kicked around on Twitter is something like: "the transparent, dynamic and non-disruptive distribution of storage resources across self-governing, discrete, peer storage systems." (And yes, I did elaborate a bit on this while I was writing based on bits and pieces from comments I read and further thought of my own.)
The idea is to have multiple storage systems cooperating as a team (as opposed to under the direction of an external entity) to place data in the aggregated storage resources (LUNs or volumes) of all participating members. An example of Storage Federation is how Dell/EqualLogic arrays distribute their volumes over multiple systems. When a new EqualLogic array is added to an iSCSI SAN, the administrator is asked if the array should be placed in the same group as other arrays in the SAN. If this is done, the arrays start splitting their volumes (and workloads) across both arrays.
Five examples of storage federation capabilities are:
Storage expansion: You want to increase the storage capacity of an existing storage system that cannot accommodate the total amount of capacity desired. Storage Federation allows you to add additional storage capacity by adding a whole new system.
Storage migration: You want to migrate from an aging storage system to a new one. Storage Federation allows the joining of the two systems and the evacuation from storage resources on the first onto the second and then the first system is removed.
Safe system upgrades: System upgrades can be problematic for a number of reasons. Storage Federation allows a system to be removed from the federation and be re-inserted again after the successful completion of the upgrade.
Load balancing: Similar to storage expansion, but on the performance axis, you might want to add additional storage systems to a Storage Federation in order to spread the workload across multiple systems.
Storage tiering: In a similar light, storage systems in a Storage Federation could have different capacity/performance ratios that you could use for tiering data. This is similar to the idea of dynamically re-striping data across the disk drives within a single storage system, such as with 3PAR's Dynamic Optimization software, but extends the concept to cross storage system boundaries.
These are all examples of Storage Federation that Dell/EqualLogic storage systems are capable of today. It's not intended to be an endorsement of their distributed volume manager, I am simply using it as an example of Storage Federation. Saying that, if you look for "Storage Federation" on the Dell/EqualLogic web site, you probably won't find it today because they don't describe it that way, but that doesn't mean that it is not in the product.
That's not it
People also want help understanding what the definition of Storage Federation should not include. Here are my thoughts:
In-band storage virtualization systems like IBM's SVC can provide all the capabilities listed above for Storage Federation. However, in-band virtualization products govern the behavior of the other storage systems networked to it and Storage Federation involves self-governing, peer systems. Another way of saying it is that Storage Federation does not have functionality in the network between host systems and storage.
File, object and data distribution technologies like EMC's Atmos certainly provide a type of federation insofar as multiple computer systems can access the same data objects from multiple locations that may be separated geographically. However, this capability primarily migrates files (data objects) - and is functionally orthogonal to Storage Federation, which works on volumes. A term like Data Federation is probably more precise than Storage Federation for this sort of capability.
Clustered storage systems, like 3PAR's InServ storage systems or clustered NAS systems are not examples of Storage Federation because they function as single, scalable storage systems, not as discrete storage systems that are networked together. Clustered storage systems can work together in Storage Federations with other clustered or non-clustered storage systems. In that case you could have a Storage Federation of clustered storage systems.
How is this different?
I thought I'd make a little effort to respond to @ianhf's requests.
The main problem Storage Federation addresses the limitations presented by a single storage system, such as capacity, performance and maintenance availability.
Currently, when a new storage system is added to an existing environment, there are server administration tasks that need to be done in order to migrate volumes from an existing storage system to the new one. In addition, there is usually some amount of downtime and/or performance degradation associated with the migration and configuration of new data paths. By contrast, with Storage Federation, a new storage system could be added without having to reconfigure host data paths and the migration would be processed transparently and dynamically, without any downtime or loss of path redundancy while the migration is in process.
Increasing performance for a particular volume in a Storage Federation is somewhat less obvious because the other federated storage systems might not have more performance-resources available to boost performance. For instance, if a new storage system inserted in a Storage Federation does not have more disk drives (spindles) or more flash SSD capacity, there is no guarantee that any volumes moved to it would provide faster performance. There is some likelihood that performance could be improved by moving a volume to a storage system running at lower utilization levels, but maintaining lower utilization levels is not realistic or very cost-effective. All this said, it is possible for a Storage Federation to use the aggregate resources of multiple storage systems to increase performance of a single volume - such as by spanning all the disk drives in the federation and by using the cache of all participating storage systems. An example of products that provides this capability today are the Dell/EqualLogic storage arrays.
The availability of storage systems needing maintenance could be greatly improved by Storage Federation if an existing storage system can be removed from the federation after having it's volumes evacuated (think v-Motion but for storage systems) to other storage systems in the federation. After being removed from the federation, the storage system could be downed to have any sort of maintenance operation done to it without risking the availability of any of the volumes that had previously been on the system undergoing maintenance.Obviously, all of this would take time planning and ensuring the Storage Federation would not be overloaded with data and workloads, but there are probably many customers that would prefer to do maintenance to storage systems when they are offline.
One of the possible exposures of Storage Federation is the increased exposure to system failures. For instance, a Storage Federation that distributes a single volume over three separate storage systems is 3 times more likely to have a failure than a Storage federation that does not allow volumes to span across storage system boundaries. FWIW, this is the main weakness of the Dell/EqualLogic implementation of Storage Federation.
That's all for now
It's late and there is plenty of material here for the grinder. Please feel free to comment in any way; agree, disagree, correct mistakes and ask questions. Thanks for reading.
OMG! I wasn't sure who to call first, my agent, the paparazzi or Dr. Phil to talk this over with. Like, this was SOOOO predictable - like, you know - two people that start out as adversaries become attracted to each other out of financial necessity and then they find out, like, they don't really have that much in common, except that, like, they sort of need each other to use as an excuse when they are, like trying to get out of other situations that they don't, like, you know, like very much?
Will this relationship become the longest running technology soap opera of all time? The rumor mill has been pretty quiet lately concerning Dell's plans to acquire technology companies and create more leverage and generate higher margins. So how is a new deal with an old flame going to help them do that? I can only guess that the EqualLogic business at Dell has not panned out as well for Dell as they have been saying. Perhaps storage investogators Chris Mellor, Beth Pariseau or Simon Sharwood can dig up something about this?
As it is with so many sales relationships, it will only last as long as the tricks that the respective sales forces play on each other don't get too nasty. Somebody is going to make more money than the other and the one with the smaller surprise won't be very happy when they find out their party is a bring your own event.
Good luck to both for having done something they will probably both regret, but never admit to having any.
I was talking with my InfoSmack co-conspirator, Greg Knieriemen (iknerd.com) last week about virtual junk and how the word "virtualization" was so incredibly unwieldy. It was killing my lazy mouth to have to do so much work for such a well-understood term/topic.
(BONUS QUESTION: is "virtualization" a noun, verb, or WHAT? )
Fear no more, bad spellers and slothful speakers! The new word for virtualization is MOSHWARE. MoshWare is software that enables all sorts of systems and applications to be blended, pureed, mashed and moshed together in a single computer, or MoshBox. It also allows MoshMachines (or MMs) to be relocated to other MoshBoxes using functions such as m-Motion or TransMoshinization.
Of course the word "MoshWare" could apply to many other things, including social networking sites, such as Twitter. There needs to be a modifying word or prefix for the social context in order to differentiate machine MoshWare (its true form) from social MoshWare. Devo MoshWare works for me.
Blade servers also provide Moshable benefits, similar to those of MoshWare, but in hardware. Whereas "Blade server" has 3 syllables, the much smaller word "BladeMosh" simply rolls off the tongue like a Scotsman's beverage.
One of the great things about MoshWare is getting rid of unnecessary networking adapters by consolidating network traffic on fewer links over the MoshNet! Not only that, but storage MoshNets can be implemented as Switchless SAMs(Storage Area MoshNets). To accomplish this, a MoshBox's HBAs are cabled directly to a storage array's ports without an intervening switch. When you consider that this eliminates two switches at at time (for HA) - as well as the need for zoning, the economic benefits can be significant. We have a number of customers at 3PAR who do just that and have saved a lot of money in the process. This means installing more SAN adapters in storage arrays, but if the arrays can accommodate them it might be worth considering. Is it for everybody - certainly not, but is is another option for reducing the cost of storage.
So what about Moshed storage - or STORMOSH! SAN and NAS are different forms of StorMosh, but DAS is most certainly Moshless. The amount of Moshing a StorMosh does depends on it's design. Some StorMoshi require a large amount of Manual Moshing (ManMosh is an oxymoron to be sure), whereas other StorMoshi, such as those from 3PAR and Dell EqualLogic, Mosh at a very high level.
The graphic below shows an implementation of a MoshStack ,with a MMs running inside MoshBoxes, connected to a StorMosh via a Switchless SAM.
Dell acquiring Perot Systems is all good. It's clear they have to follow HP and IBM to the expanding IT services markets . The question is whether or not Dell will be able to get a greater return on their investment than HP did. That's the nature of competition in an industry going through a jolting consolidation. With Cisco and Oracle starting to sell server systems, Dell was forced to find other businesses to find margin - something they are historically bad at. This acquisition will be the keystone of their business makeover.
With so few acquisitions under their belts, the challenge for Dell is not screwing up. Their EqualLogic acquisition was not done to perfection, but it certainly has been a big success for Dell. This is a much bigger deal, with much higher stakes and involves many more employees that Dell needs to manage successfully.
Employee morale at HP's EDS has not been great. It's possible that HP is doing the right things for it's long term business success, but one wonders how successful the EDS acquisition will be if there are so many disgruntled employees. Is it possible that Dell - a newbie at acquisitions could one-up HP? My thinking is that the likelihood of this increases if they operate Perot Systems as a wholly owned subsidiary, but that seems unlikely.
The other question this acquisition raises is who will run the new business. I don't think Michael Dell is the best candidate for the job and it's not clear to me that he wants to run the new Dell - even though it's very clear that he wants to change the company to compete in a new world order. There are going to be some very difficult decisions ahead. With Ross Perot getting a seat on Dell's board, there is no question board meetings are going to become much more interesting in the future. Is Dell willing to go the distance to make itself a leading IT infrastructure company? As big as the Perot Systems acquisition is to Dell, it does not come close to finishing the job. The foundation may be poured, but there is a lot of construction left to do.
I visited with 3PAR customer Gregory Thomas last week and he spoke about his role as VP of IT at Managed Health Care Associates and the technology environment he oversees. As a company that prides itself on customer service, MHA looks for the same sort of commitment from it's vendors.
MHA uses an open systems approach built on SQL Server, Exchange, VMware, Dell servers, HP ProCurve switches (they have an iSCSI SAN) and 3PAR storage - an F400 clustered storage array with four controllers with both Fibre Channel and SATA drives. Not fooled by the creative language surrounding multipathing technology in our industry, Gregory did his homework and figured out that 3PAR's mid-range F Class systems provide the same active/active multi-controller capability as the most expensive high end storage arrays. He has first hand experience with the scalable, mixed workload performance that is a 3PAR hallmark.
Just a note: Exchange admins who may be confused about Microsoft's storage statements regarding Exchange might want to check out what he says about their current use and future plans for Exchange running on 3PAR storage. Thanks for the kind words Gregory!
Funny things happen when markets retract. The growth requirement of corporate existence has to do extreme things and former industry friends find themselves at odds. The question before us today is whether or not Cisco is a manifestation of the economic bubble and - if they are - what are they willing to do to make it less obvious to investors. I guess server sales were not enough. Now its moving into data center services business too. The rumors about EMC and Cisco forming a services business appear to be true. Yes, if your margins are under attack in a stagnant market, you have to find other ways to separate customers from their cash. Voila!
To me, the interesting thing about this is the Dell/EMC relationship. After Dell bought EqualLogic, the talk was that Dell and EMC would fall apart, but both companies insisted they were good partners and that the relationship would continue for many years. This link is to VMware's VMTN forums in November 2007, the day the deal was announced - some might find my comment interesting, but from my perspective as an Equallogic blogger, it was a straight response.
But a couple years later, it appears that Dell likes selling EqualLogic more than it expected due to the higher margins than almost anything else Dell sells. I don't know whether or not this has had an impact on Dell Clariion sales, but judging by EMC's actions with Cisco to actively pursue Cisco UCS server services agreements at Dell's expense, it seems that things probably aren't the same between EMC and Dell any longer. There is no way to sugar coat this one. EMC and its large services business is going to do whatever it can to help new best friend Cisco replace Dell's, HP's and IBM's servers wherever they happen to be. Dell, lacking a competitve services business, must be astoundingly frustrated by being turned on by EMC this way.
It will be interesting to see how this impacts Cisco's reseller channel and if they will find themselves squeezed out by EMC hyper-competitive and jealous sales culture. There will be the usual words of inclusion and growth and a beautiful future together, but down in the trenches, blue sky is a figment of somebody else's imagination.
I'm waiting to see if either Dell EqualLogic or Compellent show up for the storage blog smackup started by EMC's the Storage Anarchist and taken up by yours truly for 3PAR yesterday.
The comments I'm imagining have to do with their business performance versus Clariion. Use an outside source. If you don't have one handy, just bring your best smack! Don't be like IBM and run for the covers - or Hitachi by blogging a week later and making vague references to past posts.
Recently I just discovered that the Storage Anarchist is not as old as (and maybe a few others) thought. That's good because it probably means he will be around for awhile entertaining us with his excellent writing and EMC-centric storage satire.
But how can he explain the omission in his most recent blog post of his own products from a graph attempting to denigrate Compellent and 3PAR? I suppose he will say it's because the graph published in the Register didn't show his own products, but he must have known that I would gladly fill in the blanks for him. Alas, I am concerned that he might have had a senior moment. It starts happening to guys our age -that's why the AARP starts sending cards to 50 somethings. We might forget that we're not really old farts and decide to join!
The graphic in question pulls data from a number of sources, including the financial analyst company Stifel Nicolaus, who had probably been used to fill in the EqualLogic Data after the Dell acquisition. The interesting thing is that Stifel Nicolaus has also done work estimating EMC's Symmetrix revenues since EMC stopped reporting them back in 2008. Now why would they have done something like that? Probably because they sucked.
And how loud was the big sucking sound? The chart below compares 3PAR InServ array sales with EMC Symmetrix sales from the beginning of 2006.
Now you can see why Anarchist thought we should be compared with some other companies, because in enterprise storage where 3PAR operates, we beat up his products - and he knows it. This is even after the addition of their bolt on catch up features and their overly-hyped expensive freaking doohickeys (flash SSDs) to the Symmetrix DMX products. Their differentiators aren't really differentiatin'.
3PAR is not the fastest growing storage company in the world, but we are happy to be where we are - continuing to grow our business and lead in real value-added innovation for enterprise storage.
Will EMC pay too much for DDUP? That's the question everybody is going to be asking for years. It's an awful lot of money, but de duplication of backup and archive data is probably going to be a very big deal for years to come.
I like Steve Duplessie's take on it: he said Netapp should feel relieved because they would have been under immense pressure. EMC, on the other hand, has a larger business and more ways to leverage their DDUP investment - such as their channel relationship with Dell. Of course, that would mean that Dell would have to agree to be even more dependent on EMC for their storage business.
Netapp gets a consolation prize - the $57 Million break up fee which will be paid by Data Domain. It's not a lot but I'm sure they can put it to good use. The larger problem for Netapp is how they are going to replace DDUP in their plans. Obviously there were things they wanted to do with DDUP that they aren't going to be able to do now. It will be interesting to see what their next move will be. There are other de duplication companies available if they want to grow their business that way.
The twittersphere has been abuzz about it, with most opinions (based on an informal and unscientific survey) indicating some disatisfaction or disappointment that Netapp's bid was not higher. The twit concensus is that Netapp's counter offer was weak.
I don't interpret it that way. Netapp's counter looks more like an offer-matching coupon that covers not only EMC's offer, but any that Dell might make as well - and possibly more.
FWIW, I don't think this is a case where EqualLogic systems are displacing Clariion sales - although some of that is probably going on - but is instead a case where EqualLogic storage is successful in SMB accounts just as it always has been.
3PAR and EqualLogic arrays are similar in the level of automation they provide, which saves storage administrators lots of time and effort and is why both are popular now. But other than that, the products are very different and developed for distinctly different types of customers, with some overlap in the medium sized business segment.
