Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Cloud computing services (including public cloud services) hold the promise to deliver a host of benefits to both public sector organizations and enterprises, including reduced Capital Expenditure (CAPEX), improved performance and scalability, and enhanced reliability, as well as a reduced overall Total Cost of Ownership (TCO) for their ICT infrastructures and services. According to the European Union Agency for Network and Information Security (ENISA), public bodies can also benefit from the improvement of citizen interactions with government in respect of reducing information processing time, lowering the cost of government services and enhancing citizen data security [1]. These benefits are particularly important for public bodies, especially for governmental agencies, municipalities and regions; the adoption of public cloud services as part of their numerous e-government interactions is expected to have a significant economic and social impact.

The main objective of STRATEGIC is to boost the adoption of public cloud services by the creation of a STRATEGIC Cloud Orchestrator. The STRATEGIC Cloud Orchestrator builds upon leading edge R&D results (Optimis Toolkit [2], STORK [3] and Semiramis [4] projects), to provide tools and techniques for the interoperable migration and replication of public cloud services across different EU countries and their regions. It has the following principal features:

Cloud Enablement: Cloud enablement is the migration/porting of existing on-line distributed services to the Cloud.

Replication: Replication and re-use of existing services, which have been already successfully deployed across EU countries and regions. This will result in localization and adaptation of the services to different legal, ethical and governance requirements.

Composition of New Value-Added Services: The ability to compose and integrate novel public cloud services based on other existing/legacy services could allow public administrations to streamline their processes thereby reducing overheads, alleviating bureaucracy and overall improve citizens’ benefits and satisfaction [6].

The primary incentive for an organization/public body to adopt a Cloud Orchestrator is to increase automation. The need to orchestrate really becomes clear as when using cloud environments as the automation of storage, network, performance and provisioning are in most cases handled by miscellaneous solutions that have been added incrementally over time. Even for organizations that take a transformational approach, jumping to an advanced cloud to optimize their data centers, the management of heterogeneous environments with disparate systems can be a challenge not simply addressed by automation alone [5].

In this paper, a summary of the identified user requirements for a Cloud Orchestrator are provided, STRATEGIC Cloud Orchestrator is presented in terms of technical approach and value proposition offered. Furthermore, the pilot scenarios of the three different European Municipalities (London Borough of Camden-UK, Genoa-IT and Stari Grad-SR) that will evaluate the STRATEGIC Cloud Orchestrator are depicted.

2 STRATEGIC Cloud Orchestrator

2.1 Requirements Identification

The methodology for requirements identification comprised two main axes: a questionnaire supported by selected interviews to get input from a diverse set of stakeholders, including both cloud users and providers and analysis of pilot Municipalities applications’ requirements. The requirements of the target communities were identified after analyzing a diverse set of public and private sector organizations. Public sector bodies covered included central government agencies, and municipalities and other regional or local governments, while the private sector bodies covered included cloud application developers, cloud solution providers, cloud services providers, cloud solution integrators, Independent Software Vendors (ISVs) and more. A total of 117 questionnaire responses were received and analysed [7].

Regarding users who want to adopt cloud services, the most important requirements that were considered as functional, identified from the questionnaire analyses are:

  • Security and privacy.

  • High Availability.

  • Interoperability, portability.

In the same time the requirements of lowering costs and having good performance have been identified, but were considered non-functional.

In addition, specific technical requirements were raised after analyzing 11 applications that are operated by the three large European Municipalities within the STRATEGIC project. These will now be described.

Common Application Packaging Format: This will be expressive enough to cover many aspects of the application lifecycle. The challenges here are many, since the notion of cloud enabling an application entails many difficulties. Applications may be monolithic, or multi-tier with several interdependencies between them. Furthermore, applications may have external dependencies at the service-level, at the OS-level or even at hardware-level. In addition, a proper application-packaging should take under consideration interoperability and “docking points” between packages. Beyond dependency-management, a packaging format should take under consideration the notion of application and configuration and application scalability.

Configuration Management: This deals with post-installation configuration management and covers many issues such as the setup of encryption channels, the configuration of logging handlers, the installation and configuration of security management services etc. in a multi-cloud context.

Interoperability at the Hypervisor Level: A critical requirement is the avoidance of vendor lock-in at the hypervisor level. Many mature hypervisors (KVM, ESXI etc.) are already able to process VMs that comply to specific formats. However these hypervisors expose their functionality with different API; therefore any Orchestrator should be able to use an abstraction layer on-top of these diverse APIs.

Interoperability on Monitoring: Additionally, a de facto need of any orchestrator is for interoperability with monitoring platforms. Indeed, most of the core entities that are deployed in a Cloud Environment can be “patched” in order to expose performance measurements on many levels (application-level, VM-level). This exposed information can be used for anomaly detection, deployment optimization or even SLA enforcement.

2.2 STRATEGIC Cloud Orchestrator Architecture

Taking under consideration the requirements identified for the creation of the Cloud Orchestrator, a modular high-level architecture has been defined (Fig. 1).

Fig. 1.
figure 1

STRATEGIC cloud orchestrator high level architecture components

Full size image

The Packaged-Applications Repository contains all applications that can be instantiated in an Infrastructure as a Service (IaaS) environment. The critical aspect regarding the repository is the formulation of an expressive enough application-packaging schema. This repository can be used as the basis of a STRATEGIC marketplace. A separate OS Virtual Machines (VM) Template Repository contains the available Operating Systems that can be instantiated by various IaaS environments.

The Credential Management Component is responsible for persistently storing the credentials of an end-user for each IaaS provider. The Application Instantiation Workflow coordinates the deployment of an Application to an IaaS provider. This implies the selection of the proper host-OS (based on the application packaging information), the target-IaaS and the initialization of the configuration-logic that is dependent to the application. The instantiation process combines user-oriented and system-imposed information that is required in order for a successful deployment to be performed.

One of the most crucial components is the Configuration Recipes Repository that contains the available configuration templates that can be applied after an Application instantiation. A configuration template is valuable only in the context of the adoption of a Configuration Management Framework. Therefore, although a Configuration Server is not an organic part of the Orchestrator, it constitutes a critical point since it assures that running instances maintain during runtime of a proper configuration. Beyond that, the Configuration Framework acts as a single point of reference for any functionality that has to be horizontally integrated. Indicative functionalities that are subjected to horizontal integration are Monitoring and Security.

Finally, the Governance Component is responsible for interacting with several underlying IaaS providers to start, stop, pause or delete workloads. This has to rely on an abstraction layer between the Orchestrator and the various Hypervisors. Since the risk of vendor-lock-in is high, the exploitation of Open Cloud Computing Interface (OCCI) interfaces is imperative [8]. OCCI is a set of specifications delivered through the Open Grid Forum for cloud computing service providers that provides is a boundary API that acts as a service front-end to an IaaS provider’s internal infrastructure management framework [9].

2.3 STRATEGIC Workload Metadata Model

Workloads are a key concept and capability in the STRATEGIC Cloud Orchestrator, and are designed to make it possible to manage not just simple (single server) apps, but also much more complex multi-tier applications, as found in the enterprise or distributed applications consisting of many distinct server elements.

The STRATEGIC Workload Metadata Model has been created in order to capture the semantics of any possible workload. The metadata model has several sections. The first section covers basic details about the <Name>, <Version>, <License> and <Category> of the application. These elements of the schema are indexable - instances of the model will be aggregated in a central repository in order for a customer (public body) to be able to search and deploy them.

The next section is a group of <Informational> elements. These elements are used for guiding the end-user through installation and support actions. Moreover, the <SupportedOS> element is intended to capture the compatible OS that can be used for installation. Additionally, the <DeployMethod> element is used to identify the target Cloud of the installation.

One of the most crucial parts is the <ConfigurationParameters> section where the entire configuration layer of the application is exposed and initialized. In parallel, the <DeploymentDescriptor> is used to capture the Installation scripts that are required in order to perform the systemic installation.

Finally, the <ServerConfiguration> element is used to model the post-installation part. The Puppet Framework has been used in order to automate the DevOps tasks. Puppet uses <Recipes> as the basic notion of orchestration-bundle. The Workload Metadata Model contains placeholders for Recipes [10].

The XSD schema is provided in Fig. (2).

Fig. 2.
figure 2

Workload metadata model

Full size image

3 STRATEGIC Pilot Scenarios Overview

STRATEGIC as a project has the vision to deliver the necessary cloud-enabled infrastructure, associated tools and services to governmental bodies that will let them migrate existing public services to the cloud and easily extend their portfolio of services offered to the public. To achieve this vision, three large European Municipalities (London Borough of Camden, City of Genoa and Municipality of Stari Grad) are contributing several services, and also providing realistic use cases for validation of STRATEGIC Cloud Orchestrator.

Table 1 provides a summary of the application and the expected usage of the STRATEGIC cloud orchestrator for each scenario.

Table 1. Usage of STRATEGIC cloud orchestrator from the applications of pilot use cases.
Full size table

4 STRATEGIC Cloud Orchestrator Value Proposition

The primary incentive for an organization/public body to adopt the STRATEGIC Cloud Orchestrator is to increase automation. The need to orchestrate really becomes clear when various aspects of cloud management are brought together. The value of adopting an orchestrator derives from the convergence of multiple hypervisors, the need for efficient resource usage, availability, scalability, performance and more. Through the STRATEGIC Marketplace, the pieces are woven together and can be managed more effectively to ensure smooth and rapid service delivery - and delivered in a user-friendly catalogue of services accessible through a single pane. In essence, STRATEGIC orchestration implies simultaneous speed of automation, ease of integration and clear adoption of best practices.

In addition to rapid service delivery, adoption of STRATEGIC Cloud Orchestrator and Marketplace can deliver significant cost savings by eliminating manual intervention and management of varied IT resources or services. Specific benefits include:

  • Integration of cloud capabilities across heterogeneous environments and infrastructures to simplify, automate and optimize service deployment.

  • Self-service portal for selection of cloud services, including storage and networking, from a predefined menu of offerings.

  • Reduced need for intervention to allow lower ratio of administrators to physical and virtual servers.

  • Automated high-scale provisioning and de-provisioning of resources with policy-based tools to manage virtual machine sprawl by reclaiming resources automatically.

  • Ability to integrate workflows and approval chains across technology silos to improve collaboration and reduce delays.

  • Real-time monitoring of physical and virtual cloud resources, as well as usage and accounting chargeback capabilities to track and optimize system usage.

  • Pre-packaged automation templates and workflows for most common resource types to ease adoption of best practices and minimize transition time.

  • Ability to create cross-Authentication applications and share them in a re-usable manner through an app-store.

In short, many of the capabilities that we associate with cloud computing are in essence elements of orchestration. Using the STRATEGIC cloud orchestrator, public bodies can manage their cloud workloads through a single interface, providing greater efficiency, control and scalability. As cloud environments become more complex and organizations seek greater benefit from their computing resources, the need for sophisticated management solutions that can orchestrate across the entire environment will become ever clearer.

5 Conclusion

The rationale of this paper is to provide an overview of STATEGIC Cloud Orchestrator. For this reason a brief description of STRATEGIC project main goals and the identified requirements and desirable features of a Cloud Orchestrator are provided. For the conception of STRATEGIC Cloud Orchestrator, the high level architecture and component overview has been briefly described, along with the proposed Workload Metadata Model. Finally the pilot use cases overview and the value proposition of the STRATEGIC Cloud Orchestrator are provided.