Monday 15 November 2010

Go cloud – An ISV perspective…Part 2 – PaaS

 

This blog is in continuation to my previous blog entry “Go cloud – An ISV perspective…Part 1 – SaaS” which discussed, if ISV needs to go cloud and offer their products as SaaS, the quicker ways to do so.

Just to keep this article independent, I have copied and pasted below the section which sets the context, to make it easier to read. If you have read my previous blog entry, you may directly jump in to the next section “PAAS”.

Typically as the name suggests, an ISV (Independent Software Vendor) could be one of the following:

A) Traditional Software Product companies: Companies who build and sell software products

B) Web based Software companies offering their products as “Services” typically known as SaaS companies

C) Software intensive companies offering services to a market using a software. The main business of such companies is not to sell Software or even SaaS but to “use” them as their tool to sell their services. A typical example of such a company would be one providing “subscription based” clinical information, or a subscription based access to a vast patent database and so on. In such cases, they do not sell software or service instead they sell “information” using a software.

D) A start-up company who intends to become one of the above three.

For the purpose of the article and for ease of reference, let us refer the above as – A-type ISV, B-Type ISV , C-Type ISV or D-Type ISV respectively.

This article is an attempt to provide a clarity to these ISVs as to which of the cloud services they need / should / may need to consider to embark on for the success of their business.

As briefly explained in one of my previous articles, there are three different aspects to cloud computing i.e.– SaaS (Software as a Service), IaaS (Infrastructure As a Service) & PaaS (Platform as a Service). If you are a B-Type ISV,  then I am sure you do not need any more explanation of what SaaS is. Also if you are C-Type ISV then too, you may not be too interested in SaaS as selling software isn’t the main business you are in to. But may be you wish to know more on these other aspects such as PaaS & IaaS.

So this is an attempt from me to put few points across to provide a clarity to all the ISVs out there.

 

PaaS

Using PaaS to build an offering or a SaaS product may be the fastest and the most cost effective way of doing so if you are a Type-D ISV (A start up company). As a start up you may have a fantastic product idea in mind which you think of offering it to prospective customers as a SaaS rather than an on-premise software, but you may not want to take a huge risk of doing the whole thing yourself.

By choosing a PaaS, effectively one gets a rapid application development platform to build the software along with an ease of deploying the software on the datacentres of the the PaaS providers. Because the ISVs do not have to own anything, there is no upfront investment. It is a Pay-as-you-use model and the charges of the PaaS providers can be accounted as an OpEx. This model is very useful if you are not sure how many customers you may procure during your initial years. Also, because most of the PaaS providers provide the flexibility of allowing you to increase the servers on demand, it is extremely simple to manage the spikes of customer growth.

It is very important for any ISV to ensure that their products offer a high quality of service and hence managing the non-functional Requirements is the key. And since the system is hosted on a PaaS, most of these non-functional requirements are already taken care by the PaaS providers. The ISV just need to align their Service Level Agreements they provide to their customers to the Service Level Agreement offered by the PaaS providers.

All good so far, but is PaaS a long term solution from the ISV’s perspective? May be and May be not.

If you already are a Type B ISV, i.e. you offer your product as SaaS, and if you are successful at it, there is no specific need to move your application to a PaaS. In some cases it may make sense but in most cases it would not. The only advantage of moving an existing SaaS application would be to reduce the infrastructure maintenance effort. Moreover if you already have a huge customer base, moving your system to PaaS would mean more charges / OpEx you may end up paying to the PaaS provider for each of your thousand users. Hence the cost benefit analysis needs to be done between moving the offering to a PaaS provider vs. Continuing to host (or using a Data centre) privately.

For Type A ISVs, it could be a good option to try their business model by creating a SaaS version of their product on a PaaS and sense the market reaction. As mentioned in my previous article, one option for the Type A ISV would be to reuse as much existing on-premise code as possible and build a SaaS version of it using methods mentioned in the article.

The more safer option would be to try a separate version of their product to be offered as SaaS, using a PaaS. This would mean they could treat this part of the Business as a start up and all the advantages that a Type-D ISV enjoys using a PaaS, can be exploited. And most of the PaaS providers provide a huge amount of flexibility to reuse existing code and make minor changes to make it available to be hosted for PaaS.

Type-C ISVs don’t need to worry about the PaaS immediately if they are happy with their current business model. The only reason they may or may not switch to use a PaaS would be cost as their customers are not users of their “software”. Their customers are users of the “information” provided by the software. As long as they are able to comply to the Quality of Service and their SLA agreements with their customer, the need to move to a PaaS would only be a Cost benefit in a long term and also their TCO for the business.

For an ISV (as our current focus is only ISV) whether to go PaaS or otherwise, is not an easy choice to make, for the sole reason that going PaaS means paying for each user using the system hosted on PaaS. SaaS is all about acquiring more users using the system which means more payment to PaaS providers. Hence it is extremely important to do a cost benefit analysis to evaluate if the CapEx investment + the OpEx maintenance cost for Self- hosted (privately hosted at a Datacentre), equates a lower TCO as compared to a TCO in case of having a permanent OpEx as charges to the PaaS providers.

No comments:

Post a Comment