OK. So you say there is first mover advantage, AWS has lock-in. But Windows has more moat because to read a Windows file requires the reader to also to have a Windows interface. To get stuff from the cloud any HTTP capable browser will work. Am I missing something?
People often talk about cloud computing as if it is just storing data on someone else’s servers on the Internet, but it’s far more than that. It’s running applications on a platform, similar to running applications on Windows.
As such, AWS has an application programmer interface (API), just like Windows has APIs. For instance, if you want to grab a computer somewhere in Amazon’s cloud and run something on it, you might start that by using a RunInstances request. e.g.
[https://ec2.amazonaws.com/?Action=RunInstances](https://ec2.amazonaws.com/?Action=RunInstances)
&ImageId=ami-31814f58
&InstanceType=m1.small
&MaxCount=1
&MinCount=1
&KeyName=my-key-pair
&SubnetId=subnet-b2a249da
&AUTHPARAMS
The request is going over HTTP (like web pages), but the types of requests that are supported and the effect of each request is Amazon-specific. So, if I wanted to use Google cloud instead, I’d have to use completely different requests that would do completely different things. And much of the functionality in AWS might not even be in Google, or would have different implementations.
So, just like you couldn’t take the code for a Windows application and recompile it to work on a Mac (because they have different APIs), you couldn’t just take the code from one cloud service and recompile it to make it work on another cloud service. You’d have to think it all through, all over again, taking into account all the ways that the services are different.
For instance, Google probably has a call to request a new machine, but maybe it does different authentication. Maybe it takes 4 different parameters, 2 of which don’t even have any meaning in your AWS-derived application. So you’d have to rethink the design and debug it all over again.
Richard