Cloud Computing: Database as a Service

In cloud computing we all know about Infrastructure as a Service, Software as a Service; similarly Database as a Service is emerging and is slowly becoming popular among cloud providers. This article is brief overview of database as a service.

Databases are widely used as the foundation of many enterprise applications. In most organizations, however, each project that uses a database acquires its own hardware and software and establishes its own hosting and support arrangements for the application. Consequently, there are often a large proliferation of servers and software within a given enterprise that perform the same task - provide database services for applications.

Modern databases have advanced in features and functionality to the point where they can be used to provide a larger, shared service to the enterprise as a whole. This shared service allows multiple applications to connect to a single database running on a cluster of machines. The applications are isolated from each other and explicit portions of the database processing power are allocated to each one - a high-use application would receive a larger portion of the processing power than a low-use application. This database-as-a-service (DBaaS) offering provides a number of benefits to large enterprise organizations:

• Higher availability
• Cost savings
• Better service through centralized management
• Reduced risk

Purpose and Benefits
In many enterprises today, each application development team architects, builds, and deploys each of the individual technologies that make up the application. In the case of databases, this means that each application development team deploys its own database for each application. A large enterprise may have thousands of individual database instances running on a variety of hardware; each configured separately and managed independently.

This article describes an alternate solution to the problem of providing database functionality to application developers: offering the database as a common, shared service to the enterprise as a whole. This architecture uses a pool of database computing resources that are shared across multiple applications. Rather than architecting, building, and deploying individual databases, application development teams simply connect the application to the centralized database service. This architecture delivers a number of benefits, including but not limited to:

• Higher availability - All participating applications immediately benefit from automatic failover. This is intrinsic to the service offering and does not have to be configured and managed individually per application. This puts high-availability in cost range of even low-budget projects-all applications get it "for free."
• Cost savings - By pooling hardware resources together and driving up efficiency, the overall cost to the business should be reduced. The more individual database servers currently being used, and the lower their overall utilization, the more savings can be realized. Modern databases also allow the use of many smaller, commodity servers in a cluster configuration, rather than a few large servers. Finally, there are software savings by the consolidation of database software licenses.
• Better service through centralized management - By centralizing the overall management, each development group does not have to hire its own database administrators. Administration and management is handled by full-time experts rather than part-time resources that are responsible for other tasks.
• Reduced risk - The whole environment is managed and support is available on request. In the decentralized model, support is often performed ad-hoc by a part-time team and may not be available at the time it is needed, nor with the expertise to solve the problem as soon as required.

The solution is not without risks, however. These include:

• Common point of failure - While not dissimilar to other existing shared points of failure (SAN, network, etc), the failure of the shared instance would affect all dependent applications.
• Failure to adopt - While a shared environment offers a number of desirable features, some simple conditions will need to be met that application owners might see as a barrier. For example, an application owner might decide they want control over the specific hardware used to host their application.
• Failure to recover costs - The thrust of this solution does involve trading many simple

implementations with a single sophisticated implementation. This sophistication will necessarily include some higher licensing costs and demand a high caliber of support. Without careful management and widespread adoption, this cost structure could outweigh the benefits.

Platform Types
In the current state characterized by the individual deployment of databases throughout the enterprise, each application development team is selecting the platform on which to run the database itself. While an enterprise might standardize on a particular hardware and software platform (e.g., an HP, Dell, or IBM server, running Oracle or SQL Server), these components are typically matched together in an ad-hoc way and may not reflect an optimal configuration.
By running database as a central service, the enterprise can optimize the compute density, manageability, and complexity of the hardware and software platform combination. The right components can be selected to deliver optimum performance at minimum cost. This can even be taken to the extreme of purchasing optimized database "appliances" such as Oracle Exadata systems.

Reference Architecture
As shown in Figure 1, the reference architecture has a number of different components and layers that implement a very robust database service offering. These are described in a bottom-up fashion.

Data network and SAN - This layer provides basic IP network connectivity to the system for users (application consumers) and also provides a network path to storage. In the case of the reference architecture, "SAN" may also refer to any storage networking technology compatible with the database solution (e.g., NAS, etc.).

OS and Servers - This layer provides the basic hardware and software system on which the database runs. Again, the choice of wording here is a bit arbitrary; the reference architecture would also allow optimized implementations that may not include a separate operating system, for instance.

Storage Management - This layer provides basic capabilities to manage database files in the storage pool.

Disaster Recovery - One goal of DBaaS is to increase the reliability and availability of the database functionality associated with all enterprise applications. By building the service centrally, we should be able to provide advanced functionality such as disaster recovery to individual applications "for free." The disaster recovery layer of the architecture implements data replication and mirroring to remote location for the purpose of recovery from total site failure.

Backup and Recovery - Similarly, the backup and recovery layer provides common backup and recovery services to all the data stored in the shared DBaaS implementation. All application data is automatically backed up automatically, simply by virtue of using the service rather than an ad-hoc database.

Clustering Software - The clustering software layer provides functionality that coordinates the activities of multiple physical hardware machines to create a larger shared cluster. This allows the DBaaS service to scale up and down as demand increases and decreases, using the horsepower of many individual machines to increase performance when required.

Database - The database layer represents the database software itself (SQL parser, query optimizer, execution engine, etc.). This is what we commonly think of as "the database."

Grid Management - The grid management layer allows DBaaS operators to manage the set of machines on which the DBaaS service runs. Machines can be added to the pool when load requires, or removed. The grid management software can also check on the health of individual machines.