Real World Cloud Architecture: Build or Buy a SaaS Platform?

Jan 26, 2011 by Sinclair Schuller

Yesterday, an article by Brendan Read over at TMCnet really caught my attention because it captured the spirit of what I think about every single day. The article announces the introduction of an IT service management SaaS offering by FrontRange Solutions, a relatively well known mid-market applications company with 2007 revenues at $135 million (as per their company Wikipedia entry) and apps like HEAT and GoldMine in its application portfolio. Brendan Read starts off by accurately stating that “…successfully hosting…complex applications such as IT support tools is much more than installing software onto a server and connecting it to a network that is linked to clients and their users. It requires carefully architecting the solutions for the hosted environment.” Read’s introduction set the stage for how FrontRange did SaaS the right way.

Read hit the nail on the head. Throwing an app onto some servers, whether on-premises or in the Cloud on something like Amazon’s EC2, is not SaaS. I’ve written many times about what it means to truly offer a business offering in the Cloud, but this article captures a real world example of the effort required to move to SaaS.

Read goes on to highlight data volunteered by Michael McCloskey, FrontRange’s CEO that provides an interesting data point: FrontRange “…spent two years re-architecting from scratch a new platform for the SaaS environment” Two years! (Notice the emphasis – I clearly care about this number) I don’t know the hard dollar investments made by FrontRange, but one must imagine that their SaaS platform project had a good number of developers working on it, and that the investment was, with a high probability, in the seven figure category (probably a few developers and architects, as these projects go, with a fully loaded average cost of somewhere in the $90K to $150K range per year working for two years). So a proper product to SaaS transition is a combination of 24 months of SaaS specific effort, seven figures in hard dollar costs (probably), resulting opportunity costs, and ongoing R&D maintenance costs (someone needs to fix the SaaS specific bugs and evolve the platform) – Holy smokes!

I seem surprised, but I’m really not. I’ve been in the thick of this very scenario, and responded by channeling all my effort into Apprenda. Apprenda was built on the premise that a high end SaaS architecture and operating tool-set could be productized into an application server. We built SaaSGrid to do just that – productize a world class SaaS platform so that applications running on it could inherit and give a company a sustainable short and long term solution with tremendous ROI. SaaSGrid was kicked-off as a product knowing full well the costs of a real SaaS architecture with things like multi-tenancy, provisioning, billing etc.

The scenario highlighted in this FrontRange scenario is in fact very much like the ROI analysis we go through with prospects and customers. Someone like McCloskey, faced with a SaaS decision (regardless of whether its a new application or a migration) needs to compare those build figures to investing in technology that they can buy that solves these problems out of the box. Fundamentally, you start to ask yourself:

1. Does a 12 or 24 month time to market loss result in significant competitive disadvantage? (i.e. Am I liable to lose significant market share or position by letting competitors beat me to the punch?)
2. What opportunity costs is associated with a competency distraction of this magnitude on the R&D side?
3. We haven’t built this sort of architecture before, what risk level am I willing to absorb?
4. Could an additional 12-24 month investment in the product functionality and not the SaaS platform give me access to new markets and revenue streams?
5. If a home-grown SaaS platform is going to cost $1-$3 million to materialize, what investments am I giving up to make this happen?
6. Are we going to be able to lend resources to the SaaS platform over time and evolve it despite it being orthogonal to the product, and if not, what untapped value are we leaving on the table?

If you add up the hard dollar costs of the above questions, you start to realize that millions of dollars are required, and the soft dollar costs add many more millions. SaaS is a strategic advantage, but the cost of that advantage is whats in question. Clearly, I do not think that building is a sustainable or strategic overall approach – it’s expensive and distracting. Thats not to say a company can’t be successful (just ask Salesforce.com), but the probability of success goes down while risk goes up when you build. We’ve seen this before – most companies don’t go out and build relational database servers because its not their core competency. Instead they download or license an RDBMS. A SaaS stack is of the same complexity level and same level of orthogonality, so why build? Our goal with SaaSGrid was to let people focus all of their energy on their offering – the stuff that your customers care about – and not on SaaS. My bet is that Cloud build vs buy cases like this will one day define a Harvard Business Review case study or two;-)

How do you feel about this  - does building make sense, or is the ROI not there?  Do circumstances exist where building is warranted, and if so, what are they? What other costs can you think of that should be factored in the SaaS platform build vs. buy?

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

read more

Lack of Multi-tenancy: A Broken Business Architecture?

Nov 4, 2010 by Sinclair Schuller

A couple of months back, there was a rekindling of good debate around multi-tenancy, it’s importance (or lack thereof), and who benefits most (if at all) from multi-tenancy. Cost angles as well as soft dollar angles were discussed, as was a good overview of the importance of multi-tenancy being represented in the aggregation of data into a single, digestible source and the value that creates all on its own.

For anyone who has read SaaSBlogs before, you probably know that I’m a passionate supporter of single instance, multi-tenancy as the architecture of choice in most situations (there are some good edge cases). Clearly, I side with the proponents of multi-tenancy in most of these debates, but I want to tackle something different this time. Typically, the supporting evidence is anchored on cost savings and efficiency that multi-tenancy brings to the table. Let’s look at the multi-tenancy discussion through a different lens: that of a business architecture.

We rarely consider the ramifications of software architecture decisions on fundamental business processes. Most software to date has been developed in a vacuum because the cost of operations and delivery have typically been borne by the customer, not the software company that created the product. I find that SaaS vendors are surprised when I discuss their technical decisions in terms of how it impacts their ability to sell in a most real sense. Let’s start with a simple example: offering free trials or running a beta program.

Free trials are used to provide prospects with some sort of evaluation period of your software so that they may make an informed buying decision. Beta programs give prospects and existing customers early access to new offerings, or to changes in existing offerings existing customers already subscribe to. In the on-premises world, this was a simple thing to do because you shipped bits to customers at no cost to you. As a SaaS provider, things are different: for both of these use cases, the SaaS provider must bear the incremental cost of delivery of each prospect or customer that asks for a free trial or entrance to a beta without associated revenue. The SaaS provider, being responsibility for delivery, now takes on the full operating burden that the customer used to take on to run an on-premises free trial or beta.

Now you ask “Sinclair, so where does multi-tenancy fit in?” If you understand multi-tenancy, you know that it drives up the ratio of the number of customers that fit on a given physical or virtual infrastructure by forcing resource sharing within application stack components. A “tenant” is a meta-construct that does not require physical boundaries for isolation. This means that the incremental cost of acquiring a new customer is as close to $0 as possible, and can remain at $0 if the customer posts little activity. Everything from your Oracle/SQL Server licenses to your physical or virtual infrastructure costs are spread across customers. A single instance per tenant model, even in a virtualized case, is severely broken in this respect. Let’s use a more concrete thought experiment to understand this.

Let’s say that we decided to use Amazon’s EC2 to virtualize our offering to provide for tenant isolation; that is, we create an EC2 virtual machine instance for each customer to our SaaS offering. As of the writing of this post, a small Linux EC2 instance costs $0.085 and a small Windows EC2 instance costs $0.12. Let’s use this and some other assumptions  to build a model to understand what free trials in a non multi-tenant world due to Customer Acquisition Cost (CAC) and the payback period of the CAC. Since Apprenda is in the .NET world, we’ll focus on Windows instances. This means that for every hour of a free trial we run for a single prospect, we pay $0.12. Offering a 1 month trial is quite typical. Now let’s assume that a customer earns us $250.00 in monthly revenue (for the sake of realism, maybe we earn $50.00 per seat per month, and the average deal size is 5 seats). Furthermore, let’s also assume that for every 20 prospects that try our SaaS offering, 1 decides to buy, giving us a 5% conversion ratio. Our model would look as follows:

(bigger)

Since our conversion ratio is 5%, the increase in cost for acquiring a single customer is $1,752.00 in the Windows case! Where does this number come from? Well, there were 19 trials that did not convert to paying customers. Running a 1 month free trial for those prospects cost $87.60 a piece!. The revenue generated by the single converted customer must account for the money spent on the 19 lost prospects. To add even more perspective, if we are generating $250.00 in monthly revenue from that customer, you’d have to keep that customer on board for 7 months in order to recover the money spent on CAC. In fact, that’s being kind and saying that every dollar of revenue can be spent on recovering CAC. This is incorrect, because in reality, you’d have to keep spending $87.60 per month for that EC2 instance for your new paying customer, which needs to be taken off the top of the $250.00, with gross profit applied to CAC recovery. This would stretch out to over a year, and we haven’t even accounted for the remaining customer acquisition cost (you know, the sales and marketing dollars you spent attracting new leads and closing deals). This is not feasible! Sure, you could shorten the trial, maybe ask the customer to foot an evaluation bill, or boost conversion by double, or all of these. At the end of the day, those are all extra hurdles  you could do without, and would be a band-aid that would simply reduce the pain a tiny bit.

Even on the LAMP stack, the results are terrible. You save a couple of months on CAC recovery; big deal. The fundamental problem is that this sort of “architecture” is not built for a more sophisticated delivery model, and “throwing hardware at it” is costly. Lacking multi-tenancy could really cripple your business architecture. This is just the tip of the iceberg. Things that should be simple, like effectively rolling out upgrades, managing orphaned trials, being able to build a revenue stream from data aggregation, are all hampered. We could probably find lots of ways that an ASP approach breaks down your ability to run a business or tune your sales and marketing, but this simple example seems to work as a good illustration of the types of problems to expect.

This topic is close to my heart because of SaaSGrid. As most of you know, SaaSBlogs isn’t really a place where I try to plug our platform, but it’s just so interesting to think that our customers don’t have to worry about multi-tenancy as they can inherit a single instance, multi-tenant architecture from SaaSGrid and avoid these problems without having to spend an additional 6 or 7 figures and 10 or more months in additional project time to get this sort of architecture like some of the older SaaS companies had to achieve good results like this or being able to show people how SaaSGrid can rollout an upgrade across 40,000 end users and a few thousand customers in a matter of 8 minutes because of the multi-tenancy it can inject into otherwise plain web app architectures.

As a SaaS provider, have you experienced similar results painted in the thought experiment? Have you considered issues like this prior to architecture planning? I’d love to hear your thoughts!

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

read more

Today’s PaaS Offerings: Pragmatic or Unrealistic?

Jul 12, 2010 by Sinclair Schuller

Although my focus in life right now is CEO of Apprenda, I come from a software development and architecture background (I needed to put my Math/Comp Sci. degree to good use at some point in my life). Anyone who has written software in any “old” (in this case, the double quotes are for sarcasm) platform technology like Java or .NET can assure you the writing software goes far beyond writing code and then running it. There are three major inflection points in the life of a piece of software:

1. The first time it is run
2. The first time it is tested under duress
3. Use in the real world

When people envision others writing code, they envision dozens of programmers writing text, deploying code, and using it. If it only were so simple. This make-believe scenario assumes that the only tool a developer uses is some sort of text editor/development environment. This is far from reality. Writing software typically requires the use of a number of advanced tools and techniques: debuggers (with the ability to work with real, running code), performance profiling tools, memory profiling tools, tuning tools for database queries, abilities to change the underlying runtime mechanics of your platform – you get the point. The reason for all of this is that code does not run as we expect it to, and this becomes painfully apparent at the three inflection points I described.

Interestingly, the general complexity of business software has been increasing. That is, business apps try to tackle more complex problems as each company tries to outdo their competitors by offering the market more value. This means that code also becomes more complex, tooling becomes more important, and visibility into an application becomes key.

Why then, did PaaS offerings (think Force.com style abstract PaaS offerings, particularly in the Apex only days) start off with such a “lowest common denominator” platform? Since business apps are becoming increasingly complex, and PaaS offerings presented a layer much less sophisticated than traditional platforms like .NET, how pragmatic are they for ISVs? As a tool for extending a CRM system, Force.com is clearly great stuff. It offers a simple way to provide new value to an existing system. But as a platform for serious ISVs who need to build complex offerings  - that’s a stretch. The complexity required of a serious development platform just isn’t there, and most software companies should recognize that. There are so many questions that are currently unanswered that make modern PaaS offerings unrealistic for many, many scenarios. Interestingly, these questions are unanswered for at least one (if not all) of the lifecycle inflection points I defined earlier:

1. How can I debug a live Force.com (as in real, “attach to the code and see what’s going on” debugging)?
2. My customers are complaining about speed, how can I performance profile and tune the application?
3. How can I optimize around certain types of resource consumption?
4. I can I use new architecture techniques if the PaaS is too limiting (think Apex before asynchronous calls – a concept that has existed in mature platforms for quite some time)
5. My application is not working as expected in production, and my developers need access to system specifics and the running code to assess what’s going on, how do I get to the live runtime?

I could go on for a long time.  Fundamentally, PaaS offerings seem far too trivial with VERY immature tooling. Yeah, yeah – you’ll here the “In PaaS X, you’ll never have to worry about Y.” The fact of the matter is, code rarely meets expectation at those inflection points, and developers need to dig deep to make magic happen. PaaS offerings really trivialize this. It reminds me of the days when WYSIWYG editors were going to “revolutionize” how websites were made (think Frontpage, Homesite, etc.) and that web design would be democratized, and no one would have to touch HTML, JavaScript etc. We all know how that turned out. The concept of “everything can be written for you, no need to “hand tweak” has never worked at scale, and typically has failed miserably. The best web properties are still written “low level” (relative to web technologies), and complex tools and libraries for JavaScript, Flash, and Silverlight are flourishing.

“Old” runtimes can do a far better job than PaaS when coupled with purpose-built middleware for SaaS and cloud infrastructure like EC2. Developers can capture complex requirements and systems with the right languages and have all the real world tools needed to properly build, test, and evolve software.

Do you feel that PaaS offerings nailed it, or do you agree that they missed the mark and currently cannot support high levels of complexity and real software development life cycles? Is PaaS currently a reflection of WYSIWYG web editors and we’ll instead see a cloud stack evolve that doesn’t try to “solve everything” in one silo?

read more

SaaS for the ISV Masses through SaaSGrid Express

Jun 7, 2010 by Sinclair Schuller

When my partners and I co-founded Apprenda, we had a number of very specific goals when it came to SaaS enablement and we wanted SaaSGrid to embody those goals. My co-founders and I all came from technical backgrounds where we were responsible for SaaS engineering efforts. We learned early on that when a SaaS application is engineered properly, its architecture is drastically different than plain old web applications (think multi-tenancy and scale-out) and that a huge number of auxilliary tools and subsystems (think billing, application life-cycle management, infrastructure management, subscriptions, identity federation, etc. and then some) are necessary for managing and operating a SaaS offering and business.

When you combined these “SaaS specific” aspects of a SaaS offering, the upfront and ongoing time and money investment required far eclipsed that of the application itself (the actual thing your customers want to pay you for!), and causes huge competency distraction. Taking on the build out and maintenance of a mature “SaaS stack” is akin to a software company deciding that it’s in their best interest to build and maintain their own DB technology in support of their business application.  Surely, most people buy RDBMS tech (like SQL Server) or download it (like PostgreSQL) to help ensure succcess, and firmly believe that they need not build their own. When we created SaaSGrid, we had some very specific things we wanted it to do:

1. Allow for the use of traditional stacks (in our case, the Microsoft .NET platform) and the wealth of tools and components already in existence for these stacks. New languages are best created in support of new modeling paradigms or changes in the ways we capture solutions, and not in support of a new delivery model. Traditional runtimes simply needed to be “enhanced” to really sing in an on-demand scenario.
2. Have it be comprehensive and not require a “paper mâché” approach to piecing together disjointed capabilities. Imagine that an operating system required that you find your networking substack from here, and a graphics subsystem from there, and then require that you mash them together. That would be sub-optimal in many ways.
3. Have SaaSGrid provide even the most complex capabilities, like multi-tenancy, as transparently as possible to the application code that runs on top of it. As technologists, we hate having technologies adulterate our code, so to the extent possible, we wanted SaaSGrid to be as low impact as possible.

We accomplished our goals and some, and our customers benefit wildly from SaaSGrid. But late last year, we were thinking about a number of things related to the market and to SaaSGrid. As a company, we’re committed to not only supporting the transition to SaaS, but to catalyzing it. I think great strides have been made with respect to software company adoption of the new delivery model, but the fact of the matter is, most ISVs are still not SaaS. Furthermore, those that want to become serious SaaS players have a tough time understanding how they can get there and what tools are available to them.

Enter SaaSGrid Express!

Anyone that follows my company Apprenda knows that we recently made a new product announcement with SaaSGrid Express. SaaSGrid Express is a freely downloadable application server that captures nearly all of the value of our tried and true SaaSGrid, and that can be used by anyone just to experiment or even to build a revenue producing business. Our goal with SaaSGrid Express is to let everyone experience the value that SaaSGrid has to offer, and more importantly, to democratize a highly complex SaaS architecture in hopes of moving the industry forward.

Phil Wainewright recently offered some excellent insight in his recent blog post regarding SaaSGrid Express; the goal of democratization also means that some people might get there hands on a technology but are simply not prepared to build their own clouds. But as Wainewright went on to point out, those same people would have gone down that path with or without SaaSGrid, so we’re happy that they’ll be able to walk away with such a robust starting point. Giving SaaSGrid Express to the world means that more people than ever before can experiment with and commit to a proper SaaS architecture, which will definitely help satisfy our vision of catalyzing the space. As Dana Gardner suggested, SaaSGrid Express opens up the potential for a “cloud standard” architecture and SaaS stack. If we accomplish that sort of de-facto standard, then the industry is definitely off to a good start. Having a de-facto SaaS stack means that people are not focusing on complex architectures, but on business value for their customers – which would be a huge win for everyone.

Something Special for YOU!

For those loyal SaaSBlogs readers that have an interest in downloading SaaSGrid Express and building an application, we’d like to offer you something special:

For the first 5 SaaSBlogs readers that sign up for SaaSGrid Express with the intention of building an application, or migrating your existing .NET offering, we’ll commit 1 hour of time from one of our engineers to personally work with you, and get you up and running with your project!

Just mention that you’d like to take us up on this special SaaSBlogs community offer in the comments section of the sign up form.

read more

A Future of Cloud Stacks or Cloud Silos?

May 11, 2010 by Sinclair Schuller

When thinking of the cloud, there are two sides to the coin: those who build SaaS offerings and those who consume them. For those who build SaaS applications, we’ve seen a glut of tools crop up to help engineer, architect and deploy SaaS offerings. Some are “horizontally” aligned (think EC2 on the IaaS side, SaaSGrid on the application server side, etc.) while others are “vertically” aligned holistic silos (think Force.com on the PaaS side – even with the recent VMForce announcement) and some are in a mid-silo middle (think Google’s AppEngine and Microsoft’s Azure, both “up to the runtime” PaaS stacks).

Given that there is so much velocity, tumultuousness and general confusion (acronym hell coupled with taxonomical conflation – aka the “everything and everyone is a platform” syndrome), we’re bound to see some order evolve in the future where the evolution will be motivated by what people actually use and adopt rather than the current landscape which is driven by who can yell the loudest.

The big question is what will the future of cloud architecture look like: a stack of interchangeable layers that allow one to choose best of breed or a group of incompatible but highly specialized “holistic silos?”

Looking at the history of infrastructure middleware, the answer seems to be quite clear. Typically, the trend has been that layering functional best of breeds into stacks provides the best combination of “lowest common denominator” coupled with the necessary functional value to “get things done” and keep risk minimal. For example, I can choose servers made by HP, a Windows OS, Java and JBoss, and build a killer enterprise app. If I so decided, I could have swapped Windows for Linux and essentially had a compatible stack experience.  Why, then, are silos cropping up in the market?

Silos like Force.com have their appeal. They promise a world where all your needs, ranging from hosting and execution runtimes in the cloud all the way through development frameworks and distribution channels. The problem, however, is that the software market cannot be addressed as a broad stroke.

The needs of software companies vary wildly: ISVs in the healthcare space may care more about hosting certifications than someone in the CRM space, while those in business intelligence need low latency, high compute availability and the others who altogether care very little about the hosting and it’s all about what middleware they are going to use. The number of needs permutations is staggering.

To think that Platform as a Service vendors that own the full stack, from hosting through runtime and even UI components, can ever optimize for each of these scenarios is ludicrous.  Furthermore, the silo providers ask for something huge in return for a suboptimal solution:  control of the ISVs destiny in all regards. That’s a high price to pay for a promise that can’t be fulfilled.

	Cloud Stack	“Half Stack”	Cloud Silo
Operations Management	SaaSGrid		Force.com, Quickbase
SaaS Middleware		Microsoft Azure, Google AppEngine
On-Premises Runtimes	.NET, Java, etc.
Cloud Infrastructure	EC2, Rackspace Cloud,  GoGrid

I’m a firm believer that most if not all software will be delivered online. It’s the only way to achieve true ubiquity, and it requires superior delivery. Each ISV is going to have to make lots of decisions as they move to the SaaS delivery model. Those decisions are going to focus on how to best solve all the critical problems associated with becoming a service provider. The only logical conclusion is that each ISV will look for best of breed tiers in a stack form that would allow them to create an optimized outcome. I don’t see a grand future unfolding where thousands of ISVs worldwide commit to incompatible silos that require taking on relationships that amount to single points of failure and risk. As a stack becomes more vertically consolidated (i.e., more siloed), the higher the risk grows for an ISV. If ISVs take on piece-meal stacks composed of highly compatible tiers, the walk away with the best of both worlds.

What do you think? Do you think that the next generation of business applications will be split across walled silos, or will the market adopt levels of commonality by converging to a stack approach with solutions provided by a few key companies at each layer, allowing for a “composable” stack approach that we’ve grown accustomed to?

read more

What is VMForce?

Apr 20, 2010 by Sinclair Schuller

If you haven’t heard, Salesforce.com and VMWare plan on making a joint product announcement on April 27th at http://www.vmforce.com. Clearly, this piqued the curiosity of many, including myself. Thinking about Force.com, Salesforce.com’s strategy around the platform to date, and VMWare’s activity and intent to become more entrenched in the Cloud, my best guess is that it’s an Infrastructure as a Service (IaaS) offering, and maybe some sort of Spring-based framework layer that’s tightly integrated with Salesforce.com. Furthermore, it might even offer the ability to run native Force.com code/apps on top of it (I could see something like Spring being used  to create a harness of sorts to load Force.com apps on a native Java runtime)

Force.com is a high order abstraction requiring the use of a new programming language and a heavily diluted (read crippled) runtime. As a platform for extending the CRM functionality of Salesforce.com, it’s an amazing platform. As a general purpose platform for business applications, I think it’s too trivial of a runtime (anyone who’s read this blog before knows my position on this). Most mid-large ISVs solve complex problems addressable only through mature, expressive languages and complete runtimes and stacks. VMForce might be a step in the right direction – so let’s wait and see!

PS: For the literalists out there, one thing I noticed is that VMForce.com describes  it as a “product announcement” instead of “service announcement”. Maybe it’s some sort of special VMWare on-premises integration to the Salesforce.com Cloud?

What do you think VMForce is all about? Any drastically different theories?

read more