Multi-Instance vs. Multi-Tenant Architecture
The cloud is part of everything we do. It’s always there backing up our data, pictures, and videos. To many, the cloud is considered to be a newer technology. However, cloud services actually got their start in the late 90s when large companies used it as a way to centralize computing, storage, and networking. Back then, the architecture was built on database systems originally designed for tracking customer service requests and running financial systems. For many years, companies like Oracle, IBM, EMC and Cisco thrived in this centralized ecosystem as they scaled their hardware to accommodate customer growth.
Unfortunately, what is good for large enterprises, does not typically translate to a positive experience for customers. While the cloud providers have the advantage of building and maintaining a centralized system, the customers must share the same software and infrastructure. This is known as a multi-tenant architecture, a legacy system that nearly all clouds still operate on today.
Here are three major drawbacks of the multi-tenant model for customers:
- Commingled data – In a multi-tenant environment, the customer relies on the cloud provider to logically isolate their data from everyone else’s. Essentially, customers and their competitors’ data could be commingled in a single database. While you cannot see another company’s data, the data is still not physically separate and relies on software for separation and isolation. This has major implications for government, healthcare and financial regulations, and not to mention, a security breach that could expose your data along with everyone else.
- Excessive maintenance and downtime – 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. While some departments can experience downtime in the off hours such as sales or marketing, enterprise applications that are used across the entire enterprise need to be operational nearly 100 percent of time. Ideally, enterprise applications should not experience more than 26 seconds of downtime a month on average. They simply cannot suffer the excessive maintenance downtime of a multi-tenant architecture.
- All are impacted – In a multi-tenant cloud, any action that affects the multi-tenant database such as outages, upgrades, or availability issues affect all those who share that multi-tenancy. When software or hardware issues are found on a multi-tenant database, it causes an outage for all customers. The same goes with upgrades. The main issue arises when this model is applied to run enterprise–wide business services. Entire organizations cannot tolerate this shared approach on applications that are critical to their success. Instead, they require upgrades done on their own schedule for planning purposes and for software and hardware issues to be isolated and resolved quickly.
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. To embrace and lead today’s technological innovations; companies need to look at an advanced cloud architecture called multi-instance. A multi-instance architecture provides each customer with their own unique database. Rather then using a large centralized database, instances are deployed on a per-customer basis, allowing the multi-instance cloud to scale horizontally and infinitely.
With this architecture and deployment model come many benefits, including data isolation, advanced high availability, and customer-driven upgrade schedules.
Here’s a closer look at each of these areas:
- True data isolation – In a multi-instance architecture, each customer has its own unique database making sure their data is not shared with other customers. A multi-instance architecture is not built on a large centralized database, instead, instances are deployed on a per-customer basis, making hardware and software maintenance easier to perform and issues can be resolved on a customer-by-customer basis.
- Advanced high availability – Ensuring high availability of data and achieving true redundancy is no longer possible through legacy disaster recovery tactics. Multiple sites being tested infrequently and used only in the most dire of times, is simply not enough. Through multi-instance cloud technology, true redundancy is achieved with the application logic and database for each customer instance being replicated between two paired, yet geographically separate data centers. Each redundant data center is fully operational and active resulting in almost real-time replication of the customer instances and databases. Coupling a multi-instance cloud with automation technology, the customer instances can be quickly moved between each data center resulting in high availability of data.
- Customer-driven upgrades – As described above, the multi-instance architecture allows cloud Service Providers to perform actions on individual customer instances, this also includes upgrades. A multi-instance cloud allows each instance to be upgraded on a schedule that fits compliance requirements and the needs of individual customers.
When it comes down to it, the multi-instance architecture clearly has significant advantages over the antiquated multi-tenant clouds. With its data isolation and a fully replicated environment that provides high availability and scheduled upgrades, the multi-instance architecture puts customers in control of their cloud.
By Allan Leinwand
Allan Leinwand is chief technology officer at ServiceNow , the enterprise cloud company. 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 responsible for all aspects of technology infrastructure used in the delivery of Zynga’s social games including data centers, networking, compute, storage, content distribution and cloud computing.
Previously, Leinwand was a venture partner for Panorama Capital, LLC where he focused on technology investments in data networking, open source software and cloud computing. Prior to this role, he served as an operating partner at JPMorgan Partners.
Leinwand currently serves as an adjunct professor at the University of California, Berkeley where he teaches on the subjects of computer networks, network management and network design. He holds a bachelor of science degree in computer science from the University of Colorado at Boulder.