There is a lot of momentum for the "Cloud" these days. Proponents are insisting on the great value of both building new applications, as well as moving some old applications out into the Cloud to leverage the cost and complexity reduction the Cloud promises. Offerings from Amazon, Microsoft, Salesforce.com, Sun, IBM, Rackspace, and countless smaller guys bring a promise of speedier and easier application deployments. These raw IT-resource-on-demand farms are springing up everywhere, and thankfully the deployment tools are getting easier to use. There is no question, as an industry, we are headed in this direction.
While some applications were never meant for the Cloud, the groundswell of new entrepreneurs building new applications within it are leading the charge, primarily because of the lower cost of building complex system architectures with built-in redundancy and load-balancing that before required major hardware requirements and onerous contracts with data center providers. Also, enterprises are beginning to formulate plans for deploying applications to the Cloud where it makes sense to do so, and this is driving some additional innovation and will continue to do so for quite some time.
One of the more exciting things about this trend, aside from cost and ease of deployment benefits, is the new types of cutting edge computing it will spur. Just like the Web itself brought entire new classes of applications and innovation for traditional applications into existence, the Cloud approach is likely to do the same. We should expect to see applications that live in the Cloud leverage other computing resources that also exist in the Cloud. This Cloud-to-Cloud communication is only natural, rather than trying to reach back in to behind-the-firewall and proprietary applications, especially if there is a choice. Because of this, the Cloud ought to help enforce openness and standards out of necessity, which for most of us is a pretty good thing.
The way these applications are likely to communicate and leverage other Cloud applications is via messaging to and between API interfaces. Whether or not these applications and Cloud services exist on the same Cloud, or some distant Cloud won't matter most of the time (except in rare cases where performance makes geographical proximity an imperative.) For example, if an eCommerce application needs to verify the identity of a prospective purchaser, it need only call out to an identity API somewhere out in the Cloud with a set of parameters and then retrieve back a confidence score. This then can enable a decision to be made on whether or not to review a given purchase internally for possible fraud.
Perhaps the same application only needs to verify that an address entered by a buyer is correct and shippable. This too can just be a simple call out to another Cloud service. Thousands of building blocks and service components will be available for use out in the Cloud, and APIs and Web services will be the communication mechanism between these applications. Some of these service components will be public, but many more will be private, especially as architectural decisions are re-considered and more resource are moved out into the Cloud. Generally however, the integration approach will be the same, even if security approaches are not.
So while there is lots of work to do during this build-out period, those of us who have already built applications that leverage external APIs will have a good head start as we move in this direction.
Comments