651.288.7000 info@intertech.com

I have had a very busy couple months ramping up on the new Visual Studio 2010 testing tools and starting a new project.  Now that things have settled down a little bit, cloud computing has hit my radar again.  Several years ago I wrote a white paper on what it would take to deploy my former employers COTS product in a Software as a Service (SaaS) model.  While it wouldn’t be appropriate to share the entire white paper, I reworked the introduction to share my thoughts on SaaS with the community.  What is interesting is that this was written in late 2007 or 2008 and while technology has changed considerably, and the maturity levels may have been renumbered and grown,  I believe all of the concepts are still relevant today. After I spend a little time learning about the new .Net cloud technologies at our disposal, I’ll revisit this post and start discussing how to pull all of this off.

Definition

Software as a Service is a deployment model where an application is hosted as a service over the internet.

Business benefits to the customer

· Reduced cost of maintenance and support. The hardware cost and associated support staff is the vendor’s or a 3rd party’s responsibility.

· Reduced cost of entry by reducing the initial cost of purchasing licenses a pay per use model is generally employed.

Business benefits to the application vender

· Better protection of intellectual property. The customer has much less access to the system. For example there are little or no on-site IT responsibilities so the customer would be much less knowledgeable about things like the data store or application architecture.

· Establishes an ongoing revenue stream. The pay as you go model establishes a more predictable revenue stream.

· Reduced cost of maintenance by controlling the platform that the application is deployed on. For example an application could be deployed and certified only on Windows 2008 and Sql Server 2008. Certifying on one very predictable environment simplifies the QA and support burden.

Risks and Challenges

· Trust. What is the long term viability of the application service provider? How secure is the data? What is the disaster recovery plan? What level of service can I expect?

· Integration. Integrating with on-premise applications is difficult enough, how do we integrate with hosted applications?

· Regulations. Are there regulations around data access and storage that would increase the difficulty of deploying an application in the Software as a Service model?

· Portability. If I want to move the application and data to a new service provider, will my application and data port?

· Support. Who fields help desk type calls

· Management. Maintenance and upgrades are controlled by the service provider.

· Identity Management. Customer will have less control over how users and Identity are managed.

Software as a Service maturity levels

Maturity Level 1 – Each customer has its own customized instance of the application running on the host servers. This is essentially the same as the Application Server Provider (ASP) model of the late 90’s that never really took off. Each customer is executing different code on different machines.

 

 

 

Maturity Level 2 – Each customer has its own configurable instance of the application running on the host servers. Each customer is executing the same code on a different machine.

 

Maturity Level 3 – The vendor hosts all of the customers in a single configurable instance of the application and uses authorization and security policies to ensure that each customer’s data is kept separate from the other customers. This is called multi-tenant; each customer is executing the same code on the same machine.

 

Maturity Level 4 – – The vendor hosts all of the customers in a load balanced farm of identical instances of the application and uses authorization and security policies to ensure that each customer’s data is kept separate from the other customers.

 

A Note on Application Security

When architecting an application to be deployed in an SaaS model it is important to architect the application with security in mind. CIAA is a security acronym standing for Confidentiality, Integrity, Authenticate, and Authorize and as architects we need to consider these things.

Confidentiality – Make sure nobody else can read the messages by encrypting confidential communications.

Integrity – Validate that the message has not been tampered with by using digital signatures.

Authenticate – Make sure the user is who they say they are.

Authorize – Make sure the user is allowed to do what they are trying to do.

A Note on Delivering Large Resources

Distributing large resources in the SaaS deployment model presents a particularly difficult performance challenge when you are trying to deliver large resources. Assume you have to deliver a resource that is 10’s of megabytes in size. The performance a customer can expect is equal to what a customer gets when downloading a similar size file from the internet. Software designers should consider an architecture which supports distributing these large resources to local stores. These local stores would host the large documents at various locations around the world, within an intranet, or ideally on a local network. The hosted service would still own and manage the documents but the local stores would have to communicate with the master store to ensure that the large resources are up to date.

 

 

 

Like What You've Read?

Subscribe to the Blog.

Every Friday we send that week's content from our Developers via email. Try it out!

Some ad blockers can block the form below.

You have Successfully Subscribed!

Pin It on Pinterest

Share This