Resources for iAnywhere

Eric Farrar

Subscribe to Eric Farrar: eMailAlertsEmail Alerts
Get Eric Farrar via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Cloud Computing, SaaS Journal, Microservices Journal, Cloud Data Analytics


Isolated Customer Data: A Better Fit for the Cloud?

The heavy burden of database management has made massive, multi-customer databases the default choice for ISVs with SaaS apps

For all that global business has embraced cloud computing - welcoming its low cost, low barrier to entry and reduced IT burden - not everything about this architectural sea change is working out perfectly. Limitations in security and customization are a growing source of discontent for many current and prospective cloud customers.

The need to serve similar data for many customers usually shows up in hosted environments. And for the majority of providers the default approach to satisfy that requirement is an amalgamated, "multi-tenant" customer database.

Unfortunately, multi-tenant database architecture is inherently less data-safe than an isolated, per-customer approach. Concerns over trust prevent many organizations from adopting hosted applications. Not every organization is willing or able to accept the risk of letting its data reside in a shared repository. Beyond that, a shared database limits the way that providers can service their customers, forcing them to leave revenue on the table.

Is it time to rethink our default approach to data architecture in the cloud?

If it's been awhile since you've performed an objective assessment of your data isolation strategy, the answer is probably yes. Too many organizations settled on an architectural standard early on and stuck with it - paying little attention to subtle shifts in customer demand as the marketplace matured. Worse, they've often based this important decision primarily on what's convenient for the IT department, not what's most beneficial for the business at large.

The Case for Isolation
New ideas are steadily emerging about how best to service customers through the cloud and these are challenging the status quo. Robust data security and governance policy are two issues that have long been incompatible with shared databases. But businesses are also beginning to demand flexible service options and data schema customizations that cloud providers often simply can't accommodate.

Still, there are reasons why ISVs tend to prefer a multi-tenant database for their cloud applications. Foremost among these is reducing the management burden, an issue that will be discussed in detail later.

After management, data analysis is an oft-cited advantage of the shared database approach. With all the customer data in one large database, the application provider has a hassle-free way to analyze the data extensively for interrelationships. The data is imminently available for a broad range of business analytics purposes.

A shared database will also minimize hardware costs and make it easier to maximize the utilization of your server resources. Finally, for those ISVs that have been using multi-tenant architectures for years, there will be the additional benefit of familiarity and comfort, which can result in faster development time.

Isolated data architecture, on the other hand, can't provide the same level of simplicity that an amalgamated database can for data analysis. Data analysis is still possible, but it requires the additional step of creating an automated routine to extract the data you need from each database, anonymize it and aggregate it for your analysis. It's an inconvenience to be sure, but not a disastrous one.

More important, isolated data architecture has some notable advantages in the win column:

  • Security
    —Eliminates risk of data leakage
  • Governance
    —Simplifies audit process compliance
    —Makes it possible to comply with laws related to physical data storage boundaries
  • Customization
    —Introduces flexibility to customize databases on a customer-by-customer basis
    —Creates opportunities to provide premium services

Next we'll look at each of these benefits in more detail.

In shared databases, very massive and damaging data leaks can be caused by surprisingly trivial software bugs. By isolating each customer's data you virtually eliminate the risk of a competitive data breech. Data stored in disparate databases cannot be accidentally leaked. Even with an application-level error the worst that can happen is that the company's own information is leaked within the company. For many companies, especially large enterprises, a sense of security, control and ownership over the data is mandatory.

Many industries today are subject to rigorous standards (such as HIPPA and SOX for the health care and finance industries, respectively), and these standards often require a formal audit. The regulations are rarely specific about how to architect data stores but when it comes time to do the auditing, a shared database can make it difficult or impossible to present the data in a way that complies with auditors' demands. In some industries, isolation of data is mandatory, and customers will need to be able to show proof of their compliance.

Occasionally, customers are subject to strict limitations on where their data can be stored. These limitations can be internal or part of a regulatory requirement, but when ISVs can't guarantee that data will reside within the physical boundaries mandated by these policies, the sale is lost. In these cases, only a disparate, standalone database will satisfy the requirements. A globally distributed data center - the most common architectural choice for large multi-tenant hosted apps - is a non-starter.

When each customer has a disparate data store, the possibilities for customization and premium services are virtually limitless. For ISVs that may be looking for new ways to monetize their existing assets, premium services can be an exceptional source of accretive revenue. Obviously the types of premium services you might offer will vary based on the application and the customer but they can include:

  • Charging usage fees, by the month or the hour
  • Providing an option to query the database directly for reporting purposes
  • Providing an option for local backups, for added peace of mind
  • Adding custom tables to one customer's database without forcing the change on others
  • Adding custom indexes without negatively impacting other customers' performance

When considered across the whole spectrum of pros and cons, it quickly becomes clear that the benefits of isolation far outweigh the costs. Or does it? All of these disparate databases have to be managed.

The Management Dilemma
The benefit list for single-tenant data architecture is undoubtedly long. But for ISVs, many of whom are managing thousands of very similar databases, the entire debate can boil down to one issue: management. It's a universal truth that managing one thing is easier than managing many, and databases are no exception.

Sadly, with little or no tooling in existence to help providers manage the task of deploying changes to some databases but not others, for many ISVs the business advantages of isolated data architecture are moot. The cost to hire sufficient DBA expertise to manage all of the databases effectively would be extraordinary. The management burden trumps all other rationale.

Interestingly, not all ISVs agree with that logic. Familiarity seems to play a big role in how different data architects view the significance of the management dilemma. In a 2011 survey of North American and European ISVs conducted by Sybase, respondents who said that they already were in the habit of managing many disparate customer databases reported that single-tenant architectures eased management issues rather than making them more complex.

Regardless, the widespread use of multi-tenant databases means an uphill battle for hosted application providers as they adapt to new market pressure for more secure and flexible alternatives. Solving the management dilemma, by providing significant tools and automation for common processes such as provisioning new databases, would tilt the scale drastically in the opposite direction.

Such automation is hardly a pipe dream. Self-managing and self-tuning databases have existed for decades in niche and embedded environments. The prospect for a wider spectrum database solution that can make managing many databases as easy as managing one is very near. ISVs that are strategically prepared for the opportunity will reap a competitive advantage in the cloud marketplace of the future.

More Stories By Eric Farrar

Eric Farrar is a senior product manager at Sybase, an SAP company, working on the SQL Anywhere embedded database. He is focused on bringing the power of embedded database technology into the new world of the web, and cloud computing environments.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.