Cloud computing

In order to promote the wide spread adoption of OVF it is important that software vendors have confidence in the ability to build an OVF that can be deployed on a set of target virtualization platforms (aka hypervisors). To this end it is useful to define additional constraints and requirements on the OVF package to enable automated deployment and portability. Interoperability, i.e., the ability to be deployed on target virtualization platforms, is also enhanced.
The Open Virtualization Format standard defines conformance requirements, but these are not sufficient for the use cases that this specification addresses. Conformance can be done by inspection, checking for the ovf:required tag in the OVF and noting the conformance level as specified in the standard.
Software developers need guidelines for what needs to be included in each section of the environment file to ensure that a deployment function is capable of deploying the OVF.

This document makes use of the common meta-model used by CADF, the Cloud Audit Data Federation to describe the events used by the OpenStack Cloud Management Platform.
 
The document DSP0262 defines the CADF model.

Concerns over cloud provider security remain one of the top inhibitors to adoption of cloud deployment models. Potential consumers of cloud deployments need assurance that the security policies they require on their applications are consistently managed and enforced “in the cloud” as they would be in their enterprise.
A cloud provider’s ability to provide specific audit event, log, and report information on a per-tenant and application basis is essential. It is apparent that in order to meet these customer expectations, cloud providers must provide standard mechanisms for their tenant customers to self-manage and self-audit application security that includes information about the provider’s hardware, software, and network infrastructure used to run specific tenant applications.
A proven method to address such needs is to develop open standards to enable information sharing. Specifically, this specification provides a data format and interface definitions that support the federation of normative audit event data to and from cloud providers in the form of customized reports and logs. This specification also defines a means to attach domain-specific identifiers, event classification values, and tags that can be used to dynamically generate customized logs and reports for cloud subscribers or customers.
Adoption of this and other open standards by cloud providers’ management platforms would go far to instill greate trust in “cloud hosted applications” and be a significant step forward in fulfilling the promise of an open cloud marketplace.

The Open Virtualization Format (OVF) Specification describes an open, secure, efficient and extensible format for the packaging and distribution of software to be run in virtual systems. The OVF package enables the authoring of portable virtual systems and the transport of virtual systems between virtualization platforms. This version of the specification (2.1) is intended to allow OVF 1.x tools to work with OVF 2.x descriptors in the following sense:

• Existing OVF 1.x tools should be able to parse OVF 2.x descriptors.
• Existing OVF 1.x tools should be able to give warnings/errors if dependencies to 2.x features are required for correct operation.

If a conflict arises between the schema, text, or tables, the order of precedence to resolve the conflicts is schema; then text; then tables. Figures are for illustrative purposes only and are not a normative part of the standard.

A table may constrain the text but it shall not conflict with it.

The profile conforms to the cited CIM Schema classes where used. Any requirements contained in the cited CIM Schema classes shall be met. If a conflict arises the CIM Schema takes precedence.
The profile conforms to the cited OVF XML Schema. It may constrain the schema but it shall not conflict with it. If a conflict arises the OVF XML Schema takes precedence.
 
This standard is also published as ISO/IEC 17203:2017

This document makes use of the common meta-model used by CIM, the Common Information Model to describe the CIMI logical model. This is defined in DSP004, CIM Infrastructure Specification 2.7.

Transformation of the CIMI CIM into CIM metamodel conformant representations enables access of the services defined by CIMI in CIM-based environments. Such environments encompass a broad range of supported operating systems, languages, platforms, protocols, and other technologies.

This specification describes transformations in a manner that enables any CIM metamodel conformant representation. This document will utilize MOF for examples of such transformations.

The DSP0263 specification describes the model and protocol for management interactions between a cloud Infrastructure as a Service (IaaS) Provider and the Consumers of an IaaS service. The basic resources of IaaS (machines, storage, and networks) are modeled with the goal of providing Consumer management access to an implementation of IaaS and facilitating portability between cloud implementations that support the specification. This document specifies a Representational State Transfer (REST)-style protocol using HTTP. However, the underlying model is not specific to HTTP, and it is possible to map it to other protocols as well.  

CIMI addresses the management of the life cycle of an infrastructure provided by a Provider. CIMI does not extend beyond infrastructure management to the control of the applications and services that the Consumer chooses to run on the infrastructure provided as a service by the Provider. Although CIMI may be to some extent applicable to other cloud service models, such as Platform as a Service (PaaS) or Storage as a Service ("SaaS"), these uses are outside the design goals of CIMI.

Blockchain technology has the potential to have a major impact on how institutions process transactions and conduct business.
 
Blockchain technology provides a secure transaction ledger database through a decentralized network. It has the potential to reduce operational costs and friction, create transaction records that are secure and immutable, enable transparent ledgers with nearly instant updates, and open up new opportunities for growth.
 
This whitepaper introduces basic blockchain concepts that define a standard reference architecture that can be used in creating blockchain applications.
 
Sections of the paper include:

• Blockchain fundamentals
• Key characteristics of a blockchain network
• Blockchain reference architecture capabilities
• An example supply chain scenario using the Hyperledger Fabric blockchain implementation
• Cloud deployment considerations
• Specific examples of blockchain applications

The Impact of Cloud Computing on Healthcare was written to help enterprise information technology (IT) and business decision makers of the healthcare industry as they analyze and consider the implications of cloud computing on their business.
 
This guide contains guidance and strategies to help decision makers evaluate and compare cloud computing offerings from different providers, taking into account requirements from various actors including medical practices, hospitals, research facilities, insurance companies and governments. The paper covers current market dynamics, challenges and benefits of cloud computing on healthcare IT.
 
Throughout the paper, the role that management and IT standards play to improve the flexibility, interoperability and portability of cloud computing environments is highlighted.
 
Topics covered in detail:

• Key factors influencing cloud computing adoption in the healthcare industry, the barriers to address, and considerations for service and deployment models
• Specific IT trends in the healthcare industry that are addressed most effectively, both technically and economically, by cloud computing as opposed to traditional IT environments
• Cloud computing services for healthcare currently available that provide substantial benefits to healthcare organizations and patients
• The planning process for migrating healthcare IT systems and applications to the cloud
• Recommendations for how best to achieve the benefits of cloud computing while maintaining an acceptable level of risk

The mission of the Distributed Tracing is to define standards for interoperability between tracing tools.
Modern cloud-native applications are highly distributed and often span multiple technology and vendor boundaries. The complexity of these applications requires a detailed understanding of how individual requests are executed. This is referred to as "tracing".
Tracing tools for collecting this information have been available for quite some time. However, these tools have not been built with interoperability in mind. This leaves the developer with a number of challenges in getting an end-to-end trace of complex transactions:

• Traces are often broken, because trace context information is lost in a contributing tier or the trace is restarted
• Vendors cannot pass proprietary information across tiers instrumented with a different implementation and therefore lose relevant information (e.g. step count, server information, ...)
• End users don't have the ability to create complete end-to-end traces of application transactions which are monitored by different tools, as there is no defined data format and semantics for trace data

The scope of this working group is the definition of data formats and headers enabling the propagation and correlation of tracing data across different implementations.

The TOSCA Simple Profile in YAML specifies a rendering of TOSCA which aims to provide a more accessible syntax as well as a more concise and incremental expressiveness of the TOSCA DSL in order to minimize the learning curve and speed the adoption of the use of TOSCA to portably describe cloud applications.
 
This proposal describes a YAML rendering for TOSCA. YAML is a human friendly data serialization standard (http://yaml.org/) with a syntax much easier to read and edit than XML. As there are a number of DSLs encoded in YAML, a YAML encoding of the TOSCA DSL makes TOSCA more accessible by these communities.
 
This proposal prescribes an isomorphic rendering in YAML of a subset of the TOSCA v1.0 XML specification ensuring that TOSCA semantics are preserved and can be transformed from XML to YAML or from YAML to XML. Additionally, in order to streamline the expression of TOSCA semantics, the YAML rendering is sought to be more concise and compact through the use of the YAML syntax.

Cloud computing can become more valuable if the semi-automatic creation and management of application layer services can be ported across alternative cloud implementation environments so that the services remain interoperable. This core TOSCA specification provides a language to describe service components and their relationships using a service topology, and it provides for describing the management procedures that create or modify services using orchestration processes. The combination of topology and orchestration in a Service Template describes what is needed to be preserved across deployments in different environments to enable interoperable deployment of cloud services and their management throughout the complete lifecycle (e.g. scaling, patching, monitoring, etc.) when the applications are ported over alternative cloud environments.

The OASIS TOSCA TC works to enhance the portability of cloud applications and services across their entire lifecycle. TOSCA will enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown)--independent of the supplier creating the service, and any particular cloud provider or hosting technology. TOSCA will also make it possible for higher-level operational behavior to be associated with cloud infrastructure management.
 
By increasing service and application portability in a vendor-neutral ecosystem, TOSCA will enable:

• Portable deployment to any compliant cloud
• Smoother migration of existing applications to the cloud
• Flexible bursting (consumer choice)
• Dynamic, multi-cloud provider applications