Expert insights: Why cloud architecture matters

Cloud technology is the essential infrastructure required to reach Singapore's Smart Nation's initiative's goal of hyperconnectivity. However, as corporations move to the cloud, a key decision must be made – choosing the right cloud architecture.

Choosing an enterprise cloud platform is a lot like choosing between living in a condominium or a landed property. Living in a condominium can offer conveniences and cost-savings on a month-by-month basis. You pay fees to the landlord to handle all ongoing maintenance and renovation projects — everything from fixing a leaky tap to installing a new central air-conditioning system. However, there are restrictions that prevent you from making customizations, and a fire that breaks out in another unit may threaten the safety of the entire building. On the other hand, you have more control and autonomy with a landed property. You have very similar choices to consider when evaluating cloud computing services.

There are two options available, multi-tenant (condominium) and multi-instance (landed property). The first public cloud computing services that went live in the late 1990s were built on a legacy construct called a multi-tenant architecture. Their database systems were originally designed for making airline reservations, tracking customer service requests, and running financial systems. These database systems feature centralized compute, storage, and networking that served all customers. As their numbers of users grew, the multi-tenant architecture made it easy for the services to accommodate the rapid user growth.

All customers are forced to share the same software and infrastructure. That presents three major drawbacks:

1. Data co-mingling: Your data is in the same database as everyone else, so you rely on software for separation and isolation. This has major implications for companies within the government, healthcare, and financial sectors who deal with highly sensitive content. A security breach to the cloud provider could expose your data along with everyone else co-mingled on the same multi-tenant environment.
2. Additional maintenance leads to excessive downtime: Multi-tenant architectures rely on large and complex databases that require hardware and software maintenance on a regular basis. 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. But that's becoming unacceptable for users who need enterprise applications to be operational at all times.
3. One customer's issue is everyone's issue: Any action that affects the multi-tenant database affects all shared customers. Your availability and upgrades are tied to all other customers that share your multi-tenancy. Entire organizations do not want to tolerate this shared approach on applications that are critical to their success. They need software and hardware issues isolated and resolved quickly, and upgrades that meet their own schedules.

With its inherent data isolation and multiple availability issues, multi-tenancy is a legacy cloud computing architecture that cannot stand the test of time. Multi-instance cloud architecture on the other hand, can solve the drawbacks of multi-tenancy.

1. True data isolation: multi-instance cloud architecture is not built on large centralized database software and infrastructure. Instead, it allocates a unique database to each customer. This prevents data co-mingling, simplifies maintenance, and makes delivering upgrades and resolving issues much easier because it can be done on a one-on-one basis.
2. Safeguards against hardware failures and other unexpected outages: The cloud provider actually deploys separate hardware and software stacks for each customer. There is some sharing of infrastructure pieces, such as network architecture, load balancers, and common network components. But these are segmented into distinct zones so that the failure of one or more devices does not affect more than a few customers. This enables the creation of redundancy at every layer. For example, at the internet borders, a vendor might have multiple border routers that connect to several tier- one providers on many different private circuits, direct connections, and on different pieces of fiber.
3. One's data loss will not result in your data loss: multi-instance, unlike multi-tenancy, does not run on a master file system that services all customers. You can scale out pieces of hardware — stack them on top of each other like LEGO blocks. Each block services no more than a few customers, so one hardware crash cannot affect all the blocks. And because replication is automatic, the secondary side is immediately accessible. This is extremely important for the approach to disaster recovery. Permanent data loss is a risk inherent to all multi-tenant architectures, making external disaster recovery sites no longer viable options. True, there are sites that a vendor can fall to if the active side fails. But they are only tested a few times a year and only used if an extreme situation arises. If that happens, they risk failing under load. When that happens, data is lost forever. That risk virtually disappears in a multi-instance environment.

When you partner with a cloud provider that bases its platform on a multi-instance architecture, you're moving into your own house. Your data is isolated, a fully replicated environment provides extremely high availability, and upgrades on the schedule you set, not the provider. Cloud architecture matters because you're in control, and better protected when disaster strikes.