5 Comments

Summary:

Clouds can be analagous to a self-sufficient single-family home, a shared-infrastructure apartment house, or, with the right planning, they can combine the best of both worlds.

Dealing with co-tenants can be an excruciating experience – whether you are talking about roommates, people in the office, your apartment building or even the communal table at Starbucks. And those are the co-tenants you can see and hear. In the cloud, co-tenants are often invisible but often affect your occupancy even more.

That is why one of the industry buzzwords around cloud computing is tenancy – as in multi-tenant and single-tenant. In the world of cloud computing, tenancy refers to how the cloud platform and underlying infrastructure are shared among different customers that use the same cloud service.

Multi-tenants and single-tenants

A multi-tenant cloud is where all customers share the same cloud platform and infrastructure and their data is commingled. This commingling does not mean that customers can see each other’s data. Access to the multi-tenant environment is strictly controlled and customers only get a view of their commingled data.

But this model does raise security and privacy concerns for many organizations, especially those in regulated markets. Using a real estate analogy, this would be like an apartment building. Mike’s key for apartment 10A does not allow him access to apartment 20F. He only has access to his occupancy.

The benefit of a multi-tenant model for the cloud provider is that it can maintain one shared cloud for all customers. The benefit for customers is that they are always on the latest version of the cloud software – such as when Google updates Gmail for all users. When it’s time to upgrade the cloud, all customers are upgraded at the same time and share the same experience. If you replace the main water pump in your building, all of your tenants get higher water pressure at the same time. The downside for customers is that they may have customized their use of the cloud and the latest version will cause issues or come at an untimely moment for the business.

A traditional single-tenant cloud is where customers get their own dedicated cloud service and their data is not commingled with any other customers. From the customer’s perspective, they are running their own cloud service and can customize it as they see fit. The biggest benefit for the customer is that their data is completely isolated and they have the ability to customize anything in their use of the cloud service. Keeping with our real estate analogy, this would be kind of like a development of tract homes. Each homeowner can customize their property as long as it falls within the acceptable policies of the homeowner’s association.

This introduces a big potential drawback for the cloud service provider because every customer can be running its own custom version of the cloud platform and the provider needs to develop a scheme where customers think they have their own dedicated infrastructure. Of course, the reality of deploying physical infrastructure for every customer is not a recipe for a scalable cloud service – that business is called server hosting. Imagine going to upgrade the hot water heater for one of your occupants and when you look at the property, the hot water heater is no longer in its standard location in the garage, but instead, it’s mounted on the roof and bolted to the chimney.

Let’s Do Both!

Yet, what if a cloud service could be both a scalable multi-tenant environment and provide the benefits of a traditional single-tenant environment? You’d end up with what we call a multi-instance cloud.  Several vendors, IBM, HP, Salesforce.com and, yes, ServiceNow,  all have their own take on this problem. If the solution is done right, customers win because they can fully customize their cloud service and avoid commingling data. The cloud service provider wins because it can scale its business effectively without provisioning dedicated platform and infrastructure for each customer.

Designing a multi-instance cloud service on a multi-tenant infrastructure does introduce a new set of problems – from hardware provisioning to scalability to monitoring performance – in an environment where the customer has the ability to completely customize their service to their needs.

The way to achieve this design is to build a multi-tenant cloud infrastructure while maintaining isolation of both the application state and data model for each customer – thus resulting in an efficient and scalable use of the infrastructure and a logical separation model for each customer.

For example, you could have a virtual machine that runs application logic for each customer that utilizes a persistence layer (SQL and/or NoSQL) that is shared on a per-customer basis. At ServiceNow, that is essentially how we run our multi-instance cloud platform. Each customer has a logically separated environment that they can customize exclusively for their business. Customers can have a completely customized database schema. They can develop and execute custom scripts to modify almost any piece of the platform from the user interface all the way through to the data layer. Custom processes and their associated policies can be implemented with business rules and executed through combined workflows. Entire end-to-end applications can be built within the platform.

When we upgrade our cloud platform, customizations stay intact and can be enhanced. We operate a multi-instance infrastructure environment where we have virtual machines from multiple customers sharing common hardware. We classify each of the customer environments into “size points” and run benchmarks on our hardware to understand how many size points can operate on a specific set of hardware. We monitor this environment very closely and use automation to move logical single occupants when size points expand or shrink on the associated hardware. In other words, we use our cloud infrastructure in a scalable and efficient multi-instance manner while allowing our customers to have the customization and data isolation of a traditional single environment.

Cloud infrastructure and cloud platforms should look to combine the use of both multi-tenant and multi-instance models. The multi-tenant model can allow for commingling of cloud infrastructure for all customers, providing all customers with the same benefits when upgraded. The multi-instance model can be used at the application and persistence layers giving each customer data isolation and their own logical piece of the cloud service. Using this combination of techniques, the cloud provider builds a scalable service and the customer gets peace of mind knowing that invisible co-tenants do not have access to their data.

Allan Leinwand is VP and CTO and Tim Yim is senior infrastructure engineer of ServiceNow, an enterprise IT cloud company. 

Feature photo courtesy of Shutterstock user Boris Stroujko

  1. Although this is an interesting topic, I’m not really convinced that this article adds anything new to the debate.

    Reply Share
  2. Don Rittenhouse Monday, January 27, 2014

    Great commentary

    Reply Share
  3. Different customers have different needs and preferences. Multi-tenancy may be less expensive for customers and easier to update for the provider, while single tenancy gives certain customers a feeling of increased security (although maintaining multiple single tenancies seems to be more difficult for SaaS provider, thus more expensive for the customer. SaaS vendors are smart to offer both options.

    That being said, we’re always on the lookout for cloud/engineering/devops talent at Workday. You can check out our open jobs at https://bit.ly/workdaytech.

    Reply Share
  4. [MODERATOR: Please erase my prior comment and insert this edited version of the same comment]

    I. The analogy between an apartment building and a single family home may work well for marketing, but not for technical people trying to understand the differences here. For example, in an apartment building, can one have a 5,000 acre ranch? Multi-tenant does not imply uniform, or limited, provisioned features or resource limits, nor does it imply a restriction on custom tailoring. The vendor of course has to manage for the entire range of what capabilities are offered as part of its solution roadmap overhead, but this same overhead exists for all single-tenant SaaS vendors as well. However, these vendors also have to manage the complexity of customers on multiple versions of their solution at the same time, an additional overhead that grows with time, which is what is drove many of those same customers to the cloud in the first place.

    II. I have heard that single-tenant SaaS is synonymous with a rewrite of a traditional software platform on top of (OEMed) IaaS. This analogy makes a lot of sense to me.
    1. This explains why many single tenant SaaS solutions are also available on premise. Of course there are advantages to hosted cloud infrastructure, but that is only part of the benefit of cloud computing. One must look beyond the infrastructure layer and at the platform & App layers to discover where the bulk of the cloud advantages exist, at least to multi-tenant vendors and their customers.
    2. Customers get the partial advantage of elastic infrastructure (if they prefer not to host it themselves), but on top of a newer version of the on-premise architecture (all legacy SW was single premise as well) they are replacing. Obviously replacing a 20th century SW architecture with a 21st century SW architecture is an improvement, but merely offering the ability to host the infrastructure layer for the customer is not very far up the cloud maturity curve. ServiceNow customers who host their own solution are not benefiting from cloud computing at all. They are benefiting from a long overdue refresh of traditional ITSM platforms such as ARS. This is good, but let’s be clear; they must understand they will have a similarly increasingly costly upgrade process, especially as the years go by and the platform ages.

    III. Near the beginning of the article, we have this ominous note, “In the cloud, co-tenants are often invisible but often affect your occupancy even more”, but then nowhere in the article is this really addressed. There is of course no security disadvantage to multi-tenancy and the authors of course don’t attempt to prove there is. But sadly, the meme suggesting there in fact is a risk is repeated throughout this article. Let’s clarify: Co-mingled data has existed for a couple of decades over the Internet, yet few people today fear Internet commerce because of this mingling of data with their fiber optic “neighbors”. Unless a SaaS vendor’s employees without authorization can access customer data, directly via login or otherwise, then there is no logical difference between co-mingling of data over the Internet and co-mingled encrypted data stored in a data center since all Internet data can be recorded into a data center anyways, as the NSA does. If they have the key, then any traffic over the Internet is at risk from that breach point. If not, then there is no difference. The suggestion that data being stored in a nearby someone else’s in the storage array, or platter in the same array, or even on the same platter increases security risk is a chimera…and almost any CTO can tell you this.
    Yet we have a meme to bang the drum to…and so an ostensibly technical conversation (given the authors’ titles) is really a marketing article, and as I will point out, not the thought leadership type of paper. For example, we start with the fallacious key analogy in the Apt. building, suggesting over the Internet the single tenant customer has his data travelling over a separately wired private network and not the Internet, or in some other way is safer due to the data being stored one disk array (or platter) further away. To the IP hacker, everyone is a “neighbor” to everyone else. If there is data center security problems, the single tenant has no advantage over the shared tenants. As this is unpacked it boils down to “is your data encrypted effectively or not?”

    IV. “The downside for customers is that they may have customized their use of the cloud and the latest version will cause issues or come at an untimely moment for the business.”
    All SaaS vendors that didn’t/haven’t addressed this basic requirement early are either on their way out or gone already. All successful multi-tenant SaaS vendors have addressed this issue with admin controls for rolling out potentially high impact features and a very predictable roadmap published well in advance to its customers.

    V. Discussing the “advantages” of single-tenancy, “From the customer’s perspective, they are running their own cloud service and can customize it as they see fit.”
    Perhaps the author can explain why companies not specializing on SaaS solutions themselves would want to “run their own custom cloud service” instead of simply subscribing to it and tailoring it to fit their needs. However, the second point is erroneous one. All successful multi-tenant solutions provide a rich set of APIs and configuration so that …“Each homeowner can customize their property as long as it falls within the acceptable policies of the homeowner’s association.” Perhaps the author can clarify which multi-tenant solutions don’t offer APIs or customization capabilities; I don’t know of any beyond utility type consumer services like free email.

    VI. The last paragraph in that section again describes a requirement for SaaS providers in general, and is not helpful in understanding the differences between single & multitenancy. Get beyond the elastic infrastructure hosting and into what is going above that.

    VII.” Yet, what if a cloud service could be both a scalable multi-tenant environment and provide the benefits of a traditional single-tenant environment?”
    We have yet to hear what the advantage of single-tenant SaaS environment is. Perhaps the authors can elaborate because it is not increased security, nor is it the ability to customize or even to avoid high impact enhancements from trouncing on your existing solution. Without going into the downside of single-tenancy more thoroughly here out of courtesy, I’d like to know what the advantages are beyond the option to make the trade off for self hosting the infrastructure that I mentioned above, which is of course then not a Cloud/SaaS solution at all.

    VII. The last paragraph, while repeating the phantom security meme debunked in section III, above, adds nothing to the discussion about this topic. The infrastructure comments are misleading, perhaps not intentionally, as they are irrelevant to the topic being discussed. So are environmental snapshots that can be used to assist planned releases (either customer or vendor motivated). The authors leave us with no rational reason to believe single tenancy is superior to multi-tenancy, but does sadly dash my hopes that ServiceNow is going to modernize its architecture to a multi-tenant model and instead will attempt to duplicate data centers around release versions or some other heuristic, which means its run will be on a hybrid cloud/legacy architecture stack, likely to be as successful as ARS was for its two decade run, but not the low overhead modern cloud platform many currently believe it to be. To be fair to ServiceNow, it was likely too late to alter architectures and now they must put the best face on it they can.

    Reply Share
  5. Thanks for your comments CloudZen.

    You are correct stating that a multi-tenant design does not imply uniformity. That is the beauty of the design. Customers have allocated completely different levels of resources and the complexity to manage them does increase over time. The shift is; this complexity is now the responsibility of the cloud service provider, not the customer.

    Also, thank you for pointing out that we omitted a more technical explanation of how customers can affect one another in a shared environment. Perhaps we should have added a link to a more in-depth technical article stating the many technical aspects needing to be managed in addition to the customer’s security requirements. Running a multi-instance cloud service does require continual monitoring, engineering and innovation of the service to ensure that customers cannot affect each other across the infrastructure – although in this model there is still no commingling of data in the same database or memory structures.

    At ServiceNow, we feel that operating a multi-instance cloud platform has provided our customers with the flexibility they desire while the complex requirements of infrastructure management has been entrusted to us. A privilege which we take very seriously.

    Again, thank you for your comments and feel free to contact us directly if you would like more information.

    And, like our friends at Workday, we’re always looking for great talent to join our teams too!

    http://www.servicenow.com/company/careers/join-servicenow.html

    Reply Share