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

Farewall to PaaS Provider, Coghead

Feb 19, 2009 by Sinclair Schuller

Coghead announced it was shutting it doors yesterday evening. For those unfamiliar with Coghead, it was a much talked about PaaS offering that offered an online application editor for rapid application development. They fell under the category of non-standard stack, a “4th generation language and runtime” (4GL) if you will. It seems that slow adoption coupled with the economic situation got the best of them. This is clearly a big problem for Coghead customers, and is indicative of why I don’t particularly like the “PaaS requires a new language/runtime/stack (pick and choose) because older runtimes and languages simply don’t work” statements. First, the notion that something like C# (or any .NET runtime language), Java, or Python can’t work is simply a problem with fundamentally understanding runtimes and what they can and cannot do. Second, new languages and stacks are generally dangerous unless they have MAJOR support from a large platform vendor. Why? Risk. Coghead is letting folks know they can access their data until April 30th, 2009. Unfortunately, data is not the application and any VARs, ISVs, or IT departments are up the creek without a paddle when it comes to the application itself. If the apps were built on some industry standard runtime, and the PaaS injected native SaaS into the applications, they would still retain the ability to run and use the code elsewhere (this is what SaaSGrid does). Last, some 4GL has a tough time leveraging existing code assets that your company may have invested thousands or millions into.

As for Coghead, it’s always a shame to see a startup go, despite our market approach differences. I wish the Coghead team the best of luck. Fortunately for customers, it didn’t take long for many of their competitors in the “WYSIWIG” DIY application platform space to come to the rescue:

1. Intuit QuickBase>
2. TrackVia
3. Caspio
4. TeamDesk

There have also been a few development firms offering to ease the pain as well:

1. Scio Consulting (Full disclosure, Scio is a partner of ours at Apprenda)
2. DeliveredInnovations

While it’s great to see that there are options for Coghead’s customers, it also causes me wonder once again why anyone would want to lock themselves into a full non-standard stack offering?  Granted, I have a bias as one of the creators of SaaSGrid, because our model is the exact opposite. However, our model is the exact opposite because we didn’t even see that as a reasonable approach to doing business and this is a clear example of why. A startup should focus on ensuring that it’s customers are safe and are not sinking time and money into something that cannot function outside of that runtime. If you’re building ontop of a runtime that does not have a natural “fail safe”, take a lesson from what’s going on here.

Is my fear of non standard languages overblown? Is reducing risk a better ‘key feature’ of a 3GL based PaaS, or is the fact that it can leverage existing software assets the more appealing attribute? If you are a Coghead customer, have you found alternatives yet?

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

read more

What PaaS Isn’t: An Application with an API

Feb 13, 2009 by Sinclair Schuller

For some time, I thought I was alone in battling the cloud taxonomy war. With SaaS, PaaS, IaaS, RIA, etc. being tossed around on a regular basis, I often find myself looking for clarification when it becomes obvious that someone’s definition and understanding of one of these acronyms is different than mine and those that share a similar view as my own.

Given my relationship with SaaSGrid, the one that hits closest to home is ‘platform’ and PaaS. I bumped into a great read by JP Morgenthal that attempts to build some understanding around PaaS. Morgenthal asks whether or not simply having an API makes a web application a ‘platform.’ Does it? No. As Morgenthal points out, it seems difficult to justify Facebook as a ‘platform’ if it doesn’t act as host to application code, but simply exposes an integrations API. Unfortunately, we see folks throw platform and PaaS around all too loosely. If we think about desktop applications, it would be awkward to refer to Microsoft Word as a “word processing platform” or an “office tools platform” simply because it has an API. Some do it on occassion, but everyone is comfortable calling Word an application. Furthermore, Microsoft never made silly claims like “Write the next Word on Word” or “All desktop software will be written on the Word API”. It has it’s place in the world. However, everyone is comfortable calling .NET, or Java, or the JBoss Application Container ‘platforms’ because beyond having APIs, they act as hosts to guest software. I would say this is critical minimum criteria in claiming to be any sort of platform.

My guess is that marketing departments found that using ‘platform’ makes everything sound bigger and better. It’s not a sales management application, it’s a ‘sales management platform’. It all reminds me of a bet by the Royal Chemistry Society: they are battling the marketing folks that have used the word ‘chemical’ as negative spin in hopes of boosting the image of ‘natural, chemical free foods.’ They basically claim that the word ‘chemical’ has been misused in a very harmful way, teaching people that ‘chemicals’ are bad. In fact, all foods have ‘chemicals’ and being ‘chemical free’ is an absurd claim created by marketing departments. ‘Platform’ is a little more ambiguous than this, but the spirit is the same.

Do you agree that platform and PaaS are often misused? Does it seem to you that the word ‘application’ is falling out of favor as a proper description for standard, non-host software?

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

read more