Amazon Web Services and Innovator's Dilemma

AWS rolled out yet another service last week - Simple Workflow Service (SWF). I haven’t had a chance to kick the tires yet but I liked what I saw in the docs.

But then on Twitter I started noticing people expressing concern about how this new service stacks up against existing tools in this domain (I am not an expert but acronyms such as BPMN and BPEL were mentioned several times). Some said outright that in their opinion SWF was a “retrograde step” considering “so much work [already] done in this domain.” These people are widely known as experts in their fields, and I have no doubt they have a valid point. But in spite of this, I found myself liking SWF even more.

Why?

First of all, SWF follows a well-established rollout strategy that AWS has been relying on since the very beginning - initial rollout with at least minimal viable product followed by frequent significant updates. Do you recall, for example, that EC2 launched without user-selectable kernels (aki-XXXXXX), EBS or even Elastic IPs - can you imagine EC2 as you know it today but without these features?

Secondly, SWF most likely is an attempt to productize a technology used internally. As such, a set of features available at rollout most likely approximates a set of most important features in use by amazon.com. And if Amazon uses them, it’s likely others may use them too. It’s like writing some useful piece of code for internal use, then discovering its usefulness and publishing the code on github as an open source project. Except Amazon doesn’t publish code and turns it into a product instead.

I actually know firsthand a thing or two about this approach. CohesiveFT VPN-Cubed (disclosure - I am this project's lead engineer) was not initially envisioned as what it is today - a premier connectvity solution between clouds and datacenters. It's rooted in something that I developed for internal use in a completely unrelated project. We saw its potential and it became a product, even if some key features were not even present in the first version.

And finally there is this thing called Innovator’s Dilemma. I know, I know - everybody read the book, and everybody is already tired of its mentions. But it’s not fiction - it’s not enough to read the book, one must understand it. If you don’t understand the difference between sustaining and disruptive technological changes, you must re-read it even if you are not interested in pursuing an MBA degree.

For the purposes of this post, however, here is an excerpt from the book. And here is a key part:

Generally disruptive innovations were technologically straightforward, consisting of off-the-shelf components put together in a product architecture that was often simpler than prior approaches. They offered less of what customers in established markets wanted and so could rarely be initially employed there. They offered a different package of attributes valued only in emerging markets remote from, and unimportant to, the mainstream.

SWF is meant to be not like BPEL, BPMN, etc. It is meant to be mostly ignored by existing users of this technologies - it is meant to be unimportant to them. This is all by design!

This is their M.O., it’s what they are extremely good at and it’s how they have been doing it since the very beginning. While past results are not necessarily a good indicator of future successes or failures, AWS’ track record is stellar. I wouldn’t bet against SWF if I were you.

And please - read the book (or re-read if necessary), you won’t regret it.

Categories: cloud-computing |