Many of our customers come to us with an application they have developed and want us to help them deploy it to "the cloud" in our Computing Utility service.   Often the application has only been run on a PC or perhaps a shared hosting service like GoDaddy, so there is little information on what it will take (or cost) to deploy it for revenue service.  The next step our customer has to take is to successfully deploy the application for multiple users, and develop a costing and revenue model that will allow them to make money and present an attractive pro forma business plan to investors. 

This is a big leap, one that we at ENKI have made before in our previous positions at other companies... and we know it's not easy.

Typically, SaaS startup companies' first concern is cost, since they're often on interim financing or even founder's savings.  However, the more interesting question over the medium to long term isn't the cost per customer/user, but rather the model for generating net revenue, since this is what investors will be looking at.  The cost of deploying a SaaS application typically consists of hosting costs (computing resources), labor costs for managing the deployed instance(s), and other costs of sales such as end-customer support and administration, sales commissions, adding features, etc.  Most SaaS startups don't have models for the other costs of sales, so they tend to look at their net revenue as the difference between their per-seat charges and their incremental hosting costs - which can be relatively large for the first few instances.  Without a long term revenue model, this focus can lead to an excessive emphasis on cost control that can impact the effectiveness of your initial deployments.

One of the first places we think should be looked at for controlling costs is deciding whether the SaaS application is multi-tenant or single-tenant and deployed in a shared hosting environment.

In a multi-tenant deployment, a single application and infrastructure (one or more virtual servers) delivers SaaS application services to multiple customers.  To add a new customer, you simply talk to the application itself.  The application is responsible for keeping customer's data separate and making sure each customer gets a pre-determined amount of computing power applied to their services. Clearly, writing the code to make an application multi-tenant can delay its roll-out while problems with securing one customer's data from another and administering multiple customers are solved.  However, multi-tenant applications are inherently more efficient in how they use computing resources since the overhead of the operating system and ancillary software (like language interpreters and databases) are shared across all customers.  With sufficient coding effort they can be written to minimize the effort to administer users/customers, which can become a significant cost as the number of customers rises.  If the number of customers or seats becomes very large, the monolithic nature of a multi-tenant application can cause performance problems that are difficult to solve.

In a single tenant/shared hosting deployment, there is a separate copy (instance) of the SaaS application for each end-customer, though there may be many individual seats at that customer which are served by the same application instance.   Each instance of the application has its own copy of the operating system and ancillary programs, which raises the per-customer and per-seat hosting costs.   To provision a new customer (at least in our AppLogic system) you simply make a copy of the stored memory image of the instance and start it.  However, at this point customer administration becomes more complicated and expensive, since you must log into or otherwise communicate with that instance of the application and tell it about the customer it will be serving.  If support calls come in, then you must determine which instance corresponds to the end customer, and log into that instance to service the request.  This can complicate customer service and make it expensive.  However, this may be worth it for the shorter time to market of a single-tenant deployment.  Also, in the long run, you can write a management application that automates common adminstrative tasks by acting as an interface between the administrator and the customer instances via remote communications.

Finally, services like backup and usage-based billing are simpler and less expensive with a multi-tenant application, since there need only be one process for handling all the customers' data.  For example, backing up multiple single-tenant instances can be expensive since you may need multiple copies of backup software, or find it necessary to back up the entire server image including the deployed software and ancillary software because it is unique to that customer.

Which approach is better?  It really depends on your business' needs.  If time to market is king, then a single-tenant deployment is the right solution.  If cost per seat is more important, than a multi-tenant architecture should be considered.  Or, you can choose a hybrid approach where you initially deploy multiple copies of a single-tenant application, and then rewrite it for multi-tenant service, while saving single-tenant deployments for customers who have a lot of seats.  

In any event, you should be prepared to pay more (and make less money) for your initial deployments as you will need time to figure out how to optimize your per-seat costs.  Even if you lose money on the first few customers, as long as you have a longer-range plan for positive revenue, your business plan should look attractive to investors.  The key to creating a good longer-term plan includes analyzing how you will grow per-customer and per-seat revenue as well as reducing costs.

Comments (0)

Subscribe to this comment's feed

Show/Hide comments

 Show/Hide comment form

Name

Email

Website

Title

Comment

Write the displayed characters

Add Comment