When we move from writing shrink-wrapped software that a customer runs a setup.exe in their own datacenter to the completely different world of providing the software’s functionality as a service over the Internet, probably our first port of call is to base it on a cloud platform like Microsoft, Google, Amazon, Rackspace and so on.
That’s an architectural decision, mostly technical. The commercial question, is “how do we charge for our service?”. When you think about the models that are out there – take salesforce.com or Office 365’s models where each individual customer is charged a per-user, per-month fee. That seems to be the most common. But what about others? An upfront cost for the establishment of the service, then a monthly charge no matter how many users are on the system; a direct charge to each customer for the resources they use each month such as database, storage and bandwidth (yes – this results in a variable monthly charge but does have the advantage of closely reflecting your cost of providing the service in the first place). I heard an interesting one the other day from a logistics company who charge per delivery. In other words a “per-transaction” cost. The customer would probably be happy with that – as they are more successful, they make more transactions. As business shrinks, the transaction count shrinks but so do the costs – there is a direct relationship between the success of the business and the costs of doing business.
All these models are great, but at the end of the day – you, as the service provider, have to still be able to make money while providing the service. Price your service too low and you lose money, price it too high and your competitors eat in to your customer base.
What you really need to know is how much each of your customers is costing you to service. How much database, storage and bandwidth do they use, what is their resource usage is like. From this you can calculate what a reasonable price is that still allows you to make a profit.
This is where a new Codeplex project can be useful. The Cloud Ninja Metering Block is an extensible and reusable software component designed to assist software developers with the metering of tenant resource usage in a multi-tenant solution on the Windows Azure platform.
There’s even a demo site you can have a look at which shows a collection of Windows Azure services and what resources they are actually consuming:
Maybe you’d like to try this out for yourself. If you have released a Beta service on Windows Azure, you could use this project to monitor usage and get a reasonable idea of what your pricing model should be before you go into a full commercial release. From then on, knowing exactly who is using what resources will allow you to fine-tune your pricing.
Planky – GBR-257