via H-P-Dell Pits Dave vs. Dave – WSJ.com.

via Dell, HP bidding war for 3Par heats up – Computerworld.

via Dell Ups the Ante in 3PAR Bidding War — EnterpriseStorageForum.com.

1. HP wants to own the IP of high-end storage, not OEM it.
2. 3PAR is sort of the only game in town in the next high-end wave that can conceivably take on Symmetrix, USPV, or Shark.  Note I say conceivably.
3. HP believes (accurately) that 3PAR’s growth or lack thereof is due to their own scale issues, similar to what it saw in 3Com.  The 3Com deal is zooming ahead of plan due to exactly that–HP has a damn big sales and service company that is putting 3Com stuff into many more places than 3Com could do alone.  It feels the same deal with 3PAR.
4. It wants to own everything that begins with the number 3.

What About Dell?  I love the balls Mr. D showed initiating this deal.  The reality, however, is that Dell has more execution risk on this play than HP does.  HP is in this space, albeit via an Hitachi OEM’ed product, but they are in the space.  They have a TON of Hitachi platform customers that are ready made for a strategic swap out to 3PAR attack plan over the next few years.  Dell will have to start from scratch.  It’s not to say they can’t–they did well with EqualLogic by investing in the EQ model and not trying to consume it.  They could do the same with 3PAR but organic growth will take longer, and with EQ it was right in Dell’s customer base.  This will be a stretch for them.  Both Dell and HP have the services arms and the server reach to attack the 3PAR service provider base, but storage is a different animal.

If the deal continues on in this vein (a la Data Domain), Dell will probably have to get up to at least 1.8B, and probably closer to 2B to force HP’s next move.  That’s a very expensive gamble.

HP is betting that in their enterprise customer base they can plop way more 3PAR stuff in way faster than Dell can, and they are probably correct.  To justify a $2B valuation, they need to get to north of $1B in revenue (5x) really fast – no easy feat.  3PAR has 65% margins – something not lost on either of them.  Michael has seen the light, and the EqualLogic margins make him look like a genius.  Margin sustenance at the high-end of this market is sustainable, as most players have shown.  HP would like a piece of that pie.

So much for my peaceful day.

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

via 3Par buyout puts Dell in ring against IBM, HP — even partner EMC – Computerworld.

Why did they do it?  Two reasons – 1.  3Par was the only legit truly high-end competitor at the ranks of Symmetrix and USP and Shark.  If you wanna be in the storage business, you need to be in the storage business.  2.  HP would have bought them if Dell didn’t.

Why did they pay so much?  See #2 above.  There were others in the deal.

Is EMC going to be pissed off? They won’t be thrilled but they won’t exactly be pissed either.  80% of the Dell/EMC business is the CX120, AX, NS (NAS) and Data Domain stuff – none of which has any overlap at all with 3Par.  EMC will be pissed when Dell starts winning deals at the high-end, but they are already pissed when 3Par wins them, so net/net – they will be just as pissed as always.  No new pissing, at least for a while.

What will HP do now?  I don’t know.  I believe they need a high-end solution (that they own) and I’m not sure where they get it now.  They do have the capabilities to develop their own internally, but that will take time.  They can continue with HDS (or OEM from Dell!) for a while but one must think that this can only be a temporary sub-optimal play.  They are a big machine, however, and have been doing just fine for a long time so I don’t think there will be any panic maneuvers.

What about IBM?  Status quo.  IBM has really interesting mid-market stuff its about to unleash and this won’t derail any of that.

What about NAS at Dell?  They bought Exanet, a failed Israeli company, and will most likely integrate that file system into EqualLogic – and maybe now even 3Par.  It will take 12-18 months, however, so in the meantime they will either do business as usual (NS from EMC) or perhaps make a move.  I think they should buy Isilon – the effective file equivalent of EqualLogic, but they got expensive recently (funny what happens when you hit your numbers consistently!).

Summary:  Good for 3Par.  Super nice folk, great technology, great products.  David Scott is a gentleman above all, and has big company experience (HP).  He’s as cheap as the day is long, so he’ll fit right in at Dell!

Ballsy move, and if it works the way EqualLogic has (fast approaching $1B in sales), it will be a home run.

Read Steve’s other blog entries at The Bigger Truth.

Wall St., rightfully so, loves him.

HP, arguably, is in the strongest position it has ever been in–financially, market position-wise, and general positive “vibe”-wise.

Shitty time for foolish accounting irregularities, Mark.

But, it is what it is. Hurd is gone. So what next? And who?

The first problem is the who. There is not a large population of people competent to run a $130B icon of a company such as HP. A smart CEO in Austin recently told me that “anyone you’d want to tap for that job at that level already has that job at that level”–meaning, why would they leave?

What they probably need to do is what they did last time. They looked at a much smaller company with a leader with the attributes required for HP at this point in time. Hurd was perfect: ran a multi-headed company that was in chaos, cleaned it up financially, and put it on a path to success. HP was in chaos, losing money, spending foolishly, etc. I remember when they announced Hurd. I was in NY with storage stock god Jason Gold who told me, “Hurd is a rock star.” I’d never heard of him. Jason was right.

HP needed a boring, limelight-loathing, intellect to right the ship, take the hard line, and get costs in order. Hurd did exactly that. The results speak for themselves.

The next CEO doesn’t need to do that anymore. The next CEO needs to be Steve Jobs-esque. HP has its fiscal ship in order. Now it needs a shot of sex appeal. HP needs to make Hurd’s former job the COO position and bring in someone who can reshape the boring old company into a hot, sexy one. Apple, lest ye forget, was not sexy. It was a cultish geekfest in disarray. Jobs made it sexy. Girls now like Apple. Until girls like your company, you aren’t sexy. You are a geekfest.

A reporter asked me about Joe Tucci as a possible replacement. I think Joe would be great. I also think there is no way he’d do it. He’d be great because he is a CEO that can run a business with a LOT of streams (EMC was essentially a one-trick pony when he came on board, now it’s a conglomerate) and that’s what HP is. He won’t do it because A) he’s close to retirement, B) his ego isn’t big enough to want to do it instead of retiring, and C) he doesn’t need the money. There are probably a few Joe Tucci types that would be great at the job, but already have it (albeit on a smaller scale), that won’t take it because they are 60 something.

HP needs Hurd types: 50 somethings ready to make the step up. It’s a gamble for sure, but it worked well once, so why not again? I just think this time, the company is in an entirely different place and as such should look for an entirely different type of leader to propel HP to the next level. For the record, I’m against an insider being made CEO. COO, sure, but not CEO. This is an opportunity for new ideas and new blood. Promoting old blood doesn’t do it for me. No offense to the old bloods intended.

Read more of Steve’s blog entries at The Bigger Truth.

Mother nature is simply awesome. When you watch the relentless force of the ocean, it makes you realize that you are absolutely powerless to change things that big. All you can do is watch and try to survive. Makes me realize that what we are really meant to do is focus on the small things that we can affect–because aiming too high is a fool’s errand.

In our business, it’s the same thing: if we focus on issues too large to effect real change, we’re wasting time. If we focus too myopically without understanding how our actions fit (or don’t) into the bigger picture, we’re wasting time. If your job is to rake the beach, but you do it as the tide is coming in, you wasted time. If your job is to keep the tide from rising, you are really wasting time. IT admins can be beach-rakers. Senior executives like to focus on altering tides.

In IT, we spend way too much time on both ends of the spectrum. We either spend all our time on myopic efforts that have little bearing on the overall mission at hand or too much time trying to change the way our entire business operates in order to fit some neat IT process. Neither works.

Instead, it seems to me that it would be better for all concerned if we occasionally re-evaluated our situation and adjusted to current realities. It sure would be better for your mental health, if nothing else.

The easiest way to evaluate your situation, regardless of what that situation is, is to ask yourself “WHY?” Ask it over and over, like a two-year-old. Why are you doing what you are doing? Is what you are doing relevant to the overall mission? Is the overall mission reasonable and attainable? If, at any time, your answers are at odds with your intent, it’s time to stop. The key, of course, is honesty. You can convince yourself that you simply must find a solution for interplanetary replication, but you aren’t being honest. If you are, you’ll discover that you are wasting time.

There are 1,000 problems to be solved in your data center. Half of them don’t matter, but which half? Try to focus on ones that matter–that lead to a positive outcome. Stop keeping yourself away from the beach with the family because you can’t figure out lunar snapshotting. Ask yourself this: “What problem am I trying to solve? Why? If I don’t solve it, what is the real implication? If I do solve it, what are the real benefits?” If the answers are shaky, move on to another of the thousand problems to be solved. There will always be another problem, as sure as there will always be another tide.

What you should be asking yourself are things such as, “Is this task making me a better person, spouse, parent, friend–not just a better employee? Should I have a dark ‘n stormy or a margarita? If I look hard enough, can I see my kid grow right in front of me?”

As people we let our myopic lives get in the way of the big picture–mostly for the right reasons, but often to our overall detriment. We work because we need to support our families. We work more because we need to support our egos. We work even more because along the way we convinced ourselves that somehow that is how we measure ourselves. We need to solve solar deduplication problems. We just forgot why.

In reality, what businesses should learn is that the most productive, most valuable employees we have are those most grounded in what really matters. If you aren’t solid at home, you simply can’t be solid at work. If your kid is sick, who cares about how solar flare ups are causing reboots? Companies don’t succeed because the networking guru reconfigured a router perfectly. They succeed because the guy who did it still made it to his kid’s soccer game.

Work to live, my friends, don’t live to work. It’s easy to find yourself on the wrong side of that equation. I’ve done it many times myself. Summer is a good time to re-evaluate. Surf’s up.

Read more of Steve’s blog entries at The Bigger Truth.

Overview

Computer hardware used to be an expensive resource that had to be centralized and carefully managed. Historically, there was only one way to meet the growing demand for more resources and performance, and that was to scale up; the old mainframe, network switch, storage controller, or UNIX server got traded in for a newer, bigger, faster one.

That has all changed. Hardware is now a relatively low cost commodity, which has created a growing trend that moves organizations away from expensive, scale-up architectures toward commodity, scale-out architectures.

Scale-out architectures drive network flow in an edge-to-edge (from the server farms to the storage farms), rather than edge-to-core pattern (between enterprise platforms), fashion. This has a profound impact on network architectures, where the edge carries most of the traffic and the core manages lower volume transitive traffic volumes.

Transformational Directions

Figure 1 shows the main directional movements in networking and storage technologies.

• Structure: Market share has moved away from block to file structured storage due to its flexibility and ease of use. ESG predicts future storage solutions will be based on object stores with drivers that provide block and file presentation options for legacy systems.
• SAN: SAN ports are moving strongly in the direction iSCSI due to its lower TCO and management simplicity. Legacy Fibre Channel users will deploy FCoE as a bridging technology driven by the benefits of network convergence.
• Architecture: Scale-out has been a market leading approach for computing for many years, with significant activity in scale-out storage from HP, IBM, Isilon, and others. Most networks are still designed in a three-tier scale-up architecture, which is becoming increasingly expensive and inflexible, which in turn explains the trend toward two-tier networks.  With the new phenomenon of virtual machine “motion” occurring more regularly, network technologies are now required to adapt to these dynamic change conditions.  BLADE Network Technologies’s VMready is one example of this coming to fruition.
• Network: As intelligence and functionality, driven by the deployment of scale-out storage and computers, move to the edge and away from the core, networks need to adopt a more pragmatic edge-to-edge architecture.
• Protocols: The most prevalent LAN protocol will continue to be IP over Ethernet. The SAN will converge, initially into FCoE protocols to support legacy Fibre Channel deployments. Economics will drive a full migration toward IP protocols on the converged network.

Scale-out Architectures

The unbelievable levels of infrastructure performance today are still not enough for the largest Internet-scale tasks such as hosting Twitter, Facebook, or LinkedIn or managing search indexes at Yahoo or Google. The problem is that scaling up infrastructure just doesn’t meet the capacity demands of these enterprises, so they don’t do it anymore. Instead, they scale out at every level: compute, storage, network, application architecture, and even down to the database.

Soon, almost all devices will be connected to a network. Mass consumer trends in mobile telephony and personal digital assistants (PDA)—combined with integration of video, still cameras, GPS systems, and smart analytics—offer rich opportunities for adding value to all technology areas from social networking to national security. Trillions of electrically connected devices will be added to the network; electronic direction signs, traffic lights, parking meters, toll booths, surveillance cameras, and number plate recognition systems are already revolutionizing traffic management in cities such as Seoul, South Korea.

This Internet-scale problem is becoming more common; more organizations are processing huge volumes of data in near real-time. Developers are beginning to create scale-out solutions and applications. They are adopting a MapReduce style approach to coding where a set of master processes splits the problem into a number of smaller parts and then farms them out to a large number of processes that derive the answer. The master processes then combine the answers to deliver a single consolidated output. For the largest scale computational problems, this is often the only way to get to an answer in a meaningful time frame.

A Scale-out Approach to the Problem

Keeping Data and Computing Independent, but Close

These Internet-scale solutions need to separate compute and storage nodes to enable massive parallelism while maintaining high performance, low latency connectivity between active processes and the persistent data sets they need to manipulate. Scale-out or distributed file systems (such as Apache Hadoop Distributed File System (HDFS) and Google File System (GFS)) provide support for rack awareness—ensuring that the compute element is in the same locale as the storage element. Edge-to-core networking has no place here as almost all traffic flows from edge to edge.

Network Convergence

For some time, the networks (LANs) carrying data flows from server to server and from server to consumer have been separated from the storage area networks (SANs) carrying traffic from server to data storage. The reasons for this are fairly straightforward: LAN flows expect (and are designed to manage) congestion and variable latency as well as occasional data loss, while SAN flows do not. SAN latency and data loss typically cause poor application performance and data consistency problems.

High capacity (10GbE, 40GbE, and eventually 100GbE) lossless Converged Enhanced Ethernet (CEE), also known as Data Center Bridging (DCB), changes the rules for storage traffic. CEE can deliver data storage flows reliably and without latency or loss, eliminating the need to maintain a separate storage network. Firms like BLADE Network Technologies are well positioned to support these demands for a combination of network convergence and edge-to-edge connectivity with an open standards approach that enables interworking with Cisco, Brocade, and other vendors using their BLADE Unified Fabric Architecture (UFA).

The Economics

There are very strong economic drivers for converged SAN and LAN connectivity at the edge. The cost per GB of data transferred is twice as much for 8GB Fibre Channel as for 10GB Converged Enhanced Ethernet. So, by converging the networks into CEE, total capital spending is reduced by as much as two-thirds and cabling cost and complexity are reduced by as much as half. Converged networks enable wire-once-and-forget approaches to the data center.

What is the Right Protocol for Storage Networks?

Use cases are demanding more granular control of data. For example, does the data need to be geographically replicated, need to have enhanced protection, or need to deliver higher performance? Block structured data offers limited capability in this area; NAS and object stores provide the promise of rich metadata and significantly more granular control. Scale-out architectures overcome the perceived performance penalty except for the most extreme RDBMS requirements.

As data moves from block to file storage and onto object structures with rich metadata, block protocols like FCoE or iSCSI are replaced by NAS protocols such as NFS and CIFS and then by object protocols such as HTTP or URI. All, with the exception of FCoE (which is still rooted in the legacy of Fibre Channel) are IP-based and can be routed, isolated, and managed in the same way as normal LAN traffic.

What Does a Scale-out Network Look Like?

In a scale-out network, racks are filled with high-density compute nodes, each with a large memory footprint and large numbers of cores and sockets all interconnected via 10G CEE top of rack switches. LAN and SAN protocols are converged, with most systems choosing IP-based storage connectivity (iSCSI, NAS, HTTP). Storage platforms are placed close by and also interconnected via 10G CEE top of rack switches. Each switch is connected to a pair of end of row switches via 40GbE uplinks.

In these large 1000+ port network domains, most traffic flow is edge-to-edge between the computing elements and the storage elements. Congestion control is managed from within the domain and is visible and manageable at the edge.

Scale-out networking follows the logic that most network traffic in a scale-out world is edge-to-edge, so why bother with a massive capacity, core network? Instead, converge on 10G CEE using top of rack switches supporting iSCSI, NAS, and HTTP protocols to converge the SAN and LAN into a common routable IP system.

These networks are incrementally additive; as new workloads are introduced and new compute and storage racks deployed, top of rack switches are added at the same time. This approach avoids the conventional waterfall investment strategy where all network equipment needs to be installed and wired before the first server is installed. In scale-out networks, the core is much diminished in importance. The differentiator is the adoption of open standards, low power, low latency, and low cost modular switches that can be added incrementally as the compute and storage capacity of the data center grows.

Scale-out Storage

Scale-out storage is also a growth industry with vendors like NetApp, HP (IBRIX), and IBM gaining traction. Object storage is also gaining popularity, with URI or HTTP protocols such as Amazon S3 becoming commonplace. Scale-out storage lends itself to Ethernet connectivity leveraging the lower costs of CEE adapters and switches.

Scale-out Databases

Scale-out databases are now commonly referred to as NOSQL databases that go back in time to pre-relational designs that do not provide atomicity, consistency, isolation, durability (ACID), or consistency guarantees but allow sharing to split the data sets over multiple nodes to improve parallelism and scaling of the overall system.

Analysis

The computer industry changes only gradually, building on the legacy of past. We are guided to the future by gradual changes in thinking and behavior driven by global business, governmental, and economic trends. Scale-out architectures will be a significant part of our future.

• Scale-out is becoming a common approach, is gathering momentum in storage, and is beginning to catch on in networking.
• There are a number of highly visible use cases for analyzing the data thrown up by myriad network-connected devices in near real time.
• The number of organizations needing massive scale analytic support is expanding rapidly.
• Scale-up architectures are unable to deliver the raw power and throughput needed.
• Application architectures are changing to enable use of scale-out approaches. Progress is being made in the open source world, with vendors following closely behind.
• The cost differential between commodity components and specialist scale-up components is growing particularly in the networking space driving procurement choices.

Is Scale-up Finished?

Not all applications will lend themselves to a scale-out architecture—either because they are strongly transactional and require referential integrity between transactions or need to be run sequentially, such as mainframe batch processing. Some of these applications and use cases could benefit from an alternative approach that may well fit with a scale-out, or hybrid, architecture.

Certain high performance computing (HPC) use cases demand ultra high scale-up performance. Conventional relational databases with atomicity, consistency, isolation, and durability (ACID) guarantees can be partially scaled-out via clustering; in the end, they demand high clock speeds, high performance networking, and high performance disk subsystems.  In these limited cases, a scale-out architecture may not be the right answer.

The Bigger Truth

Organizations are demanding previously impossible levels of performance and throughput to support large-scale analytics. Vendors are leveraging the economics of commodity hardware combined with smart software to deliver scale-out products that not only deliver massive aggregate throughput but also can provide cost effective and flexible service to ordinary workloads.

Buyers love the economics and flexibility of scale-out computing where increases in demand do not lead to a complete re-architecture of IT infrastructure. Scale-out offers the promise of public cloud economics in the private cloud.

The last dominions of scale-up thinking remain in networking and database designs. NOSQL approaches are challenging the very largest scale database architectures while top of rack edge-to-edge network designs such as BLADE’s UFA are providing practical, cost effective scale-out network solutions in the data center.

I mentioned Greenplum and Vertica specifically as key ingredients to stem the threat–because they can eliminate the need for the heart of Oracle’s attack–the database.

Greenplum builds a database designed from the ground up for massive scale–the kind required by data warehouses and BI systems.  They do it far more effectively and a billion times cheaper than systems using the Oracle RDB to keep track of, and provide analysis on everything.

With that in the arsenal, EMC now has a shot to at least stem the tide of Oracle Exadata defections–and even more, can offer a more compelling overall solution to the problems of massive data sets.  The issue will be simple–Oracle knows how to sell this stuff, EMC (traditional) doesn’t.  Oracle DW/BI people speak that language–to the right buyer–who is NOT THE INFRASTRUCTURE BUYER!!!!

The BI/DW buyer is a business apps person–not someone who cares in the least about spinning disk or cache or whatever.  EMC will either need to teach their high-end force a new language and the ways of a new customer set, or figure out how to keep that separate from the mainstream as they have done with their other successful software acquisitions.  My guess is they will do the latter, but I don’t know yet.

Unlike VMware or Documentum, for example, this play DIRECTLY affects EMC’s bread and butter hardware offerings.  When Oracle sweeps the floor with an Exadata deal, they sweep out Symmetrix, HP boxes, IBM, etc., and there really isn’t a heck of a lot to be done about it.  This is perhaps why EMC did what they did–and I give them credit for seeing it for what it is and doing something about it.  Why let Oracle dictate the game?  With VMware, Springsource, and Greenplum, one can make some pretty compelling software arguments as to why this combination is the face of massive data set management in the future.

I love the play.  Kudos for a ballsy move.  After Data Domain, I’m not going to challenge their ability to pull off the execution again.  I’m just dying to see this play out.  It’s like a heavyweight fight in the making.

Interesting final note – Oracle owns Sun, Greenplum was founded by some Sun folk, Scott McNeally is on the Greenplum advisory board…….

Read Steve’s other blog entries at The Bigger Truth.