Capacity Planning for PaaS

As I previously explained in my last two posts about Capacity Planning for SaaS, if you offer  Software as a Service, the capacity plan should be conducted from the application/software layer to the base hardware layers (i.e. servers, storage, network, Data Center Facilities, etc.). However, for PaaS, the biggest challenge is the distrobution of the workload. On top of what may be covered in IaaS, you can also offer database, application server, etc. for an unknown number of applications.


The hardest part of a PaaS is the design of the database layer. If you have a multi-tenant environment, what kind of isolation should you provide in your PaaS environment?

     There are two possible approaches:

    1. Use a full virtualization strategy where the database is installed in a virtual machine
    2. Use isolation promoted by instances, where the database runs on top of the operating system and accesses the hardware by directly relying on database capability to isolate each instance.

For each approach, there are pros and cons, which are summarized below:

Full   virtualization

Isolated   by Instances

User has complete access to database configurations

User has access only to table and permissions associated with the instance

Upgrade database with no impact on neighbor applications

Can only upgrade when all application associated can support the new   version

Compute resources can be directly associated with user’s database –   no direct concurrence

Compute resources will be shared among instances in the same database

Highest impact on latency – maybe prohibitive for highly OTLP   environment

Lowest impact on latency – recommended for highly OLTP environment

Backup/restore can be promoted by VM snapshot

Backup/restore should be applied individually to each instance

High availability promoted by hypervidor

High availability promoted by database cluster capability

From a management standpoint, full virtualization brings a lot of benefits for an administrator. It is much easier to provision, upgrade, backup and restore in a multi-tenant environment. However, as I explained in a previous post about database virtualization, the penalty for a high OLTP application can destroy the performance application. In some cases, it can even increase the number of locks in a database, especially those that are highly normalized.

Based on the actual state of performance for a highly OLTP environment in a virtualized environment, it would be a good idea to also offer in a PaaS. The possibility to run a database isolated by instances creates a database grid layer. It can be costly for most of the applications, such as development, homologation, small OLAP databases, etc. However, so far it is the best approach for highly OLTP applications.

Similar to many others scenarios, there is no “one size fits all” model. But for a PaaS, you should at least deliver a scalable platform that can support a wide range of database requirements. You never know what kind of application must be supported in the environment.

A good approach to identify if a database is the bottleneck of application performance is by running the application under a heavy load. It can be on fire or under a load generator. See if the transactions and CPU consumptions scale in the same pace; if transaction increases to a point where you still see low CPU usage, it is a good sign that something blocks the transaction.

In most cases, external calls such as database can be problem. Start to look for database optimization, like indexes, contentions in queries, recompilations of store procedures, the nature of how the application makes external calls, etc. If nothing improves, put the database in a dedicated machine and see if that solves the problem. If it does solve the problem, the PaaS architecture is not good to host OLTP applications, and you may run into trouble.

Best Regards!

-Bruno Domingues