Apprenda_TrueCostOfSaaSLeadership

8/6/2019 Apprenda_TrueCostOfSaaSLeadership

1/24

Understanding The Cost of

Becoming a Sustained Market

Leader in the Software Busines

through Software as a Service


2/24

UNDERSTANDING THE COST OF BECOMING A SUSTAINE

MARKET LEADER IN THE SOFTWARE BUSINESS

THROUGH SOFTWARE AS A SERVICEHelping independent software vendors (ISVs) understand the true total cost of building, deploy-ing and continually delivering an enterprise grade service to their customers

Table of Contents

Whitepaper Context 3

Abstract 4

Introduction 6What it Means to be a SaaS Provider 6

Sustained Market Leadership as a SaaS Provider 8

Understanding Whats Important 8

Single Instance Multi-tenancy and Juggling Competing Factors 13

Achieving an Architecture for Sustained Market Leadership 14

Building Single Instance Multi-tenancy 15

Leveraging a PaaS Oering 18

Building on Advanced Cloud Middleware 21

Conclusion 23

About the Author 23

Sources 24


3/24

Whitepaper Context

Who is this paper for?

This paper is most applicable to software companies exploring Software as a Service (SaaS) as a potential

delivery paradigm, or for software companies that have settled on the SaaS paradigm and are looking to

understand the tradeos associated with dierent approaches to building a SaaS oering and business. The

paper is most applicable to the business constituents within software companies who have the ability to

interpret high level discussions regarding software architectures and their impact on business metrics such as

cost of goods sold, or technical audiences within a software company responsible for strategic product

direction.

What will you learn by reading this paper?

You will learn about various SaaS business and software architectures and the cost/benefit of each architec-

ture option in both hard and soft dollar terms. You will also gain an understanding of the various solutions

which can lead to achieving an optimal SaaS architecture.

Can I skip sections of the paper?

No. Given that the paper is a deep discussion, significant framing is provided so that subsequent sections have

appropriate context. Skipping sections might cause significant confusion or result in a poor understanding of

the overall picture. The paper does provide a full summary in the Abstract section for those interested in theprimary results.

Is this paper a vendor pitch?

No. The paper is produced by Apprenda, a vendor in the cloud middleware space and does include significant

discussion of its flagship product, SaaSGrid. However, the discussion is restricted to the end of the paper where

SaaSGrid is proposed as a solution with appropriate comparison to other solutions tackling the primary

problems identified by the paper. The paper spends significant time focusing on discussing problem and

solution domains.

How can I measure whether Ive eectively understood the paper?

If you walk away comfortable with how SaaS architectures aect long terms business metrics, how to best

compare dierent architectural approaches in terms of short and long term costs and benefits, and with an

understanding of the various solutions that achieve what the paper describes as the most optimal approachto SaaS, then you most likely have a good grasp on the papers content.

How much time should I expect to invest in reading this paper?

45 minutes to 1 hour. The paper covers a good number of topics in medium depth, and may require investing

time in thinking through a number of the topics before moving forward to new sections.


4/24

Abstract

The software industry is clearly trending toward delivering most, if not all, business software via the Software

as a Service (SaaS) model. Moving to a SaaS model introduces technical and business challenges which all

Independent Software Vendors (ISVs), both new and existing must face. To date, ISVs have been accustomed

to selling software licenses at nearly 100% gross margins because software is a zero marginal cost product.

SaaS, however, is an operationally intensive services business where an ISV must pay for servers, bandwidth,

sta, and licenses associated with oering their service to business customers-and those costs grow with their

customer base (goods sold) due to the fact that increases in the customer base require increases in capacity to

meet demand (cost). The ISVs eectiveness at keeping these costs of goods sold (COGS) as low as possible is

directly linked to their SaaS oerings actual software architecture. A poor software architecture will have a

poor resource utilization profile and will do a bad job at spreading costs across the customer base, while a

highly ecient SaaS architecture will provide maximum resource utilization without sacrificing quality. This

will drive costs down and gross margins up, providing a fiscal foundation for achieving sustained market

leadership.

Eciency can vary drastically based on architecture type. Some SaaS architectures, such as single customer

per server or a virtualized architecture (where the operating system and entire application stack is virtualized

per customer) provide the ability to service only a single or possibly a few customers per server. Optimal

architecture approaches such as single instance multi-tenancy achieve eciencies that provide service todozens, if not hundreds, of customers per server. To date, the trade-o has been that inecient architectures,

such as those that rely on isolation by virtualization, have low upfront hurdles from both a cost and time to

market point of view, but a poor ongoing economic profile, while the investment required to build single

instance multi-tenancy has been a huge barrier to most ISVs because of the specialized architectural complex-

ity of the approach.

ISVs have a number of strategies for achieving SaaS stack maturity (which requires billing systems, provision-

ing systems, scale-out architecture, etc.) along with a single instance multi-tenant architecture:

1. Build -An ISV can build an entire mature SaaS stack. This has been the approach for a number of

SaaS vendors to date. It allows an ISV to achieve a healthy long-term financial profile, maintain

agility, and maintain flexibility. However, the upfront hard dollar R&D costs, significant slow-down inboth time to market and time to revenue, and significant competency loss creates a huge hurdle for

most.

2. Platform as a Service (PaaS) PaaS providers have created runtimes or quasi runtimes in the

Cloud to solve some problems associated with building cloud applications. PaaS oerings in the

market span a wide spectrum of capability. On one end, PaaS oerings are too non-specific with

respect to oering a solution to SaaS architecture problems and instead are focused on infrastruc-

ture problems, oering little value to solving SaaS architecture and commercialization problems. On

the other end, other PaaS oerings are too abstract and, while solving some SaaS architecture

problems, require the use of proprietary programming languages and runtimes in a limited environ-

ment that provides value only for the simplest applications. Furthermore, most PaaS oerings link

the runtime with hosting operations, creating an awkward coupling that links engineering decisions

to deployment decisions. As a result, PaaS requires significant upfront investment akin to the buildapproach or oers too little flexibility and too much risk to be a viable option.

3. Cloud middleware SaaS application servers like SaaSGrid provide an out of the box SaaS

stack that enhances traditional stacks such as Microsoft .NET with advanced SaaS architecture and

tooling abilities, giving ISVs the advantages of a properly engineered build oering with none of the

negative qualities. It is the clear choice for ISVs looking for optimized time to market and time to

revenue, the best possible COGS profile, with the least upfront and ongoing capital and operating

investment.


5/24

The SaaS enablement market has evolved to solve a number of the problems associated with building SaaS

oerings, and the market is clearly trending in the direction trail-blazed by pioneers such as Apprenda, where

advanced cloud middleware allows an ISV to achieve the best possible result in becoming a SaaS vendor with

the minimum possible investment.


6/24

Introduction

The past five years have furnished a great number of proof points supporting the hypothesis that the ways

software is purchased, used, and delivered are going through a permanent transformation. The notion that

business end users will continue to license software and install that software in an on-premises form factor is

quickly becoming pass. Recent history, through success stories like Salesforce.com, has shown that software

companies can build significant revenues as Software as a Service (SaaS) providers by giving business end

users access to powerful software functionality over the Internet. Software companies eectively become

service providers by giving all customers subscription-based access to their software functionality as a service

from a centrally hosted virtual location, allowing each customer to have a unique experience isolated from all

other customers despite, to some degree, sharing the same system.

Despite SaaS success stories, however, the software industry has not yet undergone a mass transformation.

Tens of thousands of independent software vendors worldwide (easily a large majority) are still delivering

their solutions to business end users as on-premises solutions. However, because of a combination of

competitive pressure, opportunistic motivation, and customer demand, a significant number of ISVs know

that their evolution to SaaS providers is imminent, but have not decided how they will pursue this transforma-

tion.

Strictly looking at consumption trends, it becomes quite apparent that demand for SaaS oerings continuesto grow. At the time of writing, publicly available reports by Gartner show that SaaS, at least from a consump-

tion point of view, will experience a compound annual growth rate (CAGR) of 19.4% through 2013. This

growing and evolving demand creates ripe opportunity for ISVs looking to capitalize on the new delivery

paradigm, and provides incentive to most all ISVs to, at a minimum, consider becoming SaaS providers, and, at

a maximum, leverage SaaS as a means to become a sustained market leader.

What it Means to be a SaaS Provider

Understanding what it means to be a SaaS provider is critical in being able to fundamentally define a path to

sustained market leadership. Typically, SaaS is touted by its end users as a means of making the operational

cost of running software disappear, and replacing it with a well-known usage fee for access to the softwarefunctionality as oered by a service provider. While this statement is generally true in spirit and motivated by

proper intentions, it is wholly inaccurate if looked at literally. Like any good magic trick, SaaS does not make

the operational cost of running software disappear, but rather it uses a sleight of hand that transfers all the

operational burdens away from each individual customer and over to the ISV en masse. Typically, each

customer would be responsible for licensing the software and then hosting and managing the software so

that internal end users may access it, thereby defining the total cost of ownership (TCO) of the on-premises

solution. Moreover, each customer would be responsible for general eciency with respect to internal costs;

some customers would do a better job at operating their instance of the same solution than other customers,

eectively lowering total cost of ownership for the more proficient customers.

SaaS can create tremendous market advantage for an ISV, allowing the ISV to capitalize on new opportunities

and establish steady, predictable revenue streams. SaaS is a significant inversion of the software operating

model described in the on-premises case. ISVs in the on-premises world are accustomed to near 100% gross

margins when selling product since no cost is incurred by the ISV as each new customer takes on the opera-

tional burden of running their own software instance, with no impact on the ISV itself. Conversely, a SaaS ISV

takes on whole and central responsibility for delivering the service to customers in exchange for revenue.

Unlike an on-premises product, the SaaS ISV is not privy to 100% margins. Oering a service costs money;

bandwidth, storage, compute costs, IT sta all the things each customer used to individually deal with have

now become the cost to serve, or Cost of Goods Sold (COGS), that the ISV must bear (fundamentally, cost to

serve makes more sense in a service business, but for purposes of familiarity, this paper will anchor on the

acronym COGS).


7/24


8/24

Sustained Market Leadership as a SaaSProvider

Defining sustained market leadership for SaaS providers is a non-trivial task, particularly when the definition

of sustained market leader can be drastically dierent within any given vertical. Fundamentally, however, a

few near-axioms exist. Traditionally, software companies would invest significant amounts of money in the

research and development of new software products. Upfront engineering investments for new product

development were typically followed by continued investments in the evolution and maintenance of the

product. However, licensing the product to customers came at little to no variable cost, essentially defining a

world of 100% gross margins and a clear path to returns on upfront engineering costs. Each time an

on-premises ISV sold a license to a new customer, the cost of delivering the product was virtually zero. Bits do

not cost anything to replicate; a customer of an on-premises software product would most likely download

the application from the Internet or receive physical media for installation. All revenues received by the ISV in

exchange for the license could be applied directly to recouping an initial investment and to operating expenses

since no per-unit costs needed to be accounted for as COGS. As described earlier, this is not true for a SaaS ISV.

Some portion of all revenues must be allocated to paying for providing the service, and as a customer base

grows, so does the total cost of delivering the service. Once this o the top expense is accounted for, theremaining can be applied toward recouping investments or paying for traditional operating expenses and

some money remaining to satisfy shareholders penchant for profit.

It would be fair to say that the one common scorecard that most businesses share is the ability to turn an

eventual profit. At a minimum, it can be agreed that sustained market leadership in any business will

undoubtedly be linked to profitability. Within SaaS, this is also true. As a model, SaaS introduces sensitivity

around certain key metrics:

Many other metrics could be taken into consideration, but interestingly, COGS remains one of the most

important: monthly recurring revenue can only drive profit if COGS is low enough to leave cash for operating

expenses. CAC is extracted from operating expenses, meaning that the rate at which CAC is recovered is wholly

dependent on COGS. If COGS is too high, TR-CAC is extended. Inversely, assuming all else is equal, the lower the

COGS, the shorter the TR-CAC. In SaaS, COGS is particularly important since usage fees charged by SaaS

vendors tend to be razor thin when compared to their chunky on-premises license counterparts. These thin

revenues create pressures to maintain healthy operating margins. It becomes quite clear that between two

competing SaaS vendors, the one with a lower COGS profile has the potential to achieve profitability sooner,

fund new growth, recover customer acquisition costs sooner, and establish a leadership position in the market

(of course, assuming that the two vendors are nearly on par with respect to all else).

1. COGS(as defined earlier)

2. Monthly recurring revenue (MRR) The amount of revenue that can be expected on a recurring

basis

3. Customer acquisition costs (CAC) How much the company must invest in acquiring a new

customer. Across a specified time period, this is the fully loaded cost of all sales & marketing

expenses divided by the number of customers acquired in the t ime period. For example, if $100,000

is spent on sales & marketing functions over the course of the year and 10 customers are acquired,

the CAC is $10,000.

4. Time to Recover CAC (TR-CAC) A measure of the number of months it takes to break even on

CAC and start turning a profit. This must be calculated from gross margin that is, if it costs

$10,000 to acquire a customer and you make $1,200 per month from that single account but the

monthly COGS on that $1,200 is $200, you apply the dierence, or $1,000, toward the $10,000 CAC.

This means your TR-CAC is 10 months.

Understanding Whats Important


9/24

In fact, COGS could almost be considered the single most important eectiveness measure in SaaS, or, at a

minimum, define the foundational stability of sustained market leadership.A sub-optimal COGS profile

means that either an ISV will lose money hand over fist or raise prices to astronomical levels (relative to a cost

ecient market competitor) in order to stay in business, which wreaks havoc on value perception within the

market. If all this discussion of the importance of COGS is true, then the next question becomes, What defines

COGS in the SaaS business and how can a SaaS provider influence it to take the upper hand in establishing

market leadership as a SaaS Provider?

The costs associated with delivering a SaaS oering can vary, but a few core costs that can be consideredcommon among all SaaS vendors and that grow or shrink as a function of the customer base include:

1. Infrastructure costs Infrastructure requirements will grow as a function of an applications

general compute and storage requirements and growth in the number of customers using the SaaS

oering. This is true regardless of whether you are using cloud infrastructure such as Amazons EC2

or physical hardware running in some datacenter.

2. Bandwidth costs Although bandwidth costs have declined drastically, their cost in oering a

service in the Cloud should not be ignored. The total bandwidth consumed on a monthly basis will

increase with both an increase in per customer application usage as well as with increases in the

number of customers.

3. IT Sta Regardless of whether an ISV is deploying to cloud infrastructure or a physical datacen-

ter, IT sta is required to manage server instances and other infrastructure in support of the SaaS

oering. In most cases, as the network infrastructure footprint grows, so will the pressure of

managing the infrastructure, requiring additional sta to keep pace.

4. Licenses (if applicable) Depending on what stack an ISV chooses to write their software on will

determine licensing requirements for stack support software. For example, if an ISV chooses a LAMP

stack, odds are that little to no cost will be incurred for running the underlying stack. However, if an

ISV is building on the Microsoft platform, the ISV will have to license Windows and SQL Server, and

the fees will grow proportionally with the growth of the underlying infrastructure.

The overall impact of these components on COGS is highly dependent on:

1. How eective an ISV is at distributing these costs amongst its customers and reducing

incremental costs per additional customer

2. What part of the application stack the ISV is relying on for isolating one customer from another

3. How eective the ISV is at generating eciencies at scale

Interestingly enough, an ISVs ability to properly create cost leverage across these resources is

directly related to how the ISV has architected their SaaS oering. A SaaS oerings architecture will

dictate how eectively it shares the resources described in the aforementioned list. Although

thinking about COGS and its eect on a SaaS providers profitability may seem like an uncomfort-

able idea, it is no dierent than looking to the eciency of a manufacturers assembly line for anindication of its production costs.

The more fine grained the SaaS oering can be at sharing resources among many customers, the

lower it can drive COGS. A coarse grained sharing (such as an approach where the full application,

operating system, and hardware is replicated per customer ASP model) leads to an

over-allocation of resources creating low general system utilization and large amounts of idle

resources which leaves significant money on the table that could have either made it to the SaaS

companys bottom line or been passed on as cost savings to the customer.


10/24

Fundamentally, one primary dimension of a SaaS oerings technical architecture is how one customer is

isolated from another customer in the system. The choice of how isolation is performed and what part of an

applications stack is providing isolation will directly impact the applications tenant density, or how many

customers can share a common resource footprint associated with the aforementioned COGS components

without sacrificing general quality. For example, if a certain architecture approach provides 2:1 density ratio, it

means that 2 customers can co-habit 1 server (this is a generalization that flattens the idea of whether

certain app tiers are more dense than others, etc. More complex measures can be taken, such as density by tier,

but for the purposes of illustration, a generalized density number works best). Low density equates to a high

COGS profile while high density drives a low COGS profile. Generally, SaaS architectures can be bucketed intofour categories:

The first two architectures are not software architectures at all, but rather systems architectures that

leverage infrastructure properties for isolation and resource sharing that is, servers are assigned to specific

customers to separate one customer from another and to assign specific resources to each customer. An

application can be nave with respect to isolation and resource sharing. On the contrary, single instancemulti-tenancy requires that the SaaS oering be built as extremely complex software architecture that takes

over the mechanics of isolation and resource sharing explicitly.

1. Single physical instance per tenant Each customer is assigned to a dedicated physical server,

leveraging physical isolation to ensure customer isolation. Essentially, this is the ASP model.

2. Single virtual instance per tenant Each customer is assigned to a virtual OS stack running on a

hypervisor that is managing some physical server, leveraging the hypervisors ability to isolate

virtual machines (VMs) as a means to provide customer isolation. Technically, this is a form of ASP.

3. Tiered single instance multi-tenant Each customer is represented by meta-data within the

SaaS architecture. This meta-data is used by each tier of the application (e.g., database, web

service, user interface) to provide isolation and higher order resource sharing, such as manycustomers sharing single instances of single application components such as the database. Isolation

and sharing is the responsibility of the application and cannot be deferred to the infrastructure.

4. Single instance multi-tenant Similar to tiered single instance multi-tenant with the caveat

that a single logical instance exists of the application without the acknowledgement of architec-

tural tiers.

TotalRe

curringCOGS

Number of Customers

Single instance,multi-tenant

Virtual instance

per customer

Physical instanceper customer


11/24

Comparisons between the dierent SaaS architectures should be made on the merits of COGS eciencies,

impact on corporate operating expenses for any non-COGS costs, and opportunity costs (i.e., do some

architectures introduce the possibility to posit value such as the ability to introduce features and functions

into the SaaS oering not possible, or at best, dicult to implement, under one of the other architectural

paradigms?). Continuing with the theme of COGS, we can hone in on understanding why COGS is impacted by

understanding tenant densities in each scenario:

Physical instance per tenant 1:1 ratio Each customer provisioned to the system

requires human intervention to setup an

actual server on which a specific

installation will run for a specific

customer. ASP businesses function in

this manner. 1000 customers would

Physical instance per tenant 2:1 ratio to 8:1 ratio Hypervisors slice physical infrastruc-

ture into full OS stacks, oering

virtualized isolation and replicating the

entire application stack for eachcustomer. The actual achieved tenant

density depends on the minimum

requirements of the application and the

specifications of the underlying servers.

For example, if the database and

frontend for an application requires 4 GB

of RAM, a physical server with 24 GB of

RAM could aord to host 5-6 virtual

machines, providing a 5:1 or 6:1 ratio. At a

5:1 ratio, 1000 customers would require

200 servers.

Tiered single instance multi-

tenant or

Single instance multi-tenant

10:1 ratio to hundreds:1

ratio

No explicit linkage exists between

provisioning a new customer and

provisioning fixed network resources.

Lack of clear mapping and architectural

abstraction requires that the application

deal with isolation mechanics, allowing

for fine grained usage allocation and

utilization independent of infrastructure

allocation. 1000 customers would

require anywhere from 100 to potentially

as few as 4 or 5 servers

Approach Tenant Density Ratio Description


12/24

Some argue in favor of a virtualized approach, but at scale and in the long term, VM based models could aect

top-line eectiveness by creating artificial ceilings on gross margins and negatively impact the bottom line by

adding significantly to ongoing operating expenses and R&D investments needed to manage huge farms of

single tenant, single instance deployments. Comparing these various approaches from an eciency point of

view is analogous to comparing how much roadway space is required to move 100 people either by car (single

instance models both physical and VM), where each person drives their own car, or by bus (multi-tenant

models), where all 100 are moved by a single bus.

The amount of roadway that a single bus requires to transport those 100 people is far less than the amount of

roadway taken up by 100 cars (or by 25 cars if we transport 4 people per car to emulate a VM based compres-

sion ratio). This analogy paints a clear picture of how a specific choice of implementation (car vs. bus) impacts

how finite, costly resources (roadway) are allocated and what those allocations might mean for overall costs

and service levels (reduced transport eciency, repair costs, trac congestion, and lack of homogeneity) but

also identifies that complexity arises in shared environments when each passenger on the bus might want to

listen to a dierent radio station on the bus without aecting the other passengers. Clearly, these benefits are

realized by both the city (the SaaS vendor) and to some degree, the passengers (the SaaS customer).

However, in the car/bus analogy, personalized transport by car has many advantages over the bus that cannot

be addressed in the physical world. Trivially speaking, single instance single tenant architectures make this

sort of personalization easy since each customer is isolated from every other by having an entire copy of the

application stack, ensuring that one customers customizations do not aect another. This level of customiza-

tion is also possible in single instance multi-tenant but is much more dicult to implement and manage,

requiring significant upfront engineering eort, creating a slightdisadvantage for single instance multi-tenant

approaches.

An ISV making a decision on which architectural approach is best needs to weigh the pros and cons of each.

(Image from the City of Mnster, Germany - Planning Oce)

Optimal Sub-optimal Legend

Physical instance per tenant

Virtual instance per tenant

Single instance multi-tenant

COGS Time to Market Upfront R&D Ongoing R&D


13/24

Based on the discussion so far, it seems clear that single instance multi-tenant is by far the best in terms of

ongoing economics, but at a significant upfront time and money cost. Single instance per tenant architectures

have very low upfront hurdles but, in many cases, oer little to no hope of good long term or at scale econom-

ics.

Analysis provided by papers such as this one coupled with real-world SaaS success stories like Salesforce.com

and NetSuite evidence the importance of single instance multi-tenant architectures. However the R&D eorts

required to build this type of architecture are massive, the architectures themselves complex, and the skills

required to build single instance multi-tenancy are rare2. This creates a huge upfront investment burden on

those looking to become single instance multi-tenant players that significantly impacts their time to market.

In fact, pursuing the path of multi-tenancy exposes a number of competing factors that an ISV must deal

with, and that in many cases, makes a commitment to this advanced and highly preferable architecture

unreasonable except for the bravest ISVs. Understanding what competing factors are introduced by choosing

to pursue a single instance multi-tenant architecture is critical if this architecture is to be undertaken with

minimal cost and risk.

Single Instance Multi-tenancy and Juggling CompetingFactors

Ideal Business Outcome Competing Factorvs.

Competency focus Loss of competency focus because of a

need to build skills and competencies in

complex, single instance multi-tenant

architectures and engineering. require

1000 servers.

Seizing a window of

opprtunity

Much longer time to market due to the

time investment required to engineer

single instance multi-tenancy into an

application. Single instance multi-tenancy could slow a project down by

30% - 100%.

Ecient use of capital Significant increases in capital require-

ments due to frontloading of additional

sta, tools and expertise required to

build a single instance multi-tenant

SaaS stack in house.


14/24

SaaS as a whole creates a host of new R&D requirements that are critical to a SaaS companys success. These

requirements range from billing systems to provisioning systems, application lifecycle management tools and

more. Single instance multi-tenancy, however, is most prominent due to its pervasiveness in software

architectures, the diculty of implementation, its ability to drastically swing a SaaS companys cost delivery

profile, and the fact that it requires significant upfront investment and thought. In fact, a SaaS oerings

ability to achieve a low COGS profile and high level of operational agility can be boiled down to a single

decision point: the build time decision of going single instance multi-tenant versus not. If this decision point

is reached and single instance multi-tenancy is not pursued, it becomes very dicult to go back and correct.

Clearly, given the described competing factors and ideal business outcomes, some will decide to opt-awayfrom single instance multi-tenancy due to the upfront hurdles. Just like an electric power company might

prefer to have a nuclear power plant to generate electricity cheaply in the long run but cannot stomach the

upfront costs when compared to a coal fired power plant, one might choose some other architecture model for

SaaS because of the upfront hard and soft dollar investments required to attain single instance multi-tenancy

Given that necessity is often the mother of invention, these very pressures of being able to achieve the

ultimate SaaS architecture while keeping upfront investments to a minimum have created a landscape where

cloud middleware has evolved. These options allow an ISV to pursue the fruits of single instance multi-

tenancy while keeping upfront time and money investments to a minimum. Being able to intelligently assess

this landscape and measure it against the framework that has been outlined in this white paper is key to

making an informed decision.

Achieving an Architecture for Sustained MarketLeadership

As described in earlier sections, many scenarios indicate that the path to sustained market leadership as a

SaaS provider is rooted in being able to achieve positive results in certain financial and agility metrics, and that

the probability of achieving positive outcomes for those metrics is influenced by how the ISV builds its SaaS

oering. Regardless of the tenancy architecture, all mature SaaS oerings will share the need for a robust set

of auxiliary systems. For example:

1. Subscription Management A SaaS customer typically pays for access to the SaaS

oering and in return, is aorded some level of access and metered usage that is capturedin a subscription. A SaaS oering needs to be able to dole out and assign subscriptions, use

subscriptions to influence application behavior, and provide a baseline for reconciling

billing around usage. Furthermore, an engine for defining subscriptions, pricing, and feature

inclusions should be in place to allow the SaaS provider to define what subscriptions are

available for purchase and to allow custom models to be developed for specific customers.

2. Metering While subscriptions define the agreed upon terms and access rights between

a tenant and the SaaS provider, metering provides a census of active usage that can be

reconciled against subscriptions to properly tally a bill for the customer.

3. Billing While subscriptions coupled with active metering define what needs to be billed

to a customer, a billing engine takes over responsibilities associated with collecting money,

using collection results to dictate changes to the subscription, and provide the customerwith a means to participate in the reconciliation process.

4. Application lifecycle management In traditional on-premises software, an upgrade or

bug fix release would be sent to a customer who would then manage the process of

installing the bug fix or upgrade. Each customer would then perform the upgrade on their

own schedule, and an upgrade mistake by one customer did not aect any other customer.

In SaaS, rolling out an upgrade or patch is much more complicated. The patch needs to be

applied successfully to all customers with as little downtime as possible. Any mistakes,

particularly in a single instance multi-tenant system, could cripple access for everyone.

Furthermore, the complexity of an upgrade is massive given that most SaaS oerings span

dozens if not hundreds of servers in a network.


15/24

1. Database/Data Storage Tier Outside of single instance multi-tenancy, data storage is relatively

nave; each customer, for example, may have a specific database provisioned purely for their own

data storage and processing. Although this approach is trivial to implement, it is the start of a poor

COGS profile. So long as business constraints (such as legal regulation) do not prevent this, single

instance multi-tenancy requires that an applications data model explicitly deal with the mixing of

data from multiple customers in single database instances. Typically, this is managed through row

level ownership, where specific pieces of data are tagged with information identifying which

customer the data belongs to. At first glance, this seems trivial, but be warned! The simpleintroduction of row level ownership means that all aspects of the data model need to be changed

and managed dierently. Key structures, indexing, and access all need to change. Execution against

the database needs to be managed so that, to the extent possible, queries executed by the

application on the behalf of one customer do not aect the experience of other customers.

Furthermore, managing growth is complex. As the database grows, the data model should support

partitioning so that some subset of the tenants can be moved to other server infrastructure to

support a scale-out model but the calling application code need not know of the scale-out

intricacies. Change management is much more complex since changes to the data model need to

remain tenant aware. This discussion is simply scratching the surface of the complexities of

multi-tenancy at the data level.

This short list captures some major subsystems of a mature SaaS oering. For the sake of brevity and reduced

complexity, the discussion did not capture details around more dicult topics such as high availability and

scale-out architecture to help ensure optimal service levels, single sign on semantics, failure detection and

isolation, and a variety of other critical subsystems that are expected to be present regardless of selected

tenancy model. Without even addressing the critical issue of tenancy, we can quickly see that the time and/ormoney investment required to build out a mature SaaS stack is huge, can easily reach six or seven figures, and

can severely impact time to market. In some cases the eort to build the SaaS stack could eclipse the eort of

the building the domain application itself. With all these architecture and delivery concerns now planted

firmly on the providers plate, the application functionality that defines their value to the market has taken a

developmental back seat!

Although the topic of what a mature, comprehensive SaaS stack is composed of is an interesting topic, the

purpose of this white paper is to examine dierent approaches to tenancy. However, the aforementioned SaaS

stack components should be kept in mind for the remainder of this paper since they represent sunk costs. The

solutions presented may or may not address these out of the box, and in some instances single instance

multi-tenancy may itself impact the cost of buying or building these components. The remainder of this white

paper will delve into a few specific approaches and conclude with an assessment of the best approach for

achieving a position of sustained market leadership.

Single instance multi-tenancy is a dimension of software architecture that aects all application tiers,

auxiliary tooling, and even ongoing operations management. SaaS success stories such as Salesforce.com

invested millions of dollars in early R&D to build out single instance multi-tenancy as a competitive dieren-

tiator, relying on venture capital to fill investment gaps and achieve a vision of eventual SaaS purity. Achieving

single instance multi-tenancy is non-trivial and requires a deep understanding of how the dimension impacts

the application. Certain features of this sort of architecture are pervasive. For example, any code execution or

data stored must be contextual, meaning that, since all application components are shared among customers

the components must be able to distinguish one customer from another and must isolate those customers

from each other for safety and quality reasons. Customizations are possible where customizations are loaded

on the fly on these shared components based on that contextual information. An ISV pursuing a build path

where they will create a single instance multi-tenant system from scratch needs to consider dierent

application tiers very carefully:

5. Account Management Portals A tenant must be able to govern interactions and account

information with a SaaS oering. Exposing a portal for this is critical if the customer experience is to

be thorough and comprehensive.

Building Single Instance Multi-tenancy


16/24

A single instance multi-tenant data model oers the ultimate in eciency, but if quality and

flexibility are to remain intact, significant investment must be made in executing this nuanced and

intricate arena of database design correctly.

2. Application Tier In a single instance multi-tenant model the application tier is being shared by

many customers. Any calls to the application tier must carry and maintain information about the

originating customer request if isolation guarantees are to be made with respect to code execution

at that tier, and to ensure that isolation is propagated to lower tiers (such as the database or

flowing contextual information to other systems). In memory, requests from dierent originatingtenants need to be protected from one another so no single tenants execution bleeds into

another (imagine if a request for one tenant returns that tenants result to another tenant!) In

more complex cases, the application tier should be capable of safely executing logic and database

queries in a tenant-agnostic fashion to perform operations across all tenants or tenant data.

Furthermore, if the application tier is a physical web service, expect to build a tenant level load

distributor to help with scale-out and peculiar isolation needs.

3. User Interface Tier Front end user interfaces need to be capable of distinguishing originating

tenants. Techniques such as providing unique URLs per tenant for identification purposes, cookie

management systems, and contextual flowing of tenant data on web requests are used. Further-

more, tenant level load balancing is used to distribute front end load across a server farm based on

identity. If Rich Internet Application (RIA) technologies are being used, which, by default, are client

side single instance single tenant systems, then those user interfaces need to maintain tenantanity but reconcile the single tenancy with the multi-tenant back end services supporting it. In

addition, modern user interfaces take on a variety of forms from browser-based to mobile, and

applications should be architected to make introduction of a new client form factor easy and quick.

Aside from the application tiers just described, the non-architectural sub-systems such as billing and subscrip-

tion management mentioned earlier in this section may also be impacted by single instance multi-tenancy.

Some of these systems may need to follow the same architectural style or be explicitly aware of them,

reinforcing the overall mantra of being single instance multi-tenant. Taking a build approach will require

significant upfront investment in hard dollar terms, soft dollar terms, and temporal terms. Furthermore,

maintenance of these complex moving parts means significant ongoing R&D investments; it is almost certain

that the baked in single instance multi-tenancy and requisite support components will be the most complexerror prone parts of the system. Even in the scenario where some of these components are provided by third

parties, you can expect to pay significant sums of money over time for relatively little strategic return. Some

SaaS subscription and billing systems alone can cost up to a recurring 2% of revenue for what amounts to very

little overall strategic value.3

When all of this is taken into consideration, the overall profile for build is clear:


Build Single Instance Multi-tenancy

COGS Time toMarket Upfront R&D$ Investmet Ongoing R&D$ Investment CompetencyFocus GeneralFlexibility Risk


17/24

1. COGS Clearly, a team of skilled software engineers will be able to achieve single instance

multi-tenancy so a build, assuming all goes well, should be able to yield an optimal COGS profile.

2. Time to Market Build means that upfront R&D will be slowed down drastically, either

significantly delaying market release of a SaaS oering or even creating a missed window of

opportunity. A mature SaaS stack could easily become the most burdensome and slowest part of

upfront R&D.

3. Upfront R&D $ Investment Most ISVs do not have skills on sta with expertise in SaaSdelivery architectures and tools development. This typically means that money needs to be

invested in hiring new talent, helping the current team acquire new skills, or outsourcing parts of

development.

4. Ongoing R&D $ Investment Once a single instance multi-tenant SaaS architecture is built into

a SaaS oering, the ISV now owns the bugs and evolution of that significant part of the overall

application stack. Typically, sta levels will be kept high since both the main product and

underlying SaaS stack must be maintained, which guarantees an inflated ongoing R&D budget.

5. Competency Focus Most ISVs have high levels of competency in engineering solutions within

their business domain: HR software companies write amazing solutions to HR problems, medical

software companies know the ins and outs of their vertical and create solutions for that. Building a

SaaS stack is a huge distraction from core competency. Imagine that relational databases did notexist and an HR software company decided that it needed to both create and maintain code for a

complex relational database, and then build the HR software against that in-house database.

Clearly, this would be viewed as a significant distraction and as a result, most ISVs leverage third

party database technology. A SaaS stack is no dierent.

6. General Flexibility Given that a build scenario allows an ISV to choose the stack of their choice

with little to no restrictions within that stack, an ISV is limited only by its own creativity, thereby

allowing it to maintain enough flexibility to create feature rich applications that meet their

markets needs.

7. Risk Although build is generally void of lock-in beyond traditional platform selection, the lack

of expertise in building single instance multi-tenant SaaS and auxiliary tooling introduces some

level of risk since the architecture could turn out to be buggy, mal-performing, or too dicult to

maintain.

Pursuing build means that it is possible to achieve the best COGS profile (assuming that the ISVs engineering

team has the skill set to properly execute the R&D) and maintain the power and flexibility of using an industry

accepted hardened stack (e.g., Microsoft .NET, Java, LAMP), but at a severe financial, temporal, and focus

penalty. The ideal scenario would be to achieve the COGS and flexibility profile of a single instance multi-

tenant model with none of the upfront or ongoing impact. One of the other architecture approaches

described later will propose a solution that allows for achieving the results of the build approach, without

the requisite costs.


18/24

1. Oer an industry hardened, robust runtime such as .NET or Java in the Cloud but without single

instance multi-tenancy

2. Oer a simplistic Rapid Application Development (RAD) environment for building simplistic

database scraping applications and receive single instance multi-tenancy.

An important member of the Cloud ecosystem is the Platform as a Service (PaaS). PaaS is a service that

bundles a hosting infrastructure/computing platform (think servers) with a tightly coupled software stack

that manages some level of burdens related to the engineering and execution of code assets. PaaS oerings

span a relatively broad spectrum of comprehensiveness; some PaaS oerings provide a rapid application

development stack for simplistic applications that use drag and drop widgets and scripting engines to

compose functionality, while others like Google AppEngine and Microsoft Azure oer industry hardenedruntimes such as Java and .NET in the Cloud. In either case, these PaaS oerings require a full stack commit-

ment; PaaS, in many, but not all cases, marries the stack benefits with the underlying hosting infrastructure

and introduces some level of lock-in through the use of either libraries or custom programming languages that

can only work on that specific PaaS. To provide an analogy, building on some PaaS oerings would be similar

to writing an application for a yet to be adopted operating system that is tightly integrated with some specific

brand of CPU, rather than writing for an operating system that is independent of the underlying CPU architec-

ture.

Single instance multi-tenancy availability on PaaS oerings varies wildly and the benefit to cost ratios on

PaaS oerings are mediocre at best. PaaS oerings seem to be in one of two orientations:

For those PaaS stacks that do oer a robust runtime in the Cloud (take Microsoft Azure, for example), one

enjoys the ability to deploy relatively arbitrary code to the Cloud and have infinitely scalable resources at their

disposal, which solves a wealth of infrastructure and operations problems. However, these benefits come with

the caveat that none of the architecture and engineering problems surfaced by the SaaS delivery paradigm are

solved. These PaaS stacks do not oer any form of tenancy capabilities or architecture advantages to the

applications they host. Microsoft Azure and Googles AppEngine, for example, are themselves multi-tenant,

but do not endow the applications that run on them with single instance multi-tenancy. Furthermore, these

traditional runtimes in the Cloud do not oer any of the application building blocks or management tools

required to deliver a SaaS oering, such as billing and application subscription management. Given that this

flavor of PaaS does not provide much with respect to SaaS architectures, a majority of the burden found in the

pure build scenario for single instance multi-tenancy is still present when leveraging todays available PaaS

oerings:

Leveraging a PaaS Oering


PaaS (Traditional Stack)

COGS Time to

Market

Upfront R&D

$ Investmet

Ongoing R&D

$ Investment

Competency

Focus

General

Flexibility

Risk


19/24

1. COGS Since a PaaS exposing a traditional stack in the Cloud has few restrictions with respect

to achievable results, it is perfectly reasonable to achieve pure single instance multi-tenancy and

achieving a top notch COGS profile.

2. Time to Market Most if not all build burdens (aside from some high availability and scale

mechanics) are equal to non-PaaS build which still drastically impacts up front time investment

and project drag.

3. Upfront R&D $ Investment Some complexities around scaling and availability architecturesalong with easily provisionable resources eases some of the skill-set requirements when building

single instance multi-tenancy, which may reduce hiring pressures and pressures on capital.

4. Ongoing R&D $ Investment The same ongoing investment rationale of a non-PaaS build still

applies.

5. Competency Focus The same lack of focus on core competency described in non-PaaS builds

still applies due to the fact the all the SaaS-specific components of the platform (multi-tenancy,

user systems, billing, etc) still need to be created by the ISV and baked into their application.

6. General Flexibility Given that few restrictions exist in traditional stack PaaS oerings, ISVs

still have full flexibility to build out complex feature sets and maintain complete control of the

SaaS oerings direction.

7. Risk The non-PaaS build scenario described the risk of incorrectly building and maintaining a

single instance multi-tenant SaaS stack, which still applies in this particular PaaS form factor.

New risk is introduced on top of the already described risk, however. Given that most traditional

stack PaaS oerings have coupled the stack runtimes with the underlying hosting infrastructure,

freedom of choice with respect to hosting is lost. This means that although both the engineering

and hosting value propositions of a PaaS might be appealing at first, if the hosting quality

degrades, the SaaS oering cannot be moved and hosted someplace else. This coupling introduces

a dangerous new form of lock-in risk.

Some of the other PaaS stacks, such as WaveMaker, LongJump and Salesforces Force.com oer some

semblance of single instance multi-tenancy but through significant layers of abstraction or atop brand new

runtimes with custom programming languages and shallow functional sets. Typically, these PaaS oerings

oer Rapid Application Development (RAD) environments and/or visual application builders to optimize

programmer productivity, but at the expense of nearly everything else. Clearly, these tools might provide

amazing value to business users looking to rapidly build simple applications; but considering the complexity of

most ISV applications, they tend to be far too simplistic to support multi-million dollar SaaS oerings. A RAD

PaaS approach requires that an ISV abandon skill-sets, existing investments, and existing engineering assets

and migrate entirely to these new PaaS oerings while sacrificing significant flexibility. Although some aspects

of SaaS delivery architectures are baked into these PaaS oerings, they come at a significant cost.

Optimal Sub-optimal BLegend

PaaS (RAD)

COGS Time to

Market

Upfront R&D

$ Investmet

Ongoing R&D

$ Investment

Competency

Focus

General

Flexibility

Risk


20/24

1. COGS A number of RAD PaaS oerings abstractly capture single instance multi-tenancy so

that the applications built on them can inherit that architecture. This guarantees that resource

sharing is happening to some degree, but two factors reduce the value to sub-optimal levels. First,

these systems, because of new runtimes and abstractions, typically cater to a least common

denominator model by creating significant meta-data overhead which will reduce overall

eciency. Second, from a pricing point of view, a number of RAD PaaS providers charge by % of

revenue or fixed fee per some unit (such as per end user), creating an artificial floor to unit cost.

This means that even if an ISV has a means to improve utilization within the application, pursuing

the optimization would not be worthwhile given that it could never escape the PaaS vendors coststructure.

2. Time to Market RAD PaaS oerings typically are highly tuned for maximum productivity

within the set of problems which can be solved using a PaaS, so generally speaking, they oer a

significant time to market advantage.

3. Upfront R&D $ Investment Although most RAD PaaS oerings claim significant reduction in

R&D investment, this tends to be true only in some cases, but definitely not in the case of ISVs.

ISVs typically need to ramp up around new programming languages and tools, come up with

workarounds for limitations in these systems (since the stacks arent terribly expressive, complex

application functionality must be hoisted out of these systems into traditional stacks), and

calculate the costs of not being able to leverage existing assets or third party libraries,tools and

modules that were usable in traditional stacks.

4. Ongoing R&D $ Investment Other than becoming well versed in the new languages, the same

properties that balloon upfront investments will continue to be present in ongoing investments.

However, it should be noted that if an ecosystem of third party systems around the RAD PaaS

matures to the level of modern industry hardened stacks, then this cost may go down.

5. Competency Focus Competency focus should be a bit more biased toward the core given that

the RAD PaaS is fundamentally built to generate some level of focus (and at this point, it wouldnt

be fair to penalize competency focus analysis for learning new languages and runtimes, which

were already captured in the investment analysis)

6. General Flexibility RAD PaaS oerings are typically good at solving very specific problem

domains. Force.com, for example, provides a wealth of functionality and room for creativity

around extending the Salesforce.com CRM system. However, deviating from this core is generally

not possible or costly. For example, if an ISV is in the 3D CAD rendering space, it is quite probable

that the RAD PaaS cannot provide an adequate foundation for a SaaS-delivered rendering system.

7. Risk Risk in RAD PaaS tends to be very high. Asset lock-in is a huge concern since the applica-

tions most likely cannot run outside of the PaaS container. This is an amplified concern since that

means that business continuity issues, which are typically expressed as problems with respect to

abandoned products, are now operational concerns since the existence of the PaaS vendor is

required just to ensure that an ISVs application can continue to be oered. Furthermore, since

these RAD PaaS stacks are not yet pervasive, the ability to easily find engineers in the workforce to

fuel growth is much more dicult.

Clearly, within some subset of problems and solution needs, RAD PaaS makes sense and can oer individuals

immense value. Business users needing to rapidly build situational applications, for example, may find PaaS

beneficial. More often than not, however, RAD PaaS is not a solution for ISVs with millions of dollars of revenue

and significant application complexity.


21/24

The evolution of SaaS enablement started with roots in building SaaS applications in their entirety from the

ground up. The huge expense, loss of focus, and ongoing maintenance burden created a market for enable-

ment vendors to help provide solutions that would reduce the build burden. Soon after, auxiliary SaaS

functions such as billing and subscription management were captured as third party tools and solutions that

aspiring SaaS vendors could utilize, but no enablement technology existed that solved deeper architecture

problems such as multi-tenancy, scale-out, and provisioning. PaaS vendors attempted to capture some of thiscomplexity in a formal stack layer, but are either too low on the stack to provide meaningful SaaS architecture

value, lack operational tools, or require abandoning existing programming languages and runtimes to use new

unproven stack components. They generally require full silo lock-in as well; meaning that the programming

environment, language and tooling is married to the underlying hosting. As most solutions go, each genera-

tion of PaaS has provided more value than the previous. The direction of the industry has clearly been moving

toward a stack approach where SaaS applications get built atop layers that aim toward providing abstract

solutions to fundamental problems.

The software industry is no stranger to this. The operating system provided an abstraction from the underlying

hardware that catalyzed desktop development. Application servers such as JBoss in the Java world and IIS in

the Microsoft .NET world removed the need for application developers to explicitly deal with HTTP conversa-

tions between the server and a clients browser (along with a host of other issues) so that web application

developers could focus on meaningful code. Likewise, the SaaS application developer now has access to cloudmiddleware (or the SaaS application server, to continue the analogy). Cloud middleware vendor Apprenda

pioneered the concept of the SaaS application server with the introduction of SaaSGrid. SaaSGrid is a server

technology which fundamentally solves the most critical problems in building and delivering SaaS applica-

tions (including complex issues such as single instance multi-tenancy) with very little sacrifice. Cloud

middleware captures a SaaS stack as a server layer, allowing applications built on top of it using traditional

stacks to inherit a pure SaaS architecture with little risk or lock-in and removing nearly all the build burden.

Much like an application built on Windows does not need to understand the intricacies of how Windows

communicates with a hard drive to be able to store data on disk, applications on technologies like SaaSGrid

simply enjoy an enterprise grade SaaS architecture vicariously.

To provide context for the analysis, understanding SaaSGrid both conceptually and physically is important.

SaaSGrid is a SaaS application server that stitches together any number of Windows based servers into a

single, distributed logical software layer and enhances the existing Microsoft platform to be finely tuned foradvanced SaaS delivery. Software engineers write traditional, single tenant web applications using standard

Microsoft platform technologies such as .NET, SQL Server, and ASP.NET. Application components are provided

to an individual SaaSGrid instance using SaaSGrids management portals and deployed on-top of the

SaaSGrid runtime. SaaSGrid transforms various parts of the application and instruments the applications with

advanced architecture capabilities, while also linking the application to a number of management and

commercialization consoles. SaaSGrid introduces single instance multi-tenancy into the application architec-

ture automatically and transparently. Rather than relying on nave coarse grained OS virtualization, which

forces a full replication of the application stack per customer, SaaSGrid injects architecture virtualization into

the application components themselves. The database, for example, is itself virtualized as a stack component

meaning that what was a single tenant data model becomes capable of storing data for multiple customers in

single, highly scalable database instances, but in a fashion that is transparent to the calling application

(remember how our Windows application didnt need to know about how Windows I/O works against a hard

drive). Although seemingly magical, SaaSGrid relies on advanced architecture capabilities to introduce the

single instance multi-tenancy dimension to all application tiers without risky requirements such as new

languages or runtimes. Additionally, SaaSGrid provides the remainder of a pure SaaS stack, including all the

components described earlier in this section such as product management tools, billing capabilities, grid based

load distribution, failover, failure isolation, and a number of other operating features. SaaSGrid is a pure

middleware layer with no awkward coupling to a hosting environment. SaaSGrid can be deployed anywhere

that Windows server is available, whether it be a Cloud provider such as Amazons EC2 or traditional hosting

provider such as Rackspace or PEER1.

Building on Advanced Cloud Middleware


22/24

1. COGS Cloud middleware like SaaSGrid leverages advanced intellectual property to merge its

abstract single instance multi-tenant stack and tools (automatic provisioning, etc.) into a guest

applications architecture. By keeping a strict separation of concerns, technologies like SaaSGrid

optimize for the most ecient single instance multi-tenant model while software engineers can

optimize the performance of their application code. This focused optimization allows cloud

middleware based applications to achieve minimum COGS through maximum tenant density.

2. Time to Market SaaSGrid allows for rapid application development by removing nearly all

SaaS specific eort. An ISVs time to market becomes purely defined by the project scope of the

application itself, and not the project scope coupled with the SaaS stack scope. This yields a most

optimal time to market, and in cases where the cloud middleware provides commercialization

tools to define pricing schemes and publish self-provisioning storefronts (as SaaSGrid does), timeto revenue is also significantly optimized.

3. Upfront R&D $ Investment Cloud middleware is typically sold as a product and is licensed to

ISVs. The cost associated with the licensing must be viewed in relative terms; when compared to

build costs, the licensing tends to be significantly lower (for example, cloud middleware, in most

cases, could reduce project costs by 30% to 60%, amounting to hundreds of thousands, if not

millions, of dollars) but is not a zero cost endeavor (like pure application replication through

virtualization might oer). Furthermore, although extremely low, initial costs associated with

familiarizing a team and project with middleware must be factored in.

4. Ongoing R&D $ Investment Ongoing R&D costs are optimized to be as low as possible.

Knowledge acquisition surrounding the middleware is absorbed at the beginning of the project,

and ongoing education tends to be minimal and easily absorbed. Due to forcing separation ofconcerns, ongoing R&D investment from the ISVs point of view is solely focused on evolving the

application that their customers pay for while maintenance and evolution of the SaaS stack is the

responsibility of the cloud middleware vendor.

5. Competency Focus SaaSGrid allows for high levels of focus on core domain competency and

core skill-sets. Some focus is directed toward understanding cloud middleware early on, but this

one time investment is amortized across the subsequent high levels of focus directed away from

the SaaS stack. Reduced distraction allows for the necessary agility to gain sustained market

leadership.

Cloud Middleware such as SaaSGrid is optimized for a best of breed profile that reduces upfront costs and

time, as well as ongoing operational costs. SaaSGrids eorts are focused on purely solving SaaS architecture

and tooling problems rather than being a vague solution (traditional OS virtualization) or too egregious and

unnecessarily binding (most PaaS oerings). Hosting and infrastructure solutions are left to the best of breed

providers in that category, with cloud middleware solving the complexities of SaaS, leaving the ISV with a

wholly optimized stack and the ability to focus on writing software that is important to their customer base.

The end result is a cost benefit that makes sense:

Optimal Sub-optimal BLegend

SaaSGrid

COGS Time to

Market

Upfront R&D

$ Investmet

Ongoing R&D

$ Investment

Competency

Focus

General

Flexibility

Risk


23/24

Conclusion

6. General Flexibility Properly built cloud middleware is built with the understanding that

existing platform technologies are unbelievably expressive and capable, giving software engineers

and architects the right tools to solve problems of ever growing complexity. By focusing on

extending the capabilities of existing stacks, cloud middleware like SaaSGrid allows one to pursue

advanced SaaS delivery architectures without sacrificing the ability to use industry hardened

stacks like .NET and leverage the massive ecosystems that have been built around these technolo-

gies over the years.

7. Risk Technologies such as SaaSGrid can overcome short term risk by being able to evidence thequalities of an advanced SaaS architecture out of the box, unlike a build approach which might

take months just to produce a fragile prototype. Furthermore, by leveraging existing stacks, not

requiring new skills, and allowing freedom of choice when it comes to deploying an application

running on SaaSGrid, lock-in risk is extremely low.

Cloud middleware such as SaaSGrid provides a backdrop for advancement where the middleware provider can

continue to drive innovation with respect to the SaaS stack and vicariously introduce refreshed benefits to the

ISV over time, while the ISV can optimize business metrics and development eorts around strategic goals

associated with servicing their customers.

This whitepaper clearly identifies the impact of the various SaaS architecture approaches and reaches a clear

conclusion that for long term, sustained market leadership a SaaS provider should give serious consideration

to single instance multi-tenancy at some or all of its application tiers.

Single instance multi-tenancy and eventual full SaaS stack maturity can be achieved through a number of

approaches ranging from expensive build approaches to using advanced middleware. When looking at build,

PaaS, and virtualization, each provides certain uniquely positive qualities, but always at the expense of some

other quality. The future of the Cloud will be fueled by technologies like SaaSGrid that have been optimized to

provide the best qualities in SaaS architectures while neutralizing or even optimizing qualities that typically

acted as counter-balances in competing approaches. ISVs can benefit from the best possible cost and risk

profile without sacrificing strategic direction or introducing tactical friction.

About the Author

Apprenda is the creator of SaaSGrid, the industrys leading Application Server for superior Software as a

Service delivery. SaaSGrid solves both the upfront and ongoing technical and business challenges of delivering

software as a service, by providing software companies with zero-eort single instance multi-tenancy and grid

scalability in addition to out of the box application services like metering and monetization, billing and

subscriber management, and much more.

To learn how SaaSGrid can help you get to market faster and save you thousands of man hours of operational

overhead visit http://www.apprenda.com or contact us at:

Phone: (877) SAAS-WEB

Email: [email protected]


24/24

What if Salesforce.com Werent Multi-tenant?:http://www.saasblogs.com/2009/05/05/what-if-salesforcecom-werent-multi-tenant

Zuora Aims To Be Salesforce for Online Billing; Benio Agrees:http://techcrunch.com/2008/05/20/zuora-the-salesforce-for-online-billing-launches

SaaS is a journey, walk with us:

http://blogs.msdn.com/fred_chong/archive/2006/02/17/534633.aspx

Sources

Apprenda_TrueCostOfSaaSLeadership

Documents

Transcript of Apprenda_TrueCostOfSaaSLeadership