Multi-Tenancy in the Cloud: The Power, Perks and Pitfalls
At SAP TechEd, a number of customers asked me about multi-tenant cloud architecture: What’s it all about? What are its benefits? Is it secure? And what should they look out for when cloud vendors call themselves “multi-tenant-enabled.” They were also interested in knowing how SuccessFactors has architected its cloud solutions – and how our architecture differs from others. So, I thought I’d write a blog that explains multi-tenancy from the perspective of three audiences – software-as-a-service (SaaS) vendors, SaaS customers (tenants), and SaaS users (seats on the tenant’s account) – and how SuccessFactors’ multi-tenant architecture is unique.
Let’s start with a useful definition of multi-tenancy. Simply put, multi-tenancy is an architectural model where a single instance of software runs on a SaaS vendor’s servers and serves multiple client organizations (tenants). Multi-tenancy differs from a multi-instance architecture, where separate software instances (or hardware systems) are set up for different client organizations.
For the SaaS vendor, multi-tenancy increases resource utilization by allowing load balancing among tenants. It also reduces operational complexity and cost in managing the software to deliver the service. For example, vendors can easily roll out a software fix to all tenants by patching a single instance instead of many. Similarly, they can back up everyone’s data in one operation by backing up a single instance. The result? Operations costs are lower due to economies of scale and increased opportunities for automation.
For the SaaS customer and user, multi-tenancy is transparent. The customer seems to have its own dedicated instance of the software entirely to itself, while the user just sees the application as a user of any application would.
Faux vs. Real: The True Test for Multi-Tenancy
When it comes to cloud-based architecture, it’s critical to distinguish between “faux multi-tenancy” and “true multi-tenancy.” A true multi-tenant environment provides tangible benefits in terms of lower costs for the service and better service levels because it’s easier for the provider to deliver the service.
A real multi-tenant environment never comingles data from multiple customers. It provides complete flexibility to configure objects or import/export historical data. And it is not a virtualized single-tenant solution. Most importantly, each customer’s data is secure relative to other customer’s data and customization can be employed to the degree the application supports it without regard to what the other tenants are doing.
There’s a lot of confusion around how to implement multi-tenancy. In a push to join the cloud bandwagon, most on-premise vendors now call themselves “multi-tenant-enabled.” Running a customer on a single instance of a customized virtual application – and using an object ID to distinguish comingled customer data at the database level – is not the best implementation of a multi-tenant architecture.
At SuccessFactors, we believe multi-tenancy is the ability to run multiple customers on a single software instance installed on multiple servers. This approach delivers valuable benefits. It increases resource utilization by allowing load balancing among tenants. It reduces operational complexity and cost in managing the software that delivers the service. And it allows tenants to use the application as though they have an instance of the software entirely to themselves, which is completely secure and insulated from impact by others.
The SuccessFactors Approach
SuccessFactors uses a unique, hybrid multi-tenant architecture that serves millions of users around the world in a secure yet cost-effective manner. This architecture completely separates your data from other customers’ data, while allowing us to roll out rapidly the latest functionality to everyone, all at once. This approach also offers the most configurability and allows you to extract deep insight from your data.
Not all approaches to multi-tenancy are created equal. The following descriptions show how SuccessFactors’ multi-tenant architecture differs from other approaches:
- Multi-tenant with identical schemas: This approach, offered by some competitors, offers substantial scalability. But it limits configuration options for each customer, forcing them to cope with limited business process support from the application.
- Multi-tenant with custom schemas: Other competitors use this approach, which offers a wide range of configuration options for each customer. But it limits the vendor’s ability to maintain one code base. It may also require the vendor to introduce customer-specific complexity into the code line, potentially impacting performance and responsiveness.
- SuccessFactors’ unique hybrid approach: While the core of our approach is multi-tenant with identical database schemas for each customer, our customers are logically segmented at the database level, complete with their own database schema. You can export your own schema out of the database, import or export data, and configure or modify fields. With this approach, we enable individual extensibility within the schemas with our Meta Data Framework (MDF) and XML objects maintained in the identical schemas. We retain all the advantages of a highly scalable and secure multi-tenant model while still offering a highly configurable application. We also provide a distinct application instance per customer, offering better security through enforced memory segregation.
Check out the advantages of SuccessFactors’ unique multi-tenant architecture:
- Continuous, timely improvement: With all our customers on the same release, we can react to market demands or industry changes more quickly. That’s because we can focus on one version for support and the next version for development. As a result, you get the benefits of four releases per year.
- More flexibility: You retain full ownership of your data without fear of comingling that data. This has positive security implications. What’s more, it provides the flexibility to import and export your data, configure the application to match your business rules, and integrate your data with your ecosystem.
- Better usage: With multiple tenants on a single software instance, we can analyze and aggregate the behavioral use of our solutions. We can identify application areas that are not often used, make improvements, and recommend training for specific customers that are not taking full advantage of their solutions.
- Faster tracking and fixing of issues: Because all customers are on a single code base, we can easily diagnose a critical issue reported by one customer – and then respond swiftly to fix the issue for all customers.
- Clearer insight: We can offer better system-wide analytics (for example, identifying most-used and least-used features and reasons why), benchmarks, best-practice content and polling information compared to single-tenant hosted solutions at both the control and parameter levels.
- Improved performance: We can more precisely assess factors such as utilization, speed, and response times across multiple tenants in our platform – and more efficiently fine-tune the technology stack whenever needed.
- Enhanced service: We have a vested interest in making sure everything runs smoothly. In a single-tenant environment, a service disruption may affect only one customer. But a slight glitch in our multi-tenant environment could affect many customers. So we invest significant amounts of money and effort into ensuring uptime, continuity, and more efficient and effective service and support, including troubleshooting and problem resolution.
- Increased customer participation: Our multi-tenant platform is similar to most consumer Web platforms like Yahoo! and Amazon. Each represents a single code base that is shared by all users, with new capabilities accessible to all users simultaneously without the delays and labor-intensive processes of conventional software upgrades. These non-disruptive regular improvements encourage our customers to submit even more product enhancements.
- Lower subscription cost: Because we only need to support one current release for all customers and the same basic infrastructure, our costs are reduced – and we pass those savings on to you.
It’s the Real Deal
Developing a scalable, secure, and cost-effective cloud technology platform requires a unique approach. Our distinctive multi-tenant cloud architecture has been tried and tested for over a decade. Today, the millions of users around the world who are currently benefiting from the system 24×7 are direct proof of its credibility.
Remember, multitenancy if done right offers several advantages. With SuccessFactors unique multi-tenant architecture there are no pitfalls, only perks and power in your hands.
Thanks for reading!
Don’t forget to follow us on Twitter
Nice job with this Vinod
Thanks, Vinod. A nice overview!
I find it surprising to see how much confusion on the basic concept of multi-tenancy still exists and this should really help.
I have to day, however, I am always a little bit sceptical, as a matter of principle, if someone promises me the very best from two worlds.
The main advantage of multi tenancy for me is the degree of standardisation in the coding base it enforces, thus allowing a higher rate of innovation actually reaching user organisations, as it makes upgrades much smoother.
Yes, there is the cost advantage, but if a vendor can offer a software at low cost and good quality, why should I care how they achieve that low cost. And if they achieve low cost for themselves through multi-tenancy, but don't pass it to their customers, but to their shareholders (or have their CEOs lighting cigars with 1000 dollar notes, come to that), what's in it for me.
So, as a customer I look at the easy innovation aspect. Do I get better, more up to date features faster?
And whilst thinking that cloud vendors will keep advantage there, the proof's still hidden in the pudding. Cloud solutions are relatively new, with fewer customers and less historical baggage for each of them. Also, there customer base comprises those ready for early adoption of SaaS principles, i.e. happy with a higher degree of standardisation and acceptance of vendor fpdriven best practise.
Now the Meta Data Framework and other options for higher degrees of customisation are added. Whilst technically complying with multi tenancy principles, we will see individual customers deployments of SF growing further apart and complexity will increase. I'm not saying there's no advantage left over the on-premise model, but after 5 years of extensive MDF use and other customisation options, I can't imagine the level of disruption for upgrades still being as low as it was in the past.
So, we may get the best from both worlds, but with opening that door, at least a few of the bad and ugly things are likely to squeeze through the gap.
In this context, it is worrying to see the big integrators using their on-premise resourcing models for implementations, which should require less than half of them (well, imho, they over-resourced by multiples of 2+ even in the old world, so we are 4+ now).
I'm afraid they grasp the opportunity of MDF and bolt-on custom solutions to drive HRIS into the same mess for the third time round.
Therefore, I'm weary of communication inducing customers to let their guard down, suggesting: once you are on a prooer SaaS solution, there is no risk of over-customisation and runnaway complexity any more. I fear this might be proven wrong in five years time.
but still: a good post, which I enjoyed reading and will share round 🙂
have a jolly good weekend
Sven
Hi Sven,
Thank you for engaging on this topic. You brought up some great points. Let’s see if I can contribute to some of those.
Cloud, I believe, is no longer in its infancy. SuccessFactors has been around for over a dozen of years and Salesforce for over 14 years. So, it is worth briefly reviewing where cloud computing sits in the continuum of computing innovations.
The advent of the Internet changed things forever, both from the perspective of the network and the perspective of the computing resources: think mainframe and personal computers. The increased reliability and reduced cost of the internet (in comparison to proprietary networks) along with the decreasing cost of computers, led to increased use of web based applications. This, along with the demand for application access via multiple devices using multiple form factors, led to a rapid growth in cloud computing—at both an infrastructure, and an application level; with the platform now catching up.
It is worth drawing parallels between the resistance to adoption of cloud computing, and that of the Internet in general. In one of his books Charles Babcock, discussed the competitive pressures that gradually led to the adoption of the Internet:
“At one time corporations built out high-performance proprietary networks to link...different locations...As the Internet became the default connection between universities, government agencies and some companies, the cost of not having an [Internet protocol] network internally went up and up.”
We believe, like the Internet the economics of cloud computing is rendering previous approaches as increasingly cost prohibitive. Yes, the initial push towards cloud computing’s “one size fits all” model were for non-strategic computing resources. But now, we have crossed that chasm and increasingly we are seeing companies moving their strategic computing resources to the cloud model.
What we are seeing now is cloud computing going to the next level, where extending applications is not synonymous to impeding innovation that we saw in the on-premise world. The design priciples are different. If implemented correctly, I don’t think that we will see the kind of problems we saw with the on-premise applications in the cloud world.
SuccessFactors has always had extensibility as a core part of its architecture. The SuccessFactors solution from the start was built with what’s called the data model. You have to do that at the architectural level, you can’t add that later on because every part of the application needs to be aware of that extensibility layer and react to the data in the extensibility layer. With Metadata Framework (MDF) we have taken this to the next level.
MDF has many advantages. First, the MDF allows SuccessFactors to deliver features and functions much faster since new code is not required. Second, customers can add additions, extensions, and configure the product to a very high degree without coding and without customization.
With MDF, there is also a clear separation of ownership. There are two sets of metadata effectively. There’s the metadata that’s delivered by SuccessFactors which is completely owned by SuccessFactors and then there’s the metadata that a customer can modify or add. This means that a customer never gets into a situation where they are overwriting what SuccessFactors delivered. They can never get into the nightmare that they’ve had before where the upgrade doesn't work. Two completely separate sets of metadata: the customers’ metadata and SuccessFactors’ metadata. Meaning that when SuccessFactors delivers a new release, we can’t step on the customers’ metadata and vice versa, the customer can’t break the delivered functionality.
Technology is constantly changing and evolving. And though things may seem impossible or diffcult at first to attain, it may not really be so far fetched after all. Yes, as cloud adopters you should not put your guards down, but realize that there are problems with putting the walls up too much also.
Thanks,
Vinod Choudhary
Hi Sven
Its now 7+ years on since this discussion.
I'm curious to get an assessment of your understanding of the results of using cloud, as I believe you had a valid point back then.
But did it come through in your experience?