Enterprises planning for public cloud computing usually start the process obsessing over what "as-a-service" offering they should focus on, but when I surveyed enterprises with more experience in the cloud, I found they quickly learned to look not at the cloud model but at the model of their own application.
An "application model" is defined by the way that the application is broken up into its major components to be hosted. Nearly every application enterprises run is componentized in some way, and it turns out that the way it's componentized will have a lot to do with how easily it can be migrated to the cloud, how much it will cost to run there, and how much enterprises can expect in the way of security headaches.
If you look at the applications most often "cloudsourced" today, you find that they fit what could be called the web-front-end application model. In this model, the enterprise builds a web server "in front" of the actual application, with the web server providing the HTML and the public face of the application, while a separate application server runs the application itself. This model is used for virtually all public websites, for much of the corporate intranet, and even for applications like desktop virtualization. Enterprises like it because the "display" side of the application is separated from its logic and data access.
This model is perfect for the public cloud because the web front-end can be cloudsourced easily, and replicated in as many regions as necessary to provide ready access to customers and employees. If the application is structured correctly, you can change the language of the site user easily from site to site, add additional web resources to handle peak loads, and even put product information and other generic material in the cloud to reduce the load on your applications and database. But when you’re ready to handle an actual transaction, like an order, that transaction is passed via a VPN (SSL or a "provisioned" VPN service like an MPLS VPN) back to the company data center.
Not only does this application model work well, it seems to be the model that cloud providers, both IaaS (Infrastructure as a Service) and PaaS (Platform as a Service), have set up their business models to support. Web front-ends don’t typically use a lot of data, so the relatively high data storage costs in the cloud aren’t a factor. The fact that you don’t store critical application data in the cloud also simplifies your compliance and security issues. Since the Web front-end is usually outside the corporate firewall, the cloudsourcing of the application doesn't introduce any new access security risks either.
The other dominant application model is a lot harder to support in the cloud. SOA-modeled applications are designed as a series of components that can be orchestrated to perform the functions a user/worker needs, and these components can be hosted anywhere that’s convenient to the user and to the data. On the surface, this model would seem ideal for the cloud because SOA directory functions can help locate an application in the cloud, in the data center, or in either place to respond to peak load demands or backup. Microsoft may well be targeting this class of application with its Azure cloud service.
The challenge for SOA-model applications is that when you separate components of an application and then mash them up, you create inter-component traffic called interprocess communications or IPC. IPC is more delay-sensitive than typical client/server or web traffic, so it will likely require more QoS from the public cloud connection than the web front-end model would. Another problem is security because most SOA components are normally hosted inside the corporate firewall; how will you extend that firewall to cover the cloud? Finally, it's easy to lose track of which SOA application components involve accessing the corporate repository. If you cloudsource something that needs data, you'll either have to cloudsource the data or access back from the cloud to the data center to get it. Depending on the data access method used by the application, the latter step can be a performance killer, not to mention driving up traffic charges from the cloud provider. The "data-in-the-cloud" option quickly drives up both data storage costs and security/compliance problems.
Companies I survey tell me that the SOA-model applications are where most of their IT dollars are spent, so those looking to save with the cloud (presuming they can find cloud services cheaper than their internal IT costs) will have to look carefully about what applications and components they elect to host in the cloud, and control their hosting of components carefully to avoid high costs and performance problems. There's some enterprise experience in this area, and some provider expertise in supporting SOA-model cloudsourcing, but enterprises should be aware that this isn’t the model that most cloud providers are currently focusing on, and it will be very important to qualify your cloud provider's skills with SOA and componentization before you make your move. In general, PaaS providers are more SOA-literate than IaaS providers; in the latter the software image and componentization of the application are entirely under your control, and you'll have to manage the risks on your own. With care, it can be done successfully, but you'll need to do your homework and run a good pilot test before you commit!
