Category Archives: SaaS

End user chargeback: Why Service Providers do it better

One of the benefits of adopting a cloud strategy is the ability to charge for resource usage back to the end user. From the early days of ISPs where end customers were charged for traffic volume, cloud chargeback has evolved to support a variety of metrics, like virtual machine uptime, disk IOPS and even API calls. Metering engines are present in all popular private and public cloud platforms (Apache cloudstack, VMware chargeback manager, Abiquo to name a few) and produce decent reports that can be directly used as input to billing services or quarterly departmental budgets.

However, charging directly the end user for consuming IT services remains a challenge. It’s easy to meter and charge a departmental virtual server running Sharepoint, but how do you charge individually each and everyone of its 1,100 users? Or, how do you charge MS Office usage all over your user base? (If you think that it’s silly to count how many users are running Office or using Sharepoint services, then take a look at your Microsoft annual bill and think again).

To implement end user chargeback, you need metrics that have affinity to the end user. Such metrics are two:

  • End user right-to-use (or software license)
  • Application or service execution

To make use of these metrics, the underlying infrastructure must be based on a SaaS stack, not an IaaS stack. Charging end users from an IaaS perspective (metering virtual server memory, CPU and disk usage) is like receiving an electricity bill for the entire building and dividing it to the number of the building tenants. On the contrary, delivering SaaS instead of IaaS makes end user chargeback feasible, since you can measure the two metrics stated above.

And here is where service providers truly have an upper hand in measuring consumed software licenses and software usage versus IT mamagers and CIOs running private clouds. The reason? Software vendors.

Most software vendors (Microsoft, Symantec, Citrix, VMware and lots of others) sell their software licenses (rent, to be exact) with a special licensing scheme, targeted at cloud service providers. The “service provider” offering (Microsoft’s SPLA, Citrix CSP, Symantec ExSP, VMware VSPP) bills service providers by the month or every quarter depending on the number of software licenses their end customers consume, without upfront investments in software licensing costs. Given today’s rich cloud software stacks, a cloud service provider can build and deliver software over the wire and charge end users for using just the software license, doing away with virtual server CPU utilization, memory consumption or cloud disk capacity.

An example: Delivering 90% of Microsoft software today is entirely possible for any cloud provider that has a signed SPLA agreement. From MS Office up to Biztalk services, Microsoft imposes a monthly fee for every reported software license. Citrix on the other hand have a flexible service provider licensing scheme, charging per concurrent user, for using XenApp for software execution and ICA for pixel/keystroke delivery over the wire. Put these on a VMware vCloud farm and utilize VMware’s VSPP for licensing your ESX infrastructure, and you have a complete SaaS stack, without any upfront licensing costs: Charge your end users for software usage, collect your payments and pay back your software vendors every month or every quarter. You don’t have to worry if you have 100 customers on January and 5000 customers on February, you don’t pay any upfront licenses.

What is wrong with this? Corporate organizations are not service providers, so they are not eligible for paying for the software they use as a service. They are stuck with inflexible contracts and software support costs, without any agility in paying for the software they use. For organizations that have a steady and fixed number of users this may be OK, but for companies that have fluctuating user numbers, that’s a problem: You just can’t rent 200 MS Sharepoint licenses for three months. If you fall in this category, why don’t you start talking to your cloud provider?

SaaS at your fingertips

Have you ever wondered what does it take to develop an SaaS app? What kind of developer resources are needed? Infrastructure? Tools? Platforms?

Let’s say you want to build a small app that shows on the fly the value of a stock and its market cap. You need a place to host it, a developer to write the code and find a credible feed of stock price info. Sounds a bit (but not too) complex.

Or, do it in 30 seconds, provided you know what a spreadsheet is… Try this.

(Hint: It’s a Google Docs spreadsheet. Hosted somewhere in a Google datacenter. Stock price and marketcap retrieved via Google Finance).

Adding value to SaaS

Software as a service is an entirely different animal from IaaS or PaaS. Implementing the latter two can be done (almost) with platforms available off the shelf and engaging a few consultants: Grab your favorite cloud automation platform (pick any: Eucalyptus, [Elastic|Open|Cloud]stack, Applogic, Abiquo, even HP SCA, throw in volume servers and storage, host on a reliable DC and you are good to go).

On the other hand, SaaS is something you have to:

  1. Conceive. IaaS and PaaS are self explanatory (infrastructure and platform: Virtual computing and database/application engine/analytics for rent); SaaS is… everything: from cloud storage to CRM for MDs.
  2. Implement: SaaS is not sold in shops. You have to develop code. This means, finding talented and intelligent humans to write code, and keep them with you throughout the project lifecycle.
  3. Market: Finding the right market for your SaaS is equally important to building it. SaaS is a service; services are tailored for customers and come in different sizes, colours, flavors. One SaaS to rule them all does not work.
  4. Sell: Will you go retail and address directly end customers? Advertising and social media is the road to go. Wholesale? Strike a good revenue sharing deal with somebody that already has customers within your target group, say, a datacenter provider or web hosting.
  5. Add some value to your SaaS. Cloudifying a desktop application brings little value to your SaaS product: It’s as good as running it on the desktop; the sole added value is ubiquitous access over the web. Want some real value? Eliminate the need to do backups. Integrate with conventional desktop software. Do auto-sync. Offer break-away capability (take your app and data and host somewhere else).
Let’s take two hypothetical examples: Cloud storage and CRM for doctors.
Cloud storage is a good offering for customers seeking a secure repository, accessible from everywhere. Let’s consider two approaches:
  • High end branded storage array with FC and SSD disks
  • 5-minute snapshots, continuous data protection
  • FTP and HTTP interface
  • Disk encryption
  • Secure deletion
The second approach would be:
  • WebDAV interface
  • Data retention
  • Daily replication
  • Auto sync with customer endpoints
  • Integrated content search

What’s wrong with the first approach? It is typical of the IT mindset: Offer enterprise IT features, like OLTP/OLAP-capable storage to the cloud. Potential customers? Enterprises that need to utilize high-powered data storage. Well, if you are an enterprise, most likely you’d rather keep your OLTP/OLAP workloads in house, wouldn’t you? Why bother?

The second approach offers services that are not delivered from your enterprise IT machinery. It’s added value to a cloud storage service and at the end of the day, they are deemed too expensive or complicated to implement in house. Potential customers? Enterprises that have not implemented these services but would seriously consider renting them.

Let’s consider now a cloud CRM for doctors. What would be some value added features for private MDs, apart from a database with customer names and appointment scheduling? I can think of a few:

  • Brief medical history of patient delivered to the doctor’s smartphone/pad. Can save lives.
  • List of prescribed medicines with direct links to medicare/manufacturer site. Patients can forget or mix up their prescribed drugs; computers never forget.
  • Videochat with patient.
  • Patient residence on Google maps and directions how to get there