Cloud computing -- Best practices for cloud SLA metrics

  • Home
  • Cloud computing -- Best practices for cloud SLA metrics

Error message

User warning: The following module is missing from the file system: cascading_grants_services. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1184 of /var/www/html/web/includes/bootstrap.inc).

ISO/IEC NP TR 23951

Cloud computing -- Best practices for cloud SLA metrics

SCOPE

In most cases, cloud service providers (CSPs) and cloud service customers (CSCs) negotiate service level agreements (SLAs) which include service level objectives (SLOs) and service qualitative objectives (SQOs) for which CSPs make commitments.. The commitments described in SLAs must be measured against actual performance of the service to ensure compliance with the SLA. How actual performance compares against commitments in SLAs, is explained in ISO/IEC 19086-2:2018[2] Metric model.  Cloud SLAs are covered in ISO/IEC 19086-1:2016[1] Service level agreement (SLA) framework Part 1:  Overview and concepts and in ISO/IEC 19086-4:2019[3] Security and privacy.
ISO/IEC 19086-2 Metric model establishes common terminology, defines a model for specifying metrics for cloud SLAs, and includes applications of the model with examples.  This document provides a primer on using the metrics model in 19086-2 to compose the calculation of a cloud service performance measure in order to compare against an SLA commitment. A few examples from the SLOs listed in ISO/IEC 19086-1 (Clause 10) are given in the document, such as Cloud Service Response Time Mean and Cloud Service Availability. As specific, measurable characteristics of a cloud service, SLOs are the basis for defining the metrics used to evaluate and compare agreements between parties.
In the second half of the document, a basic dissection of these examples is provided using a practical method based on a tabular format. This  format allows for a consistent usage of the model across practitioners such as:
- Extracting metric material from an SLA narrative and representing this content separately and unambiguously.
- Designing and representing a new metric definition.
Along with demonstrating this method on previous examples, some best practices are collected and reported.  These best practices also provide practical guidance on how to extend or complement the model when necessary, which is allowed by the 19086-2 Metric model standard but beyond its scope and non-normative.
The scope of this technical report is to describe a practical method for using ISO/IEC 19086-2 Metric Model.
 
Under development

WORKING GROUP
COMMITTEE / WG
WIKI WATCH

Insert here: activities, gaps, opportunities, and other user driven comments

  • WolfgangZiegler's picture

    Submitted by WolfgangZiegler on Wed, 06/12/2019 - 11:09

    Very valuable effort to bring forward Cloud SLAs. Quite a number of SLA metrics have been developed in various national and European projects in the last decade and could be contributed to this group. Probably a useful expert contribution would be gathering and including at least some of them before finalising the TR. A good source for these projects is the technical report on Cloud Computing Service Level Agreements, published by the European Commission July 2013. Online at https://ec.europa.eu/digital-agenda/en/news/ cloud-computing-service-level-agreements-exploitation-research-results.


    Like:
    +1
    0
    -1
  • apasic's picture

    Submitted by apasic on Fri, 07/05/2019 - 10:42

    It is a very useful effort with many practical examples. In relation to security and privacy it relies on ISO/IEC 19086-4 which in its turn has underlying privacy principles of the security and protection of PII components are described in ISO/IEC 29100. Given the importance and impact of GDPR on cloud computing in Europe, it is worth to consider new efforts, such as ISO/IEC JTC 1/SC 27/WG5 12 Month Study Period on a Privacy Engineering Model starting in April 2019 or ISO/IEC JTC 1/SC 27/WG 5 Six Month Study Period on a Consent Receipt and Record Standard started at the same time. Data access must be monitored to prevent breaches and noticing violations. Specific automated mechanisms must be implemented for solving it and notifying the incident to the affected users within 72 hours. Data owner also must enforce purpose limitation for held data. In H2020 project DITAS there is a work on technical means allowing involved parties to formulate and technically represent purpose-related restrictions, also to ensure that data communicated by an application is sent to a data source with requests being processed according to the specification of a data owner. It might be usefull starting point.


    Like:
    +1
    0
    -1

submit a comment

Back to the search results