4 ms·

Why couldn't cloud providers adopt a common API? Some providers are adopting AWS apis for their services. And we can also look at the email example : a lot of

Why couldn't cloud providers adopt a common API? Some providers are adopting AWS apis for their services. And we can also look at the email example : a lot of cloud provide email services and they all use the same protocols (SMTP, IMAP...).

mixedbit 9y ago
They probably could, but it isn't happening. It is hard to find a cloud service that seamlessly works with some other cloud service without explicit integration between the two services. Email was introduced and has become a popular standard long before commercial cloud services. The companies adopted it, but they do not seem to be interested in introducing similar standard protocols for new APIs.
jolmg 9y ago
Because they want to lock their customers to their platform. AWS has the biggest marketshare, so if a smaller provider adopts AWS's api, that means that AWS customers can easily migrate to them. I do wonder how we managed to get standard protocols adopted for email. What did email providers use before SMTP and IMAP? Maybe the key difference then from now was that the internet community was much smaller? Did Mark Crispin simply write the RFC for IMAP, email vendors noticed on their own, and adopted the protocol? Or was the emailing community then so small that there were no vendors and it was really just a handful of programmers, who could discuss and agree on protocols via something like Usenet and implement their own clients and servers?
- philsnow 9y ago
  more the latter. long ago, to get access to mail or usenet you generally were a technically minded person at one of a few universities or large corporations like DEC. to give a sense of the scale involved, check out http://olduse.net/blog/current_usenet_map/ http://olduse.net/blog/current_usenet_map/ . There were on the order of between dozens and hundreds of machines, and you would send mail to a person on a given machine by figuring out (by hand?) a path from your machine to that machine and include the names of all the machines in a "bang path" http://www.catb.org/jargon/html/B/bang-path.html http://www.catb.org/jargon/html/B/bang-path.html Also, before SMTP there was UUCP (which was used for both mail and usenet).
varenc 9y ago
I agree with the profit/control motivations the other posters mention, but there are other less anti-users reason as well. Agreeing on a common API mostly locks you into the common denominator of features. It becomes much harder to ship new capabilities to your customers if you also have to add those features to this standardized interface and get all the stakeholders to move forward with it. All these platforms have some features that their competitors lack and it'd be quite the challenge to expose each platform's unique features in a standardized API. Email (IMAP/SMTP) is a success story of a widely adopted standard, but it's also something that has barely changed in the last 15-20 years partially as a result of its standardization. You can tell IMAP is cumbersome to the modern developer. For example, you'll have an easier time working with a gmail account by using the gmail REST API instead of trying to use IMAP. (IMAP has more limited search support, lower-level thread support, and less specific support for syncing clients)

mixedbit 9y ago

They probably could, but it isn't happening. It is hard to find a cloud service that seamlessly works with some other cloud service without explicit integration between the two services. Email was introduced and has become a popular standard long before commercial cloud services. The companies adopted it, but they do not seem to be interested in introducing similar standard protocols for new APIs.

jolmg 9y ago

Because they want to lock their customers to their platform. AWS has the biggest marketshare, so if a smaller provider adopts AWS's api, that means that AWS customers can easily migrate to them. I do wonder how we managed to get standard protocols adopted for email. What did email providers use before SMTP and IMAP? Maybe the key difference then from now was that the internet community was much smaller? Did Mark Crispin simply write the RFC for IMAP, email vendors noticed on their own, and adopted the protocol? Or was the emailing community then so small that there were no vendors and it was really just a handful of programmers, who could discuss and agree on protocols via something like Usenet and implement their own clients and servers?

philsnow 9y ago
more the latter. long ago, to get access to mail or usenet you generally were a technically minded person at one of a few universities or large corporations like DEC. to give a sense of the scale involved, check out http://olduse.net/blog/current_usenet_map/ http://olduse.net/blog/current_usenet_map/ . There were on the order of between dozens and hundreds of machines, and you would send mail to a person on a given machine by figuring out (by hand?) a path from your machine to that machine and include the names of all the machines in a "bang path" http://www.catb.org/jargon/html/B/bang-path.html http://www.catb.org/jargon/html/B/bang-path.html Also, before SMTP there was UUCP (which was used for both mail and usenet).

varenc 9y ago

I agree with the profit/control motivations the other posters mention, but there are other less anti-users reason as well. Agreeing on a common API mostly locks you into the common denominator of features. It becomes much harder to ship new capabilities to your customers if you also have to add those features to this standardized interface and get all the stakeholders to move forward with it. All these platforms have some features that their competitors lack and it'd be quite the challenge to expose each platform's unique features in a standardized API. Email (IMAP/SMTP) is a success story of a widely adopted standard, but it's also something that has barely changed in the last 15-20 years partially as a result of its standardization. You can tell IMAP is cumbersome to the modern developer. For example, you'll have an easier time working with a gmail account by using the gmail REST API instead of trying to use IMAP. (IMAP has more limited search support, lower-level thread support, and less specific support for syncing clients)