As a continuation to part I, unfortunately written more than a year ago, in this post we detail architectural approaches for cloud applications. We have created two tables below – one describes the database architecture for cloud applications, and the other describes the application architecture. Note, that we are distinguishing between the database architecture and the application architecture. In our view this is important. We often read multi-tenancy articles that just talk about the database and make no mention of the application architecture. Also, the architectures we list are both multi-tenanted and non multi-tenanted (especially on the application side), and represent architectural approaches we have encountered in dealing with many cloud providers. Recently, we have begun to hear from some providers that virtualization and reduced server costs eliminate the need for multi-tenant architectures. In our view this is incorrect. Furthermore, our own internal cost models developed for clients clearly show the need for multi-tenancy. We will release these models publicly at a later date. We will also share specific implementation details for many of the architectures in future posts.

Let’s start by clarifying some jargon. This not a complete set, but should be helpful while going through the tables below:

a.    Multi-tenancy – We already described this in part I.  But it is important to emphasize that multi-tenanted cloud applications are single instance. In very large and scalable cloud applications where SOA is the preferred architecture, each service in the system/application will be built as single instance and multi-tenanted.

b.     Configuration vs. Customization – It is generally believed that cloud applications are less customizable than standard on-site applications. They are considered configurable rather than customizable, a description we do not like. You will often see references to words like configuration and customization in marketing materials. In the context of cloud applications, we view configuration as changes made to the application by tenants that involve changing parameters/behavior, user interfaces, etc., pre-determined by the application provider.  On the other hand, by customization we mean features provided by cloud applications that allow tenants themselves to create new objects, write rules, code, new user-interfaces etc. A good example of this is Salesforce.com. Providing customization features in a single instance multi-tenanted application is a challenging effort, and has a significant impact on the application architecture and the cost of developing a cloud application. As cloud applications mature further, we anticipate more of them will offer customization facilities, which will in essence have the effect of creating domain specific Platforms as a Service (PaaS) or Industry Clouds.

c.   SQL vs. NoSQL – Architectural approaches we provide for the database below apply to relational (SQL) databases only. In our view, both SQL and NoSQL technologies are essential to solve the spectrum of problems associated with today’s cloud applications. If your application requires ACID then traditional RDBMS are the most optimal (cost & maturity) solution. Sharding will be the predominant choice to address scalability. If ACID is not a requirement then NoSQL is a good option. NoSQL databases scale better because the consistency requirement is relaxed. For applications where ACID is not a requirement, NoSQL databases provide one other advantage. They are schemaless; thus some major problems encountered in building RDBMS based multi-tenanted applications are eliminated.

Even in cases where ACID is not required, RDBMS can be used if the application is not aiming for very high scale. In our view, most organizations still opt for RDBMS to address the majority of their data persistence needs. Among the many reasons for this preference are skill availability (development and operations), technology maturity, standard query language (SQL), and choice of tools to address operations, analytics, reporting, adhoc queries, etc.

Architectural approaches to implement databases (Relational) for Cloud Applications

Type

Description

A

Shared Tables Among Tenants

This is the simplest multi-tenanted architecture. The data in each table is partitioned using a tenant-id property which allows for sharing of tables by tenants. For high levels of scaling the database is sharded.

Advantages

i.          Supports high number of tenants per database instance; thus lowering licensing, support, hardware infrastructure, and maintenance costs compared to type C, D & E approaches given below. Note: The number of tenants that can be consolidated on a single database is dependent on the type of application. For example, an email, ERP, or CRM application will vary in number of tenants per database.

ii.        Easier to develop, and lower development costs especially compared to Type B – another multi-tenant approach.

iii.       Application level maintenance issues like upgrades, bug fixes, etc. are comparatively easier to implement than Type C, D & E. Keep a note of the difference between application level and tenant level maintenance issues. See disadvantages below.

Disadvantages

i.          All tenants using the application will have the same schema. The schema is not extensible, so does not enable any tenant/customer customization.

ii.        Lower levels of isolation compared to Type C, D & E.

iii.       Needs a query abstraction layer to prevent any data leakage among different tenants. A good practice is to make sure that even your own developers do not see the tenant-id and can write queries without using the tenant-id. Also, as the application grows, query optimization is necessary for maintaining performance.

iv.        Tenant level maintenance operations like tenant backups, migration, restores etc. are difficult to implement. We want to emphasize that many operational issues for Cloud applications are best resolved at the the architecture/development level, and not just in operations.  Note: Customers, especially larger ones may insist that these operational issues be part of the SLA.For more details on SLA’s for the cloud we recommend reading “Practical Guide to Cloud SLA’s” by the Cloud Standards Customer Council. As a disclosure, Gurpreet, one of the authors of this blog contributed to multiple sections of the guide.  

B

Flexible Schema, Shared Tables

As the name suggests, in this multi-tenanted architecture, schemas are flexible and customizable by tenants. Multiple techniques exist to implement this architecture. As an example, one technique is to partition the tenant data using tenant id, and provide extension tables for extending/changing the tenant schema. Note that tenant schemas are logical schemas, and there is only one physical schema for all tenants. The extension tables are also shared among the tenants. Multiple approaches for implementing extension tables include pivot tables, sparse tables etc., each with its own pros and cons. As mentioned before, the number of tenants consolidated on a single database is dependent on the type of application.

Advantages

i.          Achieves high levels of consolidation of tenants on a single instance as well as enables customization capabilities at the tenant level.

ii.        Leads to lower licensing, hardware infrastructure and maintenance costs compared to types C, D & E.

iii.       Application level maintenance issues like upgrades, bug fixes etc. are comparatively easier than Type C, D & E.

Disadvantages

i.          Higher cost and complexity of development.

ii.        To simplify query writing, a query abstraction layer is necessary to hide the strategy used for schema extension. Furthermore, complex query and database optimization techniques are required to tune the database for performance.

iii.       A metadata driven architecture is needed in order to support simplified query writing, and a single code base that supports customization for tenants.

iv.        Tenant level maintenance operations – backup, restores etc. are difficult to implement.

v.         Lower levels of isolation compared  to Type C, D, E.

C

Multi-Schema, Private Tables

This is also multi-tenanted architecture. This architecture is easier to implement than type B above, and still allows customization at the tenant level. Data partitioning is achieved by creating separate physical schema for each tenant in a single database instance.

Advantages

i.          Provides one of the best isolation methods available, second only to a separate database instance(Type E).

ii.        Allows for data customization.

iii.       Tenant level maintenance operations like backup, restores etc. are easier to implement compared to A & B.

Disadvantages

i.          In order to support tenant customization with a single code base, a metadata driven architecture is required. This can be complex to develop.

ii.        Tables grow linearly with tenants, which may lead to performance degradation and scalability issues.

iii.       In general, lower number of tenants per database instance compared to Type A & B, thus higher costs per tenant.

iv.        Application level maintenance issues like upgrades, bug fixes, etc. are difficult due to multiple physical schemas.

D

Single Schema, Private Tables for Tenants

This is another type of multi-tenanted architecture. This is a special case where each tenant has a small number of private tables, but all tenants share the same physical schema. This architecture can be used when applications have shared data between tenants, and the tenants also have some private data. The single shared schema reduces the database overhead, and the private tables keep the non-shared tenant data private.

Advantages

i.          Supports data customization for tenants because each tenant gets their own private tables.

ii.        Better isolation than Type A and B but worse than C

Disadvantages

i.          Application needs a metadata driven architecture in order to support a single code base for all tenants.

ii.        Tables grow linearly with tenants. Achieves lower levels of consolidation of tenants on a single instance of database compared to Type A & B.

iii.       Tenant level maintenance operations like backup, restores etc. are difficult to implement.

iv.        Application level maintenance issues like upgrades, bug fixes, etc. are difficult due to tenant specific private tables.

E

Multi-Instance

Each tenant has a unique instance of the database. This is not a multi-tenant solution. The databases for each tenant can be on the same or different hardware. In most cases this is not a practical solution for implementing cloud applications.

Advantages

i.          Complete isolation of the tenant data.

ii.        Supports full customization of tenant’s data.

iii.       Database instance can be fined tuned to tenant needs.

iv.        Tenant level maintenance operations like backup, restores etc. are very easy to implement.

Disadvantages

i.          Application will need a metadata driven architecture in order to support a single code base for all tenants.

ii.        Higher OPEX costs. Achieves the lowest level of consolidation of tenants on a single instance of database,
hence the highest licensing, hardware, infrastructure and operational costs.

Type

Description

A

Single Instance (SI) Applications

In a single instance application all processes associated with the application are shared among the tenants. These processes can be on a single machine or multiple machines in a network.

Advantages

i.          Best utilization of CPU and memory.

ii.        Cost per tenant is much lower than other architectures. This is especially true once application operations have been automated. You can automate with other architectures also, but single instance will be the lowest cost to operate per tenant.

Disadvantages

i.          More costly and complex to develop and optimize compared to multi-instance applications.

ii.        Difficult to build if application customization per tenant is a requirement. Providers will have to develop a meta-architecture to enable tenant customization.

iii.       Lowest level of isolation between tenants.

B

Multi-Instance without Hardware Virtualization

Multi-instance without hardware virtualization is an architectural approach where a separate instance of the application is instantiated for each tenant on the same hardware without the use of virtualization. As a consequence, this leads to sharing of only the hardware and the OS, and not the rest of the software stack. This is not a multi-tenanted architecture.

Advantages

i.          Better levels of utilization (CPU/memory) than type C below, but not as good as Single Instance (Type A).

ii.        Since every tenant has their own application instance (has isolation), customization can be done without a need for a meta-architecture. But providers will face increased cost and complexity if they do not use meta-architecture to enable tenant customization.

Disadvantages

i.          Higher OPEX Costs and possibly higher CAPEX costs.

ii.        Each tenant requires different configuration.

iii.       Since tenants are sharing the hardware & OS only, tenants have lower levels of isolation but better than type A.

C

Multi-Instance using Hardware Virtualization

In Multi-Instance Virtualized architecture the entire stack above the hardware is replicated using virtualization to support an individual tenant. Therefore each tenant has a separate OS and application instance and only the hardware is shared. This is not a multi-tenanted architecture.

Advantages

i.          Better levels of isolation compared to A and B

ii.        Easier to manage and monitor compared to type B.

iii.       Simpler to develop the application.

iv.        Easy to customize by application developers.

Disadvantages

i.          Lower levels of CPU/memory utilization compared to A & B.

ii.        More resources required to manage the application and the infrastructure, i.e. higher OPEX costs, and possibly higher CAPEX costs. Cost comparisons between Type B & Type C are difficult to make, and will depend on the individual organization/application.

iii.       Requires additional software to manage the virtual machines.

Some Takeaways

In our experience among the many business variables that affect cloud application architectures, market size(scale) and customization needs of the tenants play an important role. As an example, if you are serving a large market (large number of tenants) where tenants have no customization needs, then from the tables above, type A architectures for both the database and the application is a good choice. If significant customization is needed by tenants, let us say for a Cloud ERP application, then the preferable architectural choice would be to develop or evolve towards type B on the database side while being single instance (Type A) on the application side. It may seem a little strange that we consider providing customization features to tenants as an important business variable. This is because there is a significant increase in development cost and complexity associated with providing tenant customization features in multi-tenanted cloud applications. Customers, especially larger enterprises are asking for more customization features, and needless to say these issues are important for providers to address.

On the other hand, if the market is small, providers can even choose a non multi-tenanted approach for their cloud application architecture. Type E for database, and Type B or C for application architectures from the tables above are good examples. The operational costs for these multi-instance solutions will be higher, but companies will save on development costs and reduce development risks. We do not recommend multi-instance approaches for cloud applications that will have a large numbers of tenants.

The examples we provide are by no way complete, but they should provide a foundation for selecting your cloud application and database architectures.