First, let’s chat about commodity hardware in general. First, commodity hardware enables commodity computing. The basic idea is that we’ve moved away from supercomputers, or “scale-up” systems (i.e. throw more memory, CPU, and disk at a single physical box to make it better) and to a scenario where we can “scale-out” by adding more inexpensive physical units as a solution to scale problems. Normally, this is done as a reactive measure to a mounting scale problem. We see this in everything from plain old websites to SaaS architectures. As inbound load increases, we add hardware to resource pools thereby increasing capacity, we then load balance, and voila, all better! Interestingly, infrastructure as a service (dialing up raw resources like servers on EC2) makes this even more practical as a solution. It used to be that “commodity hardware” meant real iron, but now we can deal with this virtually and in an “elastic” fashion (the ‘E’ in ‘EC2′) We’ll categorize this reactive commodity-based measure as naïve scale-out. I don’t mean this in the pejorative, but rather in the formal sense; systematic scale-out of this type exploits coarse grained application level allocation and “bolts on” new capacity with the notion that any new capacity be only minimally aware (if at all) of the “old capacity” and the scale problem it is actually solving, hence the word naïve. Assuming that dynamic scale out needs are real enough to justify using cloud hardware (e.g. EC2, GoGrid), then we have an amazing tool to solve our problems.

Naïve commodity scale-out is amazingly powerful and has catalyzed web-scale operations, but is it the “end all” solution? Not even close. Commodity hardware, at least for most of computing, has allowed us to “back into” older software like RDBMS, traditional application servers (e.g. IIS, JBoss) and build certain types of software architectures in response to scale-problems. Realistically, however, it’s not terribly innovative on its own. What I find most intriguing is the “what’s next” discussion. If we look at the past few years, we should have good indication of what commodity hardware, and more specifically, commodity hardware in the cloud, is allowing us to do.

Let’s use Amazon as a focal point (for no particular reason other than they exemplify where some of the change is headed) When we first think of Amazon, we think of infrastructure as a service: raw servers via, EC2 and web scale storage via S3. But now, Amazon is starting to evolve. Recently, they announced Elastic Map Reduce, which is essentially a step up the stack to the algorithm layer made possible by the mass parallelization offered by commodity cloud hardware. In my opinion, we’re going to see a revolution where “the cloud” will no longer mean boring servers that can be “fired up” on command, but rather a whole array of tools like Elastic Map Reduce that are the software layers that expose commodity hardware’s real value. We even see this with our beloved SaaSGrid - rather than being a traditional “single server” or “single cluster” application server, SaaSGrid establishes a “fabric” across arrays of servers (commodity) and creates a unified hosting layer, allowing the applications it hosts to trivially leverage an expanse of servers. This is a great thing to see, given that the complexity of engineering software to actually leverage commodity hardware layers is a difficult thing to do correctly, and will open the door to a host of SaaS applications that weren’t physically or economically possible before.

Just a quick note to all readers, I’m going to be at the Structure 09 conference next week in San Francisco participating in a panel discussion titled “Hosting Cloud On Commodity Hardware“. If you are in the Bay area and are planning to be at the conference, make sure to pin me down to talk some Cloud!

Structure 09 is presented by Om Malik and The GigaOM Network team and it brings together customers, entrepreneurs and early influencers that drive the tech industry.

The Key Note speakers for this year’s conference will be Mark Benioff CEO of Salesforce.com and Paul Sagan CEO of Akamai and the speaker lineup is just as impressive so make sure not to miss out on it.

Looking forward to seeing you all there.

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 2160+ members and is growing every day; make sure you’ re not missing out and join today!

Check it out and let me know what you think!

Cheers
Abe

PS: If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 2130+ members and is growing every day; make sure you’ re not missing out and join today!

Let’s use the U.S. government as a discussion point. In 2005, the federal government was a sprawling institution of 3.3 million civil servant and military personnel with 10 million other works that were direct government contracts and “grant workers,” for a total direct and indirect workforce of 14.6 million people! Clearly, we haven’t included state and local government in this mix, but I think you get the picture; the numbers are staggering. These millions of employees leverage software every day. For many scenarios, generally available SaaS offerings like Salesforce.com will fill many needs, but the government ecosystem also requires a massive number of niche applications to help in very specific tasks. For example, consider managing parking tickets or traffic violations. Generally speaking, custom software would be used for this task. The internal market for niche applications is just as staggering as the raw employment numbers.

So how does SaaS play into all of this? Let’s consider much of internal government IT functions at this point. If some municipality needs a software package to manage traffic violations, it either (a) writes it or (b) contracts a consultant to write it and then runs that software on some server it owns or leases. The municipality next door has a similar need and pursues a similar path. You can extrapolate this process to many different municipalities, each with their own on-premises solution. The fact of the matter is, many will have the same or extraordinarily similar requirements when it comes to their traffic violation systems. What you end up with is a generally unnecessary gross over allocation of resources. Each municipality is maintaining infrastructure and code on its own, resulting in pressure on the IT budget, inefficiency in terms of delivery and maintenance, and general headaches.

These niche applications are completly warranted in terms of functional need, but can SaaS help with the delivery and save the government time, money and effort? Absolutely! SaaS is often overlooked as an intra-enterprise (i.e. private cloud) deployment model. For example, considering the common functional overlap for our traffic violation app, as well as the lack of strategic value associated with hosting the app themselves, municipalities would benefit from “banding together” or relying on a super-scope governmental body (think the county or state governments in the U.S.) and having the application written once and delivered as a service to each municipality. Furthermore, this model could be extrapolated to a number of applications, allowing the centralized management and delivery of applications, as well as governmental standardization. This would create huge savings for the government, allow for an unbelievably flexible sharing and deployment model, and get rid of waste.  I’m excited to see SaaS architectures materialize within organizations as a viable model that changes the way these organizations write and consumer internal software.

What’s your opinion? Is SaaS only beneficial to the government from a consumption point of view, or is the
idea of leveraging the delivery model on a “private cloud” for internal applications equally (if not more) powerful?

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 1970+ members and is growing every day; make sure you’ re not missing out and join today!

Recently, Bob Warfield over at Smoothspan wrote a couple of excellent multi-tenancy oriented posts. In one of those posts, Warfield drilled into the Salesforce.com numbers I mentioned earlier in an attempt to quantify the impact of their architecture on cost of service. Warfield gave some analysis around multi-tenancy on the overall cost of service incurred by salesforce.com. Looking at the salesforce.com annual report, it’s apparent that it costs salesforce.com $0.12-$0.13 per $1.00 of revenue to deliver its service for a total of $127 million for the year on roughly $1 billion in subscription revenue. Warfield identified that if they’re running 1,000 servers, we can use Amazon pricing as a roughshod estimate of what the actual servers would cost them if they were running on the Amazon cloud: about $4.7 million per year. That leaves about $122 million unaccounted for! As Warfield pointed out, clearly there are lots of other expenses. It’s most likely that these expenses are due to lack of automation and overabundance of personnel due to said lack of automation. To a degree, this means that multi-tenancy is doing its job: the software’s architecture and resource utilization is but a fraction of total cost of service.

To understand this better, let’s use Warfield’s numbers and recast the scenario with the question “What if Salesforce.com weren’t multi-tenant?” Currently, we know that about 55 customers are supported per server. Many propose virtualization as a route to multi-tenancy since it’s so easy to fire up an instance on say, EC2, and create a 1-1 affinity for a customer to a server. If we imagine Salesforce.com to use this architecture instead, one where virtualization is used instead of a multi-tenant approach, we get a drastically different picture. I won’t calculate the EC2 costs, but instead will use Warfield’s numbers: one EC2 instance costs about $4,700 per year ($4.7 million/1,000 instances). If we dedicated a single instance to each customer (that’s 55,000 instances based on Salesforce.com’s number of customers), it would cost Salesforce.com $258 million! Let’s be generous and give it a 2:1 leverage (maybe there is some server sharing) and cut the instances in half, we’re still pushing $129 million. Assuming that this virtualized approach got rid of all internal staff and expenses at Salesforce.com related to cost of service, we’d have to hit that 2:1 leverage to even be competitive with their current cost structure. More than likely, taking a virtualized approach wouldn’t entirely get rid of Salesforce.com’s “out of architecture” expenses since I’m pretty confident that not ALL of the remaining $122 million is dedicated to simply running their 1,000 servers, but some big chunk is. Even if a virtualized or in the cloud approach had a 2:1 leverage and slashed 75%  of the $122 million, Salesforce.com still wouldn’t have the cost profile they do now.

Point? It seems multi-tenancy at $4.7 million worth of hardware/software resources has a big something to do with the overall cost profile. As Warfield pointed out, something else is making up a brunt of the cost, but the architecture approach certainly seems to have depressed it’s part of the cost to something reasonable. Now, how about a multi-tenant architecture on EC2? I’d love to see some cost specifics in the wild on this sort of arrangement!

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 1950+ members and is growing every day; make sure you’ re not missing out and join today!

The conversation has been interesting to follow because it seems that the common theme everyone (including myself) wants to address is the cost effectiveness related to multi-tenancy. In one camp, there are those of us who argue that in many delivery scenarios, multi-tenancy has a drastic impact on delivery costs (even in light of modern virtualization techniques) and in the other camp, folks feel that the cost advantages are overblown/non-existent: merely a manifestation of ‘green crystals marketing.’ If you didn’t gather from the last sentence, I’m firmly in the camp that believes (I’ll go out on a limb and even say knows) that multi-tenancy can have huge relative effects on cost of delivery. I won’t dive into the cost effectiveness (since I’ve touched on this in the past), but instead, focus on a different discussion: the positive impact of multi-tenancy beyond cost, and why other 1-to-many architectures don’t make sense for SaaS.

First, let’s lay some groundwork. SaaS itself is more than just “cheaper software,” but in fact SaaS has a certain number tenets associated with it. SaaS is important because aside from helping drive TCO down for the end customer, it introduces the notions of ubiquitous access, collaborative use of data and function, and rapid adoption of newly introduced value (if your SaaS provider adds new bells and whistles, you just get them. No installs, no updates, etc.) Arguably, the TCO properties will bear less of the ”burden of proof” over time, since most line of business apps will converge to SaaS; TCO won’t differentiate one SaaS offering from another since they’ll all be saying the same thing, but the value that each delivers on the other SaaS tenets I just rattled off. The real question then becomes: does a multi-tenant architecture positively impact an application outside of TCO and does it provide an increase in net value to the end user? The answer is most assuredly yes! Let’s understand why.

When you hear the word “native” with respect to architectures, it usually means that the software architecture has ingrained artifacts of an architectural style. When we say multi-tenancy, it means that the software architecture is built to natively understand (and cope with) multiple constituents accessing shared volatile and non-volatile compute resources, maintaining virtual segregation and isolation despite said sharing. There are two big takeaways from this:

1.       Generally speaking, multi-tenancy is captured in an abstract, foundational way within these sorts of architectures so that anything written on/above this part of the stack is inherently multi-tenant. We’ll coin the phrase ‘functional tenancy projection’ at this point. A ‘functional tenancy projection’ is the notion that any new function or dataset defined in a properly architecture multi-tenant system is trivially multi-tenant. This is true from everything from application code to ‘system code’ that helps manage and maintain the operations of the application. I’ve briefly discussed the before, but this is possible because of the notion of cross-cutting concerns.

2.       A multi-tenant architecture, by virtue of natively isolating and segregating tenants from one another within a common application and resource set, may trivially de-segregate those tenants. So what, you ask? Because of collaboration! Well architected multi-tenant offerings can trivially allow for tenants to function in ‘de-segregated’ groups, thereby sharing data and function. The ISVs creativity would be the only thing limiting the amount of value that can be delivered to the end customer via collaborative function.

These two takeaways make multi-tenant systems *very* different from virtualized single tenant architectures. When someone makes references to SaaS via virtualized single instance architectures, they indicate that each customer is maintained in a completely isolated virtual container, rather than sharing resources.  In other words, the application doesn’t capture tenancy, but instead the infrastructure does. Traditionally, this was a cumbersome proposition because it meant that IT had to fire up a server per customer, so there was a clear advantage to a multi-tenant architecture since everything from provisioning a customer to updating code was trivialized. With the advent of virtualization, this was no longer the case. A customer instance could be spun up virtually (and trivially), updates were easier, etc. Essentially, with virtualization, one can build a multi-tenant “exoskeleton” that routes requests and mechanizes maintenance processes, so the “virtualize it all” camp has some merit to their claim since it is starkly different than the multi-tenant vs single-tenant discussion that people had in a non-virtualized world a few years ago. The problem comes when we try to understand whether advanced form like those defined in the “two big takeaways” are possible. Unfortunately, properties like the two big takeaways simply aren’t present in a single-tenant, single instance architecture. Let’s look at each takeaway through a single-tenant lens.

1.       Adding new application logic to a single instance, virtualized architecture becomes trivially available to all customers since the multi-tenant “exoskeleton” would roll out that code to each instance. To a degree, this is equivalent to ‘functional tenancy projection’ in the application layer. But what about “systems” code? If I need to add new maintenance capabilities, can I? If I want to manage something like ubiquitous access, would that systems functionality be trivially multi-tenant? Probably not. Each addition of systems functionality is not a ‘tenant projection’ but must instead address tenancy directly. This means that it takes longer to write these parts of the application and it takes longer for customers to experience value.

2.       Since the application code knows nothing about tenancy, the idea of writing functionality that allows for collaboration on data and function becomes far less than trivial. The “exoskeleton” would have to support piping data and function between tenants, creating a cumbersome mechanism for collaborative interaction. This is what happens when something that isn’t multi-tenant wants to play in a multi-tenant world.

Granted, these are just two positive advantages of multi-tenancy, but they actually unfold into a host of other positive attributes that simply cannot be attained easily in single-tenant, virtualized architectures. Hopefully this leans some of the discussion away from cost and toward understanding the positive business impact of multi-tenancy.

For good ‘ole time’s sake, I will briefly revisit the cost question in my next post. Warfield’s discussion of the Salesforce.com 1,000 server measure was intriguing, and may help shed some light on what we really need to understand when comparing multi-tenant architecture to virtualized single-tenant approaches.

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 1900+ members and is growing every day; make sure you’ re not missing out and join today!

“Well, a PaaS seems to save us a ton of upfront effort and cost. In fact, it might cut our costs down from $600,000 and 14 months to $200,000 and 4 months. However, if we go with a PaaS, we’ll have an ever present operational expense that never goes away. If we go with option 1 and just bite the bullet, sure we’ll spend the money and time upfront, but that’s just a one-time investment. Won’t we experience ROI on that 10 months and $400,000 rather quickly?”

My answer is an emphatic no! Now, don’t take the platform guy’s (me) word for it: let me put some substance behind my claim. To understand why I say no, let’s really understand the question. Starting from the top and irrespective of the aforementioned question, an ISV is deciding to deliver software functionality to the web. That functionality is valuable to their customer base. The better the ISV is at their core competency of capturing value for their customer, the better off the customer is and the more likely the business is to succeed. If you’re building an HR app, every minute and dime your company invests in HR functionality could yield added value for your customer and higher revenue for you.  At no point does this suggest that somehow the delivery model is the core value offering to your customer, or that your competency is in constructing a delivery model. In fact, it’s a distraction to the primary goal. Now, going with option 1 with a notion that we have to “Build it here because it’s a one-time investment and we’ll make a return” assumes that it is in fact, a one-time investment. This couldn’t be farther from the truth. Realistically, you’ve in fact decided to take on the burden of whole product line and its lifespan. I’ve constructed a conceptual diagram to capture the rough notion of relative cost between your actual offering (an HR app), the “home built” SaaS delivery model stack, and opportunity cost (all of which I’ll discuss)

At the start of your SaaS journey, option 1 means that a huge chunk of your development time and money (40% - 70%) will be focused on solving SaaS delivery model problems and not on the value proposition you plan on delivering to customers. This is what accounts for the added 10 months and $400,000 in our initial scenario. Now, if the buck stopped there, our decision maker might be right: ROI is right around the corner. Realistically, you’ve made a first attempt at building a SaaS delivery model and have rolled out a very immature SaaS support stack. Once you launch your product, you’ll start your first maintenance and “new feature” phase of your offering. During this period, you’ll find that the most bugs and changes are coming from deep SaaS architecture problems and change requests. Your time will most likely be diverted away from product change requests (read: innovation) by SaaS stack repair. If you’re successful, you hit some “scale event” and feel a massive “cost pinch” and risk point. The scale problems in this case are most likely a result of poor assumptions in the SaaS stack, or the coupling of your actual application to the underlying delivery model machine. This cycle of maintenance effort and scale events will likely happen a couple of more times, and a couple of years down the road, with thousands of man hours and lots of money spent on the SaaS stack, you’ll reach a point where the stack effort starts to decrease, giving you some breathing room. At that point, you’re done battling fires with the fits and starts of big problems and maintenance phases, but opportunity cost ambiguity kicks in; are you going to exert effort on your core product or boost value in the delivery stack? Odds are you’ll forgo improving the stack (despite the massive value it can inject in your business) in favor of responding to customer demand on domain functionality need in your nifty HR app (since you’ve been distracted by the SaaS stack for so long). Those opportunity costs mount, and potential added revenue or savings opportunities disappear. Think of simple examples like giving your customers the ability to download data backups: is that an application specific problem or a “horizontal” problem for which a stack should be responsible? Do you want to waste effort on this or would it have been wiser to build on a PaaS that either has this functionality or that would introduce it faster than you would? I guess it wasn’t a one-time investment after all! In fact, it seems to be a massive ongoing investment with little predictability or bounds. This discussion hasn’t even touched on the maturity concept (for example, a “home built” SaaS stack will bump into security problems, bugs, etc. that get resolved in PaaS offerings much quicker because of the speed at which they scale due to aggregation, and the fact that PaaS providers focus solely on solving these problems).

When looking at a PaaS offering like SaaSGrid, you need to understand that paying a utility fee gives you a fully maintained delivery model without the ongoing headaches; one that will evolve much faster than you can imagine, constantly adding value to the guest applications that depend on it. If this isn’t enough, history has shown us great analogies. For example, why don’t people write application servers each and every time they write an on-premises web app? Because it doesn’t make fiscal or logical sense! You just download JBoss or buy WebSphere and go about your business! It’s very difficult to argue that a “home built” stack would be more powerful, less costly, and more able to keep up with market change.

What’s your opinion on PaaS vs. building it all yourself? Does the application server analogy resonate well with you? I’m interested in your feedback!

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 1775+ members and is growing every day; make sure you’ re not missing out and join today!

We had a great turnout last week for the webinar, and a number of people have asked if they could get access to the recording, so here it is. I’ve also compiled a list of some of the question from the Q&A session here, along with the answers.

Q&A

Q: We have our app completed, but are working on the provisioning/billing parts (hard for us). Can SaaSGrid provide a sandbox for our app such that we can deploy one copy of the app per customer? - our app is .net based and is a web application already. For us, our value is in our s/w, not in building special purpose billing systems

A: Absolutely, you can register for access to the SDK and a Sandbox account here. 

Q: What are the on-going cost advantages of using a PaaS like SaaSGrid?

A: Applications built “from the ground up”  without a PaaS incur massive ongoing R&D and maintenance expense. Your R&D team will have to manage the code base, fix bugs, and maintain the layer. This is expense will generally become disproportionate to the R&D of the actual app on an ongoing basis. Second, a home grown SaaS stack will normally reach a “freeze” point where no new added functionality is added. A PaaS is constantly looking to evolve and inject new value into the applications and business it hosts. A PaaS provider can help drive revenues up and costs down without the participation of the ISVs it works with. Last is flexibility. A PaaS environment is built to be horizontal and support any application. Good PaaS offerings like SaaSGrid also offer commercialization tools, lifecycle management tools, and support tools that become part of an ISVs day to day.

Q: What approximate effort is needed to make existing hosted applications into SAAS. Is the architecture to be re-designed or can be used as it is?

A: It depends on the application, but utilizing SaaSGrid, some existing application can be deployed as a pure multitenant SaaS offering with out any effort.  Others may require modifications before they can be deployed.  SaaSGrid does not require any proprietary work to be done to your application, it simply requires that you’ve adhered to current best practices for architecting your .NET application.

Q: What about ISVs that already have a J2EE application?

A: Currently, SaaSGrid is specifically focused on .NET based applications 

Q: What happens if the PaaS provider goes out of business?

A: Depends on the type of PaaS provider. If it’s a “custom stack PaaS” that has its own programming languages, the scenario is dire because the code can’t work anywhere else. Existing language/runtime PaaS offerings like SaaSGrid allow you to run your code on-premise, which at least lets you recover your application even though it won’t be a SaaS offering. At Apprenda, we’ve focused on a disaster recovery plan where our cloud partners that run SaaSGrid will continue to run the platform for a significant period of time, thereby mitigating any disaster scenarios and giving the ISV the ability to continue business as usual.

Q: What is the typical cost and timeframe for developing a SaaS application?

A: Depending on the complexity of the application, the SaaS aspect of an application can take up anywhere from 30%-70% of upfront development time and account for roughly 30% of ongoing costs and development effort. 

Q: What if my application is running on a different environment – can I still use SaaSGrid to manage my business (subscriptions, etc.)?

A: Currently, no. SaaSGrid exploits the fact that it manages the environment the applications run in to provide much of the business management aspects like metering and subscription based authorization magically, without writing a line of code. A huge amount of value exists in running within SaaSGrid that normally provides rapid ROI on time and money invested to moving to the SaaSGrid environment.

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 1730+ members and it’s growing every day; make sure you are not missing out and join today.

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:

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:

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.