Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Helping independent software vendors (ISVs) understand the true total cost of building, deploying and continually delivering an enterprise grade service to their customers
UNDERSTANDING THE COST OF BECOMING A SUSTAINED MARKET LEADER IN THE SOFTWARE BUSINESS THROUGH SOFTWARE AS A SERVICE
Helping independent software vendors (ISVs) understand the true total cost of building, deploying and continually delivering an enterprise grade service to their customers
Table of Contents
Whitepaper Context Abstract Introduction What it Means to be a SaaS Provider Sustained Market Leadership as a SaaS Provider Understanding Whats Important Single Instance Multi-tenancy and Juggling Competing Factors Achieving an Architecture for Sustained Market Leadership Building Single Instance Multi-tenancy Leveraging a PaaS O ering Building on Advanced Cloud Middleware Conclusion About the Author Sources 3 4 6 6 8 8 13 14 15 18 21 23 23 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 tradeo s associated with di erent approaches to building a SaaS o ering 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/benet of each architecture 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, signicant framing is provided so that subsequent sections have appropriate context. Skipping sections might cause signicant 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 the primary results. Is this paper a vendor pitch? No. The paper is produced by Apprenda, a vendor in the cloud middleware space and does include signicant discussion of its agship 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 identied by the paper. The paper spends signicant time focusing on discussing problem and solution domains. How can I measure whether Ive e ectively understood the paper? If you walk away comfortable with how SaaS architectures a ect long terms business metrics, how to best compare di erent architectural approaches in terms of short and long term costs and benets, and with an understanding of the various solutions that achieve what the paper describes as the most optimal approach to 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.
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 o ering 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 e ectiveness at keeping these costs of goods sold (COGS) as low as possible is directly linked to their SaaS o erings actual software architecture. A poor software architecture will have a poor resource utilization prole and will do a bad job at spreading costs across the customer base, while a highly e cient SaaS architecture will provide maximum resource utilization without sacricing quality. This will drive costs down and gross margins up, providing a scal foundation for achieving sustained market leadership. E ciency 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 e ciencies that provide service to dozens, if not hundreds, of customers per server. To date, the trade-o has been that ine cient 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 prole, while the investment required to build single instance multi-tenancy has been a huge barrier to most ISVs because of the specialized architectural complexity of the approach. ISVs have a number of strategies for achieving SaaS stack maturity (which requires billing systems, provisioning 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 nancial prole, maintain agility, and maintain exibility. However, the upfront hard dollar R&D costs, signicant slow-down in both time to market and time to revenue, and signicant 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 o erings in the market span a wide spectrum of capability. On one end, PaaS o erings are too non-specic with respect to o ering a solution to SaaS architecture problems and instead are focused on infrastructure problems, o ering little value to solving SaaS architecture and commercialization problems. On the other end, other PaaS o erings are too abstract and, while solving some SaaS architecture problems, require the use of proprietary programming languages and runtimes in a limited environment that provides value only for the simplest applications. Furthermore, most PaaS o erings link the runtime with hosting operations, creating an awkward coupling that links engineering decisions to deployment decisions. As a result, PaaS requires signicant upfront investment akin to the build approach or o ers too little exibility 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 o ering 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 prole, with the least upfront and ongoing capital and operating investment.
The SaaS enablement market has evolved to solve a number of the problems associated with building SaaS o erings, 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.
Introduction
The past ve 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 signicant revenues as Software as a Service (SaaS) providers by giving business end users access to powerful software functionality over the Internet. Software companies e ectively 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 signicant number of ISVs know that their evolution to SaaS providers is imminent, but have not decided how they will pursue this transformation. Strictly looking at consumption trends, it becomes quite apparent that demand for SaaS o erings continues to grow. At the time of writing, publicly available reports by Gartner show that SaaS, at least from a consumption 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.
Operating Cost
Operating Cost
Net Prot
Licensing Cost
In the on-premises model, since each customer was responsible for operating an instance of the ISVs software and each customer had a di erent level of competency at hosting and managing that software, there was no consistency in the total cost of operating the ISVs software. A customer with nely tuned operations might manage the software internally at a very low cost and with little to no downtime, while a customer with little experience in running on-premises software might nd itself spending large sums of money and experiencing signicant downtime. Assuming all else is equal (i.e., the same exact software architecture, an ISV hosting a physical instance of the software per customer), if an ISV becomes a SaaS provider, at a minimum they should be able to operate the software on their customers behalf at some consistent, well expected unit cost rather than have the cost of service rely on the level of expertise of each customer. Furthermore, it is most probably the case that the ISV can do a better job than almost any customer at operating their own software. The mere introduction by the ISV of consistency and ne-tuned skill around operating their own software should create some level of net savings in the SaaS to on-premises comparison, but is that enough to truly leverage SaaS, create competitive advantage, and best capitalize on the opportunity? Is the transfer of operating burdens from the customer to the ISV alone enough to qualify as a SaaS provider and remain successful? The history and failures of the Application Service Provider (ASP) model, SaaSs technical predecessor, has taught us that this is not enough. Having to worry about COGS is akin to being in the manufacturing or traditional services business, which is something an ISV is not accustomed to but needs to rapidly become familiar with and optimize if they intend to build a successful, and sustainable, business. This new protability equation sums up the true meaning of becoming a SaaS ISV; to capitalize on the SaaS opportunity or to use SaaS as a competitive advantage an ISV must give up a world of 100% margins and learn to do business with the newest line item to hit their Income Statements: COGS.
Gross Prot
On-premises -> SaaS Operating Cost Burdens Transferred from Customer to ISV
Operating Expense
COGS
Licensing Cost
Many other metrics could be taken into consideration, but interestingly, COGS remains one of the most important: monthly recurring revenue can only drive prot 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 prole has the potential to achieve protability 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).
In fact, COGS could almost be considered the single most important e ectiveness measure in SaaS, or, at a minimum, dene the foundational stability of sustained market leadership. A sub-optimal COGS prole means that either an ISV will lose money hand over st or raise prices to astronomical levels (relative to a cost e cient 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 denes COGS in the SaaS business and how can a SaaS provider inuence it to take the upper hand in establishing market leadership as a SaaS Provider? The costs associated with delivering a SaaS o ering can vary, but a few core costs that can be considered common 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 o ering. 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 o ering 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 datacenter, IT sta is required to manage server instances and other infrastructure in support of the SaaS o ering. 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 e ective 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 e ective the ISV is at generating e ciencies 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 o ering. A SaaS o erings architecture will dictate how e ectively it shares the resources described in the aforementioned list. Although thinking about COGS and its e ect on a SaaS providers protability may seem like an uncomfortable idea, it is no di erent than looking to the e ciency of a manufacturers assembly line for an indication of its production costs. The more ne grained the SaaS o ering 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 signicant 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.
Fundamentally, one primary dimension of a SaaS o erings 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 sacricing 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 attens 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 prole while high density drives a low COGS prole. Generally, SaaS architectures can be bucketed into four categories: 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 many customers 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 architectural tiers.
The rst 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 specic customers to separate one customer from another and to assign specic resources to each customer. An application can be nave with respect to isolation and resource sharing. On the contrary, single instance multi-tenancy requires that the SaaS o ering be built as extremely complex software architecture that takes over the mechanics of isolation and resource sharing explicitly.
Physical instance per customer Virtual instance per customer Single instance, multi-tenant
Number of Customers
Comparisons between the di erent SaaS architectures should be made on the merits of COGS e ciencies, 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 o ering not possible, or at best, di cult 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: Approach Physical instance per tenant Tenant Density Ratio 1:1 ratio Description Each customer provisioned to the system requires human intervention to setup an actual server on which a specic installation will run for a specic customer. ASP businesses function in this manner. 1000 customers would
Hypervisors slice physical infrastructure into full OS stacks, o ering virtualized isolation and replicating the entire application stack for each customer. The actual achieved tenant density depends on the minimum requirements of the application and the specications 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 a ord 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.
No explicit linkage exists between provisioning a new customer and provisioning xed network resources. Lack of clear mapping and architectural abstraction requires that the application deal with isolation mechanics, allowing for ne 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
Some argue in favor of a virtualized approach, but at scale and in the long term, VM based models could a ect top-line e ectiveness by creating articial ceilings on gross margins and negatively impact the bottom line by adding signicantly 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 e ciency 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 compression ratio). This analogy paints a clear picture of how a specic choice of implementation (car vs. bus) impacts how nite, costly resources (roadway) are allocated and what those allocations might mean for overall costs and service levels (reduced transport e ciency, repair costs, tra c congestion, and lack of homogeneity) but also identies that complexity arises in shared environments when each passenger on the bus might want to listen to a di erent radio station on the bus without a ecting the other passengers. Clearly, these benets 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 a ect another. This level of customization is also possible in single instance multi-tenant but is much more di cult to implement and manage, requiring signicant upfront engineering e ort, 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.
COGS
Time to Market
Upfront R&D
Ongoing R&D
Physical instance per tenant Virtual instance per tenant Single instance multi-tenant
Legend
Optimal
Sub-optimal
Bad
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 signicant upfront time and money cost. Single instance per tenant architectures have very low upfront hurdles but, in many cases, o er little to no hope of good long term or at scale economics.
vs.
Competing Factor 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. Much longer time to market due to the time investment required to engineer single instance multi-tenancy into an application. Single instance multitenancy could slow a project down by 30% - 100%. Signicant increases in capital requirements due to frontloading of additional sta , tools and expertise required to build a single instance multi-tenant SaaS stack in house.
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 di culty of implementation, its ability to drastically swing a SaaS companys cost delivery prole, and the fact that it requires signicant upfront investment and thought. In fact, a SaaS o erings ability to achieve a low COGS prole 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 di cult to go back and correct. Clearly, given the described competing factors and ideal business outcomes, some will decide to opt-away from 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 red 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 multitenancy 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.
1. Subscription Management A SaaS customer typically pays for access to the SaaS o ering and in return, is a orded some level of access and metered usage that is captured in a subscription. A SaaS o ering needs to be able to dole out and assign subscriptions, use subscriptions to inuence application behavior, and provide a baseline for reconciling billing around usage. Furthermore, an engine for dening subscriptions, pricing, and feature inclusions should be in place to allow the SaaS provider to dene what subscriptions are available for purchase and to allow custom models to be developed for specic customers. 2. Metering While subscriptions dene 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 dene 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 customer with a means to participate in the reconciliation process. 4. Application lifecycle management In traditional on-premises software, an upgrade or bug x release would be sent to a customer who would then manage the process of installing the bug x or upgrade. Each customer would then perform the upgrade on their own schedule, and an upgrade mistake by one customer did not a ect 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 o erings span dozens if not hundreds of servers in a network.
5. Account Management Portals A tenant must be able to govern interactions and account information with a SaaS o ering. Exposing a portal for this is critical if the customer experience is to be thorough and comprehensive. This short list captures some major subsystems of a mature SaaS o ering. For the sake of brevity and reduced complexity, the discussion did not capture details around more di cult 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/or money investment required to build out a mature SaaS stack is huge, can easily reach six or seven gures, and can severely impact time to market. In some cases the e ort to build the SaaS stack could eclipse the e ort of the building the domain application itself. With all these architecture and delivery concerns now planted rmly on the providers plate, the application functionality that denes 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 di erent 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 specic approaches and conclude with an assessment of the best approach for achieving a position of sustained market leadership.
A single instance multi-tenant data model o ers the ultimate in e ciency, but if quality and exibility are to remain intact, signicant 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 owing contextual information to other systems). In memory, requests from di erent originating tenants 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 identication purposes, cookie management systems, and contextual owing of tenant data on web requests are used. Furthermore, 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 tenant a nity 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 subscription 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 signicant upfront investment in hard dollar terms, soft dollar terms, and temporal terms. Furthermore, maintenance of these complex moving parts means signicant ongoing R&D investments; it is almost certain that the baked in single instance multi-tenancy and requisite support components will be the most complex, error prone parts of the system. Even in the scenario where some of these components are provided by third parties, you can expect to pay signicant 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 prole for build is clear:
COGS
Time to Market
Competency Focus
General Flexibility
Risk
Legend
Optimal
Sub-optimal
Bad
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 prole. 2. Time to Market Build means that upfront R&D will be slowed down drastically, either signicantly delaying market release of a SaaS o ering 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 SaaS delivery 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 o ering, the ISV now owns the bugs and evolution of that signicant 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 inated 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 not exist 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 signicant distraction and as a result, most ISVs leverage third party database technology. A SaaS stack is no di erent. 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 exibility 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 di cult to maintain.
Pursuing build means that it is possible to achieve the best COGS prole (assuming that the ISVs engineering team has the skill set to properly execute the R&D) and maintain the power and exibility of using an industry accepted hardened stack (e.g., Microsoft .NET, Java, LAMP), but at a severe nancial, temporal, and focus penalty. The ideal scenario would be to achieve the COGS and exibility prole of a single instance multitenant 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.
COGS
Time to Market
Competency Focus
General Flexibility
Risk
Legend
Optimal
Sub-optimal
Bad
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 prole. 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 architectures along 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-specic 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 o erings, ISVs still have full exibility to build out complex feature sets and maintain complete control of the SaaS o erings 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 o erings 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 rst, if the hosting quality degrades, the SaaS o ering 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 o er some semblance of single instance multi-tenancy but through signicant layers of abstraction or atop brand new runtimes with custom programming languages and shallow functional sets. Typically, these PaaS o erings o er 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 o erings. A RAD PaaS approach requires that an ISV abandon skill-sets, existing investments, and existing engineering assets and migrate entirely to these new PaaS o erings while sacricing signicant exibility. Although some aspects of SaaS delivery architectures are baked into these PaaS o erings, they come at a signicant cost.
PaaS (RAD)
COGS
Time to Market
Competency Focus
General Flexibility
Risk
Legend
Optimal
Sub-optimal
Bad
1. COGS A number of RAD PaaS o erings 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 signicant meta-data overhead which will reduce overall e ciency. Second, from a pricing point of view, a number of RAD PaaS providers charge by % of revenue or xed fee per some unit (such as per end user), creating an articial oor 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 cost structure. 2. Time to Market RAD PaaS o erings typically are highly tuned for maximum productivity within the set of problems which can be solved using a PaaS, so generally speaking, they o er a signicant time to market advantage. 3. Upfront R&D $ Investment Although most RAD PaaS o erings claim signicant reduction in R&D investment, this tends to be true only in some cases, but denitely 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 o erings are typically good at solving very specic 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 applications most likely cannot run outside of the PaaS container. This is an amplied 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 o ered. Furthermore, since these RAD PaaS stacks are not yet pervasive, the ability to easily nd engineers in the workforce to fuel growth is much more di cult.
Clearly, within some subset of problems and solution needs, RAD PaaS makes sense and can o er individuals immense value. Business users needing to rapidly build situational applications, for example, may nd PaaS benecial. More often than not, however, RAD PaaS is not a solution for ISVs with millions of dollars of revenue and signicant application complexity.
Cloud Middleware such as SaaSGrid is optimized for a best of breed prole that reduces upfront costs and time, as well as ongoing operational costs. SaaSGrids e orts 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 o erings). 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 benet that makes sense: SaaSGrid
COGS
Time to Market
Competency Focus
General Flexibility
Risk
Legend
Optimal
Sub-optimal
Bad
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 e cient 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 specic e ort. An ISVs time to market becomes purely dened 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 dene pricing schemes and publish self-provisioning storefronts (as SaaSGrid does), time to revenue is also signicantly 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 signicantly 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 o er). 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 of concerns, 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.
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 sacricing the ability to use industry hardened stacks like .NET and leverage the massive ecosystems that have been built around these technologies over the years. 7. Risk Technologies such as SaaSGrid can overcome short term risk by being able to evidence the qualities 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 benets to the ISV over time, while the ISV can optimize business metrics and development e orts around strategic goals associated with servicing their customers.
Conclusion
This whitepaper clearly identies 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 benet from the best possible cost and risk prole without sacricing strategic direction or introducing tactical friction.
Sources
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