Why Cloud Architecture Matters: The Multi-Instance Advantage over Multi-Tenant

Not all clouds are created equal – and the key difference for The Enterprise Cloud is a superior architecture.

Nearly all clouds today – except ServiceNow — are built on a legacy construct called a multi-tenant architecture. The ServiceNow cloud is built on an advanced architecture called multi-instance.

In this second blog of my Enterprise Cloud series, I’ll explain the difference between these two architectures and why the ServiceNow multi-instance cloud is the only architecture that changes how an enterprise company gets work done.

When the first cloud services went live in the late 1990s, the architecture was built on database systems originally designed for making airline reservations, tracking customer service requests and running financial systems. These database systems were built on centralized compute, storage and networking that served all customers. These cloud services scaled their hardware to accommodate customer growth while companies like Oracle, IBM, EMC and Cisco thrived in this ecosystem.

In these multi-tenant clouds, many of which are still using this same architecture today, customers share the same software and infrastructure. While the cloud provider gains the advantage of building and maintaining a centralized system, there are three major drawbacks of the multi-tenant model for their customers:

1) Your data is commingled. You rely on the cloud provider to logically isolate your data from everyone else’s data. The data of your direct competitor could be commingled with yours in the single database. Commingling doesn’t mean you can see another company’s data; access to the multi-tenant environment is controlled. But all the same, your data is not physically separate and relies on software for separation and isolation. This has major implications for government, healthcare and financial regulations. Further, a security breach to the cloud provider could expose your data along with everyone else commingled on the same multi-tenant environment.

2) Multi-tenant architectures rely on large and complex databases that require hardware and software maintenance on a regular basis, resulting in availability issues for customers. Departmental applications in use by a single group, such as the sales or marketing teams, can tolerate weekly downtime after normal business hours or on the weekend. For example, Salesforce, a large multi-tenant architecture, takes their customers offline for 21.6 hours a month for regular maintenance. Enterprise applications that are used across the entire enterprise need to be operational as close to 24x7x365 as possible. The ServiceNow goal is 99.999% or less than 26 seconds of downtime a month on average. We have this goal because we know that enterprise applications cannot suffer the excessive maintenance downtime of a multi-tenant architecture.

3) Any action that affects the multi-tenant database affects all shared customers. When software or hardware issues are found on a multi-tenant database, it causes an outage for all customers, and an upgrade of the multi-tenant database upgrades all customers. Your availability and upgrades are tied to all other customers that share your multi-tenancy. The big problem arises when this model is applied to run enterprise–wide business services. Entire organizations do not tolerate this shared approach on applications that are critical to their success. They need software and hardware issues to be isolated and resolved quickly and to upgrade on their own schedule for planning and compliance reasons.

With its inherent data isolation and multiple availability issues, multi-tenancy is a legacy cloud computing architecture that will not stand the test of time.

Enter the Multi-Instance Cloud

In contrast, a multi-instance architecture gives every customer its own unique database, which means that it is impossible for your data to be commingled with any other customer. The multi-instance architecture is not built on large centralized database software and infrastructure. Instead, we deploy instances on a per-customer basis, allowing the multi-instance cloud to scale horizontally and infinitely. For our multi-instance cloud, we deploy separate application logic (Apache Tomcat Java Virtual Machines) and database processes (MySQL) for every customer.

Each customer instance is a unique software stack and this means that, unlike some competing platforms, there is no 70-page document of restrictions and limitations. Your instances in our cloud are for your enterprise and your business needs. With this architecture and deployment model comes a wealth of benefits; true data isolation, advanced high availability and customer-driven upgrade schedules. Let’s look at these areas more closely.

  • True data isolation: This makes hardware and software maintenance on these unique customer instances far easier to perform and issues can be resolved on a customer-by-customer basis. Unlike a multi-tenant architecture, customers are not grouped together in a shared database.
  • Advanced high availability: With our multi-instance cloud, we are able to move customers individually out of harm’s way for routine maintenance and unexpected issues. The application logic and database for each customer instance in our cloud is replicated between two paired and geographically diverse data centers in each of our eight regions around the world. The replication of each individual customer instance and database process is done in near real-time with each side of the paired data centers fully operational and active – we do not build disaster recovery sites that are only tested a few times a year and only used in extreme situations. With our multi-instance architecture and replication your application logic and database is active in two geographically diverse locations at the same time. We also deploy our own automation to quickly move customer instances between these replicated data center pairs, something we call advanced high availability. This whitepaper explains how ServiceNow advanced high availability works in detail. Because of our multi-instance architecture and the ability of our advanced high availability to quickly move individual customers, our cloud plans for a maximum of only six hours of maintenance per quarter, or two hours per month, but we often do not need this maintenance time. We regularly achieve better than 99.995% availability for our customers.
  • Customer-driven upgrades: As we described above, the multi-instance architecture allows us to perform actions on individual customer instances, such as performing an upgrade. Each individual instance can be upgraded on a schedule that fits the compliance requirements and needs of the enterprise.

In short, the multi-instance architecture puts our customers in control of their cloud. This is how the enterprise runs their mission-critical applications – with data isolated, a fully replicated environment that provides extremely high availability and upgrades on their schedule. This is why we’ve invested heavily in advancing our cloud architecture and know that the multi-instance architecture gives our customers many advantages over antiquated multi-tenant clouds.

In my next blog I’ll explore the topic of availability to give you another dimension of what ServiceNow means by The Enterprise Cloud.

mm
Allan Leinwand
Allan Leinwand has built a reputation for managing the world’s most demanding clouds – in B2B and B2C. He is the chief technology officer at ServiceNow responsible for building and running the ServiceNow Enterprise Cloud – the second largest enterprise cloud computing environment on the planet. In this role, he is responsible for overseeing all technical aspects and guiding the long-term technology strategy for the company. Before joining ServiceNow, Leinwand was chief technology officer – Infrastructure at Zynga, Inc. where he was focused on building one of the largest consumer cloud computing environments used in the delivery of the company’s social games to more than 80 million players daily. He got his start as a cloud pioneer at Cisco before “cloud computing” was a term and the idea of accessing applications from anywhere was still very new. In addition to expertise in running large enterprise cloud computing environments, he also provides expertise in software engineering, quality engineering and product-market fit to companies including Spoke, Inc.; Bulletproof 360, Inc.; MapAnything, Inc.; Founders Circle Capital; and Kleiner Perkins Caufield & Byers. He is a Board member of Marin Software. Leinwand has served as an adjunct professor at the University of California, Berkeley where he taught computer networks, network management and network design. He holds a bachelor of science degree in computer science from the University of Colorado at Boulder.

4 Responses to “Why Cloud Architecture Matters: The Multi-Instance Advantage over Multi-Tenant

  • Completely agree that multi-instance is the better model. The challenge with multi-instance is management, since you might have to manage thousands if not more service instances (rather than just the one multi-tenant instance). Better orchestration tools are required to instantiate and manage individual instances but when these tools catch up, multi-instance will not only be significantly more secure but also much cheaper to operate.

  • Hi Chris – we completely agree that a challenge with multi-instance could be the management of the environment. It is clearly easier for a cloud service provider to manage a multi-tenant environment. We are focused on the customer benefits of the multi-instance architecture, not on reducing complexity for us as a cloud service provider. And, fortunately, we have an amazing workflow, automation and orchestration platform that we use to manage our multi-instance cloud called ServiceNow 🙂

  • Hmm! Just read article. How do you scale multi-instance cloud for million customers? If we need to upgrade, how does it work.

Trackbacks & Pings

Leave a Reply Text

Your email address will not be published.

Shares