What’s More Cost Effective, Piecing a SaaS Stack Together or Using a PaaS?
At the OpSource Summit last week, Treb Ryan gave a great presentation that started with a simple (oft taken for granted) question: what is ‘the cloud’? Although this part of the talk was interesting, one particular part of the talk caught my attention. A third or so of the way through, Treb focused on the drivers behind cloud adoption and discussed how cost reduction is not a primary adoption driver because it doesn’t exist. As evidence, Treb compared two scenarios both requiring a server and equal bandwidth needs. The audience was presented with two implementations: running an EC2 instance to satisfy the server needs and getting a commodity managed server through ServerBeach. Interestingly (but not surprisingly), it was significantly cheaper to go with a raw metal ServerBeach server than an EC2 instance. As Treb went on to point out, the cloud delivers new value that justifies some of that extra cost, like being able to dial up/dial down server instances via an API as needed. This is the ultimate in flexibility, and solves lots of problems. Unfortunately, some are using this flexibility as a hammer and everything around them has become a nail.
During Treb’s talk, I recalled speaking to someone a few weeks earlier about how virtualization solves multi-tenancy (which it does, but very poorly, as I’ll go on to describe) That prompted me to ask: given Treb’s discussion of the higher cost of certain cloud services, what’s the cost of service impact of using something like EC2 as a foundation for a SaaS offering and as the “solution” to the tenancy problem? In fact, what’s the cost of service impact for building a SaaS offering around disparate off the shelf components in general (e.g. Zuora/Aria for billing, something else to help with provisioning + all necessary plumbing code)? I decided to capture this modeling experiment in this post and see if we can come up with a framework for cost of service and capital requirements.
Given that this is a theoretical analysis, we need a scenario to work from. SaaS is broad, so let’s zoom in on a SaaS model we’re all familiar with: charging a per user/per month fee for some line of business application (ala Salesforce.com, RightNow, Basecamp, etc.) A B2B SaaS offering in this model averages around 15 seats per customer. Let’s peg the price per seat at $60.00 per month for the sake of modeling (which by my measure seems reasonable). For our first step of the model, let’s look at recurring cost (cost per unit revenue measure, or in human, cost per seat license) Once we understand this, let’s estimate the total upfront investment for tying all of this together.
To start, let’s focus on EC2. As I mentioned, some like to look to EC2 to solve multi-tenancy. Usually, this is to avoid building a multi-tenant architecture like Salesforce.com’s (which, to do properly & from scratch is very difficult and time consuming) The basic idea is that an EC2 server instance can be fired up per customer (a single instance, single tenant model) or that an application can be split into a couple of layers where each customer might get their own frontend servers for application segregation, but multiple customers map to a single database server each with their own database instance (a hybrid of single instance, single tenant on the frontend and single server, multi tenant database that uses logical databases for segregation). For this hybrid case, let’s assume that we house 40 customers on 1 DB server. In other cases, some might opt for a two server setup: a frontend server and database server per customer, depending on the organization of compute and query processing needs.
So what’s it cost per seat in each of these scenarios, assuming our average? Well, we can do some mapping. First, running a single EC2 instance of the “small server” configuration is $73.00 a month. This might be ok for some, but any other configuration is at least *double* this. We’ll stick to the basics though. At 15 seats per customer, each configuration incurs the following cost penalty per user per month just for EC2:
|
Per User Server Cost |
Cost |
as % of Revenue |
|
Single Server |
$4.87 |
8.12% |
|
Two Server |
$9.73 |
16.22% |
|
40-1 Setup |
$4.99 |
8.32% |
Ok, so we know what we’re paying for hosting and “multi-tenancy” per user. We’ll reserve judgment on whether this is expensive or not for later.
Now time for billing. Practically every revenue generating SaaS offering needs to issue invoices, collect money, process refunds, etc. Some SaaS providers have cropped up that offer billing as a service. As part of the model, let’s use Zuora. Based on what I found online, Zuora charges 2% of revenue. So, regardless of tenancy scenario, that’s a $1.20 per user charge.
Ok, so we have billing taken care of, but we need to address provisioning of customers as well as a management layer for customer servers. For that, we can tap into Rightscale. Rightscale has technology that lets us capture server images, button click deploy EC2 instances, and seems to have a nice API. Technically, we could build a provisioning system around it that allows us to commission EC2 resources whenever a new customer is onboarded. Rightscale charges $500 per month for up to 20 server instances, plus $24.09 per month per server image managed thereafter. If we add billing and provisioning into the mix, we arrive at the following cost structure for different seat counts:
|
Customers |
5 |
40 |
500 |
2,000 |
|
Users |
75 |
600 |
7,500 |
30,000 |
|
Cost per User |
||||
|
Single Server |
$ 12.73 |
$ 7.70 |
$ 7.68 |
$ 7.67 |
|
Two Server |
$ 17.60 |
$ 14.18 |
$ 14.15 |
$ 14.15 |
|
40-1 Setup |
$ 12.86 |
$ 7.82 |
$ 7.80 |
$ 7.79 |
So at 30,000 end users with the most efficient setups, we’re hovering around 13% cost of revenue, and this model hasn’t even accounted for other critical pieces. Ouch! This is a huge chunk of revenue to only solve 3 problems. A full SaaS stack is much deeper than this. You’d still have lots of code to write to orchestrate these pieces, and as a delivery stack, it’s quite immature. You still have high availability to deal with, and rolling out updates (which usual requires a good engine to update and migrate customers), user and authentication systems, application health monitoring, etc. All of this stuff piles up into one massive effort, and you then have to maintain a full delivery stack and all the orchestration from and R&D perspective. The R&D requirements are large, and the cost of service continues to grow. This really isn’t optimal, with a huge chunk of service focused on multi-tenancy and hosting via EC2. Generally, efficient multi-tenancy can take a giant bite out of that cost, so using the hammer on the screw might not be the way to go.
This topic interests me because I think it really starts to shine light on why PaaS offerings like SaaSGrid make sense. PaaS offerings capture the most complex pieces of SaaS and trivialize them along with all other critical stack components, while delivering them efficiently so that cost of service goes way down, while rapidly aggregating across apps to boost economies. You could go through the aforementioned design headaches, incur the upfront R&D costs, maintenance costs and relatively high cost of service or you can drop your app into a PaaS container that can do its magic on the app. PaaS costs, particularly over the long run, are insignificant compared to the costs we discussed in this post. I find that folks that “home brew” SaaS delivery capabilities end up spending disproportionate amounts of ongoing R&D on SaaS, on not on generating value for their customers. Personally (and obviously), I like the PaaS idea; after all, we all didn’t go off and build application servers, we relied on things like IIS, Websphere, and JBoss. All of this is important to think about when trying to figure out how to implement your SaaS offering and what each implementation decision means to the bottom line. Granted, this is a theoretical model, but it works well as food for thought.
Are there any other significant components that should be factored into cost of service? Does understanding this make PaaS more appealing?
The SaaSBlogs group on LinkedIn now has 1660+ members and it’s growing every day; make sure you are not missing out and join today.
read moreRelated Posts
Tags
Share This
