Cloud Application Platform provider’s perspective

7.2 Demonstrating monitoring and analysis capabilities

7.2.1 Cloud Application Platform provider’s perspective

Primarily, the EXCLAIM framework is intended to support and enhance the CAP provider’s capabilities for platform governance, and therefore the provider is seen as the main stakeholder. We have already raised several issues the CAP provider might be concerned with. Among other things, one of the key challenges in the presence of numerous virtual tenants simultaneously accessing a common shared pool of cloud resources is to ensure that the amount of the underlying physical resources is sufficient. This underpins stable and undisrupted operation of the cloud services.

Given the motivation of the provider to minimise the amount of idle physical resources (for economic and ecological reasons), it is typically expected that physical servers are turned on and off dynamically in response to the ever-changing demands of the cloud platform consumers. In these circumstances, it is crucial for the cloud provider to be provisioned with a most recent overview of the overall resource consumption resulting from resource consumption of individual tenants. More specifically, let us focus on Heroku’s PostgreSQL data storage service, used by Destinator. When subscribing to this service, each subscriber is allocated a personal virtual space on a physical database server. Heroku aims at reduc- ing operational costs by minimising the total number of physical database server instances running at the same time. This is typically achieved by increasing the ‘tenant density’ (i.e., number of virtual tenants on each of the physical servers), and, following the principle of elasticity, launching additional database servers only in case the existing capacity is not enough. Accordingly, the CAP provider needs to measure disk space utilisation of individual virtual tenants with respect to the total available physical space in order to launch additional server if needed or ‘merge’ several already running, but idle servers.

First, the framework needs to measure disk space utilised by an individual instance of the PostgreSQL service couple with Destinator. The next step is to sum up the collected individual values to get an overall occupied amount of Post-

greSQL disk space by Destinator. Finally, this value needs to be evaluated against the rest of the disk space occupied by other instances of PostgreSQL connected with other applications (i.e., not Destinator) on Heroku. Thus, the framework will be in a position to decide whether there is still enough space for the PostgreSQL service or not.

Below, we illustrate how this kind of use case scenarios is handled by the EX- CLAIM framework to support cloud platform self-governance. The explanation is aligned with the three main steps, through which raw collected data is trans- formed as it passes through the EXCLAIM framework.

Triplification

The code snippet below (Listing 7.1) represents a stream, associated with the particular user instance of Destinator, to which all related RDF triples are sent. The snippet demonstrates how the disk space occupied by a PostgreSQL instance postgres-service-10changes with the time from 7,000 rows to 9,000 rows. Listing 7.1: RDF triples on the stream indicate database space, occupied by an individual service.