IaaS Wars - Lessons from the Steel Industry

One can view the oncoming price wars led by AWS, GCE and Azure as an anything-but-level playing field.  It’s a different time scale certainly, but, by analogy, the history of the steel industry business strategy is not unlike the history of information & communication technology (ICT) strategies of the internet, Web 1.0, SOA, Web 2.0 and now cloud computing.  But relying on the idea that the forms of IaaS are all fungible, interchangeable commodities will lead one to some mistaken conclusions.


Any recounting of world economies in the past two centuries will chronicle the role of the steel industry as a fundament of the industrial age (roughly from 1850 to somewhere in the later half of the 20th century -- probably around 1970).  Such a history will also note how the means of production and the economies of Big Steel underwent huge technological change, from a labor intensive industry to one of the first automated industries, in a very short period.  From producing steel in enormous lots to the creation of vertically integrated fabricators of steel piece-parts, the nature of the industry was changed by a series of mechanized (world) wars, the arrival of personal automotive transportation, and the population's migration to urban centers. 



A sum of money granted by the government or a public body to assist an industry
or business so that the price of a commodity or service may remain low or competitive

The importance of steel to national interests and economic dominance led to the use of subsidy as a tactic employed by aspiring economic world powers -- Japan, then India and now China -- in their efforts to accelerate the demise of the second (and most economically powerful) generation of steel companies of the US.   Along with agile, modular and 'lean' production methods which served to deliver highest quality steel in appropriate lot sizes and at exceptionally good prices, these industrial enterprises sought to accelerate their rise to the top through the use of 'dumping'.  The upstart national industries -- subsidized and nationally protected -- started selling large amounts of product at prices below cost.  This contest would eventually destroy those companies that were less economically sound (because of their reliance on outdated production approaches or facilities) or those newly tooled companies already saddled with debt which had neither access to patient investment nor to national subsidy. 

From Big One to Big Three and arrival of Cloud Dumping

With AWS now clearly the undisputed leader in IaaS -- the Big One -- are we now about to see internal subsidization by Microsoft and Google in their respective infrastructure services?  The answer is clearly 'yes.'  After starting their approach to cloud computing through platform services, both Microsoft and Google have now truly launched infrastructure services … six years after AWS' introduction.

The Big Three IaaS offerings (AWS, GCE and Azure) have been established at major cost in capital equipment, the dedication of the best architecture and development talent on the planet, and incredible attention to the operation, administration and management (OA&M) of the services.  When a company with the stature and resources of Microsoft or Google decides to go for position in an industry segment, their investment strategy is to take the long view.  That includes setting aside serious amounts of money for the continued operating costs and expansion of their infrastructure services.  

Is this 'cloud dumping' or just the patient investment by digital powerhouses who can afford it?  I'll vote for the former, since along with their investment in a nascent set of services, the impact on the rest of the infrastructure competitors and the IaaS customers has some major implications.  This not only becomes a waiting game that will demonstrate the dedication, patience and depth of the Big Three's treasuries.  This is also a cleansing action for the industry.

In the battle for turf among what, arguably, will become the Big Three, what happens to the smaller IaaS providers -- the fast followers, the specialist infrastructure services?  It puts serious economic pressure on the second tier of less well-heeled competitors. They must consider their option to move out of the commodity IaaS markets and move into specialty areas, to find themselves bulldozed, or to end as the assets in industry roll-ups.   

If the IaaS segment takes its future history from the steel industry, there would be little to recommend getting into or remaining in the business for the likes of Rackspace, Joyent, GoGrid and those carriers like Verizon which have put Terremark in place.  But this is where I believe that IaaS does NOT have to repeat the industrial history of steel.  The IaaS industry is more  malleable and more capable of major differentiation.  Furthermore, IaaS is, ultimately, NOT about the delivery of commodity services.   

The error of IaaS fungibility and other ways oligopolies might be disrupted

- IaaS offerings are not fungible and interchangeable -- or at least, not as fungible as pundits would have you believe.  They are not as easily commoditized as electricity, water, petroleum or telephony.  In recognizing the variations in demand and use cases for IaaS, the industry should find interesting opportunities.  A recent article by Owen Rogers and Willam Fellows of the 451 Group uses the analogy of hotels and hotel rooms as a better analog, and I agree.  Just as there are significant variations in functionality, amenities, location and, of course, price involved in the use of a hotel room, so are there variations in the commercially viable infrastructure services.

- The lessons learned from the partially regulated airline industry may be more instructive in both the benefits and pitfalls of oligopoly and the advantages of smaller, regional / specialist services which apply different processes and metrics to establish a winning offer.  In fact, there are probably so many interesting lessons to take home from an look at the airline industry, that I propose we go there next.

- A final point worth noting before leaving the steel industry: The lessons of the steel industry have not yet played out because the steel industry itself is going through yet another transformation. New forms of technology and process, which utilize 'steel-the-commodity' in ways never before seen in mass produced manufacture, are about to confound and disrupt the steel industry.  By analogy, we can point to similar upsets coming to the realm of infrastructure services. There are lessons yet to be learned as to how the means of production and the organization of business can be as disruptive to the present kings of the hill in IaaS.


Infrastructure (-aaS) goes to war


Among the most interesting developments in the business of IaaS during the past few months has been the rather dramatic ways in which the players have been throwing down guantlets.  Some notable examples:

  • The incumbent AWS, in Andy Jassy's recent AWS Summit presentation, has diss'd private cloud as "false cloud" 
  • Turning the beam to illuminate their position with respect to other infrastructure services, AWS has a point to showcase their record of continual price reductions while delivering just-in-time functionality to its community of customers when compared to other IaaS offerings.
  • The new aspirants GCE and VMware vCloud Hybrid Service have made clear their intention to appeal to their constituents -- the cutting edge development communities in need of almost unheard of scale in the case of Google, and the enterprise in search of the promises of hybrid clouds in the case of VMware
  • Rackspace and Joyent have revised their pricings, while accompanying the announcements with functional additions or the promise ('real soon now') of functionality and service level assurances to their customers and customers-to-be.

Like many other observers of the cloud services industry, I've made comments that include the terms 'commoditization' and 'race to the bottom.'  But in looking at historical analogs, I am coming to the conclusion that there are other ways to interpret the situation in IaaS, and consider possible outcomes other than an eventual oligopoly of the 'Big Three.'

In the upcoming series of blog posts, I hope to take selectively from the economic history of the steel industry and the airline industry to point out how the cloud infrastructure industry's 'future history' might play out.  An analyst and observer of industries is always at risk when predicting the future -- so I won't.  But I will point out some similarities to major techno-industrial disruptions, the tactics and strategies of competition, and their resulting successes and failures.  

I welcome reaction, commentary, alternative interpretation, but please... no name-calling. 


Alan Kay on Basic Research in ICT

While listening to the fireside chat moderated by Paul Saffo at the Churchill Club event last night, I found Alan Kay’s displeasure with the lack of basic research being conducted in information and communication technologies both understandable and justified.  He made several points, though the few pieces of reportage I’ve seen didn’t quite pick up on them all.

  • Basic research in ICT was in great part a byproduct of the Cold War, which made available significant amounts of funding
  • Basic research in ICT, particularly from the Advanced Research Projects Agency (ARPA), benefitted enormously from the stewardship of J.C.R. Licklider and like-minded technologist-managers, who understood the ‘success-to-fail’ ratio and how best to organize project support.
  • The role of private industry in basic research was significant, and Alan referenced the minimal sums of money spent by Xerox on the work of PARC.
  • In ‘stepping up’ to address basic research in ICT, companies like Xerox (and, might I add, Bell Labs and IBM) were successful when they put the same kind of evangelistic and experienced management that Bob Taylor brought to Xerox.
  • Basic research in the private, corporate sphere was and remains (in those few places it still exists) poorly managed and shackled by inappropriate metrics and outright fear of causing industry disruption - arguably the most important outcome of basic research.
  • Corporate support in basic research appears destined to be a generally fruitless endeavor without a very significant mind- and management-shift.
Despite the ‘grass roots’ mentality and volunteerism found in today’s open source / ‘maker’ ethos, nothing in Alan’s opinion seems to compare to those few decades of work shepherded by those who (deservedly) should be considered visionary technologist managers. 
The point about the dedication of funds to basic research in ICT and its consideration in the scheme of things was brought home to me still more forcefully this morning when I noticed Simon Wardley’s reference to this article: Apple spends more on patents than R&D after Jobs patent vow

Here’s part of David Needle’s TabTimes post on last night’s conversation. 

Kay said only a few dozen people at PARC worked on the Alto and even though it was part of a pure research effort, it created “trillions of dollars” of wealth, i.e. the personal computer industry.

But he said there’s been little in the way of true tech innovation since then because the funding for basic research has dried up.

“The past 30 years have been completely mundane,” said Kay. “It’s all been scaling (of old technology) and Angry Birds.”

Kay was joined onstage by Vishal Sikka, Head of Technology and Innovation at enterprise software giant SAP, and tech forecaster Paul Saffo, Managing Director of Foresight at Discern Analytics.

Sikka agreed not enough was being done in the way of basic research, but said companies had to find ways to encourage creative ideas that could take years to develop, but would be worth nurturing even if many of them failed.

 In reading it and reflecting on the evening, Alan Kay's criticism and displeasure appears on the surface to be recognizable as that of ‘angry old men’ who romanticize their past glories and decry the present.  I have to admit, there is some of that in Alan’s comments, and it was palpable last night.  That doesn’t mean, however, that he’s not justified in that point of view.  Alan Kay is hardly one to restrict his mental efforts to re-living the past.  Thanks, Alan.


IBM's embrace of OpenStack and 'open source': OSLC, TOSCA and ...?

David Lindquist’s post in IBM’s Thoughts on Cloud blog (made in conjunction with the IBM OpenStack announcement), is an excellent high-level explanation of the rationale behind IBM’s decisions.  It is telling for at least two reasons, and notable for what might be construed as missing pieces.

Along with the whole-hearted endorsement and embrace of OpenStack, IBM has called attention to two open initiatives.  Open Services Lifecycle Collaboration(OSLC) is an initiative of which I personally was unaware until Sunday’s presentations at the IBM Pulse Open Cloud Summit. The objective of the initiative is to standardize the way that software lifecycle tools can share data.  Not just an admirable goal, but one of the necessary preconditions of a truly open, multi-vendor approach to operations, administration, management and provisioning of cloud components.

Lindquist calls out the IBM support of OASIS Topology and Orchestration Specification for Cloud Applications (aka TOSCA).  IBM has started (and will no doubt continue) to make a strong case for the use of LinkedData and OSLC in combination with TOSCA to ease the job of integration and federation within the cloud ecosystems.   Again, it’s nothing less than what one would expect from IBM, a company with a long history that values systems management.  

From David Lindquist, For cloud computing, open means agile

Together with the OpenStack FoundationOpen Services Lifecycle Collaboration (OSLC) and OASIS, we are helping to lead open cloud standards and open source initiatives. Creating an industry rallying point to drive interoperability is accelerating delivery and lowering costs, while optimizing the infrastructure layers and enabling management of the entire lifecycle to support agility with integrity. Further, workload portability and optimization supports scale, security, recovery, resiliency and agility in the development and delivery of new business applications and business models.

Further, to support the interoperability and portability of workloads across clouds we are contributing and supporting the OASIS Topology and Orchestration Specification for Cloud Applications known asTOSCA. To drive the full lifecycle of design, development, and delivery we architect our cloud solutions with Linked Data and OSLC. By leveraging OSLC we are creating an open environment to easily integrate and federate our capabilities as well as third-party tools to support DevOps, Continuous Delivery pipelines, orchestration and automation.

By opening access to data though OSLC, we can quickly pull together solutions that span the complete lifecycle, provide dashboards with insights driven by analytics, and link information across applications and infrastructures to support subject matter experts, all with a compelling user experience. With OSLC we have been able to leverage the extensive capabilities and data across our products to provide consumable interfaces. These examples include storage management, application and infrastructure monitoring, and control desk solutions. With this architecture and these interfaces, users can easily access information across systems, using mobile access, and compose dashboards with the insights their businesses need.

What seems to be missing, however, is a less well-known, but arguably vital initiative known as the OASIS Cloud Application Management for Platforms (CAMP).  As expressed in its charter, 

CAMP defines interfaces for self-service provisioning, monitoring, and control. Based on REST, CAMP is expected to foster an ecosystem of common tools, plugins, libraries and frameworks, which will allow vendors to offer greater value-add.

That seems to be a logical addition to the effort by IBM. As important, perhaps, is the adoption and recognition of the LinkedData and OSLC work within the CAMP TC.  I know, after a number of informal conversations with participants in both OASIS TCs that the IBM emphasis has created new energy around OSLC for CAMP, and increased interest in seeing IBM attend to the work of CAMP.  

(Truth in advertising:  I am a participant in the CAMP Technical Committee and an observer in the TOSCA TC.) 


Page 1 ... 5 6 7 8 9 ... 14 Next 4 Entries »