This is the minimum set of information that is expected in a service definition (suppliers may choose not to provide these aspects of a service, but do need to be clear in their service definition that they don’t).
- An overview of the G-Cloud Service (functional, non functional)
- Information assurance – Impact Level (IL) at which the G-Cloud Service is accredited to hold and process information
- Details of the level of backup/restore and disaster recovery that will be provided
- On-boarding and Off-boarding processes/scope etc.
- Pricing (including unit prices, volume discounts (if any), data extraction etc.)
- Service management details
- Service constraints (e.g. maintenance windows, level of customisation permitted, schedule for deprecation of functionality/features etc.)
- Service Levels (e.g. performance, availability, support hours, severity definitions etc.)
- Financial recompense model for not meeting service levels
- Ordering and invoicing process
- Termination terms
- By consumers (i.e. consumption)
- By the Supplier (removal of the G-Cloud Service)
- Data restoration / service migration
- Consumer responsibilities
- Technical requirements (service dependencies and detailed technical interfaces, e.g. client side requirements, bandwidth/latency requirements etc.)
- Details of any trial service available.
Suppliers will provide a “simple” and “quick” exit process to enable consumers to move to a different supplier for each of their G-Cloud Services and/or retrieve their data. Suppliers will commit to providing details of this, clearly and unambiguously in the Service Definition for each service. This will include, but not be limited to:
- The data standards that will be in use (within the service).
- A commitment to returning all consumer generated data (e.g. content, metadata, structure, configuration etc.) and a list of the data that will be available for extraction. Where there is a risk of confusion, data that will not be available for later extraction will also be published.
- The formats/standards into which data will be able to be extracted and preferably a list other common services/technologies to which an export/import mechanism is available.
- A price for the extraction of consumer generated data (or the migration to another service provider’s service).
- Confirmation that the Supplier will purge and destroy (as defined in security accreditation for different ILs) consumer data from any computers, storage devices and storage media that are to be retained by the Supplier after the end of the subscription period and the subsequent extraction of consumer data (if requested by the consumer).
Data storage and processing locations
All servers/storage will be allocated a ‘locale’. Each locale is a physically separate set of infrastructure, such that a failure in one locale will not affect another locale, nor can any information pass from one locale to another (without the customer choosing to do so). Any one particular data-centre location will contain at least one locale, but is likely to have more. Each locale will have a security classification (i.e. security impact level) identified.
Public and private cloud services in a UK government context:
G-Cloud phase 2 definitions:
Public Cloud means Utility Computing that is available to individuals, public and private sector organisations. Public Cloud is often non-geographically specific and can be accessed wherever there is an Internet connection.
Private Cloud means a Utility Computing infrastructure exclusively for the use of one organisation or community.
Hybrid Cloud means a combination of Public and Private Clouds, both remaining separate entities, but with Workload able to migrate between them.
In addition to these three G-Cloud deployments, the US National Institute of Standards and technology (NIST) defines another cloud deployment model: Community cloud#. In UK government terms, private and community cloud deployment models refer to the same thing as the G-Cloud programme founding principles dictate that the Public Sector should be treated as one organisation for cloud services. In other words, this means that there will be only one private cloud (possibly per IL) that is able to be accessed by all public sector consumers. The components of this are expected to be delivered by multiple suppliers/organisations, but they must be interconnected and available to all, thus creating a single private cloud.
As laid out in the G-Cloud principles that were defined during phase 2, government should utilise the public cloud deployment model as a default position, utilising private cloud only where essential criteria cannot be met by public cloud delivery model offerings. For example: Information Assurance criteria might currently drive the use of government accredited data centre services and infrastructure for sole use of the public sector where services are processing/storing information at Impact Level 3 and above. However, how our essential criteria are met is expected to evolve as the cloud market innovates and matures, possibly reducing our need for private cloud delivery.
IaaS and PaaS definitions – NIST defines these as follows:
Cloud Infrastructure as a Service (IaaS).
The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).
Cloud Platform as a Service (PaaS).
The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.
Cloud Software as a Service (SaaS)
The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
Cloud Support Services
In addition to the NIST definitions, the G-Cloud requires support services associated with the different cloud service models. These may include services to transfer data/configuration between G-Cloud providers, management and support of applications (workloads) operating on G-Cloud services, multi supplier service integration services and cloud strategy and implementation services.
Burst versus elastic resources:
It is worth defining another key attribute of IaaS and PaaS, elastic versus burst resources. The G-Cloud Phase 2 Technical Architecture work strand report provides a detailed description and definition of these and should be referred to when reading this document.
Burst: Computing Resources automatically expand and contract in response to changes in application workload.
Elastic: resources must be requested by the user, operator or application. “Elastic” differs from burst in that the application or user must request the additional resources for example via an Application Programmatic Interface (API).
Elastic and burst resources can be described from a Service Unit# view point (i.e. at the level of units which can be purchased and consumed) and also from a technical view point (components within a service unit). For the purposes of the IaaS and PaaS lots, we will be interested in the elasticity and/or burstability of the service both at the level of the units we consume as well as the components thereof. It is fundamental for cloud consumers to understand this aspect of the IaaS and PaaS services being offered.
Suppliers will need to define elasticity versus burstability for services at the level of the chargeable service units offered as well as at the components thereof.
Guaranteed and non guaranteed resources:
Within the elastic and burst resource allocation models (above) the concept of guaranteed and non-guaranteed capacity also exists.
Guaranteed: Additional capacity that is reserved when not in use so that it is always available, as and when needed. It is likely that having this capacity reserved will come at a cost.
Non Guaranteed: Additional capacity is not reserved and thus not guaranteed, it is available for use by all customers on a “first come first served” basis. This is the predominant model used in the multi tenancy public cloud.
Suppliers will need to define the levels of guaranteed and non guaranteed resource capacity included in the services they offer.
Persistence of storage
Storage can be defined as persistent or non persistent when related to a virtual compute resource.
Persistent: Storage is allocated/de-allocated separately to virtual compute instance allocation/de-allocation. As such data stored in persistent storage will still be available after a virtual compute instance to which it is attached is terminated.
Non Persistent: Storage is inherent to the virtual compute instance and thus any data it contains disappears when the virtual compute instance is terminated.
It is important for consumers to understand the persistence model being offered to ensure that data/configuration is not lost when virtual compute resource is terminated and that creation of additional virtual compute instances is as efficient as possible through applying existing configuration.
Suppliers will need to define the persistence or non persistence of the storage units on offer.
Suppliers will provide rapid provisioning and de-provisioning for all G-Cloud services. This will include providing full “self service” capabilities for the ordering and provisioning/de-provisioning and cancelling of G-Cloud services.
Utilisation reporting will be available at both a consumer level as well as at a Crown level (i.e. aggregate of all consumer organisations, broken down by organisation)
“Real-time” online management information including, usage reporting by unit consumed. This will include the information required for consumers and/or the Crown to understand and control consumption e.g. units that are, and are not, being utilised, trends etc.
Suppliers will identify either the TIA-942# or the Uptime Institute# tier of the data centre(s) used to provide the services. Where tier identification is conducted through self-assessment, this must be clearly noted and the supplier must commit to providing visibility of workings if requested.
The EU Code of Conduct for data centre operations (EU CoC)# provides a number of best practices which can be applied to data centres regardless of whether they are already in use, undergoing a retrofit process or still being planned. Suppliers will commit to providing visibility of their application of those best practices.
The supplier will ensure that G-Cloud Services utilise an assured data transport mechanism, appropriate for the Services and BIL being delivered and aligned to HMG PSN strategy. Suppliers will need to ensure that they have received approval (against the relevant requirements/assurance mechanisms) from the network provider for connection of their services (e.g. PSN Compliance).
Use by other suppliers:
Suppliers will commit to make their IaaS/PaaS G-Cloud services available for purchase by third parties who intend to supply services to government so they can offer SaaS or more traditional infrastructure/application delivery (on same or better terms) etc. This is applicable to both the Public and Private cloud delivery models, but probably needs to be emphasised for the Private cloud.
Where defined, suppliers will provide pricing for at least one standardised configuration or to identify a “closest fit” from existing offerings. This is to allow government consumers to compare like for like across suppliers. The current standardised configurations are defined below.
IaaS “standardised” configuration is currently defined as follows:
|Processor||1||Equivalent of the Amazon EC2 Compute Unit (ECU)#||i.e. the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.
In this rapidly evolving market, this appears to be a current defacto standard.
|Storage||160||GigaBytes||Local non persistent block storage|
|Size||1||GigaByte||Persistent object storage|
|Data Durability and Reliability||>1||Copies of data held||In logically and physically separate infrastructure|
Content Delivery Network:
|Data Transfer Out||1||GigaByte||If multiple regions are available, provide closest (geographically) to the UK.|
This should contain notice periods for deprecation of features/functionality, listings of scheduled feature/functionality deprecation and preferably a forward look to new features/functionality or defect resolution that will be introduced.
Managed components = managed server components, available individually or grouped together in a configuration defined by the consumer. Component examples: operating system, database, application server, web server etc.)
Managed application deployment platform = a pre-configured grouping of components that provides a fully managed environment into which application code can be deployed and executed (e.g. springsource, mod_rails, LAMP etc.).