Well, Tuesday came and went and we finally go the big announcement from Apple's Tim Cook. As usual, the world was focusing on all the fun toys - the "boxes" - and, to a large extent, Apple delivered the usual array of sustaining innovations that will make their competitors seethe for the next 6 months. Despite the inevitable critiques, and the occasional gaffe (Maps, anyone?), the products will sell and achieve wide adoption. All this will happen in the face of withering competition from the commoditization experts in Asia. What got my attention yesterday, though, was one of the more modest announcements that is likely to get forgotten until it really matters, i.e. when someone's business is disrupted: Apple is giving away productivity software with it's new machines.
As I type this article into my MacBook Pro, while controlling my stereo from my iPad sitting across my desk, I feel like I should repeat what I have said before: The slave-like attention to integration, user experience, and polish will always win out over gimmickry and slipshod commoditization. For this reason, I think it is quite significant to consider what Apple is doing here, and what it portends for product development trends going forward. There's always an underlying strategy to these types of moves.
First, for the Apple fanatics amongst you, it surely has not gone unnoticed that MS Office on the Mac has become somewhat of a second class citizen. While the Windows suite was recently refreshed, it appears that the Mac version has not had a major refresh since 2011. More importantly, MS has chosen not to support any of the iOS platforms with its flagship productivity suite. There are two consequences of this decision, and both are bad for my friends in Redmond. First, it makes the lives of Mac users more disjoint and unpleasant if their data is locked up inside Office documents that they cannot edit from iPads, Minis, and iPhones. This gap creates opportunities for other people to fill the missing bits, by offering apps to provide the missing functionality. In Apple's case, it also allows them to provide customers a chance to experience what an integrated suite might look like. If you haven't tried the iWork suite, you really might want to now, especially the touch enabled versions for the tablets. Unsurprisingly, you might even start to prefer iWork over the collection of things you have now.
The flip side of this is that Microsoft is not moving the user interface idiom forward on the Apple platform any more. The future is touch and mobile, and we already know Microsoft is not there today even on their own Windows OS. They will proceed to lose ground as the masses continue to buy iPads in lieu of Windows laptops. You would think that learning to get tablets and touch right should be a strategic imperative. Apparently this is not so for them, unless it manifests itself in Windows first. They seem to have forgotten that they themselves learned how to build a GUI by building Word and Excel for the Mac long before Windows was around. In the old days, Microsoft used to be too paranoid to let these kinds of things happen. I don't think it's too far-fetched to infer that with hundreds of millions of iPads out there, it would only take a few good features in iWork to seriously damage Office. Not supporting these devices is very dangerous for MS.
The most profound part of this move, however, is the continuing theme of vertical product integration that is sweeping the low end of the technology industry. I have been talking about it for quite some time in the context of some of the things we did at EqualLogic with iSCSI storage: The lower end of any market abhors complexity. You cannot sell them a bucket of parts and expect them to build a solution from it. They will reward the manufacturers that pull together an end-to-end experience that is flawless and integrated. This is something that is unique to technology - people are afraid of it, and are always looking for an easy way to use it. EqualLogic ran the same playbook as Apple has been running: They are building all the software into a single package and polishing the experience to delight their end user. That package is a single system, either a laptop, or a tablet. In our case it was a storage array.
The big idea to draw from all this is that technology mass markets will continue expect these vertically integrated solutions. We see Apple gradually extending theirs this week. We have been seeing Microsoft doing the same thing with their Slate line and, more recently, their acquisition of Nokia's tablet and handset business. We even see it happening in various parts of the IT infrastructure markets, where more integrated, easy to use products are favored over those that require specialization. This is a mega trend that will affect people's expectations of how to consume technology. More importantly, it will substantially raise the bar for those who want to build that technology.
Showing posts with label De-commoditization. Show all posts
Showing posts with label De-commoditization. Show all posts
Wednesday, October 23, 2013
Saturday, September 28, 2013
Software Defined Storage - Zombie Box Huggers are Winning
In all honesty, I first submitted the abstract for a talk on Software Defined Storage to SNIA very early this year. It seemed like a different world then, and I really had no idea what I was getting into. For the purposes of full disclosure, I was the sponsor for an SDS project before I left Dell, and so I had spent a lot of time sifting through all the data and the nonsense that surrounds it. It felt apropos to put together a talk on what we had learned about the topic: the use cases, the technologies, the market, and the business. In the intervening months, something happened out there to cause the topic to become an epic technological hot potato. I've now given two talks at two separate conferences, and served on two panels, all in the vain attempt to place a clinical definition on SDS. I don't think that such a definition will be possible. Additionally, I want to make it clear: I am a skeptic when it comes to the products on the market today. Let's talk about my somewhat slanted viewpoint:
SDS is Like Tobacco...
While this may sound like a cruel metaphor, it is apt. You can substitute alcohol, or any other recreational drug here, but the relationship would be the same. There is a short term buzz you get from the products, but there are long term problems and dangers that need to be managed. The sellers are fundamentally hoping that you are adult enough to not go on a bender and crash your car, or destroy yourself in some way, so you can keep coming back. There are use cases where the products work, but one should be very wary of assuming that, in a super-competitive industry, storage arrays are so massively mis-priced that it is economically advantageous to construct one from parts. Integration and testing is a huge task that effectively "de-commoditizes" all of the storage products available today. A bug that has a .1% chance of occurring may seem like an acceptable risk with 4 disks. With 100 disks, you have a different calculus to consider.
One of the comments that I heard at SDC is that we have effectively unlearned all the things that we learned 20-30 years ago about creating resilient systems from cheap disks. This isn't entirely true. What we have learned is that there may be better ways to get storage resiliency at very large scale. It's a sexy concept, and those who think they have the physical scale necessary owe it to themselves to try it. Those without cloud-sized data centers need to consider the possibility that the best bet is to rent disk space from companies that have the mass, i.e. Amazon, Google, etc. Trying to convince someone that they can be Google or Amazon if they only just bought your software, is much like selling steroids to people who don't work out. Nice story, but missing key facts.
The Box Huggers Are Not Who You Think
It has been a long-speculated axiom of storage that the people want boxes. If you want to sell storage, you need to put it in a metal box and sell it. Upon much contemplation and discussion on the topic, I have come to the conclusion that his has more to do with economics than anything else: customers are used to buying capacity and sellers are used to selling in the same manner. In fact, there are very few people who have gotten past the notion of paying for something other than capacity. Generally, this is how storage works: you have some data of a particular size, and you want to put it in storage commensurate with that size. The more hazy your needs are, the more likely you will overbuy and hence overpay for your need.
It should not be a surprise then, that the people who are most religious about clinging to boxes tend to be those who are selling them. In full disclosure, I have to confess that I may be one of this cohort. It really represents the easiest way to comprehend what you are selling and what the customer is buying. You would like to be able to offer X Terabytes of highly available storage, with quantified performance, up to N LUNs, up to M snapshots, etc. This is really an indication of tested limits more than anything else, and it should be construed as a support statement from the vendor to the customer. Without that metal box to test, guaranteeing any level of performance or functionality can quickly spiral into an unbounded problem. Hence, we love boxes more than anyone. Perhaps this is why many perceive that the market is troubled by the encroachment from the cloud scale services such as Amazon's and Google's. Nonetheless, the box hugger's view of the world is that any product without clearly defined and testable performance objectives is fundamentally a toy.
Most Customers Are Actually Data Huggers
In my wanderings over the last decade, I have met many, many customers who buy and manage infrastructure. The one most important commonality among all of them is how tightly the security of their employers' data is tied to their success. The word "security" in this case is not to be understood as only protection from intrusion, but also its availability, performance, and the general control of its destiny. That last item - control - is perhaps the most important of all. Putting their data in the cloud gives them the same detachment that they get from sending their kids off to college. Risking data loss is so unacceptable, that making copies and scattering them in as many places as possible seems to be de rigueur. That is pretty paranoid.
This should be a hint to everyone. There is a mentality evident among many software vendors that their role in providing the aforementioned security can be conveniently redlined above the disks or the hardware platform or the network. I don't think that there is a bias against software only solutions. Rather, it's evident that the data-hugging masses aren't getting the feelings of security that they need to widely adopt the approach. As I said in the panel discussion last week, this is less of a technical problem and more of a business model problem. If a model exists that allows the technology to be delivered to customers with the warm, fuzzy feeling of control, I'm sure this market will find it. I don't see one right now.
So what will happen? Without some major redirection, it's clear that there is going to be a shakeup of sorts in this space. The minority of shops that have the expertise, the mandate, and the spare time, will make their choices. The bulk of those choices will be for free software because that is the easiest way to rationalize the internal support costs of the do-it-yourself approach. In the end, the paying market for many of these solutions will not be large enough to support all the players. The winners will be either open source (i.e. profit-free), or solutions incorporated into existing platforms at no extra cost (watch VMware and Microsoft here). Finally, without addressing the needs of the data hugging mid-market, its hard to see any of these products seeing more than limited acceptance.
I'm pretty flexible with my opinion. I change my mind when the facts before me change. Right now, this is what I believe.
SDS is Like Tobacco...
While this may sound like a cruel metaphor, it is apt. You can substitute alcohol, or any other recreational drug here, but the relationship would be the same. There is a short term buzz you get from the products, but there are long term problems and dangers that need to be managed. The sellers are fundamentally hoping that you are adult enough to not go on a bender and crash your car, or destroy yourself in some way, so you can keep coming back. There are use cases where the products work, but one should be very wary of assuming that, in a super-competitive industry, storage arrays are so massively mis-priced that it is economically advantageous to construct one from parts. Integration and testing is a huge task that effectively "de-commoditizes" all of the storage products available today. A bug that has a .1% chance of occurring may seem like an acceptable risk with 4 disks. With 100 disks, you have a different calculus to consider.
One of the comments that I heard at SDC is that we have effectively unlearned all the things that we learned 20-30 years ago about creating resilient systems from cheap disks. This isn't entirely true. What we have learned is that there may be better ways to get storage resiliency at very large scale. It's a sexy concept, and those who think they have the physical scale necessary owe it to themselves to try it. Those without cloud-sized data centers need to consider the possibility that the best bet is to rent disk space from companies that have the mass, i.e. Amazon, Google, etc. Trying to convince someone that they can be Google or Amazon if they only just bought your software, is much like selling steroids to people who don't work out. Nice story, but missing key facts.
The Box Huggers Are Not Who You Think
It has been a long-speculated axiom of storage that the people want boxes. If you want to sell storage, you need to put it in a metal box and sell it. Upon much contemplation and discussion on the topic, I have come to the conclusion that his has more to do with economics than anything else: customers are used to buying capacity and sellers are used to selling in the same manner. In fact, there are very few people who have gotten past the notion of paying for something other than capacity. Generally, this is how storage works: you have some data of a particular size, and you want to put it in storage commensurate with that size. The more hazy your needs are, the more likely you will overbuy and hence overpay for your need.
It should not be a surprise then, that the people who are most religious about clinging to boxes tend to be those who are selling them. In full disclosure, I have to confess that I may be one of this cohort. It really represents the easiest way to comprehend what you are selling and what the customer is buying. You would like to be able to offer X Terabytes of highly available storage, with quantified performance, up to N LUNs, up to M snapshots, etc. This is really an indication of tested limits more than anything else, and it should be construed as a support statement from the vendor to the customer. Without that metal box to test, guaranteeing any level of performance or functionality can quickly spiral into an unbounded problem. Hence, we love boxes more than anyone. Perhaps this is why many perceive that the market is troubled by the encroachment from the cloud scale services such as Amazon's and Google's. Nonetheless, the box hugger's view of the world is that any product without clearly defined and testable performance objectives is fundamentally a toy.
Most Customers Are Actually Data Huggers
In my wanderings over the last decade, I have met many, many customers who buy and manage infrastructure. The one most important commonality among all of them is how tightly the security of their employers' data is tied to their success. The word "security" in this case is not to be understood as only protection from intrusion, but also its availability, performance, and the general control of its destiny. That last item - control - is perhaps the most important of all. Putting their data in the cloud gives them the same detachment that they get from sending their kids off to college. Risking data loss is so unacceptable, that making copies and scattering them in as many places as possible seems to be de rigueur. That is pretty paranoid.
This should be a hint to everyone. There is a mentality evident among many software vendors that their role in providing the aforementioned security can be conveniently redlined above the disks or the hardware platform or the network. I don't think that there is a bias against software only solutions. Rather, it's evident that the data-hugging masses aren't getting the feelings of security that they need to widely adopt the approach. As I said in the panel discussion last week, this is less of a technical problem and more of a business model problem. If a model exists that allows the technology to be delivered to customers with the warm, fuzzy feeling of control, I'm sure this market will find it. I don't see one right now.
So what will happen? Without some major redirection, it's clear that there is going to be a shakeup of sorts in this space. The minority of shops that have the expertise, the mandate, and the spare time, will make their choices. The bulk of those choices will be for free software because that is the easiest way to rationalize the internal support costs of the do-it-yourself approach. In the end, the paying market for many of these solutions will not be large enough to support all the players. The winners will be either open source (i.e. profit-free), or solutions incorporated into existing platforms at no extra cost (watch VMware and Microsoft here). Finally, without addressing the needs of the data hugging mid-market, its hard to see any of these products seeing more than limited acceptance.
I'm pretty flexible with my opinion. I change my mind when the facts before me change. Right now, this is what I believe.
Wednesday, August 14, 2013
Grabbing For Pennies in Front of an Oncoming Locomotive
I was trying to think of a good title for a post on "Software Defined" stuff, and I settled on the above as being apropos. Apologies to all the believers I may offend in the next few paragraphs. It's not that I think this stuff can never work. (It can.) It's just that people tend to confuse the outcome with the means. The implication to something being Software Defined is that it is not tied or reliant on particular hardware... or ANY hardware. I think that one needs to keep the dialog centered by going back to that definition when things start to get screwy.
The common misconception that I want to discuss is the idea that, in any system, if you break out the software from the hardware, you somehow get huge cost reductions that flow directly into your (i.e. the end user's) pockets. Sorry to tell you this: The world just doesn't work that way. For some reason, though, this idea has become almost zombie-like. No matter how hard one tries to dispel it, it keeps coming back to life.
To understand why you can't just take apart a system product and expect uniform results from assembling it yourself, it is necessary to understand what goes into building a storage array, or a switch, or any technology platform. First, understand that rack mount, industry-standard, Intel-based servers are not commodities in the strict sense of the word. A commodity is a good that cannot be differentiated in the marketplace, i.e. the processes that create them are well known, and the products are identical. Think of a lump of coal.... or gasoline. While it can be argued that servers have been commoditized, that does not really mean the same thing. Technology goods are actually a lot more complicated than a lump of coal. There is a lot of manufacturing finesse that goes into them, and the fact that they are selling for pretty slim margins is an artifact of market dynamics more than anything else. (Digression: the dynamics of the server component supply chain are more frightening than you might think at first)
More to the point, that a server is assembled and sold for so little monetary gain means that the manufacturing process has been streamlined to the point where a few key things are not being done. In my world, we call this "integration", or maybe you know it as something else: "testing". Hence, when you assemble a system with a chip set from vendor A, memory from vendor B, a network card from C, disks from D, an operating system and application stack from E, and then you run a particular workload; well... you can be assured that not a whole lot of time has been spent making sure this thing holds together. This is what teams of smart people do at EMC, Cisco, NetApp, HP, Dell, and a bunch of other places. In order to accomplish the task, they have to narrow down the components to the point where they are not interchangeable. Then, to make you feel better, they offer to stand behind their work if there is a problem.
There may be a contingent of people out there that believe testing and qualification is something they can do without if they can reap the extra 20% of cost gains. Maybe, if they are lucky. The sad truth is that when some component in the commodity stack proves to be defective, you will need an engineering staff to test and diagnose it - a very time consuming and expensive process. Then, if you do happen to find the root cause of your troubles, you really wont have a lot of leverage with the manufacturer unless you are a buyer of significant scale... meaning millions of units. So, finally, you end up with a lot of expensive wasted time and a cardboard box full of broken parts.
Ultimately, the cost of a small number of bad experiences can wipe out the benefit from years of being lucky. In essence, you have a comparatively small, well defined financial upside: the money you saved. Your downside is all the debugging, diagnosing, and down time; which, can easily wipe out the gains from any upside. As the title of this post suggests, this a suckers' bet. Unless you think you can cover your downside, be very careful.
This doesn't mean that unbundling the software from the hardware in a solution has no benefits. In fact, there are many of them, and I may talk about them when I am feeling less cynical. The key point is that the cost savings is not normally going to be part of the benefits. Hence, focusing on cost really misses the point of building out the ecosystem.
Subscribe to:
Posts (Atom)