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

Today’s PaaS Offerings: Pragmatic or Unrealistic?

Jul 12, 2010 by

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

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

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

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

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

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

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

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

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

read more

Related Posts

Tags

Share This

Do you have to leverage “X as a Service” to be a SaaS provider?

Dec 10, 2009 by

I love the idea that a balance exists between ideology and practicality. Questions of ideology and practicality always arise when it comes to building software, building a business, and building a software business. SaaS is no exception.

Interestingly, I had two different discussions with people who were of the position that aspiring SaaS company’s should “put their money where their mouth is” and use cloud technologies exclusively to build out their SaaS offerings, stating that it was a form of hypocrisy to offer SaaS and not use Infrastructure as a Service or Platform as a Service.

The question I have is whether it is necessary to bind yourself to “XaaS” technologies in order to be a SaaS provider. To be honest, I think that such a “requirement” is absurd. No, you don’t need to use IaaS or PaaS or anything of that nature to be a SaaS provider at all, let alone a good one. Not using XaaS says nothing about convictions. I find this sort of fanatical idealism a put off, and it’s interesting to me that people in the tech space moving to SaaS fail to realize that ‘Service’ is only new and special in the context of software. Humans have been running service business for hundreds of years. Do you think that telephone companies, electric utilities, cable TV companies, etc. only use services to run their business? No, of course not. There are many good reasons and cases to use XaaS suppliers to support your own SaaS business (EC2, etc.) and in other cases, you may need/want to run your own infrastructure. Currently, there is no clear cut rule or guide forcing one way or the other. The fact of the matter is , you can be a GREAT SaaS provider and run in a co-located space, in your own datacenter, on EC2, or whatever else you deem appropriate. What matters is the quality of service and the quality of the software.

Do you agree with the statement that a SaaS provider needs to be using IaaS/PaaS to be taken seriously, or do you feel that it’s OK for a SaaS provider to leverage non “XaaS” approaches?

read more

Related Posts

Tags

Share This

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

Apr 3, 2009 by

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

“Well, a PaaS seems to save us a ton of upfront effort and cost. In fact, it might cut our costs down from $600,000 and 14 months to $200,000 and 4 months. However, if we go with a PaaS, we’ll have an ever present operational expense that never goes away. If we go with option 1 and just bite the bullet, sure we’ll spend the money and time upfront, but that’s just a one-time investment. Won’t we experience ROI on that 10 months and $400,000 rather quickly?”

My answer is an emphatic no! Now, don’t take the platform guy’s (me) word for it: let me put some substance behind my claim. To understand why I say no, let’s really understand the question. Starting from the top and irrespective of the aforementioned question, an ISV is deciding to deliver software functionality to the web. That functionality is valuable to their customer base. The better the ISV is at their core competency of capturing value for their customer, the better off the customer is and the more likely the business is to succeed. If you’re building an HR app, every minute and dime your company invests in HR functionality could yield added value for your customer and higher revenue for you.  At no point does this suggest that somehow the delivery model is the core value offering to your customer, or that your competency is in constructing a delivery model. In fact, it’s a distraction to the primary goal. Now, going with option 1 with a notion that we have to “Build it here because it’s a one-time investment and we’ll make a return” assumes that it is in fact, a one-time investment. This couldn’t be farther from the truth. Realistically, you’ve in fact decided to take on the burden of whole product line and its lifespan. I’ve constructed a conceptual diagram to capture the rough notion of relative cost between your actual offering (an HR app), the “home built” SaaS delivery model stack, and opportunity cost (all of which I’ll discuss)

At the start of your SaaS journey, option 1 means that a huge chunk of your development time and money (40% – 70%) will be focused on solving SaaS delivery model problems and not on the value proposition you plan on delivering to customers. This is what accounts for the added 10 months and $400,000 in our initial scenario. Now, if the buck stopped there, our decision maker might be right: ROI is right around the corner. Realistically, you’ve made a first attempt at building a SaaS delivery model and have rolled out a very immature SaaS support stack. Once you launch your product, you’ll start your first maintenance and “new feature” phase of your offering. During this period, you’ll find that the most bugs and changes are coming from deep SaaS architecture problems and change requests. Your time will most likely be diverted away from product change requests (read: innovation) by SaaS stack repair. If you’re successful, you hit some “scale event” and feel a massive “cost pinch” and risk point. The scale problems in this case are most likely a result of poor assumptions in the SaaS stack, or the coupling of your actual application to the underlying delivery model machine. This cycle of maintenance effort and scale events will likely happen a couple of more times, and a couple of years down the road, with thousands of man hours and lots of money spent on the SaaS stack, you’ll reach a point where the stack effort starts to decrease, giving you some breathing room. At that point, you’re done battling fires with the fits and starts of big problems and maintenance phases, but opportunity cost ambiguity kicks in; are you going to exert effort on your core product or boost value in the delivery stack? Odds are you’ll forgo improving the stack (despite the massive value it can inject in your business) in favor of responding to customer demand on domain functionality need in your nifty HR app (since you’ve been distracted by the SaaS stack for so long). Those opportunity costs mount, and potential added revenue or savings opportunities disappear. Think of simple examples like giving your customers the ability to download data backups: is that an application specific problem or a “horizontal” problem for which a stack should be responsible? Do you want to waste effort on this or would it have been wiser to build on a PaaS that either has this functionality or that would introduce it faster than you would? I guess it wasn’t a one-time investment after all! In fact, it seems to be a massive ongoing investment with little predictability or bounds. This discussion hasn’t even touched on the maturity concept (for example, a “home built” SaaS stack will bump into security problems, bugs, etc. that get resolved in PaaS offerings much quicker because of the speed at which they scale due to aggregation, and the fact that PaaS providers focus solely on solving these problems).

When looking at a PaaS offering like SaaSGrid, you need to understand that paying a utility fee gives you a fully maintained delivery model without the ongoing headaches; one that will evolve much faster than you can imagine, constantly adding value to the guest applications that depend on it. If this isn’t enough, history has shown us great analogies. For example, why don’t people write application servers each and every time they write an on-premises web app? Because it doesn’t make fiscal or logical sense! You just download JBoss or buy WebSphere and go about your business! It’s very difficult to argue that a “home built” stack would be more powerful, less costly, and more able to keep up with market change.

What’s your opinion on PaaS vs. building it all yourself? Does the application server analogy resonate well with you? I’m interested in your feedback!

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

 

read more

Related Posts

Tags

Share This