A recent discussion on CloudForum pertains to the nature of what interoperable cloud computing platform might be. It's been a real debate in the community for long time about what and inter operable cloud API actually looks like.
From the market standpoint, it's been my experience that there are two basic types of customers: customers building data-driven systems that require an API, and customers looking for easy-to-use tools in value-added services. I'm sure there are others, and of course I'm leaving out providers, and sticking specifically to the types of customers that I've seen over the last year to year and a half in the cloud computing space, much of which has been around specific applications like Drupal, SOLR, etc.
So you have a huge early adopter crowd on Amazon's EC2, and while there is a huge variation, the high degree of technical complexity required to use it makes us a platform that is basically for the API crowd. A large number of startups have emerged that are bridging the gap between the API and the application and development environments that consumers and developers need to make better use of the Amazon cloud. There is a significant benefit in becoming the bridge between a platform as a service and the applications themselves, as well as the tools required for developers to make better use of their time and infrastructure.
But there is another crowd, and it's a larger audience overall. And that's the hosting market. The global hosting market is larger than most people in technology seem to understand. As one of the leaders of rack space was recently quoted to me is saying, "the market is so big that no one company will be able to dominate; there's going to be a lot of players, and a whole lot of fragmentation to serve customer needs." These customers are looking for API services, the API services do figure in their planning. The main driver from the customers I've talked to actually has to do with the ease of use, the management gets provided, as well as the reduction in development costs, but the number one consideration of all is the ability to get to steal insurance. Whether they have the traffic or not, they're looking into the future wondering whether not they can scale their platform out without downtime, and cloud provides vision of the hosting platform that can do just that. This seems to be the number one thing that's riding the purchasing decision for cloud computing conversion from hosting customers, so the equality of marketing as well as the quality of the systems and the ease of you use as well as the ecosystem, the value-added services that are provided, is going to be driving a significant market share of this conversion to cloud over the next couple of years. It's not something that can happen immediately, but it's a trend that's going to start, and Morgan is seeing more and more hosting customers looking at cloud in cloudlike systems in order to deploy their applications. It has this major benefit of being a vital or management costs compared to traditional infrastructure because you're not actually managing the servers. It also has the possibility of, because of the underlying commoditization of the virtualization systems, having "Amazon.com pricing benefits for scale."
So the interoperable cloud computing platform really need to take advantage of the fact that Amazon has such a significant market lead in the cloud computing space, which means that interoperable APIs with the Amazon.com API for EC2 is probably going to make more sense for those that are building the overlay technologies that power of the ease-of-use tools and value-added services. Putting aside the technical semantics for a moment, having a federated API, what's called a "bug compatible" API that is the equivalent of Amazon's, could provide a significant advantage to newcomers in the cloud computing space looking to create massive adoption in short time frames. Due to the fact that this is such a market advantage, or could be, it seems only logical lead a compatible version of Amazon's API is the logical foundation for the first generation of cloud computing interoperability frameworks and APIs.
So my argument here it is essentially that Amazon's API should be the foundation for any kind of first-generation interoperability API, purely as an exercise in adoption for new club players, which are joining the fray every day, and of which there will be plenty more.
The only argument I can think of against it is the fact that Amazon is consumer service. When you look at the needs of enterprise clients, and other types of specific verticals there's a really different neat for what an API provides. If you look at high-performance computing, high-performance computing has a background of providing how whole lot more configuration than the Amazon API provides. But you can provide the Amazon API at the core, and most of those clouds are really specific to specific industries, such as biotech or financial services. There always can have different needs than a large consumer ISV.
In order for the interoperability movement in cloud computing to really be of service to the shifts in the marketplace, one of the largest of which is the hosting market, effort should doubtfully be put into interoperability around the Amazon API model, and a bug compatible version is probably the way to go. It's probably important to recognize that Amazon is the first mover, and as such building on them may be shortsighted. However using them as the foundation for any "abstraction definition" as has been suggested by Srinivas Vedula on the CloudForum list makes tremendous sense.
While most standards movements fragments on the basis of various big-company priorities, due to the fact, and I think people really don't understand is that well, that the top companies in the technology marketplace have an unbelievable influence in the industry, and use standards as a grounds for competition, looking at the problem of what would benefit the marketplace the most over the next six months to a year, pushing for one model rather than watching the marketplace fragment into tons of different models, which would limit the pace of innovation and raise the cost of developing for these platforms, is a key consideration.
What do you think?