This chapter is from the book
This chapter is from the book
This chapter is from the book
DBaaS—A Special Case of Cloud Computing
DBaaS is a very specific implementation of cloud computing. Now that we have defined cloud computing at a generic high level, let’s examine the characteristics that distinguish DBaaS.
To understand the principles of “database as a service,” it’s helpful to look at the terms database and service individually and then look at how they interact.
The Merriam-Webster online dictionary provides a definition of database that we are all familiar with: “a usually large collection of data organized especially for rapid search and retrieval (as by a computer).”
The term service is also one that we are familiar with. Merriam-Webster has quite a few definitions for this word, and following are some of the relevant ones that apply even in the specific case of DBaaS:
“The occupation or function of serving”
“The work performed by one that serves”
“A facility supplying some public demand” such as “telephone service” or “bus service”
But these definitions are generic in nature and context. The core concepts of the definitions still apply in terms of an IT infrastructure as well—but with a few context-sensitive tweaks. In this section, we further explore the meanings and implications of database and service.
First, just to be clear, the concept we are discussing is not called “Oracle database as a service”—it is just “database as a service.” Conceptually speaking, we can deploy DBaaS using Microsoft SQL Server, DB2, PostGres, MySQL, or Oracle. They are all software technologies that we can use to build and deploy DBaaS. The design and implementation of DBaaS includes choosing the underlying technologies that we use to implement the service. Oracle is a leader in database technology, and Oracle 12c focuses largely on feature sets, utilities, and functionality that enable cloud computing, making Oracle 12c a leading contender in terms of implementing DBaaS.
Now let us look at the service element of DBaaS. We must understand what services the end user expects and what components the provider must manage and maintain in order to deliver the expected services.
Let’s start with the end users’ expectations of DBaaS. Based on NIST’s definition of cloud computing, we take the generic expectations implied by “services” and frame them around DBaaS-specific expectations.
Resource Utilization—Usage Instrumentation and Self-Service
One of the fundamental concepts of cloud computing is to provide end users of the cloud service the capability to monitor cloud resource usage and consumption. Therefore, a good cloud service should provide end users visibility into their resource usage, analytics, and chargeback.
With DBaaS specifically, the cloud service should provide the functionality or self-service capabilities to view resource usage and consumption as it applies to databases. The resources would include CPU consumption, storage consumptions, backup service consumption, and network bandwidth consumption.
Broad Network Access
By its definition, a core component of a cloud service is network access, or bandwidth. The cloud service network should be accessible over multiple devices and heterogenous platforms.
From a DBaaS perspective, the focus is on the protocols, quality, and efficiency of network access to the database. Network access concerns are applicable from an application standpoint as well as from an administration and management standpoint.
Resource Pooling
The reason a cloud service provides resource utilization statistics and analytics is to allow end users to tune consumption specifically to their needs. Remember, in a cloud, all the resources come out of a pool. End users should therefore be able to request additional resources when needed and reduce resource allocation and usage as needed. Remember, a cloud service must be able to optimize resources across the entire platform and at the same time maintain performance and availability according to service level agreements (SLAs) between the provider and end user.
Consequently, the service provider must enable end users to provision and decommission resources as needed without having to request resource increases or reductions through the provider. Based on resource usage statistics and business needs, end users should be able to manage and administer all resources, including CPU, network, storage, and backups.
Multitenancy is a key construct of the implementation of any cloud service. The service provider supports multiple clients within a cloud solution. The type of the cloud solution (private, public, or hybrid) determines who the allowed clients (end users) are.
In a DBaaS environment, multitenancy means that the cloud solution supports multiple databases across multiple clients, and each client has one or more databases.
From a DBaaS perspective, the end users, as consumers of services, do not manage the availability of resources or capacity-related issues. These concerns fall under the service provider’s responsibility. The service provider must manage the resources at a holistic level across all the clients it supports.
However, there is a caveat here. The preceding statement is true as long as the end user requirements around security, privacy, and compliance are met. The provider has to ensure that the solution design meets the end user criteria.
Rapid Elasticity
Rapid elasticity is the logical next step and evolution of resource pooling. The cloud solution must be able to dynamically allocate or deallocate resources as requested by the end user. The service provided includes the ability to dynamically add or remove resources based on workload volume and nature. In other words, the solution needs to be adaptive and flexible to adjust resource requirements on the fly.
Measured Service
The culmination of all of the preceding concepts of resource usage intrumentation, pooling, and elasticity is the ability to measure resources across an entire service and at each individual cloud subscriber level. Therefore, resource usage should be monitored, controlled, and reported upon, providing transparency for both the provider and the consumers of the utilized service.
Another way to put this is that the cloud solution is based on multitenancy—multiple clients being supported from a single cloud solution, which leads to the question of who should be charged for resources. Obviously, the cost should be based on what resources are actually used. In other words, the cloud solution must be able to support chargeback capabilities. The chargeback can be based on what is provisioned or, more popularly, on what resources are actually used.