What’s the long term cost of not using a PaaS?

Apr 3, 2009 by Sinclair Schuller

If you’re an ISV considering SaaS as a delivery model (whether it’s for a new product or migrating an existing one), you’re going to inevitably bump into SaaS platforms as a potential means of building your service. Once you do, you’re presented with two options: (1) build a fully integrated SaaS offering yourself which includes your actual offering (say, an HR solution) and the underlying SaaS mechanics (relevant SaaS delivery components like multi-tenancy, onboarding and provisioning, high availability architecture, web services API, etc.) or (2) build your actual offering (the same HR solution) atop a purpose built platform as a service (PaaS) offering that does the SaaS heavy lifting in your architecture. When faced with these two options, the astute decision maker will inevitably ask:

“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!

 

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

Sink or Swim: Transitioning your Software Business to SaaS

Mar 9, 2009 by Jesse Kliza

On March 19th at 12:00pm CST, Apprenda will be teaming up with Scio Consulting for a live webinar focused on SaaS transitions for ISVs. 

From questions like “Where do we start?” to “How will our operations be different?”, we’ll be providing clear answers and focusing on the choices and challenges ISVs face when migrating their existing applications to the SaaS delivery model.  If you’re an ISV considering a move to SaaS, you won’t want to miss this! 

Register here: 
https://www2.gotomeeting.com/register/697223607

We hope the SaaSBlogs community will come out and join us for this great event, and encourage your collegues to attend as well.  If you have questions prior to the webinar, you can post them here, or email me directly at: jkliza at apprenda.com 

Thanks all!

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

SaaSGrid Is Here!

Dec 2, 2008 by Sinclair Schuller

I wanted to drop a quick note to everyone that today we’ve announced SaaSGrid’s public release. I wanted to thank everyone that is part of the SaaSBlogs community. I’ve had lots of interesting conversations (both online and offline) with readers. Many of those conversations directly have affected how we approached SaaSGrid as a technology and business solution, so again, thank you! I hope to continue to share conversations with everyone here.

As for SaaSGrid, it’s been a long R&D journey and we’re ecstatic to have reached today’s release. For anyone unfamiliar with SaaSGrid, it’s a cloud operating system (literally) that makes writing and commercializing SaaS offerings with Microsoft .NET very easy. It removes quite a few headaches from the architecture and engineering perspective, and provides a tightly woven business services layer for managing operational and customer facing aspects of your business. So, if you’re building a SaaS offering and are planning (or looking for a reason to) to use a .NET based language and stack, look no further!

We do a few interesting things from the business model perspective. Apprenda does not host applications for software companies. Instead, we enable existing hosters to offer independent cloud instances of SaaSGrid. This means that you can write an app and leverage SaaSGrid, but get to choose which Cloud Provider to publish your application to. You basically write code in Visual Studio in a single-tenant fashion, use our API for certain SaaS related duties, upload your app (UI, web services, database schema) to a SaaSGrid cloud of your choice, click a couple of buttons through a control panel and you’re up and running with a true multi-tenant, ready to accept money SaaS offering! There isn’t anything else out there that affords this sort of power and flexibility.

If you have any questions or comments, definitely leave them and I’ll be sure to answer (or if you prefer, reach out to us through the site or e-mail me directly: sschuller-at-apprenda.com)!

read more