This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
The first public cloud services went live in the late 1990s using a legacy construct called a multi-tenant architecture, and while features and capabilities have evolved, many cloud services are still based on this 20th century architecture. That raises serious questions about how legacy clouds prepare for calamity. While all architectures are susceptible to hardware failures and other issues that cause outages, the clouds that use a multi-instance architecture can better minimize the impact of an outage.
Multi-tenant cloud computing platforms are built using a centralized database system for all customers. This architecture was originally designed for making airline reservations, tracking customer service requests and running financial systems. As the number of customers in a multi-tenant cloud grew, a centralized database made it easy for cloud service providers to maintain the systems and to accommodate the user growth. But, what is best for the cloud service provider is not always best for the enterprise customer. A major problem is that all customers are forced to share the same centralized infrastructure.
That presents three major drawbacks:
1) Data commingling: Your data is in the same database as everyone else, so you rely on software for separation and isolation. This has major implications for government, healthcare and financial customers who are highly regulated and need clear separation of data. Further, a security breach to the cloud provider could expose your data along with everyone else commingled on the same centralized database in the multi-tenant environment.
2) Excessive maintenance leads to excessive downtime: Multi-tenant architectures rely on large and complex databases that require hardware and software downtime for maintenance on a regular basis, resulting in availability issues for customers. Some departmental applications used by a single group, say sales or marketing, can tolerate weekly downtime after normal business hours or on the weekend. But there are a growing list of enterprise applications that need to be operational as close to 24x7x365 as possible.
3) One customer’s issue is everyone’s issue: 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. Enterprise customers do not want to tolerate this shared approach on applications that are critical to their success. They need their availability issues isolated and resolved quickly regardless of other enterprises that may be affected and they want to perform upgrades that meet their own operational schedules.
Sign up for CIO Asia eNewsletters.