Throwing Around the Term “Multi-tenancy” Isn’t Helpful: Advice to App Developers in the Cloud

Mar 14, 2011 by

Before I get started, this post IS NOT a post about why multi-tenancy is a good thing, why it’s better than virtualization, or anything of that nature. I had to get that out before starting – there are plenty of posts that deal with this topic (one, two, three, etc.). Instead, I want to tackle a different issue: the issue of what multi-tenancy means in a variety of contexts as well as how its positioning by vendors is leading to mass confusion.

No particular event has motivated this post; instead, this post is the result of a number of conversations and miscommunications. A while back, I started noticing some disturbing trends in the market, and more specifically, in vendor pitches. Let me use a real world example of what I mean. Frequently, the sales team at Apprenda ends up in the following type of conversation at some point in our sales cycle (clearly, this is distilled for brevity):

Prospect: “I saw that SaaSGrid offers multi-tenancy.”

Apprenda: “That’s right; SaaSGrid gives your application access to various types of multi-tenancy using the same code base and application assets. It’s actually amazingly unique and takes significant effort out of your R&D.”

Prospect: “Yeah, but doesn’t <insert your favorite PaaS/IaaS here> offer multi-tenancy?”  or “Well, the folks over at <insert your favorite PaaS/IaaS here> said they offer multi-tenancy too.”

Apprenda: “That’s different. Those technologies are themselves multi-tenant. SaaSGrid is a server technology that allows your single-tenant application to be multi-tenant at all application tiers without the huge effort typically associated with going multi-tenant.

Prospect: “Wait, but that’s exactly what I heard <insert your favorite PaaS/IaaS here> say. You’re saying that they don’t do the same thing as you.”

Apprenda: “Correct. Most, if not all, cloud platform vendors that refer to multi-tenancy are references to their own architectures, meaning they can efficiently pack their customers onto shared hardware/OS instances and offer you better service and a low price point. What you’re asking is how you can be multi-tenant and offer the same to your customers. Others in the cloud can’t help you with that.

Prospect: “OK, so using their service doesn’t make sense then?”

Apprenda: “That’s hard to answer, but it usually makes sense in conjunction with something like SaaSGrid. Clearly, being on something like EC2 (which is multi-tenant at the infrastructure tier) has advantages to you. Using SaaSGrid means you can really lower your internal cost of offering your service to your customers, and either put the savings to the bottom line or pass it along to your customers.”

Prospect: “What SaaSGrid does seems pretty magical now that I’ve cut through the marketing BS, how do you do it?”

Apprenda: “SaaSGrid is a runtime. When deployed to SaaSGrid, your application is transformed and new capabilities are instrumented into all tiers of your application. When running on SaaSGrid, these transformations and runtime instrumentations ‘inject’ SaaS architecture DNA into your non-SaaS web application.”

As you can see, this sort of conversation is a distraction. Whether it’s a conversation with an analyst, industry pundit, or potential customer, I’ve found that the most important thing to do upfront is to level-set on what both sides mean/understand when they say “multi-tenant.” Why so much confusion? I think it’s due to two factors:

  1. The marketing pitch offered up by vendors and how those marketing sound-bites are contexualized
  2. The general overloading of the term “multi-tenant”

On the marketing side, vendors do a good job of highlighting multi-tenancy. The problem is that the lack of context around the “feature” of multi-tenancy causes significant miscommunication. From a marketing perspective, vendors are sucked into the Green Crystals Marketing described by Bob Warfield a couple of years ago. Most cloud vendors are touting that they are multi-tenant; they want you to understand that they have a cost-effective and safe mechanism to isolate their customers from one another. To understand this better, I’ve taken the liberty to copy and paste (with references, of course) some content related to multi-tenancy from various cloud vendors:

The AppFabric Container provides base-level application infrastructure such as automatically ensuring scale out, availability, multi-tenancy and sandboxing of your application components. (Microsoft, Windows Azure)

Cloud-enabling infrastructure to allow secure multi-tenant deployments, including fully integrated management, monitoring, metering and billing infrastructure (CloudBees)

If you are running numerous applications/application instances, XAP’s fine-grained multi-tenancy allows you to share them across all available machines, instead of running only one instance per machine. This allows you to support more users on each machine. (GigaSpaces)

There a few others to use as examples, but this is fine for now. I’m not going to debate whether advertising that you are multi-tenant is an effective use of marketing real-estate. all of these snippets of text highlight multi-tenancy, but what is unclear is the context. For example, the first two indicate multi-tenancy at the platform tier; that is, multiple, unrelated code assets can share common OS instances. While this is powerful in its own right, it’s easy to understand how someone reading this text might walk away thinking “Excellent. Our requirements for our new SaaS project call for multi-tenancy. I can check that off our list.” The fact is, while ambiguous in terms of presentation, these technologies do not endow your application with multi-tenancy, they let you run in a multi-tenant environment. If you’re looking to build a multi-tenant app, you need to still architect multi-tenancy (‘architect’ is a verb according to the Oxford English Dictionary). In the gigaspaces case, although they refer to multi-tenancy in a way that lends itself to an “endowment” interpretation, it seems that they are focusing more on a grid approach of scaling the app to support more end users. While this is also valuable, it does not deal with segregation and isolation of logical groups of tenants (which is what multi-tenancy really is). At Apprenda, we even dealt with this definition in problem in our FAQ. This leads me to the next issue: term overloading.

Multi-tenancy is valid in 3 common computing contexts:

  1. Infrastructure: This is multi-tenancy the way someone like Amazon might refer to multi-tenancy on EC2. In the IaaS context, multi-tenancy means that multiple OS instances can run on the same physical hardware through hypervisor technology.
  2. Platform: PaaS multi-tenancy means that, like a Heroku or a CloudBees, the platform can isolate code from different apps/vendors on the same OS instance (usually by commingling processes and databases on OS instances). This removes the need to allocate a whole VM per application stack component, improving efficiency.
  3. Application: SaaS multi-tenancy, at least at the highest level of isolation, means that single runtime stack component instances are shared across multiple customers. For example, a single database might commingle data rows for thousands of customers while preserving isolation and performance.

Clearly, multi-tenancy means different things in all of these scenarios. There is nothing wrong with overloading, but it certainly doesn’t help the already high levels of confusion that exist around the word. If you’re an app developer in the Cloud looking to see what tech can help you, having a sense of clarity is most useful. Make sure you ask simple questions like:

  1. When you say ‘multi-tenant’, what do you mean?
  2. If multi-tenancy is a feature of your IaaS/PaaS, does that mean my app automatically becomes multi-tenant and I get to reap efficiencies from it?
  3. If I want my app to be multi-tenant on your IaaS/PaaS, will I have to still architect the app to be multi-tenant?

If you get answers of “I don’t know” or “No”, then clearly, you’re on your own if you want to build a multi-tenant SaaS app from the ground up.

Do you feel multi-tenancy is thrown around too often by the wrong parties? Is multi-tenancy confusing to you?

Before co-founding Apprenda, Sinclair held positions at Morgan Stanley, Eden Communications, and the State University of New York (SUNY). Sinclair holds a dual Bachelor of Science in Computer Science & Mathematics from Rensselaer Polytechnic Institute, where he graduated Summa Cum Laude. Sinclair excels in understanding the economics of SaaS platforms and ecosystems, and is a frequent speaker and panelist at industry events

read more

Related Posts

Tags

Share This

2011 Predictions for Cloud, SaaS, Multi-Tenancy and More!

Jan 10, 2011 by

OK, it’s already 2011 and I’m a bit late on providing some predictions for 2011 – but now is better than never! I sat down and thought about events in 2010 and whether those events have created a meaningful disruption with near term potential to affect 2011 outcomes, and this is what I came up with. Some of it is based on intuition, some on knowledge, and some experiences I’ve had at Apprenda in working with customers, prospects, and others in the industry. This is more of a mental exercise in subjective extrapolation rather than “prediction”, so don’t hold me to these;-)

1)Adoption of SaaS by ISVs will pick up more steam in 2011

a.Overall, an overwhelming majority of Independent Software Vendors (ISVs) deliver their software via the on-premises “packaged software” model. Consumption of software as a service (SaaS) offerings continues to grow at an amazing pace, but most of the demand has been satisfied by a couple of hundred companies that have surfaced in the past 10 years as wild success stories, such as Salesforce.com. As a result, I expect that on-premises player will continue to take notice and make the switch.

b.Competitive pressures within major verticals are becoming more and more real due to successful SaaS entrants, which will drive adoption of SaaS delivery as a market response. Existing software ISVs will start respond by moving part of their product lines to SaaS, or by choosing to offer down-market offerings as an initial experiment.

c.Counter to the perspective of many experts, packaged software ISVs will find strategies that work in their transition to SaaS. Transitional “poster-children” of each vertical will give confidence to other ISVs in the market that the transition can be made successfully.

d.Continued adoption of new technologies such as platform as a service (PaaS) and cloud application servers will bridge technical gaps that will ease the overall transition burden, fueling adoption of SaaS by more and more ISVs. I do not think SaaS is the nail in the coffin for existing ISVs, particularly with technologies like SaaSGrid in the mix which flatten the technical curve for both new application development as well as migrations.

e.Continued explosion of mobile usage creates further pressure (and significant opportunity) for companies to move to a SaaS delivery model. Most business applications that have a mobile angle typically need back-end systems to reconcile the data into primary applications, and SaaS is the only architecture that makes this feasible at scale across many customers.

2) The Upstack Scramble Intensifies

a.Big players continue to make big moves to seize the opportunity to control the new software battle ground in the cloud. Traditional platform vendors will realize that the application development and architecture tiers are huge opportunities, and that infrastructure virtualization and infrastructure tier technologies are not the competitive landscape of the future. Deals like the Heroku and Makara acquisitions make a lot of sense for players like Salesforce.com and Red Hat, respectively.

b.2011 and 2012 will be a make or break years for these big players, and the moves they make over the next 12 to 24 months will ultimately determine the next decade of control and leadership.

c.Commodity players, or players that have become commodity, seek to buy value up-stack through acquisitions.

3) Real Traction with Private Cloud/Internal Utility Computing and SaaS delivery

a.Mistakes and failures experienced in 2010 will be the lessons learned to drive the real solutions and seed private cloud and private PaaS adoption over the next 12 – 36 months.

b.Organizations want a unified and scalable platform for software delivery, and the vision of private cloud will begin to include technologies that sit above the virtual tier to give significant architecture and services value to internal development assets. A paradigm shift in how software developed internally for business units will kick off.

b. Enterprise projects will continue to explore leveraging Cloud architectures such as multi-tenancy for internal use. The cost savings and agility potential presents enormous savings profiles that push their way into enterprise development shops.

4) Cloud Washing Reaches Critical Mass and Collapses by EOY 2011

a.After attempting to cloud wash offerings, a number of small and mid-market ISVs will close shop due to competitive pressures and no real tactical response. This will help identify cloud washing as a poor strategy and that only real, measurable attempts to convert a SaaS model will lead to success.

b.Forces vendors to articulate how their strategies and solutions that is unique and truly “cloud.” Continued success of pure-cloud/SaaS plays will evidence that cloud washing adds no value.

5) Force.com Starts to Realize Momentum Potential

a.Force.com/Apex’s stuttered start begins to gain true rhythm now that Salesforce.com has diversified its cloud to be competitive outside of its proprietary track, particularly in Ruby and Java arenas due to Heroku and VMForce.

b.Force.com will continue to show strong among those extending Salesforce.com’s CRM functionality and potentially within the enterprise where it can be used to displace situational “spreadsheet” applications.

6) Cloud Middleware Provides Democratized Access to Complex Software Architectures

a.General development/programming skills declining, coupled with a continued increase in architecture complexity creates a gapping void that new middleware needs to fill

b.Just like the years when desktop OS’ spurred innovation by enabling companies to focus on their software and not the underlying complexities associated with its delivery – new solutions will fill the gap and catalyze a similar era of innovation once again.

c.Middleware solutions like SaaSGrid will drive multi-tenancy as a defacto standard since the primary concern of difficulty and cost to implement is trivialized.

7) QE[pick your number] won’t be a panacea for the economy – but SaaS and Cloud will help

a.Economic factors will continue to put pressure on operating budgets. Companies will be looking to do more with less; that is, they’ll want to boost efficiency while slashing budgets in order to survive in the modern economic climate. Due to size, IT budgets will be scrutinized and IT managers will be challenged to come up with solutions.

b.SaaS will be seen as a means of democratized access to solutions that drastically improve efficiencies while driving down the cost of IT. Infrastructure as a service will be leveraged to reduce the operating burden associated with in-house infrastructure.

c.Doing more with less, optimizing business performance – SaaS based B2B solutions will grow significantly in 2011 as a result.

I’d love to get everyone’s thoughts. Agree/disagree? Why? Did I miss something or does this seem to cover the right surface area?

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

read more

Related Posts

Tags

Share This

Lack of Multi-tenancy: A Broken Business Architecture?

Nov 4, 2010 by

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

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

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

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

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

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

Free trials via VMs
(bigger)

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

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

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

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

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

read more

Related Posts

Tags

Share This

The Cost of Sustained Market Leadership as a SaaS Company – New Whitepaper

Jun 17, 2010 by

Hi everyone,

We just yesterday released a brand new white paper entitled “Understanding the Cost of Becoming a Sustained Market Leader in the Software Business Through Software as a Service”, that we thought the community might be interested in. It’s vendor neutral, no product pushing, etc, and we’ve gotten great feedback thus far.  As always, we’d love to hear your thoughts, so please speak up! :-)

You can access the full white paper here.

Topics covered include:

- What it means to be a SaaS provider
- The importance of highly efficient SaaS architecture
- Optimal strategies for achieving the SaaS stack maturity necessary to become a sustained market leader

The paper begins with an overview of providing a SaaS offering, the primary infrastructure and delivery costs, and the requirements for market leadership before proceeding into the complexities and benefits of single-instance multi-tenancy and a critique of several compensatory strategies. The paper then concludes with an explanation on how cloud middleware can solve these architectural problems thereby achieving the benefits of building your own multi-tenant stack without the onerous upfront R&D costs and long time-to-market or the poor customer management and lock-in deficiencies normally associated with leveraging Platform as a Service (PaaS) offerings.

Here’s the link again to access the full white paper.

Should you have any questions or feedback on the whitepaper, please let us know.  We hope you find it to be a useful and informative read!

- Jesse

read more

Related Posts

Tags

Share This

Is Multi-tenancy Just a Database Architecture?

Sep 7, 2009 by

Most everyone that’s part of SaaSGrid has converations either with customers, industry types, media, etc. about multi-tenancy capabilities that we “inject” into guest applications that live on SaaSGrid. One common misconception that we hear people spew out is that  multi-tenancy “is just a database thing.” That is so far from the truth! While many typically think of multi-tenancy as data segregation, it’s in fact much, much more. Usually, folks that haven’t done it (multi-tenancy) don’t get it!

First, let’s look at multi-tenancy at it’s core. What we’re really saying is that we want each customer to feel as if they have their own application instance regardless of what instance orientation is being used (single instance, multi-instance, etc.) Let’s look at the holy grail of single instance, multi-tenant. What we’re really saying is that generally (this doesn’t fit all applications, but most):

  1. Customers needs to login to some *shared* frontend.
  2. Customers execute business logic on *shared* compute resources
  3. Customers store/get data from a *shared* data stores
  4. Customers use auxilliary systems to manage their presence with the service

Is multi-tenancy just a database issue? I hope at this point some level of obviousness has become part of the equation. Multi-tenancy means that you architect your front-end to fit the instance flavor you’ve chosen (in our case, single instance) so that UIs can segregate provisioning and UI rendering. Second, services layers need to execute against data for the correct customer in a safe fashion (so one customer doesn’t clobber another customer), which means we need execution isolation from a tenancy perspective. Next, data needs to be stored and retrieved correctly per tenant. Last, everything from authentication systems to upgrade engines need to understand tenancy and distinguish tenants from one another.

The footprint of multi-tenancy, when done correctly, is huge on an architecture (which also means you’re not using SaaSGrid;-)) One shouldn’t trivialize it as “just an extra column on some tables” because it’s far from that, so make sure you really understand multi-tenancy before tackling it, as it’s one huge iceberg!

read more

Related Posts

Tags

Share This