One of my clients, ITNAmerica has become a Microsoft case study for the idea of software + services. The idea behind software + services is that software should run where ever it makes sense: in the cloud, on the desktop, or on a mobile device, not just in a thin client such as a browser.

Latency, bandwidth limits, and the need for software to  work if the connection to the cloud disappears makes this a logical approach.  Anybody who has tried to get a cell phone signal should understand the issues about continual connectivity.

Curt Devlin, a Microsoft evangelist, demonstrates another reason why this approach makes sense. It makes the transition to a cloud provider such as Azure much simpler.

If you want some further ideas on how to take a software + services application to a cloud platform. Check out my recent ARCast on "Software + Services in the Cloud."

The application delivery scenarios focus around software as a service. Software as a service applications fall into three varieties: pure service, and software + service, hosted application.

The hosted application scenario is similar to hosted application delivery. Examples are SalesForce, or Hosted Microsoft Exchange. People provide or buy an application that runs in the cloud. At the other extreme is the pure service play. Providers create web services (SOAP or REST based) that provide services used by other applications. Examples are credit card approvals, or certain loan applications. Applications written by third parties use this software to compose their applications in conjunction with their own software. Then there is the mixed play. Providers create both web applications and web services to be used by third parties. These applications consume the same web services that are available to others to build their own applications. This is often done to allow the provider to share the web services among various offerings, or because they need to boot strap the application marketplace. The need for rich clients does not necessarily disappear here. If applications (such as emergency services) have to run with loss of internet connectivity, stand alone apps may be necessary with synchronization software used when connectivity is re-established. Transactional queuing is not enough here because substantive work has to be done by the rich client app when connectivity is absent.

Internet scale is the last class of application. The first scaling factor is number of users. In order to achieve such scale you may to use cloud features such as tables (Google Big Table, Azure Tables, Amazon Simple DB) instead of or in addition to relational databases. Note that transactional guarantees are often impossible to make here. The second scaling factor is geographic distance. If your clients are geographically separated by enough distance, the latency caused by the speed of light in fiber optic cable actually matters. You may have to use the cloud features mentioned previously to achieve the responsiveness for writeable data because transactions, especially distributed transactions are not feasible to achieve scalability.

The next post in the series will start to discuss the architectural  implications of these different types of applications.