On Disruption

A few months ago, there was an email thread at my employer asking the question if All-Flash Storage was a “disruptive” technology. Disruptive, in the business sense, refers to Clayton Christensen’s definition of the term from his book, “The Innovators’ Dilemma”.

This, from a year ago, Christensen reviews his concept:

What Is Disruptive Innovation?

However, I think this is a narrow, and perhaps obsolete definition. He says Uber is not disruptive, because it did not originate in the low-end or new-market segments. However, while Uber did not disrupt car for hire, it did disrupt the capital model of cars for hire, and it did disrupt the medallion licensing model. Then the article also talks about how Netflix, in its original format (DVDs by mail) attacked an underserved periphery—not the low end, and not a new segment—of the market.

If we use the pure Christensen definition, All-Flash Arrays (AFAs) are not disruptive, but HyperConverged Infrastructure meets the definition. But perhaps we should look more broadly at the definition.

“The Innovator’s Dilemma” is 20 years old. It was written during the Dot-Com boom. Business books are not canonical. If they were there would never be revisions and follow-ons.

I think we need to take a wider view of disruptive technologies. Uber disrupted car for hire capital and licensing models. Driving an Uber is much less expensive than buying a taxi medallion, so the cost of entry was disrupted.

So how does that apply to AFAs? We know cost of IOPS is much lower with AFAs. We also know the costs of sizing and performance management dramatically decrease. One can argue the TCO of AFAs is lower. While AFAs did not enter at the low-end or a new-market segment, it did enter at a periphery, at a market segment (high transactional performance storage) where it offered a lower cost. AFAs disrupted a market segment of the overall frame storage market. Not the Mainframe attach segment, and not the extreme reliability segment, but at the assured high performance segment.

But here is another aspect of AFAs I am seeing—they mandate changes to a customer’s operational model. AFAs were made cost effective in part by using data reduction technologies (deduplication and compression). While there were some hard-drive based storage arrays which leveraged data reduction technologies (NetApp FAS, EMC Celerra, Sun/Oracle ZFS based arrays), these data reduction technologies were not available on high-end frame storage (EMC Symmetrix/DMX/VMAX, HDS USP/VSP, IBM ESS/DS8000). These data reduction technologies worked well for certain workloads: virtual machines benefited from deduplication, and OLTP databases benefited from compression.

This meant AFAs with built-in data reduction, targeting small, peripheral workloads (VDI, high-transaction OLTP), were set up for easy success.

However, at the same time other trends were occurring. To more effectively leverage the expensive high-end frame storage, some DBAs were turning on compression within their database software. Yes, this increased the number of CPUs needed to run the database, and increased their cost, but often DB licensing was a sunk cost. It was also possible to compress at the OS/filesystem level. It was not unusual in organizations where IT departments charged back storage capacity to users, for users to turn on compression in their servers to reduce their chargeback.

The second thing that happened over the last five years has been the fear of a data breach. This has driven the need to encrypt data at rest. While storage arrays offer this capability through Self-Encrypting Drives, encryption boards, or software encryption running on the array’s controller, often enabling storage encryption could only be done after upgrading the storage array to a new model. As a result, turning on encryption at the application level (i.e., the database), at the OS level (encrypting file systems), or at the VM level (using products like HyTrust) was a much faster path to security for many customers. Also, customers were assured only host level encryption ensured data was encrypted “over the wire” in addition to at rest.

The result of either of these technologies is it eliminates ability of the data reduction technology in the storage array to provide any benefit, and it returns the cost per gigabyte of flash storage to what it was with early generation, non-efficient architectures, which ultimately lost out to the AFAs with built-in data reduction.

The only way to benefit from an AFA’s data reduction features are to ensure applications and operating systems are not running host level compression or encryption. It may mean ripping out products like HyTrust and Vormetric. It may mean internal battles with DBAs. It may mean new terms and conditions in internal SLAs and storage chargebacks. The All-Flash Data Center sounds innovative on paper, but implementing it means working across traditional IT divides of applications, servers, security, and storage.

There are some data types which are natively compressed. For example, all the current Microsoft Office file formats are compressed. Additionally, most image files are compressed. Traditional file shares full of PowerPoint files are not going to benefit from AFA data reduction. Generally these workloads have never rated high-performance storage, and because of the lack of reducible data, it will take more time for the cost per gigabyte of All-Flash storage to come down to a point to provide the necessary payback to justify migrating these workloads to flash.

Why did I go down this path? It was to point the potential limits of a disruptive technology. When AFAs were narrowly applied to certain workloads, there was a cost-benefit which accelerated their adoption. When they are applied more broadly, they hit organizational barriers to adoption. Perhaps these barriers mean AFAs do not fit the definition of a disruptive technology. However, in IT I see many “disruptive technologies” which ultimately force significant operational changes on IT organizations. That was true for UNIX, Storage Area Networks, Windows, Linux, and VMware. It will likely be true for All-Flash Storage, Software Defined Networking, and adoption of Cloud Computing.

Why is There Not More Scepticism on Climate Science?

I continue to be surprised at how many people, especially Millennials (who are supposed to be skeptical), take "Climate Change" as gospel, despite evidence of highly questionable, and in some cases fraudulent science, such as the math used in Mann's "Hockey Stick" formula, and other questionable science revealed in the East Anglia email leaks.

Here are the questions I pose to anyone on the topic:

• What percentage of warming is due to CO2 emissions due to the burning of fossil fuels?
• What percentage of warming is due to other man-caused reasons?
• What percentage of warming is due to changes in solar activity?
• What percentage of warming is due to changes in other natural reasons?

Given observed questionable surface temperature measurement stations, and a noticeable difference in surface station temperatures and atmospheric temperatures, do Climate Scientist's heavy dependence on surface temperature measurements lead to unreliable results?

Source: New study shows half of the global warming in the USA is artificial

Source: 7 questions with John Christy and Roy Spencer: Climate change skeptics for 25 years

Given many Climate Scientists claim solar activity plays no significant role in Climate Change, but other Climate Scientists claim the significant pause in global warming is due to a decline in solar activity, how trustworthy is the climate science regarding solar activity?

Source: New study claims low solar activity caused "the pause" in global temperature – but AGW will return!

Source: Tiny Solar Activity Changes Affect Earth's Climate

Given one can insert random numbers into Michael Mann's equation and still produce a "Hockey Stick" output, how trustworthy should Dr Mann's science be considered?

Source: Michael Crichton - On Michael Mann's Climate Temperature Graph

Given evidence scientist Keith Briffa selectively picked evidence to support his desired outcome, and discarded evidence which did not support his desired outcome, how trustworthy should Dr Briffa's science be considered?

Source: YAD06 – the Most Influential Tree in the World


Given evidence scientist Philip Jones stated he used Michael Mann's "trick" to "hide the decline" of late 20th century cooling to overstate warming in the industrial era, how trustworthy should Dr Jones's science be considered?

Source: Climategate reveals 'the most influential tree in the world'

Source: IPCC and the "Trick"

Given climate scientists refused to allow critical peer review of their research, and only allowed it to be peer-reviewed within their tight circle of fellow climate scientists who believed the same way they did, how trustworthy should their science be considered?

Source: The tribalistic corruption of peer review – the Chris de Freitas incident

Given climate scientists working at government organizations refused FOIA requests for details of their research, how trustworthy should their science be considered?

Source: Climategate: James Hansen Finds Complying with FOIA To Be Too Much of a Burden


So there it is. Why not more skepticism, not that temperatures are rising, but skepticism of the science? I have said repeatedly, Climate Science is a Social Science, not a Physical Science. It is more about computer methods and curated data, and less about measurement. And other Social Science is held to much greater skepticism than Climate Science.

UPDATE:

Now there is this. The data used to dispute the "pause" in Global Warming is in dispute. By definition, science based on data that is in dispute cannot be considered "settled".

Exposed: How world leaders were duped into investing billions over manipulated global warming data

"True" Private Clouds

Wikibon is talking about "True" Private Clouds. I think their definition is too narrow, and gets into the weeds. It misses the true customer of a "true" private cloud. And there are two customers. The first is the organizational customer that purchases a private cloud. The second is the internal end-consumer of cloud services.

To Wikibon's credit, the definition of "Private Cloud" is an issue that needs to be addressed. In my career I have seen too many organizations overuse the term "Private Cloud". I have seen a VMware cluster deployed on disparate hardware with no upper level cloud management platform called a private cloud. I have seen converged infrastructure, acquired but managed identically to non-converged infrastructure (as discrete components each managed by their functional staff) called private clouds.

Converged infrastructure plays a role in a private cloud, be even that term is challenged. I have seen disparate servers and storage, purchased separately at different times, cobbled together and called converged infrastructure after the fact. I have also seen single-SKU converged infrastructure broken apart, support for component infrastructure separated, and individual components upgraded on different life-cycles.

From an operations perspective, I have seen mature IT organizations in large enterprises provide similar levels of managed services as traditional managed service providers. I have also seen the converged infrastructure single-support model dramatically fail organizational customers, and provide no better single support that that provided by an reseller or managed service provider.

If the goal of a "true" private cloud is to provide a similar level of service offering to internal end-consumers they receive from a public cloud, but with higher levels of compliance and data sovereignty, then much of the detailed requirements Wikibon mentions are not necessary. As long as the organization can provide an offering to internal end-consumers which is competitive (on cost,  ease of consumption, and reliability), it should meet the definition.

Here are what I believe are required of a "True" Private Cloud:

• Acquired in consolidated units of management, virtualization, compute, network, and storage with common amortization, and common life-cycle management.
• Components supported as an integrated whole, with a single number, first-call support model, and escalated support abstracted from the internal end-consumer.
• Compute, storage, network, and virtualization managed as a single entity by a single, cross-functional team.
• Provisioned and managed via a cloud management platform (CMP).
• Consumed by internal end-consumer as a shared resource in logical, not physical increments, i.e., VMs and GBs.
• End-consumer offerings include multiple performance and data protection SLAs.
• Provides charge-back to internal end-consumers.
• Provides the Private Cloud operator performance, capacity, and licensing budgeting of the infrastructure; performance metering and capacity measurement to manage over-subcription, prevent over-consumption (especially of performance), and allow for elastic performance and capacity scaling; and provide built-in performance and capacity planning for predictable infrastructure growth.
• Managed by high IT maturity organizational customer IT staff, or optionally part of a managed services offering  that does not require organizational customer IT staff to manage.
• Financed to organizational customer either through capital purchase, capital lease, operational lease, capacity lease, or pay-per-use offering.

Some organizational customers will want to capitalize the "True" Private Cloud and manage it themselves. Others will want to basically rent the whole stack to include the software, and have it managed for them. But the common denominator should be how the internal end-consumer consumes the offering. It should look, feel, and cost as much like the public cloud as possible.