Great Interview on the Benefits of Multi-tenancy

Feb 5, 2010 by Devon Watson

This is a very good podcast of Phil Wainewright from The Connected Web interviewing Rick Nucci, CTO of SaaS integration vendor Boomi on the impact of multi-tenant architecture on the operational cost of delivering software in a SaaS fashion.

Two choice excerpts:

“SuccessFactors recently gave a speech, [by CEO] Lars [Dalgaard], talking about their architecture and their approach. They have something like over a thousand customers per physical server when you net it all out and aggregate it. Andthat‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

“And that‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

Continue reading the transcript or listen to the podcast here.

read more

Do you have to leverage “X as a Service” to be a SaaS provider?

Dec 10, 2009 by Sinclair Schuller

I love the idea that a balance exists between ideology and practicality. Questions of ideology and practicality always arise when it comes to building software, building a business, and building a software business. SaaS is no exception.

Interestingly, I had two different discussions with people who were of the position that aspiring SaaS company’s should “put their money where their mouth is” and use cloud technologies exclusively to build out their SaaS offerings, stating that it was a form of hypocrisy to offer SaaS and not use Infrastructure as a Service or Platform as a Service.

The question I have is whether it is necessary to bind yourself to “XaaS” technologies in order to be a SaaS provider. To be honest, I think that such a “requirement” is absurd. No, you don’t need to use IaaS or PaaS or anything of that nature to be a SaaS provider at all, let alone a good one. Not using XaaS says nothing about convictions. I find this sort of fanatical idealism a put off, and it’s interesting to me that people in the tech space moving to SaaS fail to realize that ‘Service’ is only new and special in the context of software. Humans have been running service business for hundreds of years. Do you think that telephone companies, electric utilities, cable TV companies, etc. only use services to run their business? No, of course not. There are many good reasons and cases to use XaaS suppliers to support your own SaaS business (EC2, etc.) and in other cases, you may need/want to run your own infrastructure. Currently, there is no clear cut rule or guide forcing one way or the other. The fact of the matter is , you can be a GREAT SaaS provider and run in a co-located space, in your own datacenter, on EC2, or whatever else you deem appropriate. What matters is the quality of service and the quality of the software.

Do you agree with the statement that a SaaS provider needs to be using IaaS/PaaS to be taken seriously, or do you feel that it’s OK for a SaaS provider to leverage non “XaaS” approaches?

read more

Not All Clouds Are Created Equal…

Jun 11, 2009 by Abe Sultan

Just a quick note: I just published an article in Datamation titled “How to Be a Cloud Computing Vendor”. The article focuses on clarifying the jargon that exists on using Cloud Computing Providers as substitutes to SaaS Platforms. 

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!

read more

Webinar Recording and Q&A Now Available – Sink or Swim: Transitioning your Software Business to SaaS

Mar 28, 2009 by Jesse Kliza

Hi everyone,

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.

read more

What’s More Cost Effective, Piecing a SaaS Stack Together or Using a PaaS?

Mar 19, 2009 by Sinclair Schuller

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 more

Non-standard PaaS – The Software Industry’s Rubber Stamp

Mar 2, 2009 by Sinclair Schuller

Coghead’s departure from the PaaS world sparked plenty of interesting debate. One small debate that caught my attention started on Phil Wainewright’s post about Coghead’s demise with a comment by Microsoft’s Eugenio Pace, which then spilled into a post Eugenio wrote here.

To give a brief synopsis, Phil argues that Coghead’s demise and the subsequent stranding of customers highlights the need for a “…standard for transferring not just data but application logic…” The argument stems from the fact that Coghead customers could not easily migrate their applications to another platform, potentially setting those folks back by months of development time, but more importantly, possibly having to throw in the towel on their applications if Coghead goes offline before they manage to perform the migration. Eugenio replied that such a standard essentially exists through standard technology stacks like Java & .NET and that if Coghead was anchored around one of these substacks, customers would not be stranded. He [Eugenio] went on to say that a “standard” was not essential. Phil responded with the following post over at eBizQ.

It’s probably of no surprise to readers that I’m siding with Eugenio on this one. First, let’s clear up some definitions. Let’s call well known development platforms like .NET, Java and Ruby to mention a few ’Standard stacks’. Standard here is being used to describe wide use and general acceptance: that is, I can walk into a development shop and drop one of those names, and engineers either work on that platform regularly or are very aware of its existence. Let’s refer to everything else as ‘Non-standard stacks.’ Something like Coghead or Caspio is definitely ‘Non-standard’; outside of the SaaS choir, few have heard of them. Note that I’m refraining from using words like ‘proprietary’; being proprietary is ok if you’ve achieved a gold standard status in the industry. 

Complex Apps Need Expressive Runtimes

First, a root problem of Non-standard stacks is that they do not Stand on the shoulders of giants. They attempt to re-invent full stacks but fail miserably. I’d be ok if these platforms focused on helping business analysts, casual developers, etc. but they all claim to solve the ailments of ISVs and software engineers. This is simply not the case. They are far too restrictive to be general purpose and solve complex issues. Stacks like Java, Ruby and .NET are unbelievably expressive. It’s like handing Michaelangelo a rubber stamp instead of a full set of paint and brushes: I’m sure he could have done something at the Sistine Chapel with a rubber stamp (see title), but it would look nothing like what we have today. For example, what happens if someone wants to build an audioprocessing application on Coghead (or an equivalent) and deliver it as SaaS? It can’t be done. The expressiveness required for this sort of endeavor is beyond any current Non-standard stack for SaaS. Clearly, .NET, Java and Ruby can support this endeavor. Now, build a Non-standard stack with the expressiveness of the ‘antiquated’ stacks and it has a fighting chance!

A Standard Probably Won’t Help

Assuming one is ok with the limited stack and understands that they will function in a small corral, then the discussion moves to ‘lock in/lock out’. The whole conversation stemmed from the idea of ‘lock-out’ experienced on Coghead. Yes, having an intermediary ‘logic standard’ would have prevented lock out. I can appreciate Phil’s desire for a ‘kill all’ logic standard, but it’s quite impractical, almost impossible to implement correctly, and wouldn’t eliminate the ‘lock in/lock  out’ problem. Eugenio really hit the nail on the head with some of his comments regarding “minimum common denominator syndrome” (the fact that a standard has to be the baseline and expose only control mechanisms that are common across translation targets) and the fact that each implementation can innovate atop of the standard, but this is hidden from the standard. Most folks want to take advantage of innovation, but if you do and you live in standard world, you’ve now re-locked yourself. It seems that it doesn’t really solve the problem, only pushes the boundary out into the world of mediocrity. Many moons ago, I was a Java architect and  also worked as a .NET architect. I can assure you that even in similar stacks, the idea that the ‘logic’ could be captured generically in a standard is difficult to swallow. For the sake of making a point, imagine writing an audio processor delivered as a SaaS application in this generic standard (XML or otherwise). Next, what happens when rogue group X doesn’t like the standard? They’ll define a competing ‘standard’ of course! This never happens in the dev industry…

If you’re locked into Java or .NET, yes, in agreement with Phil, it’s still lock-in, but not anywhere near as bad as lock in to a non standard stack. Locking to a standard stack provides some sense of ubiquity with a max downside of having to figure out where and how to run your IP, and how to fill the gaps left by the now done platform. Lock in to a non-standard stack means a downside of disaster.

The Better Way

At Apprenda, we chose to implement a real multi-tenant, SaaS commercialization and architecture platform ontop of a giant – .NET, and allow those writing apps to leverage this. This gives you a certain amount of mobility and ubiquity, and defers SaaS architecture and commercialization issues to the platform. In SaaSGrid’s case, we treat SaaS like a cross-cutting concern, which leaves most of the application to it’s own concern. This ensures that lock in/lock out is minimized and the application can actually function somewhere other than SaaSGrid, but when in SaaSGrid it runs fully as a service. I think Eugenio’s point that this design seems much more reasonable and would have helped ISVs with application from simple to complex deal with the disastrous Coghead outcome. This is very different to Phil’s examples of Heroku or Engineyard for Rails.

The SaaSBlogs group on LinkedIn now has 1500+ members and it’s growing every day; make sure you are not missing out and join today.

read more