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.
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.
The multi-instance cloud architecture is not built on large centralized database software and infrastructure. Instead, it allocates a unique database process to each customer. This prevents data commingling, simplifies maintenance, and makes delivering upgrades and resolving issues much easier because it can be done on a one-on-one basis. It also provides safeguards against centralized hardware failures and other unexpected outages across multiple customers at the same time that a multi-tenant system cannot.
The most advanced multi-instance cloud providers are able to replicate application logic and database for each customer instance between two paired and geographically diverse data centers. Data replication can be done in near real-time with each side of the paired data centers fully operational and active. The use of orchestration and automation technology can quickly move customer instances between these replicated data center pairs. This architecture is deployed on a customer-by-customer basis thus eliminating the need for a disaster-recovery site – in a multi-instance cloud built in this manner you have two paired locations that are both always active.
It’s important to emphasize that multi-instance is not the same as single-tenant, where the cloud provider actually deploys separate hardware and software stacks for each customer. Like muti-tenant, there is some sharing of infrastructure pieces, such as network architecture, load balancers and common network components. But these are often segmented into distinct zones so that the failure of one or more devices does not affect a large set of customers.
Choosing an enterprise cloud platform is a lot like choosing a place to live. You could move into an apartment or condo building with a bunch of other people, or into a single-family house. At first, apartment living may seem like the more convenient and cost-effective option. You pay the landlord rent every month, relieving you of the responsibilities for on-going maintenance and upkeep. But you will soon discover that freedom is actually a collection of restrictions that prevent you from making any customizations. And a fire that breaks out in a single apartment is always a threat to destroy the entire building.
The multi-instance architecture provides the benefits of moving to a house. It follows the same approach enterprises use to run their mission-critical applications – with data isolated, a fully replicated environment that provides extremely high availability, and upgrades on a schedule it sets. In short, cloud architecture matters because it’s what enables a vendor to be highly available and to handle a sudden calamity - or not.